gitlab scraper: download in toml and text format

2920 files changed, 84688 insertions, 0 deletions

diff --git a/gitlab/issues_text/target_alpha/host_missing/accel_TCG/2569 b/gitlab/issues_text/target_alpha/host_missing/accel_TCG/2569
new file mode 100644
index 00000000..6c6698a0
--- /dev/null
+++ b/gitlab/issues_text/target_alpha/host_missing/accel_TCG/2569
@@ -0,0 +1,5 @@
+The alpha target doesn't support tcg plugin register tracking due to missing XML
+Description of problem:
+There is no register tracking because we build our register list based on XML and there was no XML for alpha because its so old. We could synthesise one to cover the register to fix this.
+Steps to reproduce:
+1. ./qemu-alpha -d plugin -plugin ./contrib/plugins/libexeclog.so,reg=\* ./tests/tcg/alpha-linux-user/hello-alpha
diff --git a/gitlab/issues_text/target_alpha/host_missing/accel_TCG/438 b/gitlab/issues_text/target_alpha/host_missing/accel_TCG/438
new file mode 100644
index 00000000..3538f9d3
--- /dev/null
+++ b/gitlab/issues_text/target_alpha/host_missing/accel_TCG/438
@@ -0,0 +1 @@
+[alpha] FEN bit not honored in system mode
diff --git a/gitlab/issues_text/target_alpha/host_missing/accel_TCG/494 b/gitlab/issues_text/target_alpha/host_missing/accel_TCG/494
new file mode 100644
index 00000000..20eca227
--- /dev/null
+++ b/gitlab/issues_text/target_alpha/host_missing/accel_TCG/494
@@ -0,0 +1 @@
+cmake crashes on qemu-alpha-user with Illegal Instruction
diff --git a/gitlab/issues_text/target_alpha/host_missing/accel_missing/1456 b/gitlab/issues_text/target_alpha/host_missing/accel_missing/1456
new file mode 100644
index 00000000..2ef7fb79
--- /dev/null
+++ b/gitlab/issues_text/target_alpha/host_missing/accel_missing/1456
@@ -0,0 +1,11 @@
+qemu-system-alpha crashes during migration
+Description of problem:
+QEMU crashes (aborts) when trying to migrate with qemu-system-alpha.
+
+```
+qemu-system-alpha: migration/ram.c:874: pss_find_next_dirty: Assertion `pss->host_page_end' failed.
+```
+Steps to reproduce:
+1. Run `./qemu-system-alpha -incoming tcp:0:1234` in one terminal
+2. Run `./qemu-system-alpha -monitor stdio` in another terminal
+3. Type `migrate tcp:0:1234` in the HMP monitor
diff --git a/gitlab/issues_text/target_alpha/host_missing/accel_missing/577 b/gitlab/issues_text/target_alpha/host_missing/accel_missing/577
new file mode 100644
index 00000000..ba7c5e3c
--- /dev/null
+++ b/gitlab/issues_text/target_alpha/host_missing/accel_missing/577
@@ -0,0 +1,25 @@
+getdtablesize() returns wrong value in qemu user mode on Linux/alpha
+Description of problem:
+The `getdtablesize()` function returns a value that is too large. Namely, `getdtablesize() - 1` ought to be a valid file descriptor, but is not.
+Steps to reproduce:
+[foo.c](/uploads/7a9e99d3811fe4a7eef183ed98c966a4/foo.c)
+
+1.
+```
+# apt install g++-10-alpha-linux-gnu
+```
+2.
+```
+$ alpha-linux-gnu-gcc-10 -Wall -static foo.c
+```
+[a.out](/uploads/4fffa6dd2332885f51e4030dcbe25644/a.out)
+
+3. Transfer the a.out file to a Linux/alpha machine; execute it there. The return code is 0.
+4.
+```
+$ QEMU_LD_PREFIX=/usr/alpha-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-alpha ./a.out ; echo $?
+```
+Expected: `0`
+Actual: `1`
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host:32bit/accel_TCG/2034 b/gitlab/issues_text/target_arm/host:32bit/accel_TCG/2034
new file mode 100644
index 00000000..ac42afd5
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host:32bit/accel_TCG/2034
@@ -0,0 +1,8 @@
+ERROR:../accel/tcg/cpu-exec-common.c:56:cpu_loop_exit_atomic: assertion failed: (!cpu_in_serial_context(cpu))
+Description of problem:
+```
+cat boot.log
+aarch64>**
+aarch64>ERROR:../accel/tcg/cpu-exec-common.c:56:cpu_loop_exit_atomic: assertion failed: (!cpu_in_serial_context(cpu))
+aarch64>Bail out! ERROR:../accel/tcg/cpu-exec-common.c:56:cpu_loop_exit_atomic: assertion failed: (!cpu_in_serial_context(cpu))
+```
diff --git a/gitlab/issues_text/target_arm/host_aarch64/accel_HVF/2713 b/gitlab/issues_text/target_arm/host_aarch64/accel_HVF/2713
new file mode 100644
index 00000000..120b4898
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_aarch64/accel_HVF/2713
@@ -0,0 +1,13 @@
+Addressing Limitations with 64GB RAM on virt-9.2 Machine Type in QEMU 9.1.93
+Description of problem:
+When attempting to run a VM with 64GB of RAM using the `virt-9.2` machine type, QEMU encounters an error related to addressing limitations. It appears that the memory configuration exceeds the 32-bit addressing limit.
+
+Error output:
+**qemu-system-aarch64: Addressing limited to 32 bits, but memory exceeds it by 65498251264 bytes**
+Steps to reproduce:
+1. Build QEMU from source on macOS (M2 MacBook, arm64).
+2. Run the command with the `virt-9.2` machine type and 64GB of RAM.
+Additional information:
+- Changes in [UTM app](https://github.com/utmapp/UTM/releases) for release v4.6.2 - (macOS) Support > 32GiB RAM configurations in QEMU ([#5537](https://github.com/utmapp/UTM/issues/5537))
+- Although the site advertises release of qemu-9.2.0-rc3, the brew install doesn't install the latest version yet.
+- The QEMU build environment includes dependencies installed via Homebrew: libffi, gettext, glib, pkg-config, pixman, ninja, meson, sdl2, gtk+3, gnu-tar.
diff --git a/gitlab/issues_text/target_arm/host_arm/accel_HVF/2072 b/gitlab/issues_text/target_arm/host_arm/accel_HVF/2072
new file mode 100644
index 00000000..b53a5b46
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_arm/accel_HVF/2072
@@ -0,0 +1 @@
+Regression in 8.2: Synchronous Exception when running a VM on AArch64
diff --git a/gitlab/issues_text/target_arm/host_arm/accel_HVF/2312 b/gitlab/issues_text/target_arm/host_arm/accel_HVF/2312
new file mode 100644
index 00000000..a61be44e
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_arm/accel_HVF/2312
@@ -0,0 +1,44 @@
+hvf_vcpu_exec isv assert with qemu-xhci device
+Description of problem:
+Using the qemu-xhci device with HVF on darwin-aarch64 causes [this assert](https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/hvf/hvf.c#L1920) to fire.
+
+```
+travis@gmachine vms % cat launch.sh
+#!/usr/bin/env bash
+
+~/sources/nixpkgs/result-qemu/bin/qemu-system-aarch64 \
+    -nographic \
+    -machine virt \
+    -accel hvf \
+    -cpu host \
+    -m 16M \
+    -device qemu-xhci \
+    -bios ~/sources/nixpkgs/result-uboot-bin/u-boot.bin
+travis@gmachine vms % ./launch.sh
+
+
+U-Boot 2024.04 (Apr 02 2024 - 10:58:58 +0000)
+
+DRAM:  16 MiB (effective 16 EiB)
+Assertion failed: (isv), function hvf_vcpu_exec, file ../target/arm/hvf/hvf.c, line 1920.
+./launch.sh: line 10: 22295 Abort trap: 6           ~/sources/nixpkgs/result-qemu/bin/qemu-system-aarch64 -nographic -machine virt -accel hvf -cpu host -m 16M -device qemu-xhci -bios ~/sources/nixpkgs/result-uboot-bin/u-boot.bin
+```
+
+This is NixOS' build of u-boot 2024.04. This is also Nixpkgs' build of qemu-9.0.0; by default it contains some patches, but if I remove those and build with the unmodified release tarball there's no change in behavior. Naturally this doesn't happen with TCG and I haven't found any other (non-USB) device to cause this issue.
+Steps to reproduce:
+On a darwin-aarch64 machine with git and nix setup (8.2.2 is latest in Nixpkgs head, the same problem occurs with 9.0.0):
+
+```
+% git clone https://github.com/nixos/nixpkgs
+% cd ./nixpkgs
+% $(nix-build -A qemu)/bin/qemu-system-aarch64 -nographic -machine virt -accel hvf -cpu host -m 16M -device qemu-xhci -bios $(nix-build -E 'with import ./default.nix {system = "aarch64-linux";}; ubootQemuAarch64')/u-boot.bin
+
+
+U-Boot 2024.04 (Apr 02 2024 - 10:58:58 +0000)
+
+DRAM:  16 MiB (effective 16 EiB)
+Assertion failed: (isv), function hvf_vcpu_exec, file ../target/arm/hvf/hvf.c, line 1915.
+zsh: abort      $(nix-build -A qemu)/bin/qemu-system-aarch64 -nographic -machine virt -accel 
+```
+Additional information:
+I have not yet tried other u-boot binaries. I suppose it could be u-boots fault? Eyeballing hvf.c this seems to be an unhandled case in the MMIO callback? I'm far out of my element so that could be total nonsense.
diff --git a/gitlab/issues_text/target_arm/host_arm/accel_HVF/2893 b/gitlab/issues_text/target_arm/host_arm/accel_HVF/2893
new file mode 100644
index 00000000..01142c3c
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_arm/accel_HVF/2893
@@ -0,0 +1,12 @@
+with m4 mac mini windows 11 arm 64 iso not booting for installation
+Description of problem:
+Trying to run win11 arm 64 version in m4 mac mini and the ios failed to boot 
+
+i went to the efi shell and tried to boot from there and it just hangs no problem reported 
+
+when i attach the serial to stdio i get the error convertprogress failed to find range errors
+Steps to reproduce:
+1. In m4 mac mini download win11 arm 64 iso from microsoft site
+2. run the above mentioned command and you will see that it does not boot
+
+/label ~"kind::Bug"
diff --git a/gitlab/issues_text/target_arm/host_arm/accel_HVF/2913 b/gitlab/issues_text/target_arm/host_arm/accel_HVF/2913
new file mode 100644
index 00000000..d8584d9f
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_arm/accel_HVF/2913
@@ -0,0 +1 @@
+vmapple machine unusable with macOS 15.4
diff --git a/gitlab/issues_text/target_arm/host_arm/accel_KVM/2551 b/gitlab/issues_text/target_arm/host_arm/accel_KVM/2551
new file mode 100644
index 00000000..3417cba0
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_arm/accel_KVM/2551
@@ -0,0 +1,13 @@
+RTC time could run slow 3s than host time when clock=vm & base=UTC
+Description of problem:
+When start qemu with `-rtc base=utc,clock=vm`, sometime guest time can slower 3s than host. There's no problem (also didn't be noticed) as we often start ntp service, who will adjust our system time. But let's talk about if we havn't enable NTP service(for example system just booted)
+
+After inspect into the code, i found that there are two problem we should think about:
+#
+Steps to reproduce:
+1. start vm with `-rtc base=utc,clock=vm`
+2. disable NTP (OS specific)`systemctl disable --now ntpd;systemctl disable --now ntpdate`
+3. reboot in the guest
+4. after guest started, compare guest time with host time(at the same time) `date +'%F %T.%3N'`
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_arm/accel_TCG/1616 b/gitlab/issues_text/target_arm/host_arm/accel_TCG/1616
new file mode 100644
index 00000000..be2ac1ed
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_arm/accel_TCG/1616
@@ -0,0 +1 @@
+convd on arm tcg test fails on arm64 (Apple M1)
diff --git a/gitlab/issues_text/target_arm/host_arm/accel_Xen/2173 b/gitlab/issues_text/target_arm/host_arm/accel_Xen/2173
new file mode 100644
index 00000000..d9aa4973
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_arm/accel_Xen/2173
@@ -0,0 +1 @@
+Disable CPU dirty region tracking on Xen + Arm64 where xen migration is not supported.
diff --git a/gitlab/issues_text/target_arm/host_arm/accel_missing/1167 b/gitlab/issues_text/target_arm/host_arm/accel_missing/1167
new file mode 100644
index 00000000..abe8d86b
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_arm/accel_missing/1167
@@ -0,0 +1 @@
+Does qemu-system-aarch64 support hyper-v elightenment feature for windows for arm guest?
diff --git a/gitlab/issues_text/target_arm/host_arm/accel_missing/1776 b/gitlab/issues_text/target_arm/host_arm/accel_missing/1776
new file mode 100644
index 00000000..35d97eb4
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_arm/accel_missing/1776
@@ -0,0 +1 @@
+qemu-armel SEGFAULTs when trying to map a commpage on armel
diff --git a/gitlab/issues_text/target_arm/host_arm/accel_missing/1857 b/gitlab/issues_text/target_arm/host_arm/accel_missing/1857
new file mode 100644
index 00000000..eca6855c
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_arm/accel_missing/1857
@@ -0,0 +1,52 @@
+Major qemu-aarch64 performance slowdown since commit 59b6b42cd3
+Description of problem:
+I have observed a major performance slowdown between qemu 8.0.0 and 8.1.0:
+
+
+qemu 8.0.0: 0.8s
+
+qemu 8.1.0: 6.8s
+
+
+After bisecting the commits between 8.0.0 and 8.1.0, the offending commit is 59b6b42cd3:
+
+
+commit 59b6b42cd3446862567637f3a7ab31d69c9bef51
+Author: Richard Henderson <richard.henderson@linaro.org>
+Date:   Tue Jun 6 10:19:39 2023 +0100
+
+    target/arm: Enable FEAT_LSE2 for -cpu max
+
+    Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
+    Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
+    Message-id: 20230530191438.411344-21-richard.henderson@linaro.org
+    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
+
+
+Reverting the commit in latest master fixes the problem:
+
+qemu 8.0.0: 0.8s
+
+qemu 8.1.0: 6.8s
+
+qemu master + revert 59b6b42cd3: 0.8s
+
+Alternatively, specify `-cpu cortex-a35` to disable LSE2:
+
+`time ./qemu-aarch64 -cpu cortex-a35`: 0.8s
+
+`time ./qemu-aarch64`: 6.77s
+
+The slowdown is also observed when running qemu-aarch64 on aarch64 machine:
+
+`time ./qemu-aarch64 /usr/bin/node -e 1`: 2.91s
+
+`time ./qemu-aarch64 -cpu cortex-a35 /usr/bin/node -e 1`: 1.77s
+
+The slowdown on x86_64 machine is small: 362ms -> 378ms.
+Steps to reproduce:
+1. Run `time ./qemu-aarch64 node-aarch64 -e 1` (node-aarch64 is NodeJS v16 built for AArch64)
+2. Using qemu master, the output says `0.8s`
+3. Using qemu master with commit 59b6b42cd3 reverted, the output says `6.77s`
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_arm/accel_missing/2884 b/gitlab/issues_text/target_arm/host_arm/accel_missing/2884
new file mode 100644
index 00000000..2514e881
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_arm/accel_missing/2884
@@ -0,0 +1,35 @@
+Questions about vfio-pci
+Description of problem:
+When I use VFIO-PCI to pass through an hns3 device and load the driver to the VM to enable the hns3 network port, there is a possibility that the failure occurs.
+Steps to reproduce:
+1. Start the VM and load the hns3 driver.
+2. enable net port
+
+   `ifconfig eth0 10.10.10.10/24 up`
+3. ping host
+
+   `ping 10.10.10.11 -c 3`
+Additional information:
+I have the following findings:
+
+1. The problem can be reproduced in different kernel versions and QEMU versions.
+2. The problem does not recur when the number of vCPUs is 1.
+3. It is irrelevant to the GIC version.
+
+the hns3 relately logic:
+
+![image.png](/uploads/523c6fd8d564d4d48ba5c930fd811478/image.png){width="394" height="285"}
+
+If the VM has two vCPUs, "ifconfig eth0 10.10.10.10/24 up" command performs two sequential enable_irq operations(vector_num=2). The enable_irq will trap into KVM for interrupt configuration and exit to QEMU for PCI device emulation. When emulating interrupt enabling in QEMU, vfio\_\[intx/msi/msix\]\_enable calls vfio_disable_interrupts to disable all interrupts on the vdev.
+
+![image.png](/uploads/e51baf6ee3a533332a3107a133184f11/image.png){width="455" height="266"}
+
+vfio_disable_interrupts in QEMU calls the kernel vfio driver interface vfio_pci_set_irqs_ioctl
+
+![image.png](/uploads/e4534c4e0b7033eb13e2ccfda558f505/image.png){width="404" height="127"}
+
+dump stack as above. and then its_irq_domain_deactivate will call its_send_discard to discard the interrupt on the device.
+
+If an interrupt is handled after the first enable_irq but the second enable_irq discards it, this inconsistency leads to network port enablement failures.
+
+It puzzles me. why does the vfio-pci disable all interrupts of the device before enabling irqs?
diff --git a/gitlab/issues_text/target_arm/host_mips/accel_TCG/496 b/gitlab/issues_text/target_arm/host_mips/accel_TCG/496
new file mode 100644
index 00000000..c302409f
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_mips/accel_TCG/496
@@ -0,0 +1,13 @@
+qemu-system-aarch64: ../accel/tcg/cpu-exec.c:681: cpu_loop_exec_tb: Assertion 'icount_enabled()' failed
+Description of problem:
+When I use qemu-system-aarch64 start a Debian(ARM64) on a mips64el host(ARM64 and X86_64 host don't have this bug), I get a bug as follows:
+
+
+`qemu-system-aarch64: ../accel/tcg/cpu-exec.c:681: cpu_loop_exec_tb: Assertion 'icount_enabled()' failed`
+
+
+The crash code is in ../accel/tcg/cpu-exec.c:681, the code in qemu v5.2.0 as follows:
+
+
+```
+#
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_HVF/1029 b/gitlab/issues_text/target_arm/host_missing/accel_HVF/1029
new file mode 100644
index 00000000..f99bc794
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_HVF/1029
@@ -0,0 +1,53 @@
+Unable to build qemu on macOS Monterey, M1 Pro
+Description of problem:
+qemu doesn't build, producing the following error:
+```
+$ make
+# snip
+FAILED: libqemu-aarch64-softmmu.fa.p/target_arm_hvf_hvf.c.o 
+cc -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -I../dtc/libfdt -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/opt/homebrew/Cellar/pixman/0.40.0/include/pixman-1 -I/opt/homebrew/Cellar/glib/2.72.1/include -I/opt/homebrew/Cellar/glib/2.72.1/include/glib-2.0 -I/opt/homebrew/Cellar/glib/2.72.1/lib/glib-2.0/include -I/opt/homebrew/opt/gettext/include -I/opt/homebrew/Cellar/pcre/8.45/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -iquote . -iquote /Users/duncanbayne/code/qemu -iquote /Users/duncanbayne/code/qemu/include -iquote /Users/duncanbayne/code/qemu/disas/libvixl -iquote /Users/duncanbayne/code/qemu/tcg/aarch64 -DOS_OBJECT_USE_OBJC=0 -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-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/target_arm_hvf_hvf.c.o -MF libqemu-aarch64-softmmu.fa.p/target_arm_hvf_hvf.c.o.d -o libqemu-aarch64-softmmu.fa.p/target_arm_hvf_hvf.c.o -c ../target/arm/hvf/hvf.c
+../target/arm/hvf/hvf.c:586:15: error: unknown type name 'ARMCPRegInfo'; did you mean 'ARMCPUInfo'?
+        const ARMCPRegInfo *ri;
+              ^~~~~~~~~~~~
+              ARMCPUInfo
+../target/arm/cpu-qom.h:38:3: note: 'ARMCPUInfo' declared here
+} ARMCPUInfo;
+  ^
+../target/arm/hvf/hvf.c:589:14: error: implicit declaration of function 'get_arm_cp_reginfo' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
+        ri = get_arm_cp_reginfo(arm_cpu->cp_regs, key);
+             ^
+../target/arm/hvf/hvf.c:589:12: warning: incompatible integer to pointer conversion assigning to 'const ARMCPUInfo *' (aka 'const struct ARMCPUInfo *') from 'int' [-Wint-conversion]
+        ri = get_arm_cp_reginfo(arm_cpu->cp_regs, key);
+           ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../target/arm/hvf/hvf.c:591:26: error: no member named 'type' in 'struct ARMCPUInfo'
+            assert(!(ri->type & ARM_CP_NO_RAW));
+                     ~~  ^
+/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/assert.h:99:25: note: expanded from macro 'assert'
+    (__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __ASSERT_FILE_NAME, __LINE__, #e) : (void)0)
+                        ^
+../target/arm/hvf/hvf.c:591:33: error: use of undeclared identifier 'ARM_CP_NO_RAW'
+            assert(!(ri->type & ARM_CP_NO_RAW));
+                                ^
+1 warning and 4 errors generated.
+ninja: build stopped: subcommand failed.
+make[1]: *** [run-ninja] Error 1
+make: *** [all] Error 2
+```
+Steps to reproduce:
+```
+git clone https://gitlab.com/qemu-project/qemu.git
+cd qemu
+./configure
+make
+```
+Additional information:
+```
+$ cc --version
+Apple clang version 13.1.6 (clang-1316.0.21.2.5)
+Target: arm64-apple-darwin21.4.0
+Thread model: posix
+InstalledDir: /Library/Developer/CommandLineTools/usr/bin
+
+$ ninja --version
+1.10.2.git.kitware.jobserver-1
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_HVF/1073 b/gitlab/issues_text/target_arm/host_missing/accel_HVF/1073
new file mode 100644
index 00000000..08ddc332
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_HVF/1073
@@ -0,0 +1,29 @@
+SIGABRT with -M raspi3b,accel=hvf on macOS
+Description of problem:
+There is a `SIGUSR2` or `SIGUSR1` raised which causes QEMU to abort:
+```
+(lldb) bt
+* thread #3, stop reason = signal SIGUSR2
+  * frame #0: 0x0000000184c384a4 libsystem_kernel.dylib`__sigsuspend + 8
+    frame #1: 0x0000000100b7ff34 qemu-system-aarch64`qemu_coroutine_new at coroutine-sigaltstack.c:221:9
+    frame #2: 0x0000000100b91f0c qemu-system-aarch64`qemu_coroutine_create(entry=(qemu-system-aarch64`monitor_qmp_dispatcher_co at qmp.c:211), opaque=0x0000000000000000) at qemu-coroutine.c:90:14
+    frame #3: 0x0000000100a833d8 qemu-system-aarch64`monitor_init_globals_core at monitor.c:707:25
+```
+
+I tried skipping over it with `lldb`:
+```
+(lldb) b main
+(lldb) r
+(lldb) process handle SIGUSR1 -s false -p true
+(lldb) process handle SIGUSR2 -s false -p true
+(lldb) c
+qemu-system-aarch64: Unknown Error
+```
+
+I investigated the Unknown Error and and it's actually `HV_ILLEGAL_GUEST_STATE` which is unhandled in the `assert_hvf_ok` function. From here the VM will fail.
+Steps to reproduce:
+1. Get a fake disk. Or create a fake one with: `qemu-img create -f qcow2 zero.qcow2 2G`
+2. Run QEMU with the HVF accelerator: `qemu-system-aarch64 -M raspi3b,accel=hvf -drive id=card0,if=none,format=qcow2,index=0,file=./zero.qcow2 -device sd-card,drive=card0 -serial stdio
+`
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_HVF/1990 b/gitlab/issues_text/target_arm/host_missing/accel_HVF/1990
new file mode 100644
index 00000000..c2e4e146
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_HVF/1990
@@ -0,0 +1,19 @@
+qemu ASSERT [ArmCpuDxe] DefaultExceptionHandler.c:333 on Mac M3
+Description of problem:
+I am installing Podman 4.7.2 and `podman-machine` uses `qemu-system-aarch64` to boot up an embedded coreos image to run containers.
+With the new Apple M3 hardware, I am experiencing a QEMU assertion failure almost all of the time.
+
+![image](/uploads/372b9ae2dfaa2d70e704a0f30b1964f1/image.png)
+
+`ASSERT [ArmCpuDxe] /home/kraxel/projects/qemu/roms/edk2/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(333): ((BOOLEAN)(0==1))`
+
+I have been unable to get the full crash output - I didn't figure out how to resize the console any larger, and I tried a couple different ways to hook the console up to qemu stdout without any success. (since the kernel command line parameters are not passed in, but instead the image uses a bootloader)
+
+I believe this is the same issue I experience, but with a better capture of the crash:
+https://github.com/lima-vm/lima/issues/1996
+Steps to reproduce:
+1. Use Mac M3 (Max in my case)
+2. Install Podman
+3. Run `podman-machine init`
+4. Run `podman-machine start --log-level=debug`
+5. Crash (almost certainly)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_HVF/2665 b/gitlab/issues_text/target_arm/host_missing/accel_HVF/2665
new file mode 100644
index 00000000..1c6a460f
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_HVF/2665
@@ -0,0 +1,11 @@
+target/arm: cannot boot when CPU supports SME
+Description of problem:
+On macOS 15.2 beta, Apple's Hypervisor.framework exposes the SME feat flag to QEMU. As a result, in `arm_cpu_sme_finalize`, `cpu_isar_feature(aa64_sme, cpu)` returns true and the program will always exit with the following:
+
+```
+qemu-aarch64-softmmu: cannot disable sme4224
+All SME vector lengths are disabled.
+With SME enabled, at least one vector length must be enabled.
+```
+
+This is because `vq_supported` and `vq_init` are both 0 as they are not initialized anywhere. It seems that in the original commit e74c097638d38b46d9c68f11565432034afc0ad0 the only place `cpu->sme_vq.supported` is initialized is with `aarch64_max_initfn` when KVM and HVF are not used as the backend.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_HVF/743 b/gitlab/issues_text/target_arm/host_missing/accel_HVF/743
new file mode 100644
index 00000000..e3a616c2
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_HVF/743
@@ -0,0 +1,11 @@
+aarch64: Number of SMP CPUS exceeds max CPUs supported by machine (10 > 8) for M1 Pro/Max
+Description of problem:
+Trying to launch QEMU with more than 8 cores gives the following error:
+
+`qemu-system-aarch64: Number of SMP CPUs requested (10) exceeds max CPUs supported by machine 'mach-virt' (8)`
+
+Apple M1 Pro can have up to 10 cores while M1 Max only has 10 cores.
+Steps to reproduce:
+1. Install QEMU via homebrew (or MacPorts or from source)
+2. Run `qemu-system-aarch64 -machine virt,highmem=off -accel hvf -cpu cortex-a72 -smp 10`
+3. Get error, QEMU doesn't start
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_HVF/747 b/gitlab/issues_text/target_arm/host_missing/accel_HVF/747
new file mode 100644
index 00000000..e05a09f4
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_HVF/747
@@ -0,0 +1,30 @@
+hvf-accelerated aarch64 hangs when switching to big endian mode
+Description of problem:
+Trying to boot a big endian Linux kernel using the above command line on an M1 Mac Mini just hangs, there is not a single output.  However, by replacing `hvf` with `tcg`, the kernel boots up fine.  The kernel also starts if I use KVM acceleration on a Linux host system.
+Steps to reproduce:
+1. Build a Linux kernel for big endian arm64
+2. Try to boot it with -accel hvf on an M1 Mac
+3. Observe a lot of nothing happening  :-)
+Additional information:
+Sample run, TCG vs HVF
+```
+mikan:/tmp% qemu-system-aarch64 -accel tcg -machine virt,highmem=off -cpu cortex-a72 -nographic -kernel /tmp/vmlinuz-5.10.76-gentoo-r1-arm64.be |& head -16
+[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]
+[    0.000000] Linux version 5.10.76-gentoo-r1-arm64 (root@localhost) (aarch64-unknown-linux-gnu-gcc (Gentoo 11.2.0 p1) 11.2.0, GNU ld (Gentoo 2.37_p1 p0) 2.37) #1 SMP Sun Nov 21 16:30:21 -00 2021
+[    0.000000] Machine model: linux,dummy-virt
+[    0.000000] NUMA: No NUMA configuration found
+[    0.000000] NUMA: Faking a node at [mem 0x0000000040000000-0x0000000047ffffff]
+[    0.000000] NUMA: NODE_DATA [mem 0x47f65300-0x47f76fff]
+[    0.000000] Zone ranges:
+[    0.000000]   DMA      [mem 0x0000000040000000-0x0000000047ffffff]
+[    0.000000]   DMA32    empty
+[    0.000000]   Normal   empty
+[    0.000000] Movable zone start for each node
+[    0.000000] Early memory node ranges
+[    0.000000]   node   0: [mem 0x0000000040000000-0x0000000047ffffff]
+[    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x0000000047ffffff]
+[    0.000000] psci: probing for conduit method from DT.
+[    0.000000] psci: PSCIv0.2 detected in firmware.
+mikan:/tmp% qemu-system-aarch64 -accel hvf -machine virt,highmem=off -cpu cortex-a72 -nographic -kernel /tmp/vmlinuz-5.10.76-gentoo-r1-arm64.be       
+```
+(followed by tumbleweeds)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_HVF/797 b/gitlab/issues_text/target_arm/host_missing/accel_HVF/797
new file mode 100644
index 00000000..4cae7cf8
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_HVF/797
@@ -0,0 +1,9 @@
+ARM64 hvf fails to boot Windows 11 on 6.2.0
+Description of problem:
+On QEMU v6.1.0 with patches from @agraf manually applied, Windows 11 boots fine from the VHDX. Now that the patches have been mainlined, I would expect it to work the same but it gets stuck at EFI (no Windows "spinner").
+Steps to reproduce:
+1. `brew install qemu`
+2. Download Windows 11 VHDX from https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewARM64
+3. Run command from above.
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_HVF/864 b/gitlab/issues_text/target_arm/host_missing/accel_HVF/864
new file mode 100644
index 00000000..f6d8a7df
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_HVF/864
@@ -0,0 +1,15 @@
+HVF virtual counter diverges from CLOCK_VIRTUAL when the host sleeps
+Description of problem:
+HVF's virtual counter diverges from `CLOCK_VIRTUAL` when the host sleeps and causes the inconsistency between Linux's system counter and everything else.
+
+HVF's virtual counter apparently relies on something similar to `mach_absolute_time`, which stops when the host sleeps and resumes after it wakes up. However, `CLOCK_VIRTUAL` is implemented with `mach_continuous_time`, which continues even while the host sleeps. Linux uses the virtual counter as the source of the system counter and sees inconsistencies between the system counter and the other devices.
+Steps to reproduce:
+1. Launch Fedora.
+2. Compare the time shown at the top of the guest display and one at the top of the host display. The difference should be less than 2 minutes.
+3. Let the host sleep for 3 minutes.
+4. Compare the times again. The difference is now greater than 2 minutes.
+Additional information:
+Here are solutions I've came up with so far. There are trade-offs but any of them should be better than the current situation. I'm happy to implement one if the maintainers have decided which one is the best or figure out a superior alternative.
+- Implement `cpus_get_virtual_clock` of `AccelOpsClass` with `mach_absolute_time`. It would make HVF inconsistent with the other accelerators. Linux also expects the virtual clock is "continuous" and it leaves the divergence from the real time.
+- Request XNU `HOST_NOTIFY_CALENDAR_CHANGE` to update the virtual clock with the continuous time. The interface is undocumented.
+- Use `IORegisterForSystemPower` to update the virtual clock with the continuous time. It is undocumented that the interface handles every cases where `mach_absolute_time` and `mach_continuous_time`, but it actually does if I read XNU's source code correctly.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_HVF/949 b/gitlab/issues_text/target_arm/host_missing/accel_HVF/949
new file mode 100644
index 00000000..477d0f72
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_HVF/949
@@ -0,0 +1,314 @@
+M1 MacOS Panic with qemu version 6.2.0
+Description of problem:
+After running the command above, the macbook freeze and reboots, here is the stacktrace:
+```
+panic(cpu 2 caller 0xfffffe001748de90): vm_fault() KERN_FAILURE from guest fault on state 0xfffffe600c57c000 @sleh.c:3091
+Debugger message: panic
+Memory ID: 0x1
+OS release type: User
+OS version: 21D62
+Kernel version: Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_ARM64_T6000
+Fileset Kernelcache UUID: FA4EB485BA9DC1EBAA5D0E80232A48CC
+Kernel UUID: BADF56F4-2876-3FF4-AC12-F25E78B09AA1
+iBoot version: iBoot-7429.81.3
+secure boot?: YES
+Paniclog version: 13
+KernelCache slide: 0x000000000f9e8000
+KernelCache base:  0xfffffe00169ec000
+Kernel slide:      0x000000001021c000
+Kernel text base:  0xfffffe0017220000
+Kernel text exec slide: 0x0000000010304000
+Kernel text exec base:  0xfffffe0017308000
+mach_absolute_time: 0x2c74ea4beb
+Epoch Time:        sec       usec
+  Boot    : 0x62437319 0x0002a603
+  Sleep   : 0x62441e87 0x00018bb3
+  Wake    : 0x62442289 0x00044ebb
+  Calendar: 0x62442c00 0x000ccb26
+
+Zone info:
+Foreign   : 0xfffffe001fb94000 - 0xfffffe001fba8000
+Native    : 0xfffffe10001a8000 - 0xfffffe30001a8000
+Readonly  : 0xfffffe14cce74000 - 0xfffffe1666808000
+Metadata  : 0xfffffe62f056c000 - 0xfffffe62fc4f0000
+Bitmaps   : 0xfffffe62fc4f0000 - 0xfffffe6302084000
+CORE 0 PVH locks held: None
+CORE 1 PVH locks held: None
+CORE 2 PVH locks held: None
+CORE 3 PVH locks held: None
+CORE 4 PVH locks held: None
+CORE 5 PVH locks held: None
+CORE 6 PVH locks held: None
+CORE 7 PVH locks held: None
+CORE 0: PC=0xfffffe001738ef4c, LR=0xfffffe001738ef4c, FP=0xfffffe60ba06bef0
+CORE 1: PC=0xfffffe001738ef4c, LR=0xfffffe001738ef4c, FP=0xfffffe60b7003ef0
+CORE 2 is the one that panicked. Check the full backtrace for details.
+CORE 3: PC=0xfffffe001738ef50, LR=0xfffffe001738ef4c, FP=0xfffffe600c773ef0
+CORE 4: PC=0xfffffe001738ef50, LR=0xfffffe001738ef4c, FP=0xfffffe60a4dabef0
+CORE 5: PC=0xfffffe001738ef50, LR=0xfffffe001738ef4c, FP=0xfffffe600c683ef0
+CORE 6: PC=0xfffffe001738ef50, LR=0xfffffe001738ef4c, FP=0xfffffe60a5553ef0
+CORE 7: PC=0xfffffe001738ef4c, LR=0xfffffe001738ef4c, FP=0xfffffe60b7ae3ef0
+Panicked task 0xfffffe2997ce2d48: 24310 pages, 11 threads: pid 12708: qemu-system-aarc
+Panicked thread: 0xfffffe1ffd861860, backtrace: 0xfffffe600c5c3300, tid: 97347
+		  lr: 0xfffffe001735a4e8  fp: 0xfffffe600c5c3370
+		  lr: 0xfffffe001735a1b8  fp: 0xfffffe600c5c33e0
+		  lr: 0xfffffe001749a2bc  fp: 0xfffffe600c5c3400
+		  lr: 0xfffffe001748c6c8  fp: 0xfffffe600c5c3480
+		  lr: 0xfffffe001748a118  fp: 0xfffffe600c5c3540
+		  lr: 0xfffffe001730f7f8  fp: 0xfffffe600c5c3550
+		  lr: 0xfffffe0017359e2c  fp: 0xfffffe600c5c38f0
+		  lr: 0xfffffe0017359e2c  fp: 0xfffffe600c5c3960
+		  lr: 0xfffffe0017b6d738  fp: 0xfffffe600c5c3980
+		  lr: 0xfffffe001748de90  fp: 0xfffffe600c5c39e0
+		  lr: 0xfffffe001748da14  fp: 0xfffffe600c5c3a50
+		  lr: 0xfffffe001731a828  fp: 0xfffffe600c5c3a60
+		  lr: 0xfffffe00174a222c  fp: 0xfffffe600c5c3e50
+		  lr: 0xfffffe001748a530  fp: 0xfffffe600c5c3f10
+		  lr: 0xfffffe001730f7f8  fp: 0xfffffe600c5c3f20
+
+last started kext at 861542788: com.apple.driver.driverkit.serial	6.0.0 (addr 0xfffffe00170fced0, size 3432)
+loaded kexts:
+com.apple.fileutil	20.036.15
+com.apple.filesystems.autofs	3.0
+com.apple.driver.AppleBiometricServices	1
+com.apple.driver.CoreKDL	1
+com.apple.driver.AppleTopCaseHIDEventDriver	5020.1
+com.apple.driver.DiskImages.ReadWriteDiskImage	493.0.0
+com.apple.driver.DiskImages.UDIFDiskImage	493.0.0
+com.apple.driver.DiskImages.RAMBackingStore	493.0.0
+com.apple.driver.DiskImages.FileBackingStore	493.0.0
+com.apple.driver.SEPHibernation	1
+com.apple.driver.BCMWLANFirmware4387.Hashstore	1
+com.apple.filesystems.apfs	1933.80.3
+com.apple.driver.AppleUSBDeviceNCM	5.0.0
+com.apple.driver.AppleThunderboltIP	4.0.3
+com.apple.driver.AppleFileSystemDriver	3.0.1
+com.apple.nke.l2tp	1.9
+com.apple.filesystems.tmpfs	1
+com.apple.filesystems.lifs	1
+com.apple.IOTextEncryptionFamily	1.0.0
+com.apple.filesystems.hfs.kext	582.60.2
+com.apple.security.BootPolicy	1
+com.apple.BootCache	40
+com.apple.AppleFSCompression.AppleFSCompressionTypeZlib	1.0.0
+com.apple.AppleFSCompression.AppleFSCompressionTypeDataless	1.0.0d1
+com.apple.AppleEmbeddedSimpleSPINORFlasher	1
+com.apple.driver.ApplePMP	1
+com.apple.driver.AppleCS42L84Audio	530.2
+com.apple.driver.AppleSmartIO2	1
+com.apple.driver.AppleSN012776Amp	530.2
+com.apple.driver.AppleT6000SOCTuner	1
+com.apple.driver.AppleT6000CLPCv3	1
+com.apple.driver.AppleSmartBatteryManager	161.0.0
+com.apple.driver.AppleALSColorSensor	1.0.0d1
+com.apple.driver.AppleAOPVoiceTrigger	100.1
+com.apple.driver.ApplePMPFirmware	1
+com.apple.driver.AppleSPMIPMU	1.0.1
+com.apple.driver.AppleM68Buttons	1.0.0d1
+com.apple.driver.AppleSDXC	3.1.1
+com.apple.driver.AppleSamsungSerial	1.0.0d1
+com.apple.driver.AppleSerialShim	1
+com.apple.AGXG13X	188.10
+com.apple.driver.AppleAVD	555
+com.apple.driver.AppleAVE2	530.3.0
+com.apple.driver.AppleJPEGDriver	4.7.9
+com.apple.driver.AppleProResHW	128.2.0
+com.apple.driver.AppleMobileDispT600X-DCP	140.0
+com.apple.driver.usb.AppleSynopsysUSB40XHCI	1
+com.apple.driver.AppleMCDP29XXUpdateSupport	1
+com.apple.driver.AppleDPDisplayTCON	1
+com.apple.driver.AppleEventLogHandler	1
+com.apple.driver.AppleS5L8960XNCO	1
+com.apple.driver.AppleT6000PMGR	1
+com.apple.driver.AppleS8000AES	1
+com.apple.driver.AppleS8000DWI	1.0.0d1
+com.apple.driver.AppleInterruptControllerV2	1.0.0d1
+com.apple.driver.AppleT8110DART	1
+com.apple.driver.AppleBluetoothModule	1
+com.apple.driver.AppleBCMWLANBusInterfacePCIe	1
+com.apple.driver.AppleS5L8920XPWM	1.0.0d1
+com.apple.driver.AudioDMAController-T600x	100.51
+com.apple.driver.AppleT6000DART	1
+com.apple.driver.AppleSPIMC	1
+com.apple.driver.AppleS5L8940XI2C	1.0.0d2
+com.apple.driver.AppleT6000	1
+com.apple.iokit.IOUserEthernet	1.0.1
+com.apple.driver.usb.AppleUSBUserHCI	1
+com.apple.iokit.IOKitRegistryCompatibility	1
+com.apple.iokit.EndpointSecurity	1
+com.apple.driver.AppleDiskImages2	126.60.3
+com.apple.AppleSystemPolicy	2.0.0
+com.apple.nke.applicationfirewall	402
+com.apple.kec.InvalidateHmac	1
+com.apple.kec.AppleEncryptedArchive	1
+com.apple.driver.driverkit.serial	6.0.0
+com.apple.kext.triggers	1.0
+com.apple.iokit.IOAVBFamily	1010.2
+com.apple.plugin.IOgPTPPlugin	1000.11
+com.apple.iokit.IOEthernetAVBController	1.1.0
+com.apple.driver.AppleMesaSEPDriver	100.99
+com.apple.iokit.IOBiometricFamily	1
+com.apple.driver.AppleHIDKeyboard	228
+com.apple.driver.AppleActuatorDriver	5430.21
+com.apple.driver.AppleMultitouchDriver	5430.21
+com.apple.driver.AppleHSBluetoothDriver	5020.1
+com.apple.driver.IOBluetoothHIDDriver	9.0.0
+com.apple.driver.DiskImages.KernelBacked	493.0.0
+com.apple.driver.AppleSEPHDCPManager	1.0.1
+com.apple.driver.AppleTrustedAccessory	1
+com.apple.iokit.AppleSEPGenericTransfer	1
+com.apple.driver.AppleXsanScheme	3
+com.apple.driver.usb.networking	5.0.0
+com.apple.driver.AppleThunderboltUSBDownAdapter	1.0.4
+com.apple.driver.AppleThunderboltPCIDownAdapter	4.1.1
+com.apple.driver.AppleThunderboltDPInAdapter	8.5.1
+com.apple.driver.AppleThunderboltDPAdapterFamily	8.5.1
+com.apple.nke.ppp	1.9
+com.apple.driver.AppleBSDKextStarter	3
+com.apple.filesystems.hfs.encodings.kext	1
+com.apple.driver.AppleConvergedIPCOLYBTControl	1
+com.apple.driver.AppleConvergedPCI	1
+com.apple.driver.AppleBluetoothDebug	1
+com.apple.driver.AppleBTM	1.0.1
+com.apple.driver.AppleHIDTransportSPI	5400.30
+com.apple.driver.AppleHIDTransport	5400.30
+com.apple.driver.AppleInputDeviceSupport	5400.30
+com.apple.driver.AppleDCPDPTXProxy	1.0.0
+com.apple.driver.DCPDPFamilyProxy	1
+com.apple.driver.AppleDiagnosticDataAccessReadOnly	1.0.0
+com.apple.driver.AppleCSEmbeddedAudio	530.2
+com.apple.driver.ApplePassthroughPPM	3.0
+com.apple.driver.AppleAOPAudio	102.2
+com.apple.driver.AppleEmbeddedAudio	530.2
+com.apple.iokit.AppleARMIISAudio	100.1
+com.apple.driver.AppleSPU	1
+com.apple.AGXFirmwareKextG13XRTBuddy	188.10
+com.apple.AGXFirmwareKextRTBuddy64	188.10
+com.apple.driver.AppleStockholmControl	1.0.0
+com.apple.iokit.IONVMeFamily	2.1.0
+com.apple.driver.AppleNANDConfigAccess	1.0.0
+com.apple.driver.AppleDialogPMU	1.0.1
+com.apple.driver.usb.AppleUSBHostPacketFilter	1.0
+com.apple.iokit.IOGPUFamily	35.11
+com.apple.driver.DCPAVFamilyProxy	1
+com.apple.iokit.IOMobileGraphicsFamily-DCP	343.0.0
+com.apple.driver.AppleDCP	1
+com.apple.driver.AppleFirmwareKit	1
+com.apple.iokit.IOMobileGraphicsFamily	343.0.0
+com.apple.driver.AppleSPMI	1.0.1
+com.apple.driver.AppleUSBXDCIARM	1.0
+com.apple.driver.AppleUSBXDCI	1.0
+com.apple.iokit.IOUSBDeviceFamily	2.0.0
+com.apple.driver.usb.AppleSynopsysUSBXHCI	1
+com.apple.driver.usb.AppleUSBXHCI	1.2
+com.apple.driver.AppleEmbeddedUSBHost	1
+com.apple.driver.usb.AppleUSBHub	1.2
+com.apple.driver.usb.AppleUSBHostCompositeDevice	1.2
+com.apple.driver.AppleT6000TypeCPhy	1
+com.apple.driver.AppleT8103TypeCPhy	1
+com.apple.driver.AppleHPM	3.4.4
+com.apple.driver.AppleSART	1
+com.apple.driver.ApplePMGR	1
+com.apple.driver.AppleARMWatchdogTimer	1
+com.apple.driver.AppleDisplayCrossbar	1.0.0
+com.apple.iokit.IODisplayPortFamily	1.0.0
+com.apple.driver.AppleTypeCPhy	1
+com.apple.driver.AppleThunderboltNHI	7.2.8
+com.apple.driver.AppleT6000PCIeC	1
+com.apple.iokit.IOThunderboltFamily	9.3.3
+com.apple.driver.ApplePIODMA	1
+com.apple.driver.AppleT600xPCIe	1
+com.apple.driver.AppleMultiFunctionManager	1
+com.apple.driver.AppleBluetoothDebugService	1
+com.apple.driver.AppleBCMWLANCore	1.0.0
+com.apple.iokit.IO80211Family	1200.12.2b1
+com.apple.driver.IOImageLoader	1.0.0
+com.apple.driver.AppleOLYHAL	1
+com.apple.driver.corecapture	1.0.4
+com.apple.driver.AppleEmbeddedPCIE	1
+com.apple.driver.AppleMCA2-T600x	600.95
+com.apple.driver.AppleEmbeddedAudioLibs	100.9.1
+com.apple.driver.AppleFirmwareUpdateKext	1
+com.apple.driver.AppleH13CameraInterface	4.87.0
+com.apple.driver.AppleH10PearlCameraInterface	17.0.3
+com.apple.driver.AppleGPIOICController	1.0.2
+com.apple.driver.AppleFireStormErrorHandler	1
+com.apple.driver.AppleMobileApNonce	1
+com.apple.iokit.IOTimeSyncFamily	1000.11
+com.apple.driver.DiskImages	493.0.0
+com.apple.iokit.IOGraphicsFamily	593
+com.apple.iokit.IOBluetoothSerialManager	9.0.0
+com.apple.iokit.IOBluetoothHostControllerUSBTransport	9.0.0
+com.apple.iokit.IOBluetoothHostControllerUARTTransport	9.0.0
+com.apple.iokit.IOBluetoothHostControllerTransport	9.0.0
+com.apple.driver.IOBluetoothHostControllerPCIeTransport	9.0.0
+com.apple.iokit.IOBluetoothFamily	9.0.0
+com.apple.driver.FairPlayIOKit	68.13.1
+com.apple.iokit.CSRBluetoothHostControllerUSBTransport	9.0.0
+com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport	9.0.0
+com.apple.driver.AppleSSE	1.0
+com.apple.driver.AppleSEPKeyStore	2
+com.apple.driver.AppleUSBTDM	532.40.7
+com.apple.iokit.IOUSBMassStorageDriver	209.40.6
+com.apple.iokit.IOPCIFamily	2.9
+com.apple.iokit.IOSCSIBlockCommandsDevice	452.60.2
+com.apple.iokit.IOSCSIArchitectureModelFamily	452.60.2
+com.apple.driver.AppleIPAppender	1.0
+com.apple.driver.AppleFDEKeyStore	28.30
+com.apple.driver.AppleEffaceableStorage	1.0
+com.apple.driver.AppleCredentialManager	1.0
+com.apple.driver.KernelRelayHost	1
+com.apple.iokit.IOUSBHostFamily	1.2
+com.apple.driver.AppleUSBHostMergeProperties	1.2
+com.apple.driver.usb.AppleUSBCommon	1.0
+com.apple.driver.AppleSMC	3.1.9
+com.apple.driver.RTBuddy	1.0.0
+com.apple.driver.AppleEmbeddedTempSensor	1.0.0
+com.apple.driver.AppleARMPMU	1.0
+com.apple.iokit.IOAccessoryManager	1.0.0
+com.apple.driver.AppleOnboardSerial	1.0
+com.apple.iokit.IOSkywalkFamily	1.0
+com.apple.driver.mDNSOffloadUserClient	1.0.1b8
+com.apple.iokit.IONetworkingFamily	3.4
+com.apple.iokit.IOSerialFamily	11
+com.apple.driver.AppleSEPManager	1.0.1
+com.apple.driver.AppleA7IOP	1.0.2
+com.apple.driver.IOSlaveProcessor	1
+com.apple.driver.AppleBiometricSensor	2
+com.apple.iokit.IOHIDFamily	2.0.0
+com.apple.iokit.CoreAnalyticsFamily	1
+com.apple.driver.AppleANELoadBalancer	5.35.2
+com.apple.driver.AppleH11ANEInterface	5.35.0
+com.apple.AUC	1.0
+com.apple.iokit.IOAVFamily	1.0.0
+com.apple.iokit.IOHDCPFamily	1.0.0
+com.apple.iokit.IOCECFamily	1
+com.apple.iokit.IOAudio2Family	1.0
+com.apple.driver.AppleIISController	100.1
+com.apple.driver.AppleAudioClockLibs	100.9.1
+com.apple.driver.AppleM2ScalerCSCDriver	265.0.0
+com.apple.iokit.IOSurface	302.11.1
+com.apple.driver.IODARTFamily	1
+com.apple.security.quarantine	4
+com.apple.security.sandbox	300.0
+com.apple.kext.AppleMatch	1.0.0d1
+com.apple.driver.AppleMobileFileIntegrity	1.0.5
+com.apple.security.AppleImage4	4.2.0
+com.apple.kext.CoreTrust	1
+com.apple.iokit.IOCryptoAcceleratorFamily	1.0.1
+com.apple.driver.AppleARMPlatform	1.0.2
+com.apple.iokit.IOStorageFamily	2.1
+com.apple.iokit.IOSlowAdaptiveClockingFamily	1.0.0
+com.apple.iokit.IOReportFamily	47
+com.apple.kec.pthread	1
+com.apple.kec.Libm	1
+com.apple.kec.corecrypto	12.0
+
+
+
+** Stackshot Succeeded ** Bytes Traced 456730 (Uncompressed 1205472) **
+```
+Steps to reproduce:
+1. run the qemu command above
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_KVM/1002 b/gitlab/issues_text/target_arm/host_missing/accel_KVM/1002
new file mode 100644
index 00000000..4933c8a0
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_KVM/1002
@@ -0,0 +1 @@
+qemu-system-aarch64: Synchronous Exception with smp > 1 (on M1 running Asahi Linux with KVM)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_KVM/1046 b/gitlab/issues_text/target_arm/host_missing/accel_KVM/1046
new file mode 100644
index 00000000..e4104f21
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_KVM/1046
@@ -0,0 +1,12 @@
+Using more than 2G of RAM on armv7l guest with RPI4
+Description of problem:
+I was able to run my armv7l guest on RPI4 8G using qemu 6.2, but on 7.0 it doesn't work:
+`qemu-kvm: Addressing limited to 32 bits, but memory exceeds it by 3221225472 bytes`.
+
+The only reference I found is this issue: https://gitlab.com/qemu-project/qemu/-/issues/903
+Steps to reproduce:
+1. `-M virt,highmem=off,gic-version=host,accel=kvm`
+2. `-cpu host,aarch64=off`
+3. `-m 6G`
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_KVM/412 b/gitlab/issues_text/target_arm/host_missing/accel_KVM/412
new file mode 100644
index 00000000..e3355921
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_KVM/412
@@ -0,0 +1 @@
+stable-5.0 crashes with SIGSEV while checking for kvm extension
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_KVM/862 b/gitlab/issues_text/target_arm/host_missing/accel_KVM/862
new file mode 100644
index 00000000..ee890a52
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_KVM/862
@@ -0,0 +1,49 @@
+Using qemu+kvm is slower than using qemu in rv6(xv6 rust porting)
+Description of problem:
+Using qemu+kvm is slower than using qemu in rv6(xv6 rust porting)
+Steps to reproduce:
+```
+git clone https://github.com/kaist-cp/rv6
+cd rv6
+make clean
+TARGET=arm GIC_VERSION=3 KVM=yes make qemu
+```
+Additional information:
+We are currently working on the [rv6 project](https://github.com/kaist-cp/rv6) which is porting MIT's educational operating system [xv6](https://github.com/mit-pdos/xv6-public) to Rust.<br> Our code is located [here](https://github.com/kaist-cp/rv6/tree/main/kernel-rs).
+We use qemu and [qemu's virt platform](https://qemu.readthedocs.io/en/latest/system/arm/virt.html) to execute rv6, and it works well with using qemu.
+Executing command on arm machine is this:
+```
+RUST_MODE=release TARGET=arm KVM=yes GIC_VERSION=3
+qemu-system-aarch64 -machine virt -kernel kernel/kernel -m 128M -smp 80 -nographic -drive file=fs.img,if=none,format=raw,id=x0,copy-on-read=off -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 -cpu cortex-a53  -machine gic-version=3  -net none
+```
+To make some speed boost experiment with KVM, we made rv6 support the arm  architecture on arm machine. The arm architecture's driver code locates in [here](https://github.com/kaist-cp/rv6/tree/main/kernel-rs/src/arch/arm).
+The problem is, when we use qemu with kvm, the performance is significantly reduced.
+Executing command on arm machine with KVM is this:
+```
+qemu-system-aarch64 -machine virt -kernel kernel/kernel -m 128M -smp 80 -nographic -drive file=fs.img,if=none,format=raw,id=x0,copy-on-read=off -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 -cpu host -enable-kvm  -machine gic-version=3  -net none
+``` 
+We repeated 
+1. Write 500 bytes syscall 10,000 times and the result was: kvm disable: 4,500,000 us, kvm enable: 29,000,000 us. (> 5 times)
+2. Open/Close syscall 10,000 times result: kvm disable: 12,000,000 us, kvm enable: 29,000,000 us. (> 5 times)
+3. Getppid syscall 10,000 times result: kvm disable: 735,000 us, kvm enable: 825,000 us. (almost same)
+4. Simple calculation(a = a * 1664525 + 1013904223) 100 million times result: kvm disable: 2,800,000 us, kvm enable: 65,000,000 us. (> 20 times)
+
+And the elapsed time was estimated by [uptime_as_micro](https://github.com/kaist-cp/rv6/blob/90b84b60931327ae8635875b788b10280e47b99c/kernel-rs/src/arch/arm/timer.rs#L17) syscall in rv6.
+These results were so hard to understand. <br>So first we tried to find the bottleneck on rv6's booting process, because finding bottleneck during processing user program was so difficult.
+We found that the first noticeable bottleneck on rv6 booting process was [here](https://github.com/kaist-cp/rv6/blob/main/kernel-rs/src/kalloc.rs#L107-L108):
+```
+run.as_mut().init();
+self.runs().push_front(run.as_ref());
+```
+As far as we know, this part is just kind of "list initialization and push element" part. So we thought that by some reason, the KVM is not actually working and it makes worse result. And also this part is even before turn on some interrupts, so we thought [arm's GIC](https://developer.arm.com/documentation/dai0492/b/) or interrupt related thing is not related with problem.
+
+So, how can I get better performance when using kvm with qemu?
+
+To solve this problem, we tried these already:
+1. change qemu(4.2, 6.2), virt version, change [some command for qemu-kvm](https://linux.die.net/man/1/qemu-kvm) like cpu, drive cache, copy-on-read something, kernel_irqchip.., cpu core.. etc
+2. find some kvm hypercall to use - but not exists on arm64
+3. Run [lmbench](http://lmbench.sourceforge.net/) by ubuntu on qemu with kvm to check KVM itself is okay. - We found KVM with ubuntu is super faster than only using qemu.
+4. Check [16550a UART print code](https://github.com/kaist-cp/rv6/blob/main/kernel-rs/src/arch/arm/uart.rs) is really slow on enabling KVM which makes incorrect result on benchmark - Without bottleneck code, we found the progress time of rv6 booting were almost same with KVM enabled or not.
+5. Check other people who suffer same situation like us - but [this superuser page](https://superuser.com/questions/1317948/qemu-enable-kvm-slower-than-pure-emulation-for-x86-64) not works. Our clocksource is arch_sys_counter.
+
+Thank you for your help.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_KVM/961 b/gitlab/issues_text/target_arm/host_missing/accel_KVM/961
new file mode 100644
index 00000000..5748305d
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_KVM/961
@@ -0,0 +1 @@
+Property not found when using aarch64 `-machine=virt,secure=on` with KVM enabled
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_KVM/966 b/gitlab/issues_text/target_arm/host_missing/accel_KVM/966
new file mode 100644
index 00000000..0a37dfda
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_KVM/966
@@ -0,0 +1,58 @@
+simple code line is so slow on rv6(rust os) than ubuntu
+Description of problem:
+[Simple code line for getppid](https://github.com/kaist-cp/rv6/blob/main/kernel-rs/src/proc/procs.rs#L470) takes so long time(About 0.08 microsec, which is about 70% time of ubuntu getppid() syscall) on kernel. So we wonder if there is a problem with the qemu or kvm side settings.
+Steps to reproduce:
+```
+git clone https://github.com/kaist-cp/rv6
+cd rv6
+make clean
+RUST_MODE=release TARGET=arm GIC_VERSION=3 KVM=yes make qemu
+```
+Additional information:
+We are currently working on the [rv6 project](https://github.com/kaist-cp/rv6) which is porting MIT's educational operating system [xv6](https://github.com/mit-pdos/xv6-public) to Rust.<br> Our code is located [here](https://github.com/kaist-cp/rv6/tree/main/kernel-rs).
+We use qemu and [qemu's virt platform](https://qemu.readthedocs.io/en/latest/system/arm/virt.html) to execute rv6, and it works well with using qemu.
+Executing command on arm machine is this:
+```
+RUST_MODE=release TARGET=arm KVM=yes GIC_VERSION=3; # compile
+qemu-system-aarch64 -machine virt -kernel kernel/kernel -m 128M -smp 1 -nographic -drive file=fs.img,if=none,format=raw,id=x0 -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 -cpu host -enable-kvm -machine gic-version=3
+```
+Now, we are comparing the speed(exactly, elapsed wall clock time) of system call of qemu+rv6+kvm and qemu+ubuntu 18.04+kvm with [lmbench](http://lmbench.sourceforge.net/).
+For ubuntu, qemu command is this:
+```
+qemu-system-aarch64 -cpu host -enable-kvm -device rtl8139,netdev=net0 -device virtio-scsi-device -device scsi-cd,drive=cdrom -device virtio-blk-device,drive=hd0 -drive "file=${iso},id=cdrom,if=none,media=cdrom" -drive "if=none,file=${img_snapshot},id=hd0" -m 2G -machine "virt,gic-version=3,its=off" -netdev user,id=net0 -nographic -pflash "$flash0" -pflash "$flash1" -smp 1
+``` 
+Now, our goal is to make rv6 perform similar or faster than ubuntu for relatively simple system call like getppid(). <br>
+Relatively simple system call means, for example, in the case of getppid(), the actual system call execution part is so simple. So it mainly measures the time for user space -> kernel space -> user space. <br>
+And we thought that on getppid() syscall, rv6 could show similar performance or more faster than ubuntu cause it's simple system.<br>
+**The most important problem** is that, although it will be described later, a [simple code line for getppid](https://github.com/kaist-cp/rv6/blob/main/kernel-rs/src/proc/procs.rs#L470) takes so long time(About 0.08 microsec, which is about 70% time of ubuntu getppid() syscall) on kernel. So we wonder if there is a problem with the qemu or kvm side settings.
+
+First, the measured performance result for lmbench's "lat_syscall null" which executes internally getppid() is:
+ - rv6, Rust opt-level: 1, smp 3(qemu), gcc optimization level: -O -> average 1.662 microsec
+ - ubuntu, smp 3, gcc optimization level: -O -> average 0.126 microsec
+So we see that rv6 is so slower than ubuntu over 10x.
+
+To find the bottleneck of rv6, we use [linux perf](https://perf.wiki.kernel.org/index.php/Main_Page) and divided execution path into 4 stages. <br>
+Stage 1: Call getppid in the user space  to  until just before the trap handler is called<br>
+Stage 2: From after stage 1 to until just before the start of code specific to sys_getppid.<br>
+Stage 3: From after stage 2 to [end of actual sys_getppid function](https://github.com/kaist-cp/rv6/blob/main/kernel-rs/src/proc/procs.rs#L468-L473)<br>
+Stage 4: From after stage 3 to the point which getppid syscall returns on user space<br>
+The result with perf was:
+  - ubuntu: 0.042 microsec/ 0.0744 microsec / 0.00985 microsec / 0 -> total 0.126 microsec
+  - rv6:  ?   /   ?   /  0.3687 microsec  / ?  -> 1.662 microsec
+  - we made assumption for ubuntu stage 4 time is zero.
+  - The question mark is, on rv6 we couldn't use perf so only stage 3 time is measured for right now, but checked stage 3 part manually.
+
+So from the result, it can be confirmed that the rv6's stage 3 already consumes more than 3 times of ubuntu's syscall total time, and at least 30 times more than ubuntu's stage 3.
+This is so bad, so we tried several things to inspect the problem:
+  - Check whether rv6's timer interrupt affects execution time: The interval is 100ms which is so big, so it seems not related.
+  - To check user space's execution speed, we made simple quick sort program and check rv6's user space speed is significantly slower than ubuntu.
+     - When running 100,000 times, rv6(smp 1, opt-level 1)'s execution time: 3.2s vs ubuntu(smp 1)'s execution time: 2.7s.
+     - Although it is 20% slower, it is judged that there is almost no difference compared to the lmbench result. So we thought it is no big problem.
+
+  - Next we checked rv6's stage 3's code. https://github.com/kaist-cp/rv6/blob/main/kernel-rs/src/proc/procs.rs#L468
+    - The lock is held twice at line 469 and line 472, whereas ubuntu's same code part, lock is held only once. So first if we change the structure to hold lock only once, there will be improvement in speed. we noticed that.
+    - **Also there's a big problem on 470 line.** We measured time for 470 line with CNTPCT_EL0 register, and it was found that at least 0.08 microsec was consumed in the corresponding line.
+       - So ubuntu's stage 3 consumes about 0.01 microsec, but only line 470 of rv6, which does not have complicated logic(it also doesn't hold lock) consumes about 8 times that ubuntu's stage 3.
+       - So we concluded that there may be a problem with the kvm setting on the kernel side or other settings.
+
+So do you have any idea for this problem? Thank you for your help.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1034 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1034
new file mode 100644
index 00000000..e2f47c07
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1034
@@ -0,0 +1,17 @@
+Erlang/OTP 25 JIT on AArch64 fails in user mode emulation
+Description of problem:
+Compiling Erlang/OTP 25 fails with segfault when using user mode (but works in system mode), the Erlang devs have tracked it down in [ErlangForums](https://erlangforums.com/t/otp-25-0-rc3-release-candidate-3-is-released/1317/24) and give this explanation:
+
+> Thanks, I’ve found a bug in QEMU that explains this. The gist of it is:
+> 
+> Instead of interpreting guest code, QEMU dynamically translates it to the host architecture. When the guest overwrites code for one reason or another, the translation is invalidated and redone if needed.
+> 
+> Our JIT:ed code is mapped in two regions to work in the face of W^X restrictions: one executable but not writable, and one writable but not executable. Both of these regions point to the same physical memory and writes to the writable region are “magically” reflected in the executable one.
+> 
+> I would’ve expected QEMU to honor the IC IVAU / ISB instructions we use to tell the processor that we’ve altered code at a particular address, but for some reason QEMU just ignores them 3 and relies entirely on trapping writes to previously translated code.
+> 
+> In system mode QEMU emulates the MMU and sees that these two regions point at the same memory, and has no problem invalidating the executable region after writing to the writable region.
+> 
+> In user mode it instead calls mprotect(..., PROT_READ) on all code regions it has translated, and invalidates translations in the signal handler. The problem is that we never write to the executable region – just the writable one – so the code doesn’t get invalidated.
+
+There doesn't seem to a open or closed QEMU bug that actually describes this problem.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1054 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1054
new file mode 100644
index 00000000..06f16ad5
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1054
@@ -0,0 +1,30 @@
+Unable to start CirrOS 0.5.1 on QEMU 7.0 with -M virt and -cpu max
+Description of problem:
+
+Steps to reproduce:
+1. Fetch CirrOS image: ```wget https://github.com/cirros-dev/cirros/releases/download/0.5.1/cirros-0.5.1-aarch64-disk.img```
+2. Run QEMU:
+   ```
+   qemu-system-aarch64 -drive file=cirros-0.5.1-aarch64-disk.img -M virt -m 2048 \
+      -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd -cpu max -nographic
+   ```
+Additional information:
+When image boots, GRUB window appears for a second and then kernel/initramfs are loaded and booted:
+```
+EFI stub: Booting Linux Kernel...
+EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
+EFI stub: Using DTB from configuration table
+EFI stub: Exiting boot services and installing virtual address map...
+```
+
+When everything is fine we can see kernel output:
+```
+[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd070]
+[    0.000000] Linux version 5.3.0-26-generic (buildd@bos02-arm64-028) (gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)) #28~18.04.1-Ubuntu SMP Wed Dec 18 16:41:01 UTC 2019 (Ubuntu 5.3.0-26.28~18.04.1-generic 5.3.13)
+[    0.000000] efi: Getting EFI parameters from FDT:
+[    0.000000] efi: EFI v2.70 by EDK II
+```
+
+But on QEMU 7.0 with ```-M virt -cpu max``` we never get kernel output.
+
+#
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1057 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1057
new file mode 100644
index 00000000..82c426f9
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1057
@@ -0,0 +1,23 @@
+AArch64: ISV is set to 1 in ESR_EL2 when taking a data abort with post-indexed instructions
+Description of problem:
+I think that I have a Qemu bug in my hands, but, I could still be missing something. Consider the following instruction:
+`0x0000000000000000:  C3 44 00 B8    str   w3, [x6], #4`
+
+notice the last #4, I think this is what we would call a post-indexed instruction (falls into the category of instructions with writeback). As I understand it, those instructions should not have ISV=1 in ESR_EL2 when faulting.
+
+Here is the relevant part of the manual:
+
+```
+For other faults reported in ESR_EL2, ISV is 0 except for the following stage 2 aborts:
+• AArch64 loads and stores of a single general-purpose register (including the register specified with 0b11111, including those with Acquire/Release semantics, but excluding Load Exclusive or Store Exclusive and excluding those with writeback).
+```
+
+However, I can see that Qemu sets ISV to 1 here. The ARM hardware that I tested gave me a value of ISV=0 for similar instructions.
+
+Another example of instruction: `0x00000000000002f8:  01 1C 40 38    ldrb  w1, [x0, #1]!`
+Steps to reproduce:
+1. Run some hypervisor in EL2
+2. Create a guest running at EL1 that executes one of the mentioned instructions (and make the instruction fault by writing to some unmapped page in SLP)
+3. Observe the value of ESR_EL2 on data abort
+
+Unfortunately, I cannot provide an image to reproduce this (the software is not open-source). But, I would be happy to help test a patch.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1062 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1062
new file mode 100644
index 00000000..b4a09b09
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1062
@@ -0,0 +1,16 @@
+AArch64: SCR_EL3.RW behaves incorrectly for CPUs with no AArch32
+Description of problem:
+In the ARM DDI 0487G.a, D13-3572, the SCR_EL3.RW bit is defined as RAO/WI if both EL2 and EL1 don't support Aarch32. However, the function `scr_write` in `target/arm/helper.c` does not reflect this behavior, even though it checks for Aarch32 EL1 support.
+
+This would break this EL3 code, which should run on cpu reset to attempt to return to EL1:
+```asm
+mov x1, #((1<<0)|(1<<2)|(1<<6)|(1<<7)|(1<<8)|(1<<9)) ; EL1h, DAIF masked
+mov SPSR_EL3, x1
+adr x1, 1f
+msr ELR_EL3, x1
+eret
+1:
+; something something
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1130 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1130
new file mode 100644
index 00000000..ac09550f
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1130
@@ -0,0 +1,29 @@
+error on run qemu-system-aarch64 -icount shift=1,align=off,sleep=on -smp 2
+Description of problem:
+This issue happen with the most recent version. 
+* Compile parameters:
+```
+./configure --target-list=aarch64-softmmu  --prefix=pwd/release  --disable-werror --enable-lto --enable-capstone --enable-system --enable-fdt --disable-xen --disable-kvm --enable-plugins
+```
+* run：
+```
+qemu-system-aarch64 -nographic -machine virt -cpu cortex-a57 -icount shift=1,align=off,sleep=on -smp 2 -vnc :2 -m 4080 -kernel /home/yuzy/mywork/linux/linux-5.15.30/arch/arm64/boot/Image.gz -initrd /home/yuzy/mywork/build/rootfs.cpio.gz
+```
+* error occurred：
+```
+**
+ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked())
+Aborted (core dumped)
+```
+Steps to reproduce:
+1. run qemu-system-aarch64 -machine virt -cpu cortex-a57 -icount shift=1,align=off,sleep=on -smp 2 -m 4080 -kernel Image.gz -initrd rootfs.cpio.gz 
+2. it will assertion failed: (qemu_mutex_iothread_locked())
+Additional information:
+The following two situations are good：
+```
+qemu-system-aarch64 -machine virt -cpu cortex-a57 -icount shift=1,align=off,sleep=on -smp 1 -m 4080 -kernel Image.gz -initrd rootfs.cpio.gz
+```
+```
+qemu-system-aarch64 -machine virt -cpu cortex-a57 -smp 2 -m 4080 -kernel Image.gz -initrd rootfs.cpio.gz
+```
+I assume the issues are: gic
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1153 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1153
new file mode 100644
index 00000000..745a09c0
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1153
@@ -0,0 +1 @@
+arm: wrong syndrome reported for FP and SIMD traps to AArch32 Hyp
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1154 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1154
new file mode 100644
index 00000000..60eae280
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1154
@@ -0,0 +1 @@
+arm: M-profile loads and stores done via helpers should enforce alignment restrictions
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1177 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1177
new file mode 100644
index 00000000..f17e8f08
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1177
@@ -0,0 +1,16 @@
+booting linux hangs with -cpu max or -cpu max,lpa2=off, but works with -cpu cortex-a57
+Description of problem:
+
+Steps to reproduce:
+1. Snag mini.iso from http://ports.ubuntu.com/ubuntu-ports/dists/bionic-updates/main/installer-arm64/current/images/netboot/mini.iso
+2. qemu-img create ubuntu-image.img 20G
+3. dd if=/dev/zero of=flash1.img bs=1M count=64
+4. dd if=/dev/zero of=flash0.img bs=1M count=64
+5. dd if=/home/imp/git/qemu/00-build/pc-bios/edk2-aarch64-code.fd of=flash0.img conv=notrunc
+6. Run the above command
+7. Select install, watch the kernel hang.
+8. Change -cpu max to -cpu cortex-a57 and it will work. -cpu max,lpa2=off also exhibits the problem
+Additional information:
+Just grabbed git and built it with ./configure in /home/imp/git/qemu/00-build.
+
+pm215 on irc suggested that it was an old EDK2 and a newer one is needed to cope with the newer CPU features in -cpu max
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1204 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1204
new file mode 100644
index 00000000..b62fb60c
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1204
@@ -0,0 +1,29 @@
+AArch64 unaligned accesses are allowed by QEMU when SCTLR_EL3.A is 0, but SCTLR_EL3.M is also 0
+Description of problem:
+As per the ARM ARM, when address translation is disabled and the access is not done from EL1/0 with HCR_EL2.DC set to 1, data accesses receive the 'Device-nGnRnE' memory attribute (D.8.2.10 The effects of disabling an address translation stage - DDi0487I.a, Page D8-5119).
+Memory regions marked as Device do not support unaligned access.
+Steps to reproduce:
+Run the following snippet under EL3, and notice the last load instruction completes successfully (doesn't raise an alignment fault)
+```
+.balign 8
+.global first_variable
+first_variable:
+      .word 0x1
+.balign 4
+.global second_variable
+second_variable:
+      .word 0x2
+
+no_mmu_sctlr: .dword 0x0000000030C51834
+
+.globl reproducer
+reproducer:
+      ldr  x1, no_mmu_sctlr // A=0,M=0
+      msr  sctlr_el3, x1
+      dsb  sy
+      isb
+
+      ldr  x0, =first_variable
+      ldr  x1, [x0, #0] // Aligned - Success
+      ldr  x1, [x0, #4] // Unaligned - Success??? (Should be failure)
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1208 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1208
new file mode 100644
index 00000000..a7426046
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1208
@@ -0,0 +1,9 @@
+Raspberry Pi 4 Model B
+Additional information:
+There have been some attempts at implementing this a few years ago: see:
+* https://gitlab.com/philmd/qemu/-/tree/raspi4_wip
+* https://github.com/0xMirasio/qemu-patch-raspberry4
+
+
+
+Thanks!
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1293 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1293
new file mode 100644
index 00000000..7abe62b8
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1293
@@ -0,0 +1 @@
+Trusted Firmware stopped booting on SBSA-ref
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1347 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1347
new file mode 100644
index 00000000..046a6538
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1347
@@ -0,0 +1,23 @@
+qemu-system-arm segfaults: arm_v7m_tcg_ops.restore_state_to_opc is NULL
+Description of problem:
+gdb backtrace:
+```
+#0  0x0000000000000000 in ?? ()
+#1  0x0000555555eda714 in cpu_restore_state_from_tb (cpu=0x5555570020e0, tb=0x7fffb8f6ce80, host_pc=140735277023274) at ../accel/tcg/translate-all.c:311
+#2  0x0000555555eda785 in cpu_restore_state (cpu=0x5555570020e0, host_pc=140735277023274) at ../accel/tcg/translate-all.c:335
+#3  0x0000555555d01323 in arm_cpu_do_transaction_failed (cs=0x5555570020e0, physaddr=1073885184, addr=1073885184, size=4, access_type=MMU_DATA_LOAD, mmu_idx=1, attrs=..., response=1, retaddr=140735277023274) at ../target/arm/tlb_helper.c:199
+#4  0x0000555555ee4118 in cpu_transaction_failed (cpu=0x5555570020e0, physaddr=1073885184, addr=1073885184, size=4, access_type=MMU_DATA_LOAD, mmu_idx=1, attrs=..., response=1, retaddr=140735277023274) at ../accel/tcg/cputlb.c:1344
+#5  0x0000555555ee42aa in io_readx (env=0x555557003f50, full=0x5555580f26c0, mmu_idx=1, addr=1073885184, retaddr=140735277023274, access_type=MMU_DATA_LOAD, op=MO_32) at ../accel/tcg/cputlb.c:1380
+#6  0x0000555555ee59f2 in load_helper (env=0x555557003f50, addr=1073885184, oi=33, retaddr=140735277023274, op=MO_32, code_read=false, full_load=0x555555ee5dbf <full_le_ldul_mmu>) at ../accel/tcg/cputlb.c:1970
+#7  0x0000555555ee5e12 in full_le_ldul_mmu (env=0x555557003f50, addr=1073885184, oi=33, retaddr=140735277023274) at ../accel/tcg/cputlb.c:2070
+#8  0x0000555555ee5e44 in helper_le_ldul_mmu (env=0x555557003f50, addr=1073885184, oi=33, retaddr=140735277023274) at ../accel/tcg/cputlb.c:2077
+#9  0x00007fff7c31c0be in code_gen_buffer ()
+#10 0x0000555555ed15b8 in cpu_tb_exec (cpu=0x5555570020e0, itb=0x7fffb8f6ce80, tb_exit=0x7fff7a3fc068) at ../accel/tcg/cpu-exec.c:438
+#11 0x0000555555ed2185 in cpu_loop_exec_tb (cpu=0x5555570020e0, tb=0x7fffb8f6ce80, pc=2824872, last_tb=0x7fff7a3fc080, tb_exit=0x7fff7a3fc068) at ../accel/tcg/cpu-exec.c:868
+#12 0x0000555555ed2545 in cpu_exec (cpu=0x5555570020e0) at ../accel/tcg/cpu-exec.c:1032
+#13 0x0000555555ef3329 in tcg_cpus_exec (cpu=0x5555570020e0) at ../accel/tcg/tcg-accel-ops.c:69
+#14 0x0000555555ef39ca in mttcg_cpu_thread_fn (arg=0x5555570020e0) at ../accel/tcg/tcg-accel-ops-mttcg.c:95
+#15 0x00005555560b1e87 in qemu_thread_start (args=0x5555571358e0) at ../util/qemu-thread-posix.c:505
+#16 0x00007ffff7fb6cbe in start (p=0x7fff7a3fc1e0) at src/thread/pthread_create.c:195
+#17 0x00007ffff7fc3e7b in __clone () at src/thread/x86_64/clone.s:22
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1400 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1400
new file mode 100644
index 00000000..95e70b92
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1400
@@ -0,0 +1 @@
+helper_access_check_cp_reg() raising Undefined Instruction on big-endian host
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1412 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1412
new file mode 100644
index 00000000..4a807c44
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1412
@@ -0,0 +1,5 @@
+QEMU segfault (null pointer dereference) in sve_probe_page from ldff1* instructions
+Description of problem:
+After upgrading to QEMU v7.2.0 from v7.1.0, when executing any SVE ldff1* instructions with a faulting address, QEMU crashes due to a null pointer dereference at target/arm/sve_helper.c:5364
+
+I believe this was introduced in b8967ddf393aaf35fdbc07b4cb538a40f8b6fe37 (@rth7680), since in that commit `full` is dereferenced before the `flags & TLB_INVALID_MASK` check at line 5369, and full is set to null by `probe_access_full` when `TLB_INVALID_MASK` is given.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1416 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1416
new file mode 100644
index 00000000..adb4d918
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1416
@@ -0,0 +1,5 @@
+MTE tags are applied at page granularity (4K) instead of tag granularity (16)
+Description of problem:
+After upgrading to QEMU v7.2.0 from v7.1.0, when executing stg/ldg instructions on any address, QEMU behaves as if the instruction was executed on the page base of said address.
+
+I believe this was introduced in b8967ddf393aaf35fdbc07b4cb538a40f8b6fe37 (@rth7680), since in that commit `ptr_paddr` is changed to be calculated based on `CPUTLBEntryFull::phys_addr`, which contains the page base address, while beforehand it was calculated based on `host` which does have the page offset applied.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1417 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1417
new file mode 100644
index 00000000..eabead07
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1417
@@ -0,0 +1,5 @@
+QEMU fails an assertion when hitting a breakpoint that is set on a tlb-missed 2-stage translated AArch64 memory
+Description of problem:
+After upgrading to QEMU v7.2.0 from v7.1.0, when hitting an instruction breakpoint on a memory address that is translated by 2 stages of translation, and is not already cached in the TLB, QEMU fails the assertion at target/arm/ptw.c:301 (`assert(fi->type != ARMFault_None);`).
+
+I believe this was introduced in f3639a64f602ea5c1436eb9c9b89f42028e3a4a8 (@rth7680), since in that commit the failure check for the return value of `get_phys_addr_lpae()` changed from checking for true (meaning failure) to checking for false (which actually means success).
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1498 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1498
new file mode 100644
index 00000000..90beb501
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1498
@@ -0,0 +1,5 @@
+LDC, STC unimplemented in qemu-system-arm
+Description of problem:
+I used differential testing to compared the instruction consistency (ARMv7) between QEMU and raspberry pi 2B in system level and some inconsistency in LDC, SDC instruction was detected.
+
+The instructions run successfully in raspi2b, but cause undefined in QEMU. I found that LDC and SDC instructions remain unimplemented in QEMU.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1499 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1499
new file mode 100644
index 00000000..c26e47ee
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1499
@@ -0,0 +1,90 @@
+qemu-system-arm doesn't honour CPACR.ASEDIS, D32DIS
+Description of problem:
+We used differential testing to compared the instruction consistency (ARMv7) between QEMU and raspberry pi 2B in system level and some inconsistency in SIMD instruction was detected.
+
+We compiled the kernel with options `-mcpu=cortex-a7 -march=armv7ve -mfloat-abi=hard -mfpu=vfpv4 `. Some SIMD instructions are considered as **undefined** instructions in raspi2b, but run successfully in the QEMU. 
+
+We checked that the CPACR.ASEDIS=1, which disables Advanced SIMD functionality, according to ARMv7-a manual B4.1.40.  The manual says "All instruction encodings identified in the Alphabetical list of instructions on page A8-300 as being Advanced SIMD instructions, but that are not VFPv3 or VFPv4
+instructions, are UNDEFINED when accessed from PL1 and PL0 modes."
+
+Tested instruction samples are shown as follows:
+
+- VMAX_int_T1A1_A 11110010010010110000011010100100 0xf24b06a4
+- VMUL_scalar_A1_A 11110010101001001100100 001000011 0xf2a4c843
+- VADD_int_T1A1_A 11110010000111111010100000001100 0xf21fa80c
+
+...
+
+Some checks of the SIMD instructions may be needed before the execution of the instructions in function ` do_3same` etc. in target/arm/translate-neon.c.
+Steps to reproduce:
+1. Compile a kernel module to run the test instruction in PL1.
+2. Hook a undefined handler in kernel module to catch the undefined instructions. A kernel module template we used to test is as follows
+
+```c
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <asm/traps.h> 
+
+MODULE_LICENSE("GPL");
+#pragma GCC optimize ("O0")
+// instr is undefined instruction value
+static int undef_instr_handler(struct pt_regs *regs, u32 instr)
+{
+    printk(KERN_INFO "get undefined instruction\n");
+    // Just skip over to the next instruction.
+    regs->ARM_pc += 4;
+    return 0; // All fine!
+}
+
+static struct undef_hook uh = {
+    .instr_mask  = 0x0, // any instruction
+    .instr_val   = 0x0, // any instruction
+    .cpsr_mask = 0x0, // any pstate
+    .cpsr_val  = 0x0, // any pstate
+    .fn          = undef_instr_handler
+};
+int init_module(void) {
+    // Lookup wanted symbols.
+    register_undef_hook(&uh);
+    __asm__ __volatile__("push {R0-R12}");
+    __asm__ __volatile__(
+      ".global inialize_location\n"
+      "inialize_location:\n"
+      "mov r0, %[reg_init]        \n"
+      "mov r1, %[reg_init]        \n"
+      "mov r2, %[reg_init]        \n"
+      "mov r3, %[reg_init]        \n"
+      "mov r4, %[reg_init]        \n"
+      "mov r5, %[reg_init]        \n"
+      "mov r6, %[reg_init]        \n"
+      "mov r7, %[reg_init]        \n"
+      "mov r8, %[reg_init]        \n"
+      "mov r9, %[reg_init]        \n"
+      "mov r10, %[reg_init]       \n"
+      "mov r11, %[reg_init]       \n"
+      "mov r12, %[reg_init]       \n"
+      :
+      : [reg_init] "n"(0)
+    );
+  // =======TODO=======
+  // replace nop with test instruction
+   __asm__ __volatile__(
+      ".global inst_location\n"
+      "inst_location:\n"
+      "nop\n" 
+    );
+    // kgdb_breakpoint();
+    __asm__ __volatile__(
+      ".global finish_location\n"
+      "finish_location:\n"
+    );
+    __asm__ __volatile__("pop {R0-R12}");
+    return 0;
+}
+
+void cleanup_module(void) {
+    unregister_undef_hook(&uh);
+}
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1500 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1500
new file mode 100644
index 00000000..8d52d0c6
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1500
@@ -0,0 +1,38 @@
+Some system/debug regisiters are inconsistent with real device in qemu-system-arm
+Description of problem:
+We used differential testing to compared the instruction consistency (ARMv7) between QEMU and raspberry pi 2B in system level and some inconsistency in system regisiter was detected.
+
+1. CCSIDR--Cache Size ID Registers
+
+   **Inconsistency**
+
+   - CCSIDR in QEMU: 0x701fe00a--Associativity: 2, Number of sets:256
+
+   - CCSIDR in  Raspi2B: 0x700fe01a--Associativity: 4, Number of sets:128
+
+   **Tested Instruction sample**
+
+   - MRC_T1A1_A 11101110001100000000111100010000 0xee300f10
+
+   According to ARMv7 Manual B4.1.19 encoding, the NumSets and Associativity are set different bewteen QEMU when emulating raspi2b and raspi2b.
+
+   The CCSIDR is set in the function`cortex_a7_initfn(Object *obj)` in target/arm/cpu_tcg.c for cortex_a7. 
+
+2. DBGDRAR--Debug ROM Address Register
+
+   **Inconsistency**
+
+   - DBGDRAR in QEMU: 0x0 --Invalid
+
+   - DBGDRAR in  Raspi2B: 0x40020003--Valid
+
+   According to ARMv7 Manual C11.11.16 encoding, the DBGDRAR in qemu is invalid.
+
+   **Tested Instruction sample**
+
+   - MRC_T1A1_A 11101110000100010001111000010000 0xee111e10
+Steps to reproduce:
+1. Compile a kernel module to run the test instruction in PL1.
+2. Use kgdb to get the register info
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1551 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1551
new file mode 100644
index 00000000..bfc398ee
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1551
@@ -0,0 +1,40 @@
+qemu-system-arm: ../accel/tcg/cpu-exec.c:917: cpu_loop_exec_tb: Assertion `icount_enabled()' failed.
+Description of problem:
+When starting the guest, the mentioned assertion is triggered very soon:
+```
+qemu-system-arm: ../accel/tcg/cpu-exec.c:917: cpu_loop_exec_tb: Assertion `icount_enabled()' failed.
+```
+I'm able to successfully boot the same image with QEMU 7.2.0.
+
+The last output from the qemu logging with `-d guest_errors,in_asm,int,pcall,cpu` is
+```
+----------------
+IN:
+0x40209100:  e92d4ff0  push     {r4, r5, r6, r7, r8, sb, sl, fp, lr}
+0x40209104:  e28db020  add      fp, sp, #0x20
+0x40209108:  e24b3f49  sub      r3, fp, #0x124
+0x4020910c:  e24ddf43  sub      sp, sp, #0x10c
+0x40209110:  e1a0e00f  mov      lr, pc
+0x40209114:  e3e0f0ff  mvn      pc, #0xff
+
+R00=4021000c R01=4020a5f8 R02=0000000f R03=40209100
+R04=40210018 R05=40210018 R06=4020c000 R07=40002000
+R08=00000000 R09=00000000 R10=00000000 R11=4020d7fc
+R12=00000000 R13=4020d7f0 R14=4020074c R15=40209100
+PSR=2000011f --C- A sys32
+----------------
+IN:
+0xffffff00:  ee1d0f50  mrc      p15, #0, r0, c13, c0, #2
+
+R00=4021000c R01=4020a5f8 R02=0000000f R03=4020d6c8
+R04=40210018 R05=40210018 R06=4020c000 R07=40002000
+R08=00000000 R09=00000000 R10=00000000 R11=4020d7ec
+R12=00000000 R13=4020d6c0 R14=40209118 R15=ffffff00
+PSR=2000011f --C- A sys32
+```
+
+Please note that the L4Re OS uses `mvn pc, #0xff` to switch from EL1 to EL2 (system call).
+Steps to reproduce:
+1. Boot the attached image with the provided command line to trigger the assertion
+Additional information:
+I will attach the bootstrap image to this ticket.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1612 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1612
new file mode 100644
index 00000000..93eecac2
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1612
@@ -0,0 +1,51 @@
+SVE first-faulting gather loads return incorrect data
+Description of problem:
+The results of `ldff1(b|h|w|d)` seem to be incorrect when `<Zt> == <Zm>`. The first element is duplicated throughout the vector while the FFR indicates that all elements were successfully loaded. This happens since https://gitlab.com/qemu-project/qemu/-/commit/50de9b78cec06e6d16e92a114a505779359ca532, and still happens on the latest master.
+Steps to reproduce:
+1. This assembly sequence loads data with an `ldff1d` instruction (and also loads the ffr). Note that with `ldff1d`, `<Zt> == <Zm>`.
+
+asmtest.s
+```
+    .type asmtest, @function
+    .balign 16
+    .global asmtest
+asmtest:
+    setffr
+    ptrue   p0.d
+    index   z1.d, #0, #1
+    ldff1d  z1.d, p0/z, [x0, z1.d, LSL #3]
+    rdffr   p1.b
+    st1d    {z1.d}, p0, [x1]
+    str     p1, [x2]
+    ret
+```
+
+This harness for convenience intialises some data and checks the element at index 1, which should be 1.
+
+test.c
+```
+#include <arm_sve.h>
+#include <stdio.h>
+
+void asmtest(int64_t const * data, svint64_t * loaded, svbool_t * ffr);
+
+int main() {
+    const int64_t data[] = {42,  1,  2,  3,  4,  5,  6,  7,  8,  9,  10,
+                          11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21,
+                          22, 23, 24, 25, 26, 27, 28, 29, 30, 31};
+    svint64_t loaded;
+    svbool_t ffr;
+
+    asmtest(data, &loaded, &ffr);
+
+    // Check value of element at index 1
+    svuint64_t lanes = svindex_u64(0, 1);
+    svbool_t lane = svcmpeq_n_u64(svptrue_b64(), lanes, 1);
+    printf("%ld\n", svaddv_s64(lane, loaded));
+}
+```
+
+2. ```clang-15 -fuse-ld=lld -march=armv8-a+sve2 -target aarch64-unknown-linux-gnu -static *.c *.s -o svldffgathertest```
+3. ```qemu-aarch64 svldffgathertest``` - the value printed should be 1, but it can be seen that all values in the loaded vector are 42.
+Additional information:
+The above code was successfully tested on real SVE hardware. Normal gathers work fine in QEMU, as does a non-gather first-fault load.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1620 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1620
new file mode 100644
index 00000000..543af9ee
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1620
@@ -0,0 +1,94 @@
+SME FMOPA outer product instruction gives incorrect result
+Description of problem:
+The SME outer product instructions operate on tiles of elements. In the
+below example we are performing an outer product of a vector of 1.0
+by itself. This naturally should produce a matrix filled with 1.0
+values, however if we read the values of the tile and printf them we
+instead observe 0.0 values.
+
+Without digging into the underlying QEMU code this appears to be a bug
+in how elements are set based on the tile number, since the same code
+using za0.s rather than za1.s correctly reports all 1.0 values as output
+as expected.
+
+main.c
+```
+#include <stdio.h>
+
+void foo(float *dst);
+
+int main() {
+  float dst[16];
+  foo(dst);
+
+  // This should print:
+  // >>> 1.000000  1.000000  1.000000  1.000000
+  // >>> 1.000000  1.000000  1.000000  1.000000
+  // >>> 1.000000  1.000000  1.000000  1.000000
+  // >>> 1.000000  1.000000  1.000000  1.000000
+  for (int i=0; i<4; ++i) {
+    printf(">>> ");
+    for (int j=0; j<4; ++j) {
+      printf("%lf  ", (double)dst[i * 4 + j]);
+    }
+    printf("\n");
+  }
+}
+```
+
+foo.S
+```
+.global foo
+foo:
+  stp x29, x30, [sp, -80]!
+  mov x29, sp
+  stp d8, d9, [sp, 16]
+  stp d10, d11, [sp, 32]
+  stp d12, d13, [sp, 48]
+  stp d14, d15, [sp, 64]
+
+  smstart
+
+  ptrue p0.s, vl4
+  fmov z0.s, #1.0
+
+  // An outer product of a vector of 1.0 by itself should be a matrix of 1.0.
+  // Note that we are using tile 1 here (za1.s) rather than tile 0.
+  zero {za}
+  fmopa za1.s, p0/m, p0/m, z0.s, z0.s
+
+  // Read the first 4x4 sub-matrix of elements from tile 1:
+  // Note that za1h should be interchangable here.
+  mov w12, #0
+  mova z0.s, p0/m, za1v.s[w12, #0]
+  mova z1.s, p0/m, za1v.s[w12, #1]
+  mova z2.s, p0/m, za1v.s[w12, #2]
+  mova z3.s, p0/m, za1v.s[w12, #3]
+
+  // And store them to the input pointer (dst in the C code):
+  st1w {z0.s}, p0, [x0]
+  add x0, x0, #16
+  st1w {z1.s}, p0, [x0]
+  add x0, x0, #16
+  st1w {z2.s}, p0, [x0]
+  add x0, x0, #16
+  st1w {z3.s}, p0, [x0]
+
+  smstop
+
+  ldp d8, d9, [sp, 16]
+  ldp d10, d11, [sp, 32]
+  ldp d12, d13, [sp, 48]
+  ldp d14, d15, [sp, 64]
+  ldp x29, x30, [sp], 80
+  ret
+```
+Steps to reproduce:
+```
+$ clang -target aarch64-linux-gnu -march=armv9-a+sme test.c -O1 -static
+$ ~/qemu/build/qemu-aarch64 ./a.out
+>>> 0.000000  0.000000  0.000000  0.000000
+>>> 0.000000  0.000000  0.000000  0.000000
+>>> 0.000000  0.000000  0.000000  0.000000
+>>> 0.000000  0.000000  0.000000  0.000000
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1658 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1658
new file mode 100644
index 00000000..d65804dc
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1658
@@ -0,0 +1,60 @@
+Zephyr TF-M IPC example triggers failed assertion !arm_feature(env, ARM_FEATURE_M) on recent Qemu
+Description of problem:
+I can't run the TrustedFirmware-M IPC example in the Zephyr repo with recent Qemu (in particular v8.0.0).
+
+By bisecting, I got the last commit OK : v7.2.0-351-gfaa1451e7b
+
+```
+$ qemu-system-arm -M mps2-an521 -device loader,file=tfm_merged.hex -serial stdio
+[INF] Beginning TF-M provisioning
+[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
+[Sec Thread] Secure image initializing!
+Booting TF-M 8209cb2ed
+Creating an empty ITS flash layout.
+Creating an empty PS flash layout.
+[INF][Crypto] Provisioning entropy seed... complete.
+*** Booting Zephyr OS build zephyr-v3.3.0-4041-g7ba5ecf451ef ***
+TF-M IPC on mps2_an521_ns
+The version of the PSA Framework API is 257.
+The PSA Crypto service minor version is 1.
+Generating 256 bytes of random data:
+71 03 DD 50 8E E5 00 C7 E0 61 7B EB 77 15 E9 38 
+E9 A8 7D 0C 51 23 76 9F C3 61 E9 8B 8A 67 BD 14 
+73 A3 2C 6E E5 8C E3 19 53 6B 50 55 A8 A7 F4 7B 
+56 03 60 AA 48 B6 DF 04 33 56 BE 84 43 FA 4E AC 
+D7 6E 2E 2E 1D 7E 46 69 D5 9B B0 42 5C 54 E4 09 
+73 9E 4F 55 F8 3E 05 9E A3 DE 46 D3 E4 02 B0 9C 
+F3 21 9F 20 85 74 34 07 19 79 07 B8 02 B5 0E 90 
+74 21 BE B5 09 4C D7 20 D8 43 F7 72 23 1C F0 3E 
+77 7B D3 70 29 72 69 D3 7F 1F 61 16 12 73 D5 89 
+C5 8B D1 A3 7B 4B FD F5 11 C2 B1 9A C0 A5 F9 7B 
+16 3D 98 17 66 FE E9 F4 FE 37 76 62 E0 E6 83 99 
+69 26 41 CD FF 0C 44 AC F9 F4 91 B8 CA 63 5E 1D 
+B9 C4 38 D6 0C 11 19 1B 94 BE C9 4F EC 2E 5A 05 
+3F 72 5F 41 44 3C 91 39 AC 2D 50 75 DF FD D3 11 
+39 F2 43 18 D7 69 B0 A3 99 0C C0 6E 83 84 1A A8 
+B0 37 6C 8E 32 B2 8E 4F AA 12 97 09 09 87 D3 FD 
+qemu-system-arm: terminating on signal 2
+```
+
+But after 452c67a427, for example v8.0.0-918-g6972ef1440, I get :
+
+```
+$ qemu-system-arm -M mps2-an521 -device loader,file=tfm_merged.hex -serial stdio
+[INF] Beginning TF-M provisioning
+[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
+[Sec Thread] Secure image initializing!
+Booting TF-M 8209cb2ed
+Creating an empty ITS flash layout.
+Creating an empty PS flash layout.
+[INF][Crypto] Provisioning entropy seed... complete.
+*** Booting Zephyr OS build zephyr-v3.3.0-4041-g7ba5ecf451ef ***
+TF-M IPC on mps2_an521_ns
+qemu-system-arm: ../target/arm/cpu.h:2396: arm_is_secure_below_el3: Assertion `!arm_feature(env, ARM_FEATURE_M)' failed.
+Aborted
+```
+Steps to reproduce:
+1. Build the Zephyr tfm_merged.hex file from Zephyr 7ba5ecf451 https://github.com/zephyrproject-rtos/zephyr/commit/7ba5ecf451ef29f96b30dbe5f0e54c1865839093 : ``west -v build -p -b mps2_an521_ns ./samples/tfm_integration/tfm_ipc``
+2. Build qemu-system-arm and run : ``qemu-system-arm -M mps2-an521 -device loader,file=tfm_merged.hex -serial stdio``
+Additional information:
+More info to build Zephyr TF-M IPC example on the official repo https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/tfm_integration/tfm_ipc
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1697 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1697
new file mode 100644
index 00000000..094982db
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1697
@@ -0,0 +1,19 @@
+qemu-arm -cpu cortex-m55 dummy_test qemu-arm: ../accel/tcg/user-exec.c:492: page_set_flags: Assertion `last <= GUEST_ADDR_MAX' failed.
+Description of problem:
+Basic testing failed for cortex m55
+Steps to reproduce:
+1.Pulled the newest qemu 8.0.50
+
+2.Create a Dummy test with only return 0 in main function
+
+3.run  ` arm-none-eabi-gcc -o dummy_test -O2 -g -mcpu=cortex-m55 dummy_test.cc --specs=rdimon.specs` and then `qemu-arm -cpu cortex-m55 dummy_test`
+
+`arm-none-eabi-gcc (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 12.2.1 20230214
+Copyright (C) 2022 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.`
+
+`qemu-arm version 8.0.50 (v8.0.0-1739-g5f9dd6a8ce)
+Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers`
+Additional information:
+It is a known problem in another issues: https://gitlab.com/qemu-project/qemu/-/issues/1528#note_1389268261.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1704 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1704
new file mode 100644
index 00000000..79e3e235
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1704
@@ -0,0 +1,69 @@
+Booting arm64 Linux in TCG mode fails with "ERROR:../tcg/tcg.c:4317:temp_load: code should not be reached"
+Description of problem:
+Linux seems to boot successfully, but around loading/executing userspace, QEMU crashes with an error:
+
+```
+[    4.047919] EXT4-fs (vda): mounted filesystem 59b147ee-5613-43a2-aab4-eaceb6e95be5 with ordered data mode. Quota mode: none.
+[    4.049630] VFS: Mounted root (ext4 filesystem) on device 254:0.
+[    4.055437] devtmpfs: mounted
+[    4.160039] Freeing unused kernel memory: 8256K
+[    4.161855] Run /sbin/init as init process
+[    4.547387] EXT4-fs (vda): re-mounted 59b147ee-5613-43a2-aab4-eaceb6e95be5. Quota mode: none.
+**
+ERROR:../tcg/tcg.c:4317:temp_load: code should not be reached
+Bail out! ERROR:../tcg/tcg.c:4317:temp_load: code should not be reached
+zsh: abort      /home/mark/.opt/apps/qemu-v8.0.0-1645-ge6dd5e782b/bin/qemu-system-aarch64 -sm
+```
+Steps to reproduce:
+1. Run the provided qemu commandline
+2. Wait for QEMU to crash
+Additional information:
+I attempted a bisect, which suggests that the first bad commit is:
+
+```
+[e6dd5e782becfe6d51f3575c086f5bd7162421d0] target/arm: Use tcg_gen_qemu_{ld, st}_i128 in gen_sve_{ld, st}r 
+```
+
+The full bisect log is:
+
+```
+[mark@lakrids:~/src/qemu]% git bisect log
+git bisect start
+# good: [f7f686b61cf7ee142c9264d2e04ac2c6a96d37f8] Update version for 8.0.2 release
+git bisect good f7f686b61cf7ee142c9264d2e04ac2c6a96d37f8
+# bad: [5f9dd6a8ce3961db4ce47411ed2097ad88bdf5fc] Merge tag 'pull-9p-20230608' of https://github.com/cschoenebeck/qemu into staging
+git bisect bad 5f9dd6a8ce3961db4ce47411ed2097ad88bdf5fc
+# good: [c1eb2ddf0f8075faddc5f7c3d39feae3e8e9d6b4] Update version for v8.0.0 release
+git bisect good c1eb2ddf0f8075faddc5f7c3d39feae3e8e9d6b4
+# good: [1a42d9d472b61e4db2fb16800495d402cb9b94af] tcg/sparc64: Split out tcg_out_movi_s32
+git bisect good 1a42d9d472b61e4db2fb16800495d402cb9b94af
+# good: [a30498fcea5a8b9c544324ccfb0186090104b229] tcg/riscv: Support CTZ, CLZ from Zbb
+git bisect good a30498fcea5a8b9c544324ccfb0186090104b229
+# good: [759573d05b808344f7047f893d2dd095884dfa4d] test-cutils: Add coverage of qemu_strtod
+git bisect good 759573d05b808344f7047f893d2dd095884dfa4d
+# good: [dc2a070d125772fe30384596d4d4ce6d9950b004] hw/arm/allwinner-r40: add Clock Control Unit
+git bisect good dc2a070d125772fe30384596d4d4ce6d9950b004
+# good: [c0dde5fc5ccce56b69095bc29af72987efd65d1e] accel/tcg: Fix undefined shift in store_whole_le16
+git bisect good c0dde5fc5ccce56b69095bc29af72987efd65d1e
+# bad: [e58e55dd8d5777f8a58ce30cfe04a8023282eb80] meson: fix "static build" entry in summary
+git bisect bad e58e55dd8d5777f8a58ce30cfe04a8023282eb80
+# bad: [5c13983e23de4095e2dfa8bc52333ef40ebe40db] target/arm: Sink gen_mte_check1 into load/store_exclusive
+git bisect bad 5c13983e23de4095e2dfa8bc52333ef40ebe40db
+# good: [6c4f229a2e0d6f882bae389ce0c5bdaea712ce0f] tests: avocado: boot_linux_console: Add test case for bpim2u
+git bisect good 6c4f229a2e0d6f882bae389ce0c5bdaea712ce0f
+# good: [e452ca5af88fc49b3026c2de0f1e65fd18d1a656] target/arm: Introduce finalize_memop_{atom,pair}
+git bisect good e452ca5af88fc49b3026c2de0f1e65fd18d1a656
+# good: [d450bd0157be43d273116c3e3617883c8a0ac3d1] target/arm: Use tcg_gen_qemu_{st, ld}_i128 for do_fp_{st, ld}
+git bisect good d450bd0157be43d273116c3e3617883c8a0ac3d1
+# bad: [e6dd5e782becfe6d51f3575c086f5bd7162421d0] target/arm: Use tcg_gen_qemu_{ld, st}_i128 in gen_sve_{ld, st}r
+git bisect bad e6dd5e782becfe6d51f3575c086f5bd7162421d0
+# good: [e6073d88cc1fb43b00be16f79d9d6b0f9d2276f5] target/arm: Use tcg_gen_qemu_st_i128 for STZG, STZ2G
+git bisect good e6073d88cc1fb43b00be16f79d9d6b0f9d2276f5
+# first bad commit: [e6dd5e782becfe6d51f3575c086f5bd7162421d0] target/arm: Use tcg_gen_qemu_{ld, st}_i128 in gen_sve_{ld, st}r
+```
+
+Each build step was performed with:
+
+```
+ git clean -fdx && ./configure --prefix=/home/mark/.opt/apps/qemu-$(git describe --long HEAD) --enable-debug-info --disable-strip && make -j64 && make install
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1737 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1737
new file mode 100644
index 00000000..30dbe209
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1737
@@ -0,0 +1,49 @@
+qemu-aarch64: Incorrect result for ssra instruction when using vector lengths of 1024-bit or higher.
+Description of problem:
+```
+#include <arm_sve.h>
+#include <stdio.h>
+
+#define SZ 32
+
+int main(int argc, char* argv[]) {
+  svbool_t pg = svptrue_b64();
+  uint64_t VL = svcntd();
+
+  fprintf(stderr, "One SVE vector can hold %li uint64_ts\n", VL);
+
+  int64_t sr[SZ], sx[SZ], sy[SZ];
+  uint64_t ur[SZ], ux[SZ], uy[SZ];
+
+  for (uint64_t i = 0; i < SZ; ++i) {
+    sx[i] = ux[i] = 0;
+    sy[i] = uy[i] = 1024;
+  }
+
+  for (uint64_t i = 0; i < SZ; i+=VL) {
+    fprintf(stderr, "Processing elements %li - %li\n", i, i + VL - 1);
+
+    svint64_t SX = svld1(pg, sx + i);
+    svint64_t SY = svld1(pg, sy + i);
+    svint64_t SR = svsra(SX, SY, 4);
+    svst1(pg, sr + i, SR);
+
+    svuint64_t UX = svld1(pg, ux + i);
+    svuint64_t UY = svld1(pg, uy + i);
+    svuint64_t UR = svsra(UX, UY, 4);
+    svst1(pg, ur + i, UR);
+  }
+
+  for (uint64_t i = 0; i < SZ; ++i) {
+    fprintf(stderr, "sr[%li]=%li, ur[%li]\n", i, sr[i], ur[i]);
+  }
+
+  return 0;
+}
+```
+Steps to reproduce:
+1. Build the above C source using "gcc -march=armv9-a -O1 ssra.c", can also use clang.
+2. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=64 ./a.out" and you'll see the expected result of 64 (signed and unsigned)
+3. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=128 ./a.out" and you'll see the expected result of 64 for unsigned but the signed result is 0. This suggests the emulation of SVE2 ssra instruction is incorrect for this and bigger vector lengths.
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1740 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1740
new file mode 100644
index 00000000..d4db06c7
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1740
@@ -0,0 +1,73 @@
+QEMU Abort in Cortex-M Exception raising
+Description of problem:
+When an exception should be raised in a ARM Cortex-M board QEMU aborts.
+
+```
+$ qemu-system-arm --version
+QEMU emulator version 8.0.2
+
+$ qemu-system-arm -M stm32vldiscovery -device loader,file=/tmp/raw-hardfault.hex -d in_asm,exec,int
+[...]
+Trace 0: 0x7f2aa8000680 [00800400/00000110/00000110/ff200000]
+----------------
+IN:
+0x00000140:  f64b 6eef  movw     lr, #0xbeef
+0x00000144:  f6cd 6ead  movt     lr, #0xdead
+0x00000148:  4770       bx       lr
+
+Linking TBs 0x7f2aa8000680 index 0 -> 0x7f2aa80007c0
+Trace 0: 0x7f2aa80007c0 [00800400/00000140/00000110/ff200000]
+qemu-system-arm: ../qemu-8.0.2/target/arm/cpu.h:2396: arm_is_secure_below_el3: Assertion `!arm_feature(env, ARM_FEATURE_M)' failed.
+```
+
+Expected behavior:
+```
+$ qemu-system-arm --version
+QEMU emulator version 7.1.0
+
+$ qemu-system-arm -M stm32vldiscovery -device loader,file=raw-hardfault.hex -d in_asm,exec,int
+[...]
+Trace 0: 0x7fb488000680 [00800400/00000110/00000110/ff000000]
+----------------
+IN:
+0x00000140:  f64b 6eef  movw     lr, #0xbeef
+0x00000144:  f6cd 6ead  movt     lr, #0xdead
+0x00000148:  4770       bx       lr
+
+Linking TBs 0x7fb488000680 [00000110] index 0 -> 0x7fb488000780 [00000140]
+Trace 0: 0x7fb488000780 [00800400/00000140/00000110/ff000000]
+Taking exception 3 [Prefetch Abort] on CPU 0
+...at fault address 0xdeadbeee
+...with CFSR.IACCVIOL
+...BusFault with BFSR.STKERR
+...taking pending nonsecure exception 3
+...loading from element 3 of non-secure vector table at 0xc
+...loaded new PC 0x0
+```
+Steps to reproduce:
+1. Run any Cortex-M firmware that raises an exception. (minimal example attached)
+Additional information:
+- Minimal Reproducer:
+[raw-hardfault.hex](/uploads/113889116675b608e05748280d1db354/raw-hardfault.hex)
+- Assert introduced in fcc7404eff24b4c8b322fb27ca5ae7f3113129c3.
+- Stacktrace:
+```
+#4  0x00007ffff6a483d6 in __assert_fail () from /usr/lib/libc.so.6
+#5  0x00007ffff73afe67 in arm_is_secure_below_el3 (env=0x55555712f9b0) at target/arm/cpu.h:2396
+#6  0x00007ffff73afedd in arm_is_el2_enabled (env=0x55555712f9b0) at target/arm/cpu.h:2448
+#7  0x00007ffff73afcd4 in arm_el_is_aa64 (env=0x55555712f9b0, el=0x1) at target/arm/cpu.h:2509
+#8  0x00007ffff73af68f in compute_fsr_fsc (env=0x55555712f9b0, fi=0x7fffffff7098, target_el=0x1, mmu_idx=0x1, ret_fsc=0x7fffffff6fe0)
+    at target/arm/tcg/tlb_helper.c:71
+#9  0x00007ffff73af483 in arm_deliver_fault (cpu=0x55555712d250, addr=0xdeadbeee, access_type=MMU_INST_FETCH, mmu_idx=0x1, fi=0x7fffffff7098)
+    at target/arm/tcg/tlb_helper.c:114
+#10 0x00007ffff73afa4c in arm_cpu_tlb_fill (cs=0x55555712d250, address=0xdeadbeee, size=0x1, access_type=MMU_INST_FETCH, mmu_idx=0x1, probe=0x0, retaddr=0x0)
+    at target/arm/tcg/tlb_helper.c:242
+#11 0x00007ffff74a3a1e in probe_access_internal (env=0x55555712f9b0, addr=0xdeadbeee, fault_size=0x1, access_type=MMU_INST_FETCH, mmu_idx=0x1, nonfault=0x0, phost=0x7fffffff71c8,
+    pfull=0x7fffffff71d0, retaddr=0x0) at accel/tcg/cputlb.c:1555
+#12 0x00007ffff74a4085 in get_page_addr_code_hostp (env=0x55555712f9b0, addr=0xdeadbeee, hostp=0x0) at accel/tcg/cputlb.c:1694
+#13 0x00007ffff7490c0f in get_page_addr_code (env=0x55555712f9b0, addr=0xdeadbeee) at include/exec/exec-all.h:748
+#14 0x00007ffff7490b2a in tb_htable_lookup (cpu=0x55555712d250, pc=0xdeadbeee, cs_base=0x800408, flags=0x110, cflags=0xff200200) at accel/tcg/cpu-exec.c:233
+#15 0x00007ffff748f719 in tb_lookup (cpu=0x55555712d250, pc=0xdeadbeee, cs_base=0x800408, flags=0x110, cflags=0xff200200) at accel/tcg/cpu-exec.c:270
+#16 0x00007ffff748f463 in helper_lookup_tb_ptr (env=0x55555712f9b0) at accel/tcg/cpu-exec.c:425
+#17 0x00007fff6800091c in code_gen_buffer ()
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1742 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1742
new file mode 100644
index 00000000..a1e96d77
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1742
@@ -0,0 +1,95 @@
+Arm64 kernel run with qemu-system-aarch64 crashes handling program using SVE and Streaming SVE modes
+Description of problem:
+The userspace program shown, which switches between SVE/SME states, crashes the kernel on task switch when running under qemu-system-aarch64. This does not reproduce on an Arm Fast Model, but I can't be sure that that is not a timing difference.
+
+The kernel appears to have no space allocated to save SVE state for this process, but also believes that it should save the state, where it then faults.
+Steps to reproduce:
+1. Compile the following program:
+```
+#include <sys/prctl.h>
+
+int main() {
+  asm volatile("msr  s0_3_c4_c7_3, xzr" /*smstart*/);
+  prctl(PR_SVE_SET_VL, 8 * 4);
+  asm volatile("msr  s0_3_c4_c7_3, xzr" /*smstart*/);
+  while (1) {} // Wait to be preempted?
+  return 0;
+}
+```
+With:
+```
+$ aarch64-unknown-linux-gnu-gcc main.c -o main.o -g -O3 -march=armv8.6-a+sve
+```
+Compiler version does not matter I don't think, but in case:
+```
+$ aarch64-unknown-linux-gnu-gcc --version
+aarch64-unknown-linux-gnu-gcc (crosstool-NG 1.25.0.85_61c4cca) 10.4.0
+```
+It is a 10.4.0 built with CrossToolNG.
+
+2. Boot Linux and run the program in the emulated environment. I've found looping it to be more consistent:
+```
+$ while true; do ./main.o; done
+```
+Though sometimes it will crash after only one run.
+Additional information:
+Here is the output from the kernel:
+```
+$ /mnt/virt_root/sme_crash/main.o
+[  190.813392] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
+[  190.818912] Mem abort info:
+[  190.819255]   ESR = 0x0000000096000046
+[  190.819727]   EC = 0x25: DABT (current EL), IL = 32 bits
+[  190.820391]   SET = 0, FnV = 0
+[  190.820757]   EA = 0, S1PTW = 0
+[  190.821145]   FSC = 0x06: level 2 translation fault
+[  190.821635] Data abort info:
+[  190.821978]   ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000
+[  190.822490]   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
+[  190.822991]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
+[  190.823645] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000475f1000
+[  190.824269] [0000000000000000] pgd=0800000047645003, p4d=0800000047645003, pud=0800000047641003, pmd=0000000000000000
+[  190.826225] Internal error: Oops: 0000000096000046 [#1] PREEMPT SMP
+[  190.826996] Modules linked in:
+[  190.827748] CPU: 0 PID: 198 Comm: main.o Not tainted 6.4.0-01761-g6aeadf7896bf #1
+[  190.828638] Hardware name: linux,dummy-virt (DT)
+[  190.829304] pstate: 234000c5 (nzCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
+[  190.830115] pc : sve_save_state+0x4/0xf0
+[  190.831378] lr : fpsimd_save+0x184/0x1f0
+[  190.831848] sp : ffff80008047bc70
+[  190.832223] x29: ffff80008047bc70 x28: ffff0000036c49c0 x27: 0000000000000000
+[  190.833182] x26: ffff0000036c4f58 x25: ffff0000036c49c0 x24: ffff0000036c5868
+[  190.834045] x23: 0000000000000020 x22: ffff24441ea31000 x21: 0000000000000001
+[  190.834894] x20: ffff00003fdc50b0 x19: ffffdbbc213940b0 x18: 0000000000000000
+[  190.835759] x17: ffff24441ea31000 x16: ffff800080000000 x15: 0000000000000000
+[  190.836593] x14: 000000000000026c x13: 0000000000000001 x12: 0000000000000020
+[  190.837436] x11: 0000000000000000 x10: 0000000000000001 x9 : 0000000000000800
+[  190.838323] x8 : ffff00003fdcffc0 x7 : ffff00003fdcff40 x6 : 0000000002da9c8c
+[  190.839149] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000000
+[  190.839976] x2 : 0000000000000001 x1 : ffff0000036c56a0 x0 : 0000000000000440
+[  190.840936] Call trace:
+[  190.841406]  sve_save_state+0x4/0xf0
+[  190.841993]  fpsimd_thread_switch+0x24/0xd4
+[  190.842572]  __switch_to+0x20/0x1d4
+[  190.843043]  __schedule+0x2a0/0xa7c
+[  190.843488]  schedule+0x5c/0xc4
+[  190.843912]  do_notify_resume+0x1a4/0x474
+[  190.844410]  el0_interrupt+0xc4/0xd4
+[  190.844855]  __el0_irq_handler_common+0x18/0x24
+[  190.845350]  el0t_64_irq_handler+0x10/0x1c
+[  190.845824]  el0t_64_irq+0x190/0x194
+[  190.846661] Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800)
+[  190.847545] ---[ end trace 0000000000000000 ]---
+[  190.848125] note: main.o[198] exited with irqs disabled
+```
+
+I have looked the kernel functions in the backtrace and it seems to be loading memory fine, so it's not obviously a code generation problem. The pointer loaded prior to the crash is definitely a nullptr.
+
+Removing any of the lines (`while (1) {}` aside) from the example seems to avoid the issue but again, could be timing.
+
+An important point here is that the kernel syscall ABI states that streaming mode will be exited on
+a syscall. I have observed that this does happen as expected. This is why the test case does a syscall, then immediately goes back to streaming mode. And it is perhaps where the confusion starts.
+
+I have confirmed that SME is supported by the emulated CPU and other SME programs do run correctly.
+
+I initially thought this was to do with having many cores, but it reproduces on a single core also.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1790 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1790
new file mode 100644
index 00000000..60af2f7b
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1790
@@ -0,0 +1,29 @@
+[AARCH64] STGP instruction is not writing the value of the second register to memory
+Description of problem:
+My application is built with Clang 16 and the option -fsanitize=memtag-stack.
+It means the the MTE protection is activated for the stack.
+The local variables are tagged and the compiler is often using the STGP instruction "Store Allocation Tag and Pair of registers" in order to transfer the value of two 64-bit registers to memory.
+The following instruction was not working as expected:
+   18004: 69000895     	stgp	x21, x2, [x4]
+The value of the second register x2 is not transferred to the memory.
+Only x21 is written.
+
+I think that the issue is in trans_STGP().
+We don't call finalize_memop_pair() like we do for in the general trans_STP().
+
+```
+diff --git a/target/arm/tcg/translate-a64.c b/target/arm/tcg/translate-a64.c
+index 7d0c8f79a7..f599f3e136 100644
+--- a/target/arm/tcg/translate-a64.c
++++ b/target/arm/tcg/translate-a64.c
+@@ -3034,6 +3034,8 @@ static bool trans_STGP(DisasContext *s, arg_ldstpair *a)
+ 
+     tcg_rt = cpu_reg(s, a->rt);
+     tcg_rt2 = cpu_reg(s, a->rt2);
++    mop = a->sz + 1;
++    mop = finalize_memop_pair(s, mop);
+ 
+     assert(a->sz == 3);
+```
+
+With this fix, my OS (Kinibi) is now able to boot.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1799 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1799
new file mode 100644
index 00000000..3c3cfe60
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1799
@@ -0,0 +1,177 @@
+Support running real-world Android on Arm by supporting one-register list for the POP (LDMIA) Thumb32 instruction.
+Steps to reproduce:
+1. Get any aarch64 Linux on QEMU for x86_64 running. Make sure that Wayland is running. (For example, build PostmarketOS with "phosh" for aarch64 and install it.)
+2. Install waydroid (e.g. `apk add waydroid`).
+3. Install the LineageOS 18.1 for waydroid image (e.g. `waydroid init`).
+4. Run the waydroid-container (e.g. `rc-service waydroid-container restart`).
+5. Start the waydroid session (e.g. click on the "Waydroid" symbol on the graphical user interface).
+6. Observe the waydroid log file (e.g. run `waydroid logcat`).
+Additional information:
+The output of the Android log (using `waydroid logcat`) will be akin:
+
+```
+23908 23908 D AndroidRuntime: >>>>>> START com.android.internal.os.ZygoteInit uid 0 <<<<<<
+23908 23908 I AndroidRuntime: Using default boot image
+23908 23908 I AndroidRuntime: Leaving lock profiling enabled
+23908 23908 E cutils-trace: Error opening trace file: No such file or directory (2)
+23908 23908 I zygote  : option[0]=-Xzygote
+23908 23908 I zygote  : option[1]=exit
+23908 23908 I zygote  : option[2]=vfprintf
+23908 23908 I zygote  : option[3]=sensitiveThread
+23908 23908 I zygote  : option[4]=-verbose:gc
+23908 23908 I zygote  : option[5]=-XX:PerfettoHprof=true
+23908 23908 I zygote  : option[6]=-Xms8m
+23908 23908 I zygote  : option[7]=-Xmx512m
+23908 23908 I zygote  : option[8]=-XX:HeapGrowthLimit=192m
+23908 23908 I zygote  : option[9]=-XX:HeapMinFree=8m
+23908 23908 I zygote  : option[10]=-XX:HeapMaxFree=16m
+23908 23908 I zygote  : option[11]=-XX:HeapTargetUtilization=0.6
+23908 23908 I zygote  : option[12]=-Xusejit:true
+23908 23908 I zygote  : option[13]=-Xjitsaveprofilinginfo
+23908 23908 I zygote  : option[14]=-XjdwpOptions:suspend=n,server=y
+23908 23908 I zygote  : option[15]=-XjdwpProvider:default
+23908 23908 I zygote  : option[16]=-Xopaque-jni-ids:swapable
+23908 23908 I zygote  : option[17]=-Xlockprofthreshold:500
+23908 23908 I zygote  : option[18]=-Xcompiler-option
+23908 23908 I zygote  : option[19]=--instruction-set-variant=generic
+23908 23908 I zygote  : option[20]=-Xcompiler-option
+23908 23908 I zygote  : option[21]=--instruction-set-features=default
+23908 23908 I zygote  : option[22]=-Xcompiler-option
+23908 23908 I zygote  : option[23]=--generate-mini-debug-info
+23908 23908 I zygote  : option[24]=-Ximage-compiler-option
+23908 23908 I zygote  : option[25]=--runtime-arg
+23908 23908 I zygote  : option[26]=-Ximage-compiler-option
+23908 23908 I zygote  : option[27]=-Xms64m
+23908 23908 I zygote  : option[28]=-Ximage-compiler-option
+23908 23908 I zygote  : option[29]=--runtime-arg
+23908 23908 I zygote  : option[30]=-Ximage-compiler-option
+23908 23908 I zygote  : option[31]=-Xmx64m
+23908 23908 I zygote  : option[32]=-Ximage-compiler-option
+23908 23908 I zygote  : option[33]=--dirty-image-objects=/system/etc/dirty-image-objects
+23908 23908 I zygote  : option[34]=-Ximage-compiler-option
+23908 23908 I zygote  : option[35]=--instruction-set-variant=generic
+23908 23908 I zygote  : option[36]=-Ximage-compiler-option
+23908 23908 I zygote  : option[37]=--instruction-set-features=default
+23908 23908 I zygote  : option[38]=-Ximage-compiler-option
+23908 23908 I zygote  : option[39]=--generate-mini-debug-info
+23908 23908 I zygote  : option[40]=-Duser.locale=en-US
+23908 23908 I zygote  : option[41]=--cpu-abilist=armeabi-v7a,armeabi
+23908 23908 I zygote  : option[42]=-Xcore-platform-api-policy:just-warn
+23908 23908 I zygote  : option[43]=-Xfingerprint:waydroid/lineage_waydroid_arm64/waydroid_arm64:11/RQ3A.211001.001/48:userdebug/test-keys
+23908 23908 I zygote  : Core platform API reporting enabled, enforcing=false
+23908 23908 D zygote  : Time zone APEX ICU file found: /apex/com.android.tzdata/etc/icu/icu_tzdata.dat
+23908 23908 D zygote  : I18n APEX ICU file found: /apex/com.android.i18n/etc/icu/icudt66l.dat
+23908 23908 I zygote  : Using memfd for future sealing
+23908 23908 W zygote  : Using default instruction set features for ARM CPU variant (generic) using conservative defaults
+   49    49 I tombstoned: received crash request for pid 23908
+23908 23908 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
+23908 23908 F DEBUG   : LineageOS Version: '18.1-20230723-VANILLA-waydroid_arm64'
+23908 23908 F DEBUG   : Build fingerprint: 'waydroid/lineage_waydroid_arm64/waydroid_arm64:11/RQ3A.211001.001/48:userdebug/test-keys'
+23908 23908 F DEBUG   : Revision: '0'
+23908 23908 F DEBUG   : ABI: 'arm'
+23908 23908 F DEBUG   : Timestamp: 2023-07-28 14:13:34+0000
+23908 23908 F DEBUG   : pid: 23908, tid: 23908, name: main  >>> zygote <<<
+23908 23908 F DEBUG   : uid: 0
+23908 23908 F DEBUG   : signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0x709443da (*pc=0x4000e8bd)
+23908 23908 F DEBUG   :     r0  54647764  r1  3fb9709b  r2  fffffe56  r3  4337ffff
+23908 23908 F DEBUG   :     r4  707184b0  r5  3fdaaaaa  r6  f295837e  r7  00000001
+23908 23908 F DEBUG   :     r8  00000000  r9  f7986e00  r10 ffa33320  r11 ffa332e4
+23908 23908 F DEBUG   :     ip  e9930ba4  sp  ffa332cc  lr  709443d5  pc  709443da
+23908 23908 F DEBUG   : 
+23908 23908 F DEBUG   : backtrace:
+23908 23908 F DEBUG   :       #00 pc 0007e3da  /apex/com.android.art/javalib/arm/boot.oat (art_jni_trampoline+34) (BuildId: 4af94ec040111dd87be55d34780e36769428675c)
+23908 23908 F DEBUG   :       #01 pc 000d39d5  /apex/com.android.art/lib/libart.so (art_quick_invoke_stub_internal+68) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #02 pc 004f0759  /apex/com.android.art/lib/libart.so (art_quick_invoke_static_stub+276) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #03 pc 0012ca93  /apex/com.android.art/lib/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+166) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #04 pc 00240bbf  /apex/com.android.art/lib/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+254) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #05 pc 002388df  /apex/com.android.art/lib/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+746) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #06 pc 004e44db  /apex/com.android.art/lib/libart.so (MterpInvokeStatic+482) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #07 pc 000ce594  /apex/com.android.art/lib/libart.so (mterp_op_invoke_static+20) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #08 pc 003bdaa0  /system/framework/framework.jar
+23908 23908 F DEBUG   :       #09 pc 0023182b  /apex/com.android.art/lib/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool, bool) (.llvm.10727712076471079728)+254) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #10 pc 00238109  /apex/com.android.art/lib/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+144) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #11 pc 00239581  /apex/com.android.art/lib/libart.so (bool art::interpreter::DoCall<true, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+536) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #12 pc 004e7239  /apex/com.android.art/lib/libart.so (MterpInvokeStaticRange+372) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #13 pc 000ce894  /apex/com.android.art/lib/libart.so (mterp_op_invoke_static_range+20) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #14 pc 003bd9d4  /system/framework/framework.jar
+23908 23908 F DEBUG   :       #15 pc 0023182b  /apex/com.android.art/lib/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool, bool) (.llvm.10727712076471079728)+254) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #16 pc 00238109  /apex/com.android.art/lib/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+144) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #17 pc 00239581  /apex/com.android.art/lib/libart.so (bool art::interpreter::DoCall<true, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+536) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #18 pc 004e7239  /apex/com.android.art/lib/libart.so (MterpInvokeStaticRange+372) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #19 pc 000ce894  /apex/com.android.art/lib/libart.so (mterp_op_invoke_static_range+20) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #20 pc 003bc286  /system/framework/framework.jar
+23908 23908 F DEBUG   :       #21 pc 0023182b  /apex/com.android.art/lib/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool, bool) (.llvm.10727712076471079728)+254) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #22 pc 00238109  /apex/com.android.art/lib/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+144) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #23 pc 002388c7  /apex/com.android.art/lib/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+722) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #24 pc 004e44db  /apex/com.android.art/lib/libart.so (MterpInvokeStatic+482) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #25 pc 000ce594  /apex/com.android.art/lib/libart.so (mterp_op_invoke_static+20) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #26 pc 003b1c7c  /system/framework/framework.jar
+23908 23908 F DEBUG   :       #27 pc 0023182b  /apex/com.android.art/lib/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool, bool) (.llvm.10727712076471079728)+254) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #28 pc 0023803d  /apex/com.android.art/lib/libart.so (art::interpreter::EnterInterpreterFromEntryPoint(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*)+120) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #29 pc 004d321b  /apex/com.android.art/lib/libart.so (artQuickToInterpreterBridge+686) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #30 pc 000d8561  /apex/com.android.art/lib/libart.so (art_quick_to_interpreter_bridge+32) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #31 pc 0042dbaf  /system/framework/arm/boot-framework.oat (android.graphics.ColorSpace$Rgb.isSrgb+446) (BuildId: 7ce3c24f3f20164927036fc8f58e1baa2a8f4020)
+23908 23908 F DEBUG   :       #32 pc 0042cddf  /system/framework/arm/boot-framework.oat (android.graphics.ColorSpace$Rgb.<init>+822) (BuildId: 7ce3c24f3f20164927036fc8f58e1baa2a8f4020)
+23908 23908 F DEBUG   :       #33 pc 000d39d5  /apex/com.android.art/lib/libart.so (art_quick_invoke_stub_internal+68) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #34 pc 004f0627  /apex/com.android.art/lib/libart.so (art_quick_invoke_stub+282) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #35 pc 0012ca81  /apex/com.android.art/lib/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+148) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #36 pc 00240bbf  /apex/com.android.art/lib/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+254) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #37 pc 00239597  /apex/com.android.art/lib/libart.so (bool art::interpreter::DoCall<true, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+558) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #38 pc 004e6b7d  /apex/com.android.art/lib/libart.so (MterpInvokeDirectRange+392) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #39 pc 000ce814  /apex/com.android.art/lib/libart.so (mterp_op_invoke_direct_range+20) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #40 pc 003bce74  /system/framework/framework.jar
+23908 23908 F DEBUG   :       #41 pc 004e6cdd  /apex/com.android.art/lib/libart.so (MterpInvokeDirectRange+744) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #42 pc 000ce814  /apex/com.android.art/lib/libart.so (mterp_op_invoke_direct_range+20) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #43 pc 003bce8c  /system/framework/framework.jar
+23908 23908 F DEBUG   :       #44 pc 004e6cdd  /apex/com.android.art/lib/libart.so (MterpInvokeDirectRange+744) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #45 pc 000ce814  /apex/com.android.art/lib/libart.so (mterp_op_invoke_direct_range+20) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #46 pc 003be6b6  /system/framework/framework.jar
+23908 23908 F DEBUG   :       #47 pc 0023182b  /apex/com.android.art/lib/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool, bool) (.llvm.10727712076471079728)+254) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #48 pc 0023803d  /apex/com.android.art/lib/libart.so (art::interpreter::EnterInterpreterFromEntryPoint(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*)+120) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #49 pc 004d321b  /apex/com.android.art/lib/libart.so (artQuickToInterpreterBridge+686) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #50 pc 000d8561  /apex/com.android.art/lib/libart.so (art_quick_to_interpreter_bridge+32) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #51 pc 000d39d5  /apex/com.android.art/lib/libart.so (art_quick_invoke_stub_internal+68) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #52 pc 004f0759  /apex/com.android.art/lib/libart.so (art_quick_invoke_static_stub+276) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+23908 23908 F DEBUG   :       #53 pc 0012ca93  /apex/com.android.art/lib/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+166) (BuildId: d0f40e4862987997ffa9c0a264e61174)
+```
+
+
+Analyzing with `gdb` (by repeatedly calling `gdb -p "$(ps xua | grep zygote | grep -v grep | grep -v zygote64 | awk {'print $2'})"` until `gdb` attaches earlier to the current `zygote` process than the offending instruction is reached) reveals that the crash happens here:
+
+```
+   0x6fc373b0 <+944>:   cmp     r3, #223        @ 0xdf
+   0x6fc373b2 <+946>:   movs    r6, r0
+   0x6fc373b4 <+948>:   movs    r0, r5
+   0x6fc373b6 <+950>:   movs    r0, r0
+   0x6fc373b8 <+952>:   push    {lr}
+   0x6fc373ba <+954>:   sub     sp, #4
+   0x6fc373bc <+956>:   vstr    d0, [sp, #12]
+   0x6fc373c0 <+960>:   vstr    d1, [sp, #20]
+   0x6fc373c4 <+964>:   mov     r4, r0
+   0x6fc373c6 <+966>:   ldr     r2, [sp, #20]
+   0x6fc373c8 <+968>:   ldr     r3, [sp, #24]
+   0x6fc373ca <+970>:   ldr     r0, [sp, #12]
+   0x6fc373cc <+972>:   ldr     r1, [sp, #16]
+   0x6fc373ce <+974>:   ldr.w   r12, [r4, #20]
+   0x6fc373d2 <+978>:   blx     r12
+   0x6fc373d4 <+980>:   vmov    d0, r0, r1
+   0x6fc373d8 <+984>:   add     sp, #4
+=> 0x6fc373da <+986>:   ldmia.w sp!, {lr}
+   0x6fc373de <+990>:   bx      lr
+```
+
+(note that the actual address changes for every instance of `zygote`, probably due to address-space layout randomization)
+
+The instruction at this location is 0xe8bd4000, as evidenced by:
+
+```
+(gdb) x/16hx 0x6fc373da
+0x6fc373da <oatexec+986>:       0xe8bd  0x4000  0x4770  0x2c0f  0x0006  0x0020  0x0000  0xb500
+0x6fc373ea <oatexec+1002>:      0xb081  0xed8d  0x0b03  0x4604  0x9803  0x9904  0xf8d4  0xc014
+```
+
+The disassembly into `ldmia.w sp!, {lr}` is indeed correct. However, such an instruction [would be assembled](https://developer.arm.com/documentation/ddi0308/d/Thumb-Instructions/Alphabetical-list-of-Thumb-instructions/POP?lang=en) into `pop lr` and then into `ldr.w lr,[sp,#-4]`, which would be encoded differently. Hence, the assembly into this instruction was incorrect in the first place.
+
+It turns out that the assembly error is due to an error in the [`vixl` ARMv8 Runtime Code Generation Library](https://github.com/Linaro/vixl), which is also used by Android. This error [has been fixed by Feb 9, 2021](https://github.com/Linaro/vixl/commit/b0a2e281aebbf93e6ee521dcc40ba6dd2aa5124d). However, this fix has [not made it into Android 13](https://android.googlesource.com/platform/external/vixl/+log/02ab12aafeb5278d89184ae6a3ff3a7883b34c5e). Thus, at least Android 11, Android 12, Android 13 cannot run on current `qemu-system-aarch64`, while it should.
+
+Users of the Android emulator (also based on QEMU) do not seem to suffer from this bug because the Android QEMU [has bitrotted since the year 2018](https://android.googlesource.com/platform/external/qemu/+log/e7390f2265257d66093dfe858ce3a47b2e1de539/target/arm/translate.c) and hence has not seen any Arm emulation modernization in QEMU (e.g. the Tiny Code Generator) since, and only this modernization has exposed this bug in the first place.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1812 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1812
new file mode 100644
index 00000000..b80e492c
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1812
@@ -0,0 +1,25 @@
+older programs running under qemu-aarch64 segfaults
+Description of problem:
+Numerous aarch64 programs segfaults when run under qemu-aarch64.
+Steps to reproduce:
+1. Install an arm64 chroot (with working qemu-aarch64 binfmt_misc setup):
+```
+debootstrap --variant=minbase --arch=arm64 jessie /tmp/jessie-arm64/ http://archive.debian.org/debian
+or
+debootstrap --variant=minbase --arch=arm64 xenial /tmp/xenial-arm64/ http://ports.ubuntu.com/
+```
+2. build qemu-aarch64; cp qemu-aarch64 /tmp/jessie-arm64/
+3. chroot /tmp/jessie-arm64/
+4. ./qemu-aarch64 /bin/ls
+```
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault 
+```
+Additional information:
+Old userspace (eg Debian jessie, Ubuntu xenial) does not work within qemu 8.1-rc2 aarch64 linux-user emulation, since commit 59b6b42cd3446862567637f3a7ab31d69c9bef51 .  My guess is that old userspace isn't prepared for recent CPU features, but it still smells strange.
+
+Not all programs segfaults. dash works, ls or bash does not.
+
+A chroot is easier in this case, since many old programs don't run inside current environment, like asserting while reading locale-specific information.  To run debootstrap and to enter the resulting chroot, a working qemu-aarch64 binfmt_misc setup is needed.
+
+Reverting the mentioned commit makes everything work again.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1833 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1833
new file mode 100644
index 00000000..a74f7bdb
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1833
@@ -0,0 +1,84 @@
+ARM64 SME ST1Q incorrectly stores 9 bytes (rather than 16) per 128-bit element
+Description of problem:
+QEMU incorrectly stores 9 bytes instead of 16 per 128-bit element in the ST1Q SME instruction (https://developer.arm.com/documentation/ddi0602/2022-06/SME-Instructions/ST1Q--Contiguous-store-of-quadwords-from-128-bit-element-ZA-tile-slice-). It copies the first byte of the upper 64-bits, then lower the 64-bits.
+
+This seems to be a simple issue; I tracked it down to:
+https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/tcg/sme_helper.c?ref_type=heads#L382
+
+Updating that `+ 1` to a `+ 8` fixes the problem.
+Steps to reproduce:
+```c
+#include <stdio.h>
+#include <stdint.h>
+#include <string.h>
+
+void st1q_sme_copy_test(uint8_t* src,  uint8_t* dest) {
+  asm volatile(
+    "smstart sm\n"
+    "smstart za\n"
+    "ptrue p0.b\n"
+    "mov x12, xzr\n"
+    "ld1q {za0h.q[w12, 0]}, p0/z, %0\n"
+    "st1q {za0h.q[w12, 0]}, p0, %1\n"
+    "smstop za\n"
+    "smstop sm\n" : : "m"(*src), "m"(*dest) : "w12", "p0");
+}
+
+void print_first_128(uint8_t* data) {
+  putchar('[');
+  for (int i = 0; i < 16; i++) {
+    printf("%02d", data[i]);
+    if (i != 15)
+      printf(", ");
+  }
+  printf("]\n");
+}
+
+int main() {
+  _Alignas(16) uint8_t dest[512] = { };
+  _Alignas(16) uint8_t src[512] = { };
+  for (int i = 0; i < sizeof(src); i++)
+    src[i] = i;
+  puts("Before");
+  printf(" src: ");
+  print_first_128(src);
+  printf("dest: ");
+  print_first_128(dest);
+  st1q_sme_copy_test(src, dest);
+  puts("\nAfter ");
+  printf(" src: ");
+  print_first_128(src);
+  printf("dest: ");
+  print_first_128(dest);
+}
+```
+
+Compile with (requires at least clang ~14, tested with clang 16):<br/>
+`clang ./qemu_repro.c -march=armv9-a+sme+sve -o ./qemu_repro` 
+
+Run with:<br/>
+`qemu-aarch64 -cpu max,sme=on ./qemu_repro`
+
+It's expected just to copy from `src` to `dest` and output:
+```
+Before
+ src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15]
+dest: [00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
+
+After 
+ src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15]
+dest: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15]
+```
+
+But currently outputs:
+```
+Before
+ src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15]
+dest: [00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
+
+After 
+ src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15]
+dest: [00, 08, 09, 10, 11, 12, 13, 14, 15, 00, 00, 00, 00, 00, 00, 00]
+```
+Additional information:
+N/A
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1953 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1953
new file mode 100644
index 00000000..d03aeccf
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1953
@@ -0,0 +1,146 @@
+Segmentation fault when compiling elixir app on qemu aarch64 on x86_64 host
+Description of problem:
+When I try to install an elixir escript using
+
+```
+mix escript.install github upmaru/pakman --force 
+```
+
+I run into a segfault with the following output
+
+```
+
+
+Build and Deploy
+failed Oct 22, 2023 in 1m 27s
+2s
+2s
+22s
+56s
+remote: Compressing objects:  86% (144/167)        
+remote: Compressing objects:  87% (146/167)        
+remote: Compressing objects:  88% (147/167)        
+remote: Compressing objects:  89% (149/167)        
+remote: Compressing objects:  90% (151/167)        
+remote: Compressing objects:  91% (152/167)        
+remote: Compressing objects:  92% (154/167)        
+remote: Compressing objects:  93% (156/167)        
+remote: Compressing objects:  94% (157/167)        
+remote: Compressing objects:  95% (159/167)        
+remote: Compressing objects:  96% (161/167)        
+remote: Compressing objects:  97% (162/167)        
+remote: Compressing objects:  98% (164/167)        
+remote: Compressing objects:  99% (166/167)        
+remote: Compressing objects: 100% (167/167)        
+remote: Compressing objects: 100% (167/167), done.        
+remote: Total 2568 (delta 86), reused 188 (delta 58), pack-reused 2341        
+origin/HEAD set to develop
+Resolving Hex dependencies...
+Resolution completed in 0.872s
+New:
+  castore 1.0.4
+  finch 0.16.0
+  hpax 0.1.2
+  jason 1.4.1
+  mime 2.0.5
+  mint 1.5.1
+  nimble_options 1.0.2
+  nimble_pool 1.0.0
+  slugger 0.3.0
+  telemetry 1.2.1
+  tesla 1.7.0
+  yamerl 0.10.0
+  yaml_elixir 2.8.0
+* Getting tesla (Hex package)
+* Getting jason (Hex package)
+* Getting yaml_elixir (Hex package)
+* Getting slugger (Hex package)
+* Getting finch (Hex package)
+* Getting mint (Hex package)
+* Getting castore (Hex package)
+* Getting hpax (Hex package)
+* Getting mime (Hex package)
+* Getting nimble_options (Hex package)
+* Getting nimble_pool (Hex package)
+* Getting telemetry (Hex package)
+* Getting yamerl (Hex package)
+Resolving Hex dependencies...
+Resolution completed in 0.413s
+Unchanged:
+  castore 1.0.4
+  finch 0.16.0
+  hpax 0.1.2
+  jason 1.4.1
+  mime 2.0.5
+  mint 1.5.1
+  nimble_options 1.0.2
+  nimble_pool 1.0.0
+  slugger 0.3.0
+  telemetry 1.2.1
+  tesla 1.7.0
+  yamerl 0.10.0
+  yaml_elixir 2.8.0
+All dependencies are up to date
+==> mime
+Compiling 1 file (.ex)
+Generated mime app
+==> nimble_options
+Compiling 3 files (.ex)
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault (core dumped)
+```
+Steps to reproduce:
+1. Create a repo using the github action zacksiri/setup-alpine
+2. Install elixir
+3. run `mix escript.install github upmaru/pakman --force`
+Additional information:
+You can use the following github action config as an example / starting point.
+
+
+```yml
+name: 'Deployment'
+
+on:
+  push:
+    branches:
+      - main
+      - master
+      - develop
+
+jobs:
+  build_and_deploy:
+    name: Build and Deploy
+    runs-on: ubuntu-latest
+    steps:
+      - name: 'Checkout'
+        uses: actions/checkout@v3
+        with:
+          ref: ${{ github.event.workflow_run.head_branch }}
+          fetch-depth: 0
+
+      - name: 'Setup Alpine'
+        uses: zacksiri/setup-alpine@master
+        with:
+          branch: v3.18
+          arch: aarch64
+          qemu-repo: edge
+          packages: |
+            zip 
+            tar 
+            sudo 
+            alpine-sdk 
+            coreutils 
+            cmake
+            elixir
+
+      - name: 'Setup PAKman'
+        run: |
+          export MIX_ENV=prod
+
+          mix local.rebar --force
+          mix local.hex --force
+          mix escript.install github upmaru/pakman --force
+        shell: alpine.sh {0}
+```
+
+I'm using alpine 3.18 which has otp25 with jit enabled so I suspect this is something to do with https://gitlab.com/qemu-project/qemu/-/issues/1034
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/1970 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1970
new file mode 100644
index 00000000..208e209e
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/1970
@@ -0,0 +1 @@
+A64 LDRA decode scales the immediate by wrong amount
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2005 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2005
new file mode 100644
index 00000000..6a80c698
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2005
@@ -0,0 +1,29 @@
+qemu-system-aarch64: ../target/arm/helper.c:6757: sve_vqm1_for_el_sm: Assertion `sm' failed.
+Description of problem:
+Qemu crashes when sve is completely disabled for CPU model "max" (`-cpu max,sve=off`). Using any CPU model which does not include SVE, or using only e.g. SVE128 (`-cpu max,sve128=on`) works fine.\
+\
+`#0  0x00007f94b8291dec in __pthread_kill_implementation () at /lib64/libc.so.6 `\
+`#1  0x00007f94b823f0c6 in raise () at /lib64/libc.so.6 `\
+`#2  0x00007f94b82268d7 in abort () at /lib64/libc.so.6 `\
+`#3  0x00007f94b82267eb in _nl_load_domain.cold () at /lib64/libc.so.6 `\
+`#4  0x00007f94b8237016 in  () at /lib64/libc.so.6 `\
+`#5  0x000055d6794aa698 in sve_vqm1_for_el_sm (env=env@entry=0x55d67c6ff9b0, el=el@entry=1, sm=false) at ../target/arm/helper.c:6757 `\
+`#6  0x000055d6794afc29 in sve_vqm1_for_el (el=1, env=0x55d67c6ff9b0) at ../target/arm/helper.c:6763 `\
+`#7  smcr_write (env=0x55d67c6ff9b0, ri=0x55d67c78f600, value=<optimized out>) at ../target/arm/helper.c:6887 `\
+`#8  0x00007f9469bad101 in code_gen_buffer () `\
+`#9  0x000055d67977dc19 in cpu_tb_exec (cpu=cpu@entry=0x55d67c6fd1f0, itb=<optimized out>, tb_exit=tb_exit@entry=0x7f94acdcc4c4) at ../accel/tcg/cpu-exec.c:457 `\
+`#10 0x000055d67977e59f in cpu_loop_exec_tb (tb_exit=0x7f94acdcc4c4, last_tb=<synthetic pointer>, pc=<optimized out>, tb=<optimized out>, cpu=<optimized out>) at ../accel/tcg/cpu-exec.c:919 `\
+`#11 cpu_exec_loop (cpu=cpu@entry=0x55d67c6fd1f0, sc=sc@entry=0x7f94acdcc570) at ../accel/tcg/cpu-exec.c:1040 `\
+`#12 0x000055d67977ee7d in cpu_exec_setjmp (cpu=0x55d67c6fd1f0, sc=0x7f94acdcc570) at ../accel/tcg/cpu-exec.c:1057 `\
+`#13 0x000055d679787c3d in cpu_exec (cpu=0x55d67c6fd1f0) at ../accel/tcg/cpu-exec.c:1083 `\
+`#14 0x000055d6797a1d52 in tcg_cpus_exec (cpu=0x55d67c6fd1f0) at ../accel/tcg/tcg-accel-ops.c:75 `\
+`#15 mttcg_cpu_thread_fn (arg=arg@entry=0x55d67c6fd1f0) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 `\
+`#16 0x000055d679938698 in qemu_thread_start (args=0x55d67c7a1500) at ../util/qemu-thread-posix.c:541 `\
+`#17 0x00007f94b828ff44 in start_thread () at /lib64/libc.so.6 `\
+`#18 0x00007f94b8318314 in clone () at /lib64/``libc.so``.6`\
+ \
+This happens when the system is booting, i.e. grub has just finished, loaded kernel and initrd, and the kernel has just began to run, i.e. early in the kernel startup.
+Steps to reproduce:
+1. 
+2. 
+3.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2083 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2083
new file mode 100644
index 00000000..0e6cc43a
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2083
@@ -0,0 +1,111 @@
+AArch64 SME SMOPA (4-way) outer product instruction gives incorrect result
+Description of problem:
+The SME SMOPA (4-way) instruction ([spec](https://developer.arm.com/documentation/ddi0602/2023-09/SME-Instructions/SMOPA--4-way---Signed-integer-sum-of-outer-products-and-accumulate-?lang=en)) is giving incorrect result. Example below for 8-bit variant, which is equivalent to following Python example (128-bit VL) to make it clearer:
+
+```
+import numpy as np
+vl = 128
+esize = 32
+dim = vl // esize
+
+A = range(16)
+B = range(16, 32)
+C = np.zeros((4, 4,), dtype=np.int32)
+
+for row in range(dim):
+    for col in range(dim):
+        for k in range(4):
+            C[row, col] += A[4*row + k] * B[4*col + k]
+
+print(C)
+
+[[ 110  134  158  182]
+ [ 390  478  566  654]
+ [ 670  822  974 1126]
+ [ 950 1166 1382 1598]]
+```
+
+main.c
+```
+#include <stdio.h>
+#include <stdint.h>
+
+void foo(int *dst);
+
+int main() {
+  int32_t dst[16];
+  foo(dst);
+
+  // This should print:
+  // >>> 110  134  158  182
+  // >>> 390  478  566  654
+  // >>> 670  822  974  1126
+  // >>> 950  1166  1382  1598
+  for (int i=0; i<4; ++i) {
+    printf(">>> ");
+    for (int j=0; j<4; ++j) {
+      printf("%d  ", dst[i * 4 + j]);
+    }
+    printf("\n");
+  }
+}
+```
+
+foo.S
+
+```
+.global foo
+foo:
+  stp x29, x30, [sp, -80]!
+  mov x29, sp
+  stp d8, d9, [sp, 16]
+  stp d10, d11, [sp, 32]
+  stp d12, d13, [sp, 48]
+  stp d14, d15, [sp, 64]
+
+  smstart
+
+  ptrue p0.b
+  index z0.b, #0, #1
+  mov   z1.d, z0.d
+  add   z1.b, z1.b, #16
+
+  zero  {za}
+  smopa za0.s, p0/m, p0/m, z0.b, z1.b
+
+  // Read the first 4x4 sub-matrix of elements from tile 0:
+  mov w12, #0
+  mova z0.s, p0/m, za0h.s[w12, #0]
+  mova z1.s, p0/m, za0h.s[w12, #1]
+  mova z2.s, p0/m, za0h.s[w12, #2]
+  mova z3.s, p0/m, za0h.s[w12, #3]
+
+  // And store them to the input pointer (dst in the C code):
+  st1w {z0.s}, p0, [x0]
+  add x0, x0, #16
+  st1w {z1.s}, p0, [x0]
+  add x0, x0, #16
+  st1w {z2.s}, p0, [x0]
+  add x0, x0, #16
+  st1w {z3.s}, p0, [x0]
+
+  smstop
+
+  ldp d8, d9, [sp, 16]
+  ldp d10, d11, [sp, 32]
+  ldp d12, d13, [sp, 48]
+  ldp d14, d15, [sp, 64]
+  ldp x29, x30, [sp], 80
+  ret
+```
+Steps to reproduce:
+```
+$ clang -target aarch64-linux-gnu -march=armv9-a+sme main.c foo.S
+$ ~/qemu/build/qemu-aarch64 -cpu max,sme128=on a.out
+>>> 110  478  158  654
+>>> 0  0  0  0
+>>> 670  1166  974  1598
+>>> 0  0  0  0
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2089 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2089
new file mode 100644
index 00000000..d06599a6
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2089
@@ -0,0 +1,27 @@
+aarch64: incorrect emulation of sqshrn instruction
+Description of problem:
+`sqshrn` instruction test fails with qemu-aarch64, but passes on real aarch64 hardware.
+Steps to reproduce:
+1. Build [inline_asm_tests](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/) and run with qemu-aarch64
+2. Observe two failures
+
+```
+[ RUN      ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1
+frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6697: Failure
+Expected equality of these values:
+  res1
+    Which is: 4294967188
+  MakeUInt128(0x94U, 0U)
+    Which is: 148
+[  FAILED  ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 (5 ms)
+[ RUN      ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1
+frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6793: Failure
+Expected equality of these values:
+  res3
+    Which is: 4294967168
+  MakeUInt128(0x0000000000000080ULL, 0x0000000000000000ULL)
+    Which is: 128
+[  FAILED  ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 (2 ms)
+```
+Additional information:
+[Direct link to SignedSaturatingShiftRightNarrowInt16x1 test source](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc;l=6692;drc=4ee2c3035fa5dc0b7a48b6c6dc498296be071861)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2098 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2098
new file mode 100644
index 00000000..4c6ef6a3
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2098
@@ -0,0 +1 @@
+AArch32 Arm CPUs no longer support the 'vfp' property
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2150 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2150
new file mode 100644
index 00000000..0545ea31
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2150
@@ -0,0 +1,13 @@
+ERROR:tcg/optimize.c:580:do_constant_folding_2: code should not be reached
+Description of problem:
+After booting Windows 10 or 11 (ARM) QEMU suddenly quits with:
+
+ERROR:tcg/optimize.c:580:do_constant_folding_2: code should not be reached
+
+It seems like it is missing an OPCODE in that function?
+Steps to reproduce:
+1. Boot Windows
+2. QEMU quits
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2183 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2183
new file mode 100644
index 00000000..937cfc0d
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2183
@@ -0,0 +1,20 @@
+aarch-64 emulation much slower since release 8.1.5 (issue also present on 8.2.1)
+Description of problem:
+Since QEMU 8.1.5 our aarch64 based emulation got much slower. We use a linux 5.4 kernel which we cross-compile with the ARM toolchain. Things that are noticable:
+- Boot time got a lot longer
+- All memory accesses seem to take 3x longer (can be verified by e.g. executing below script, address does not matter):
+```
+date
+for i in $(seq 0 1000); do
+    devmem 0x200000000 2>/dev/null
+done
+date
+```
+Steps to reproduce:
+Just boot an ARM based kernel on the virt machine and execute above script.
+Additional information:
+I've tried reproducing the issue on the master branch. There the issue is not present. It only seems to be present on releases 8.1.5 and 8.2.1. 
+
+I've narrowed the problem down to following commit on the 8.2 branch (@bonzini): ef74024b76bf285e247add8538c11cb3c7399a1a accel/tcg: Revert mapping of PCREL translation block to multiple virtual addresses.
+
+Let me know if any other information / tests are required.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2224 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2224
new file mode 100644
index 00000000..7e3771aa
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2224
@@ -0,0 +1,205 @@
+OpenBSD 7.4+ does not boot on sbsa-ref with Neoverse-V1/N2 or max cpu core
+Description of problem:
+System boots and then hangs:
+
+```
+disks: sd0*
+>> OpenBSD/arm64 BOOTAA64 1.18
+boot>
+cannot open sd0a:/etc/random.seed: No such file or directory
+booting sd0a:/bsd: 2861736+1091248+12711584+634544 [233295+91+666048+260913]=0x1
+3d5cf8
+FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+Copyright (c) 1982, 1986, 1989, 1991, 1993
+        The Regents of the University of California.  All rights reserved.
+Copyright (c) 1995-2023 OpenBSD. All rights reserved.  https://www.OpenBSD.org
+
+OpenBSD 7.4 (RAMDISK) #2131: Sun Oct  8 13:35:40 MDT 2023
+    deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK
+real mem  = 1066156032 (1016MB)
+avail mem = 996659200 (950MB)
+random: boothowto does not indicate good seed
+mainbus0 at root: ACPI
+psci0 at mainbus0: PSCI 1.1, SMCCC 1.4
+efi0 at mainbus0: UEFI 2.7
+efi0: EFI Development Kit II / SbsaQemu rev 0x10000
+smbios0 at efi0: SMBIOS 3.4.0
+smbios0: vendor EFI Development Kit II / SbsaQemu version "1.0" date 03/13/2024
+smbios0: QEMU QEMU SBSA-REF Machine
+cpu0 at mainbus0 mpidr 0: ARM Neoverse N2 r0p3
+cpu0: 0KB 64b/line 4-way L1 PIPT I-cache, 0KB 64b/line 4-way L1 D-cache
+cpu0: 0KB 64b/line 8-way L2 cache
+cpu0: RNDR,TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SM4,SM3,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,GPA,LRCPC+LDAPUR,FCMA,JSCVT,APA+PAC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2+SCXT,DIT,BT,SBSS+MSR
+agintc0 at mainbus0 shift 4:3 nirq 288 nredist 4: "interrupt-controller"
+agintcmsi0 at agintc0
+agtimer0 at mainbus0: 62500 kHz
+acpi0 at mainbus0: ACPI 6.0
+acpi0: tables DSDT FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+acpimcfg0 at acpi0
+acpimcfg0: addr 0xf0000000, bus 0-255
+acpiiort0 at acpi0
+pluart0 at acpi0 COM0 addr 0x60000000/0x1000 irq 33
+pluart0: console
+ahci0 at acpi0 AHC0 addr 0x60100000/0x10000 irq 42: AHCI 1.0
+ahci0: port 0: 1.5Gb/s
+scsibus0 at ahci0: 32 targets
+sd0 at scsibus0 targ 0 lun 0: <ATA, QEMU HARDDISK, 2.5+> t10.ATA_QEMU_HARDDISK_QM00001_
+sd0: 43MB, 512 bytes/sector, 88064 sectors, thin
+xhci0 at acpi0 USB0 addr 0x60110000/0x10000 irq 43, xHCI 0.0
+usb0 at xhci0: USB revision 3.0
+uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1
+acpipci0 at acpi0 PCI0
+pci0 at acpipci0
+0:1:0: rom address conflict 0xfffc0000/0x40000
+0:2:0: rom address conflict 0xffff8000/0x8000
+"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured
+em0 at pci0 dev 1 function 0 "Intel 82574L" rev 0x00: msi, address 52:54:00:12:34:56
+"Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+simplefb0 at mainbus0: 1280x800, 32bpp
+wsdisplay0 at simplefb0 mux 1
+wsdisplay0: screen 0 added (std, vt100 emulation)
+```
+
+If I use Neoverse-N1 (sbsa-ref default core type) then it boots into installer:
+
+```
+disks: sd0*
+>> OpenBSD/arm64 BOOTAA64 1.18
+boot>
+cannot open sd0a:/etc/random.seed: No such file or directory
+booting sd0a:/bsd: 2861736+1091248+12711584+634544 [233295+91+666048+260913]=0x1
+3d5cf8
+FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+Copyright (c) 1982, 1986, 1989, 1991, 1993
+        The Regents of the University of California.  All rights reserved.
+Copyright (c) 1995-2023 OpenBSD. All rights reserved.  https://www.OpenBSD.org
+
+OpenBSD 7.4 (RAMDISK) #2131: Sun Oct  8 13:35:40 MDT 2023
+    deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK
+real mem  = 1066156032 (1016MB)
+avail mem = 996659200 (950MB)
+random: boothowto does not indicate good seed
+mainbus0 at root: ACPI
+psci0 at mainbus0: PSCI 1.1, SMCCC 1.4
+efi0 at mainbus0: UEFI 2.7
+efi0: EFI Development Kit II / SbsaQemu rev 0x10000
+smbios0 at efi0: SMBIOS 3.4.0
+smbios0: vendor EFI Development Kit II / SbsaQemu version "1.0" date 03/13/2024
+smbios0: QEMU QEMU SBSA-REF Machine
+cpu0 at mainbus0 mpidr 0: ARM Neoverse N1 r4p1
+cpu0: 64KB 64b/line 4-way L1 PIPT I-cache, 64KB 64b/line 4-way L1 D-cache
+cpu0: 1024KB 64b/line 8-way L2 cache
+cpu0: DP,RDM,Atomic,CRC32,SHA2,SHA1,AES+PMULL,LRCPC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2,SBSS+MSR
+agintc0 at mainbus0 shift 4:3 nirq 288 nredist 4: "interrupt-controller"
+agintcmsi0 at agintc0
+agtimer0 at mainbus0: 62500 kHz
+acpi0 at mainbus0: ACPI 6.0
+acpi0: tables DSDT FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+acpimcfg0 at acpi0
+acpimcfg0: addr 0xf0000000, bus 0-255
+acpiiort0 at acpi0
+pluart0 at acpi0 COM0 addr 0x60000000/0x1000 irq 33
+pluart0: console
+ahci0 at acpi0 AHC0 addr 0x60100000/0x10000 irq 42: AHCI 1.0
+ahci0: port 0: 1.5Gb/s
+scsibus0 at ahci0: 32 targets
+sd0 at scsibus0 targ 0 lun 0: <ATA, QEMU HARDDISK, 2.5+> t10.ATA_QEMU_HARDDISK_QM00001_
+sd0: 43MB, 512 bytes/sector, 88064 sectors, thin
+xhci0 at acpi0 USB0 addr 0x60110000/0x10000 irq 43, xHCI 0.0
+usb0 at xhci0: USB revision 3.0
+uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1
+acpipci0 at acpi0 PCI0
+pci0 at acpipci0
+0:1:0: rom address conflict 0xfffc0000/0x40000
+0:2:0: rom address conflict 0xffff8000/0x8000
+"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured
+em0 at pci0 dev 1 function 0 "Intel 82574L" rev 0x00: msi, address 52:54:00:12:34:56
+"Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+simplefb0 at mainbus0: 1280x800, 32bpp
+wsdisplay0 at simplefb0 mux 1
+wsdisplay0: screen 0 added (std, vt100 emulation)
+softraid0 at root
+scsibus1 at softraid0: 256 targets
+root on rd0a swap on rd0b dump on rd0b
+WARNING: CHECK AND RESET THE DATE!
+erase ^?, werase ^W, kill ^U, intr ^C, status ^T
+
+Welcome to the OpenBSD/arm64 7.4 installation program.
+(I)nstall, (U)pgrade, (A)utoinstall or (S)hell?
+```
+Steps to reproduce:
+1. download OpenBSD 7.4 image: https://cdn.openbsd.org/pub/OpenBSD/7.4/arm64/miniroot74.img
+2. download sbsa-ref firmware files from https://artifacts.codelinaro.org/ui/native/linaro-419-sbsa-ref/20240313-116475/edk2/ and decompress them
+3. start qemu-system-aarch64 as shown above (adapt paths if needed)
+4. watch console serial output
+Additional information:
+I am going to discuss this on OpenBSD mailing list. Will point to this bug.
+
+OpenBSD 7.5-current snapshot works on Neoverse-N1 and fails on Neoverse-V1/N2/max:
+
+```
+disks: sd0*
+>> OpenBSD/arm64 BOOTAA64 1.18
+boot>
+cannot open sd0a:/etc/random.seed: No such file or directory
+booting sd0a:/bsd: 3015576+1213504+12712936+634144 [269381+91+701664+287051]=0x1
+3edee0
+FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+Copyright (c) 1982, 1986, 1989, 1991, 1993
+        The Regents of the University of California.  All rights reserved.
+Copyright (c) 1995-2024 OpenBSD. All rights reserved.  https://www.OpenBSD.org
+
+OpenBSD 7.5 (RAMDISK) #121: Thu Mar 14 03:28:46 MDT 2024
+    deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK
+real mem  = 1066147840 (1016MB)
+avail mem = 992886784 (946MB)
+random: boothowto does not indicate good seed
+mainbus0 at root: ACPI
+psci0 at mainbus0: PSCI 1.1, SMCCC 1.4
+efi0 at mainbus0: UEFI 2.7
+efi0: EFI Development Kit II / SbsaQemu rev 0x10000
+smbios0 at efi0: SMBIOS 3.4.0
+smbios0: vendor EFI Development Kit II / SbsaQemu version "1.0" date 03/13/2024
+smbios0: QEMU QEMU SBSA-REF Machine
+cpu0 at mainbus0 mpidr 0: ARM Neoverse N2 r0p3
+cpu0: 0KB 64b/line 4-way L1 PIPT I-cache, 0KB 64b/line 4-way L1 D-cache
+cpu0: 0KB 64b/line 8-way L2 cache
+cpu0: RNDR,TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SM4,SM3,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPA,LRCPC+LDAPUR,FCMA,JSCVT,APA+PAC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2+SCXT,DIT,BT,SBSS+MSR,MTE
+agintc0 at mainbus0 shift 4:3 nirq 288 nredist 4: "interrupt-controller"
+agintcmsi0 at agintc0
+agtimer0 at mainbus0: 62500 kHz
+acpi0 at mainbus0: ACPI 6.0
+acpi0: tables DSDT FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+acpimcfg0 at acpi0
+acpimcfg0: addr 0xf0000000, bus 0-255
+acpiiort0 at acpi0
+pluart0 at acpi0 COM0 addr 0x60000000/0x1000 irq 33
+pluart0: console
+ahci0 at acpi0 AHC0 addr 0x60100000/0x10000 irq 42: AHCI 1.0
+ahci0: port 0: 1.5Gb/s
+scsibus0 at ahci0: 32 targets
+sd0 at scsibus0 targ 0 lun 0: <ATA, QEMU HARDDISK, 2.5+> t10.ATA_QEMU_HARDDISK_QM00001_
+sd0: 43MB, 512 bytes/sector, 88064 sectors, thin
+xhci0 at acpi0 USB0 addr 0x60110000/0x10000 irq 43, xHCI 0.0
+usb0 at xhci0: USB revision 3.0
+uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1
+acpipci0 at acpi0 PCI0
+pci0 at acpipci0
+0:1:0: rom address conflict 0xfffc0000/0x40000
+0:2:0: rom address conflict 0xffff8000/0x8000
+"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured
+em0 at pci0 dev 1 function 0 "Intel 82574L" rev 0x00: msi, address 52:54:00:12:34:56
+"Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2248 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2248
new file mode 100644
index 00000000..368fe937
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2248
@@ -0,0 +1,36 @@
+qemu-aarch64: wrong execution result when executing the code
+Description of problem:
+The following aarch64 code results in the wrong execution result `4611686018427387903`, which is `0x3fffffffffffffff`. (The correct result is `-1`) The bug seems to be introduced in between v8.1.5 and v8.2.1 since the results are correct in v8.1.5.
+
+```c
+// foo.c
+#include <stdio.h>
+#include <stdint.h>
+
+int64_t callme(size_t _1, size_t _2, int64_t a, int64_t b, int64_t c);
+
+int main() {
+    int64_t ret = callme(0, 0, 0, 1, 2);
+    printf("%ld\n", ret);
+    return 0;
+}
+```
+
+```s
+// foo.S
+.global callme
+callme:
+  cmp   x2, x3
+  cset  x12, lt
+  and   w11, w12, #0xff
+  cmp   w11, #0x0
+  csetm x14, ne
+  lsr   x13, x14, x4
+  sxtb  x0, w13
+  ret
+```
+Steps to reproduce:
+1. Build the code with `aarch64-linux-gnu-gcc foo.c foo.S -o foo` (`aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0`)
+2. Run the code with `qemu-aarch64 -L /usr/aarch64-linux-gnu -E LD_LIBRARY_PATH=/usr/aarch64-linux-gnu/lib foo` and see the result
+Additional information:
+- Original discussion is held in [this wasmtime issue](https://github.com/bytecodealliance/wasmtime/issues/8233). Thanks to Alex Crichton for clarifying this bug.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2250 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2250
new file mode 100644
index 00000000..9e9a9051
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2250
@@ -0,0 +1,44 @@
+FEAT_RME: NS EL1/0 Address Translation from EL3 fails
+Description of problem:
+I'm playing around with the QEMU RME Stack (TF-A, TF-RMM, Linux/KVM) for a research project.  
+For this I want to access some virtual normal world memory address from within EL3.
+To translate the address to the physical address I use the `AT` instructions (e.g., `ats1e2r`).  
+If the NW memory is initially mapped in the GPT as `GPT_GPI_ANY`, this works fine, however, if the NW memory is mapped as `GPT_GPI_NS` the address translation fails with the error `0b100101`/GPT on PTW.  
+However, EL3/Root World should be able to access memory from all PAS, and therefore, if I understand the ARM documentation correctly, should also be able to execute a PTW for an address marked NS in the GPT.
+Steps to reproduce:
+1. Setup GPT with some memory marked as `GPT_GPI_NS`
+2. Forward some NW virtual address from the kernel to EL3
+3. Execute a PTW on this address via the `AT` instructions.
+Additional information:
+I also took a look into the QEMU source code and potentially found the issue.  
+When executing a PTW we execute `target/arm/ptw.c:granule_protection_check`.  
+The function extracts the target page's GPI (`ptw.c:440'):  
+```c 
+ switch (gpi) {
+    case 0b0000: /* no access */
+        break;
+    case 0b1111: /* all access */
+        return true;
+    case 0b1000:
+    case 0b1001:
+    case 0b1010:
+    case 0b1011:
+        if (pspace == (gpi & 3)) {
+            return true;
+        }
+        break;
+    default:
+        goto fault_walk; /* reserved */
+    }
+```
+The if statement checks if the current `pstate` (previously set to `ptw->in_space`) is the same security state as the one contained in the GPI.  
+If this is not the case, we generate a GPF.  
+However, I think the code misses the fact, that EL3/Root world can access memory from each PAS, meaning that the if statement should be something like
+```c
+if (pspace == (gpi & 3) || (pspace == ARMSS_Root)) {
+            return true;
+}
+```
+Additionally, as both Secure and Realm World can also access Normal World memory, similar checks should also be added in such cases.  
+ 
+I have a patch prepared for this, however, I first want to check in if I'm in line with the Arm ARM or if I'm missing something and EL3 is indeed not supposed to execute PTWs for NS memory.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2326 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2326
new file mode 100644
index 00000000..2e68b3be
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2326
@@ -0,0 +1,24 @@
+qemu-system-arm regression with Qemu 9.0.0
+Description of problem:
+Bootup of the userland crashes:
+```
+[    1.713693] Run /init as init process
+[    2.372470] Alignment trap: not handling instruction f8530b04 at [<0001225a>]
+[    2.391053] 8<--- cut here ---
+[    2.392942] Unhandled fault: alignment exception (0x001) at 0x00035335
+[    2.397042] [00035335] *pgd=6066b831, *pte=6030734f, *ppte=6030783f
+```
+Steps to reproduce:
+wget https://debug.openadk.org/vexpress-v2p-ca9.dtb
+
+wget https://debug.openadk.org/qemu-arm-vexpress-a9-initramfspiggyback-kernel
+
+qemu-system-arm -M vexpress-a9 -nographic -cpu cortex-a9 -net user -net nic,model=lan9118 -dtb vexpress-v2p-ca9.dtb -kernel qemu-arm-vexpress-a9-initramfspiggyback-kernel -qmp tcp:127.0.0.1:4444,server,nowait -no-reboot
+Additional information:
+It works fine for ARM instruction set, but not for Thumb2.
+
+Git bisect showed following commit as the problematic one:<br>
+From 59754f85ed35cbd5f4bf2663ca2136c78d5b2413 Mon Sep 17 00:00:00 2001<br>
+From: Richard Henderson <richard.henderson@linaro.org><br>
+Date: Fri, 1 Mar 2024 10:41:09 -1000<br>
+Subject: [PATCH] target/arm: Do memory type alignment check when translation disabled<br>
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2372 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2372
new file mode 100644
index 00000000..cbbaf878
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2372
@@ -0,0 +1,109 @@
+A bug in AArch64 UMOPA/UMOPS (4-way) instruction
+Description of problem:
+umopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. A source register’s element size is 16 bits, while a destination register’s element size is 64 bits in case of the 4-way variant of this instruction. Before performing matrix multiplication, each element should be zero-extended to a 64-bit element.
+
+However, the current implementation of the helper function fails to convert the element type correctly. Below is the helper function implementation:
+```
+// target/arm/tcg/sme_helper.c
+#define DEF_IMOP_64(NAME, NTYPE, MTYPE) \
+static uint64_t NAME(uint64_t n, uint64_t m, uint64_t a, uint8_t p, bool neg) \
+{                                                                           \
+    uint64_t sum = 0;                                                       \
+    /* Apply P to N as a mask, making the inactive elements 0. */           \
+    n &= expand_pred_h(p);                                                  \
+    sum += (NTYPE)(n >> 0) * (MTYPE)(m >> 0);                               \
+    sum += (NTYPE)(n >> 16) * (MTYPE)(m >> 16);                             \
+    sum += (NTYPE)(n >> 32) * (MTYPE)(m >> 32);                             \
+    sum += (NTYPE)(n >> 48) * (MTYPE)(m >> 48);                             \
+    return neg ? a - sum : a + sum;                                         \
+}
+
+DEF_IMOP_64(umopa_d, uint16_t, uint16_t)
+```
+When the multiplication is performed, each element, such as `(NTYPE)(n >> 0)`, is automatically converted to `int32_t`, so the computation result has a type `int32_t`. The result is then converted to `uint64_t`, and it is added to `sum`. It seems the elements should be casted to `uint64_t` **before** performing the multiplication.
+Steps to reproduce:
+1. Write `test.c`.
+```
+#include <stdio.h>
+
+char i_P1[4] = { 0xff, 0xff, 0xff, 0xff };
+char i_P5[4] = { 0xff, 0xff, 0xff, 0xff };
+char i_Z0[32] = { // Set only the first element as non-zero
+    0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+};
+char i_Z20[32] = { // Set only the first element as non-zero
+    0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+};
+char i_ZA2H[128] = { 0x0, };
+char o_ZA2H[128];
+
+void __attribute__ ((noinline)) show_state() {
+    for (int i = 0; i < 8; i++) {
+        for (int j = 0; j < 16; j++) {
+            printf("%02x ", o_ZA2H[16*i+j]);
+        }
+        printf("\n");
+    }
+}
+
+void __attribute__ ((noinline)) run() {
+    __asm__ (
+        ".arch armv9.3-a+sme\n"
+        "smstart\n"
+        "adrp x29, i_P1\n"
+        "add x29, x29, :lo12:i_P1\n"
+        "ldr p1, [x29]\n"
+        "adrp x29, i_P5\n"
+        "add x29, x29, :lo12:i_P5\n"
+        "ldr p5, [x29]\n"
+        "adrp x29, i_Z0\n"
+        "add x29, x29, :lo12:i_Z0\n"
+        "ldr z0, [x29]\n"
+        "adrp x29, i_Z20\n"
+        "add x29, x29, :lo12:i_Z20\n"
+        "ldr z20, [x29]\n"
+        "adrp x29, i_ZA2H\n"
+        "add x29, x29, :lo12:i_ZA2H\n"
+        "mov x15, 0\n"
+        "ld1d {za2h.d[w15, 0]}, p1, [x29]\n"
+        "add x29, x29, 32\n"
+        "ld1d {za2h.d[w15, 1]}, p1, [x29]\n"
+        "add x29, x29, 32\n"
+        "mov x15, 2\n"
+        "ld1d {za2h.d[w15, 0]}, p1, [x29]\n"
+        "add x29, x29, 32\n"
+        "ld1d {za2h.d[w15, 1]}, p1, [x29]\n"
+        ".inst 0xa1f43402\n" // umopa   za2.d, p5/m, p1/m, z0.h, z20.h
+        "adrp x29, o_ZA2H\n"
+        "add x29, x29, :lo12:o_ZA2H\n"
+        "mov x15, 0\n"
+        "st1d {za2h.d[w15, 0]}, p1, [x29]\n"
+        "add x29, x29, 32\n"
+        "st1d {za2h.d[w15, 1]}, p1, [x29]\n"
+        "add x29, x29, 32\n"
+        "mov x15, 2\n"
+        "st1d {za2h.d[w15, 0]}, p1, [x29]\n"
+        "add x29, x29, 32\n"
+        "st1d {za2h.d[w15, 1]}, p1, [x29]\n"
+        "smstop\n"
+        ".arch armv8-a\n"
+    );
+}
+
+int main(int argc, char **argv) {
+    run();
+    show_state();
+    return 0;
+}
+```
+2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`.
+3. Run `QEMU` using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`.
+4. The program, runs on top of the buggy QEMU, prints the first 8 bytes of `ZA2H` as `01 00 fe ff ff ff ff ff`. It should print `01 00 fe ff 00 00 00 00` after the bug is fixed.
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2373 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2373
new file mode 100644
index 00000000..de6ede92
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2373
@@ -0,0 +1,95 @@
+A bug in AArch64 FMOPA/FMOPS (widening) instruction
+Description of problem:
+fmopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. A source register’s element size is 16 bits, while a destination register’s element size is 64 bits in the case of widening variant of this instruction. Before the matrix multiplication is performed, each element should be converted to a 64-bit floating point. FPCR flags are considered when converting floating point values. Especially, when the FZ (or FZ16) flag is set, denormalized values are converted into zero. When the floating point size is 16 bits, FZ16 should be considered; otherwise, FZ flag should be used.
+
+However, the current implementation only considers FZ flag, not FZ16 flag, so it computes the wrong value.
+Steps to reproduce:
+1. Write `test.c`.
+```
+#include <stdio.h>
+
+char i_P2[4] = { 0xff, 0xff, 0xff, 0xff };
+char i_P5[4] = { 0xff, 0xff, 0xff, 0xff };
+char i_Z0[32] = { // Set only the first element as non-zero
+    0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+};
+char i_Z16[32] = { // Set only the first element as non-zero
+    0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+};
+char i_ZA3H[128] = { 0x0, };
+uint64_t i_fpcr = 0x0001000000; // FZ = 1;
+char o_ZA3H[128];
+
+void __attribute__ ((noinline)) show_state() {
+    for (int i = 0; i < 8; i++) {
+        for (int j = 0; j < 16; j++) {
+            printf("%02x ", o_ZA3H[16*i+j]);
+        }
+        printf("\n");
+    }
+}
+
+void __attribute__ ((noinline)) run() {
+    __asm__ (
+        ".arch armv9.3-a+sme\n"
+        "smstart\n"
+        "adrp x29, i_P2\n"
+        "add x29, x29, :lo12:i_P2\n"
+        "ldr p2, [x29]\n"
+        "adrp x29, i_P5\n"
+        "add x29, x29, :lo12:i_P5\n"
+        "ldr p5, [x29]\n"
+        "adrp x29, i_Z0\n"
+        "add x29, x29, :lo12:i_Z0\n"
+        "ldr z0, [x29]\n"
+        "adrp x29, i_Z16\n"
+        "add x29, x29, :lo12:i_Z16\n"
+        "ldr z16, [x29]\n"
+        "adrp x29, i_ZA3H\n"
+        "add x29, x29, :lo12:i_ZA3H\n"
+        "mov x15, 0\n"
+        "ld1w {za3h.s[w15, 0]}, p2, [x29]\n"
+        "add x29, x29, 32\n"
+        "ld1w {za3h.s[w15, 1]}, p2, [x29]\n"
+        "add x29, x29, 32\n"
+        "mov x15, 2\n"
+        "ld1w {za3h.s[w15, 0]}, p2, [x29]\n"
+        "add x29, x29, 32\n"
+        "ld1w {za3h.s[w15, 1]}, p2, [x29]\n"
+        "adrp x29, i_fpcr\n"
+        "add x29, x29, :lo12:i_fpcr\n"
+        "ldr x29, [x29]\n"
+        "msr fpcr, x29\n"
+        ".inst 0x81a0aa03\n" // fmopa   za3.s, p2/m, p5/m, z16.h, z0.h
+        "adrp x29, o_ZA3H\n"
+        "add x29, x29, :lo12:o_ZA3H\n"
+        "mov x15, 0\n"
+        "st1w {za3h.s[w15, 0]}, p2, [x29]\n"
+        "add x29, x29, 32\n"
+        "st1w {za3h.s[w15, 1]}, p2, [x29]\n"
+        "add x29, x29, 32\n"
+        "mov x15, 2\n"
+        "st1w {za3h.s[w15, 0]}, p2, [x29]\n"
+        "add x29, x29, 32\n"
+        "st1w {za3h.s[w15, 1]}, p2, [x29]\n"
+        ".arch armv8-a\n"
+    );
+}
+
+int main(int argc, char **argv) {
+    run();
+    show_state();
+    return 0;
+}
+```
+2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`.
+3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`.
+4. The program, runs on top of the buggy QEMU, prints only zero bytes. It should print `00 01 7e 2f + 00 .. (rest of bytes) .. 00` after the bug is fixed.
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2374 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2374
new file mode 100644
index 00000000..e9679627
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2374
@@ -0,0 +1,111 @@
+A bug in AArch64 FMOPA/FMOPS (non-widening) instruction
+Description of problem:
+fmopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. Depending on the instruction encoding, the element size of operands is either 32 bits or 64 bits. When the computation produces a NaN as a result, the default NaN should be generated.
+
+However, the current implementation of 32-bit variant of this instruction does not generate default NaNs, because invalid float_status pointer is passed:
+```
+// target/arm/tcg/sme_helper.c
+void HELPER(sme_fmopa_s)(void *vza, void *vzn, void *vzm, void *vpn,
+                         void *vpm, void *vst, uint32_t desc)
+{
+...
+    float_status fpst;
+
+    /*
+     * Make a copy of float_status because this operation does not
+     * update the cumulative fp exception status.  It also produces
+     * default nans.
+     */
+    fpst = *(float_status *)vst;
+    set_default_nan_mode(true, &fpst);
+
+...
+                            *a = float32_muladd(n, *m, *a, 0, vst); // &fpst should be used
+...
+}
+```
+Steps to reproduce:
+1. Write `test.c`.
+```
+#include <stdio.h>
+
+char i_P0[4] = { 0xff, 0xff, 0xff, 0xff };
+char i_P6[4] = { 0xff, 0xff, 0xff, 0xff };
+char i_Z9[32] = { // Set only the first element as NaN, but it is not default NaN.
+    0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+};
+char i_Z27[32] = {
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+};
+char i_ZA1H[128] = { 0x0, };
+char o_ZA1H[128];
+
+void __attribute__ ((noinline)) show_state() {
+    for (int i = 0; i < 8; i++) {
+        for (int j = 0; j < 16; j++) {
+            printf("%02x ", o_ZA1H[16*i+j]);
+        }
+        printf("\n");
+    }
+}
+
+void __attribute__ ((noinline)) run() {
+    __asm__ (
+        ".arch armv9.3-a+sme\n"
+        "smstart\n"
+        "adrp x29, i_P0\n"
+        "add x29, x29, :lo12:i_P0\n"
+        "ldr p0, [x29]\n"
+        "adrp x29, i_P6\n"
+        "add x29, x29, :lo12:i_P6\n"
+        "ldr p6, [x29]\n"
+        "adrp x29, i_Z9\n"
+        "add x29, x29, :lo12:i_Z9\n"
+        "ldr z9, [x29]\n"
+        "adrp x29, i_Z27\n"
+        "add x29, x29, :lo12:i_Z27\n"
+        "ldr z27, [x29]\n"
+        "adrp x29, i_ZA1H\n"
+        "add x29, x29, :lo12:i_ZA1H\n"
+        "mov x15, 0\n"
+        "ld1w {za1h.s[w15, 0]}, p0, [x29]\n"
+        "add x29, x29, 32\n"
+        "ld1w {za1h.s[w15, 1]}, p0, [x29]\n"
+        "add x29, x29, 32\n"
+        "mov x15, 2\n"
+        "ld1w {za1h.s[w15, 0]}, p0, [x29]\n"
+        "add x29, x29, 32\n"
+        "ld1w {za1h.s[w15, 1]}, p0, [x29]\n"
+        ".inst 0x809bc121\n" // fmopa   za1.s, p0/m, p6/m, z9.s, z27.s
+        "adrp x29, o_ZA1H\n"
+        "add x29, x29, :lo12:o_ZA1H\n"
+        "mov x15, 0\n"
+        "st1w {za1h.s[w15, 0]}, p0, [x29]\n"
+        "add x29, x29, 32\n"
+        "st1w {za1h.s[w15, 1]}, p0, [x29]\n"
+        "add x29, x29, 32\n"
+        "mov x15, 2\n"
+        "st1w {za1h.s[w15, 0]}, p0, [x29]\n"
+        "add x29, x29, 32\n"
+        "st1w {za1h.s[w15, 1]}, p0, [x29]\n"
+        ".arch armv8-a\n"
+    );
+}
+
+int main(int argc, char **argv) {
+    run();
+    show_state();
+    return 0;
+}
+```
+2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`.
+3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`.
+4. The program, runs on top of the buggy QEMU, prints 8 non-default NaNs (ff ff ff ff). It should print 8 default NaNs (00 00 c0 7f) after the bug is fixed.
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2375 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2375
new file mode 100644
index 00000000..07d51b34
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2375
@@ -0,0 +1,85 @@
+A bug in AArch64 FJCVTZS instruction
+Description of problem:
+fjcvtzs instruction converts a double-precision floating-point value in the source register into a 32-bit signed integer, and stores the result in the destination register. The contents of the FPCR register influence the exception result. Especially, when FPCR.FZ (Flushing denormalized numbers to Zero) is set and an input is a denormalized number, the PSTATE.Z flag should be cleared even if the conversion result is zero.
+
+However, because the helper function for this instruction does not properly check the denormalized case, the Z flag will have an incorrect value:
+```
+// target/arm/vfp_helper.c
+uint64_t HELPER(fjcvtzs)(float64 value, void *vstatus)
+{
+    float_status *status = vstatus;
+    uint32_t inexact, frac;
+    uint32_t e_old, e_new;
+
+    e_old = get_float_exception_flags(status);
+    set_float_exception_flags(0, status);
+    frac = float64_to_int32_modulo(value, float_round_to_zero, status);
+    e_new = get_float_exception_flags(status);
+    set_float_exception_flags(e_old | e_new, status);
+
+    if (value == float64_chs(float64_zero)) {
+        /* While not inexact for IEEE FP, -0.0 is inexact for JavaScript. */
+        inexact = 1;
+    } else {
+        /* Normal inexact or overflow or NaN */
+        inexact = e_new & (float_flag_inexact | float_flag_invalid); // float_flag_input_denormal should also be checked.
+    }
+
+    /* Pack the result and the env->ZF representation of Z together.  */
+    return deposit64(frac, 32, 32, inexact);
+}
+```
+Steps to reproduce:
+1. Write `test.c`.
+```
+#include <stdint.h>
+#include <stdio.h>
+#include <string.h>
+
+char i_D27[8] = { 0x0, 0xff, 0xfc, 0x0, 0x0, 0x0, 0x0, 0x0 };
+uint64_t i_fpcr = 0x01000000; // FZ = 1;
+char o_X28[8];
+uint64_t o_nzcv;
+
+void __attribute__ ((noinline)) show_state() {
+    char Z = ((o_nzcv >> 30) & 1);
+
+    printf("PSTATE.Z: %d\n", Z);
+    printf("X28: ");
+    for (int i = 0; i < 8; i++) {
+        printf("%02x ", o_X28[i]);
+    }
+    printf("\n");
+}
+
+void __attribute__ ((noinline)) run() {
+    __asm__ (
+        "adrp x29, i_D27\n"
+        "add x29, x29, :lo12:i_D27\n"
+        "ldr d27, [x29]\n"
+        "adrp x29, i_fpcr\n"
+        "add x29, x29, :lo12:i_fpcr\n"
+        "ldr x29, [x29]\n"
+        "msr fpcr, x29\n"
+        ".inst 0x1e7e037c\n" // fjcvtzs w28, d27
+        "mrs x26, nzcv\n"
+        "adrp x29, o_nzcv\n"
+        "add x29, x29, :lo12:o_nzcv\n"
+        "str x26, [x29]\n"
+        "adrp x29, o_X28\n"
+        "add x29, x29, :lo12:o_X28\n"
+        "str x28, [x29]\n"
+    );
+}
+
+int main(int argc, char **argv) {
+    run();
+    show_state();
+    return 0;
+}
+```
+2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`.
+3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./test.bin`.
+4. The program, runs on top of the buggy QEMU, prints the value of Z as `01`. It should print `00` after the bug is fixed.
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2376 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2376
new file mode 100644
index 00000000..9428fc04
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2376
@@ -0,0 +1,114 @@
+A bug in ARM VCMLA.f16/VCMLA.f32 instructions
+Description of problem:
+The vcmla instruction performs complex-number operations on the vector registers. There is a bug in which this instruction modifies the contents of an irrelevant vector register.
+
+The reason is simple out-of-bound; the helper functions should correctly check the number of modified elements:
+```
+// target/arm/tcg/vec_helper.c
+void HELPER(gvec_fcmlah_idx)(void *vd, void *vn, void *vm, void *va,
+                             void *vfpst, uint32_t desc)
+{
+    uintptr_t opr_sz = simd_oprsz(desc);
+    float16 *d = vd, *n = vn, *m = vm, *a = va;
+    float_status *fpst = vfpst;
+    intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1);
+    uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1);
+    intptr_t index = extract32(desc, SIMD_DATA_SHIFT + 2, 2);
+    uint32_t neg_real = flip ^ neg_imag;
+    intptr_t elements = opr_sz / sizeof(float16);
+    intptr_t eltspersegment = 16 / sizeof(float16); // This should be fixed;
+    intptr_t i, j;
+
+    ...
+}
+
+...
+
+void HELPER(gvec_fcmlas_idx)(void *vd, void *vn, void *vm, void *va,
+                             void *vfpst, uint32_t desc)
+{
+    uintptr_t opr_sz = simd_oprsz(desc);
+    float32 *d = vd, *n = vn, *m = vm, *a = va;
+    float_status *fpst = vfpst;
+    intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1);
+    uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1);
+    intptr_t index = extract32(desc, SIMD_DATA_SHIFT + 2, 2);
+    uint32_t neg_real = flip ^ neg_imag;
+    intptr_t elements = opr_sz / sizeof(float32);
+    intptr_t eltspersegment = 16 / sizeof(float32); // This should be fixed;
+    intptr_t i, j;
+
+    ...
+}
+```
+Steps to reproduce:
+1. Write `test.c`.
+```
+#include <stdint.h>
+#include <stdio.h>
+#include <string.h>
+
+// zero inputs should produce zero output
+char i_D4[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 };
+char i_D8[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 };
+char i_D30[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 };
+char i_D31[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; // this should never be touched
+char o_D30[8];
+char o_D31[8];
+
+void __attribute__ ((noinline)) show_state() {
+    printf("D30: ");
+    for (int i = 0; i < 8; i++) {
+        printf("%02x ", o_D30[i]);
+    }
+    printf("\n");
+    printf("D31: ");
+    for (int i = 0; i < 8; i++) {
+        printf("%02x ", o_D31[i]);
+    }
+    printf("\n");
+}
+
+void __attribute__ ((noinline)) run() {
+    __asm__ (
+        "movw r7, #:lower16:i_D4\n"
+        "movt r7, #:upper16:i_D4\n"
+        "vldr d4, [r7]\n"
+        "movw r7, #:lower16:i_D8\n"
+        "movt r7, #:upper16:i_D8\n"
+        "vldr d8, [r7]\n"
+        "movw r7, #:lower16:i_D30\n"
+        "movt r7, #:upper16:i_D30\n"
+        "vldr d30, [r7]\n"
+        "movw r7, #:lower16:i_D31\n"
+        "movt r7, #:upper16:i_D31\n"
+        "vldr d31, [r7]\n"
+        "adr r7, Lbl_thumb + 1\n"
+        "bx r7\n"
+        ".thumb\n"
+        "Lbl_thumb:\n"
+        ".inst 0xfed8e804\n" // vcmla.f32       d30, d8, d4[0], #90
+        "adr r7, Lbl_arm\n"
+        "bx r7\n"
+        ".arm\n"
+        "Lbl_arm:\n"
+        "movw r7, #:lower16:o_D30\n"
+        "movt r7, #:upper16:o_D30\n"
+        "vstr d30, [r7]\n"
+        "movw r7, #:lower16:o_D31\n"
+        "movt r7, #:upper16:o_D31\n"
+        "vstr d31, [r7]\n"
+    );
+}
+
+int main(int argc, char **argv) {
+    run();
+    show_state();
+    return 0;
+}
+```
+2. Compile `test.bin` using this command: `arm-linux-gnueabihf-gcc-12 -O2 -no-pie -marm -march=armv7-a+vfpv4 ./test.c -o ./test.bin`.
+3. Run QEMU using this command: `qemu-arm -L /usr/arm-linux-gnueabihf/ ./test.bin`.
+4. The program, runs on top of the buggy QEMU, prints the value of D31 as `00 00 c0 7f 00 00 c0 7f`. It should print `ff ff ff ff ff ff ff ff` after the bug is fixed.
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2419 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2419
new file mode 100644
index 00000000..56611baf
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2419
@@ -0,0 +1,18 @@
+ldapr_stlr_i instructions doesn't consider signed offset
+Description of problem:
+The format ldapr_stlr_i models the load acquire / store release immediate instructions. \
+These instructions has a bug in the sign extension calculation of the imm field. \
+imm should be defined as s9 instead of 9.
+
+@ldapr_stlr_i   .. ...... .. . imm:9 .. rn:5 rt:5 &ldapr_stlr_i
+
+Should be changed to:
+
+@ldapr_stlr_i   .. ...... .. . imm:s9 .. rn:5 rt:5 &ldapr_stlr_i
+Steps to reproduce:
+1. Run ARM target
+2. Generate any ldapr_stlr_i instructions (for example: LDAPUR)
+3. When the imm value is negative, the immediate calculation is done wrong. In case the calculation leads to an undefined location, QEMU will fail.
+Additional information:
+In trans_LDAPR_i (translate-a64.c), when imm field is negative, the value of a->imm will be 512-x instead of x. \
+I already fixed the issue by adding the s9 to the imm field. This made a call to sextend32 for imm instead of extend32 in the generated file build/libqemu-aarch64-softmmu.fa.p/decode-a64.c.inc
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2432 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2432
new file mode 100644
index 00000000..2e74bc8e
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2432
@@ -0,0 +1,70 @@
+Bug in bcm2835_thermal interface
+Description of problem:
+Stack traces, crash detail:
+```
+#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737230841344) at ./nptl/pthread_kill.c:44
+#1  __pthread_kill_internal (signo=6, threadid=140737230841344) at ./nptl/pthread_kill.c:78
+#2  __GI___pthread_kill (threadid=140737230841344, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
+#3  0x00007ffff5042476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
+#4  0x00007ffff50287f3 in __GI_abort () at ./stdlib/abort.c:79
+#5  0x00007ffff6f0eb57 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
+#6  0x00007ffff6f6870f in g_assertion_message_expr () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
+#7  0x0000555555d642a6 in bcm2835_thermal_write (opaque=0x7ffff0a475b0, addr=2, value=0, size=2)
+    at ../hw/misc/bcm2835_thermal.c:76
+#8  0x0000555556c4a119 in memory_region_write_accessor
+    (mr=0x7ffff0a478e0, addr=2, value=0x7fffffffd250, size=2, shift=0, mask=65535, attrs=...)
+    at ../system/memory.c:497
+#9  0x0000555556c49da6 in access_with_adjusted_size
+     (addr=2, value=0x7fffffffd250, size=2, access_size_min=1, access_size_max=4, access_fn=0x555556c49ef0 <memory_region_write_accessor>, mr=0x7ffff0a478e0, attrs=...) at ../system/memory.c:573
+#10 0x0000555556c49395 in memory_region_dispatch_write (mr=0x7ffff0a478e0, addr=2, data=0, op=MO_16, attrs=...)
+    at ../system/memory.c:1521
+#11 0x0000555556c84e88 in flatview_write_continue_step
+    (attrs=..., buf=0x7fffffffd470 "", len=512, mr_addr=2, l=0x7fffffffd360, mr=0x7ffff0a478e0)
+    at ../system/physmem.c:2757
+#12 0x0000555556c84c42 in flatview_write_continue
+    (fv=0x555559717490, addr=1059135490, attrs=..., ptr=0x7fffffffd470, len=512, mr_addr=2, l=2, mr=0x7ffff0a478e0) at ../system/physmem.c:2787
+#13 0x0000555556c73305 in flatview_write
+    (fv=0x555559717490, addr=1059135490, attrs=..., buf=0x7fffffffd470, len=512) at ../system/physmem.c:2818
+#14 0x0000555556c73179 in address_space_write
+--Type <RET> for more, q to quit, c to continue without paging--c
+    (as=0x5555598056f0, addr=1059135490, attrs=..., buf=0x7fffffffd470, len=512) at ../system/physmem.c:2938
+#15 0x0000555556c735df in address_space_set (as=0x5555598056f0, addr=1059135490, c=0 '\000', len=2025625, attrs=...) at ../system/physmem.c:2965
+#16 0x0000555555a95b66 in rom_reset (unused=0x0) at ../hw/core/loader.c:1284
+#17 0x0000555555ab872d in legacy_reset_hold (obj=0x5555598069b0, type=RESET_TYPE_COLD) at ../hw/core/reset.c:76
+#18 0x0000555556d7dbf4 in resettable_phase_hold (obj=0x5555598069b0, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:180
+#19 0x0000555556d7d19f in resettable_container_child_foreach (obj=0x5555595573d0, cb=0x555556d7d970 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resetcontainer.c:54
+#20 0x0000555556d7f4a4 in resettable_child_foreach (rc=0x555558b02f50, obj=0x5555595573d0, cb=0x555556d7d970 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:92
+#21 0x0000555556d7da92 in resettable_phase_hold (obj=0x5555595573d0, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:169
+#22 0x0000555556d7d47a in resettable_assert_reset (obj=0x5555595573d0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:58
+#23 0x0000555556d7d2f7 in resettable_reset (obj=0x5555595573d0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:45
+#24 0x0000555555ab842e in qemu_devices_reset (reason=SHUTDOWN_CAUSE_NONE) at ../hw/core/reset.c:179
+#25 0x000055555633227d in qemu_system_reset (reason=SHUTDOWN_CAUSE_NONE) at ../system/runstate.c:493
+#26 0x0000555555aa6bd2 in qdev_machine_creation_done () at ../hw/core/machine.c:1643
+#27 0x000055555633679f in qemu_machine_creation_done (errp=0x555558587ee0 <error_fatal>) at ../system/vl.c:2685
+#28 0x0000555556335ffd in qmp_x_exit_preconfig (errp=0x555558587ee0 <error_fatal>) at ../system/vl.c:2715
+#29 0x000055555633bfe4 in qemu_init (argc=9, argv=0x7fffffffdc68) at ../system/vl.c:3759
+#30 0x0000555556d6eea2 in main (argc=9, argv=0x7fffffffdc68) at ../system/main.c:47
+```
+Description:
+I encountered a part of the code during QEMU execution that shouldn't have been reached, which led to an error.
+
+Crash detail:
+```
+ERROR:../hw/misc/bcm2835_thermal.c:76:bcm2835_thermal_write: code should not be reached
+Bail out! ERROR:../hw/misc/bcm2835_thermal.c:76:bcm2835_thermal_write: code should not be reached
+Aborted
+```
+
+Malicious inputs:
+Malicious input is attached as tar.gz archive to this file, it contains file name id:000017,sig:06,src:000428,time:48261741,execs:1725363,op:havoc,rep:8
+[malicious_input.tar.gz](/uploads/fcf47faafb59308cfdb04b3e81e788f3/malicious_input.tar.gz)
+
+Affected code area/snippet:
+
+qemu/hw/misc/bcm2835_thermal.c:bcm2835_thermal_write
+![bug](/uploads/24598ad2b9ca0edfcc7f8e422e94e87d/bug.png)
+
+Acknowledge for reporting this issue:
+Alisher Darmenov (darmenovalisher@gmail.com),
+Mohamadreza Rostami (mohamadreza.rostami@trust.tu-darmstadt.de),
+Ahmad-Reza Sadeghi (ahmad.sadeghi@trust.tu-darmstadt.de)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2542 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2542
new file mode 100644
index 00000000..a8f8ec91
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2542
@@ -0,0 +1 @@
+qemu-system-arm failure with picolibc tests since 59754f85ed35cbd5f4bf2663ca2136c78d5b2413
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2568 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2568
new file mode 100644
index 00000000..df5f92fd
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2568
@@ -0,0 +1 @@
+[AARCH64] HPFAR_EL2.NS not set for non secure read in S-EL1
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2585 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2585
new file mode 100644
index 00000000..0b5a6026
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2585
@@ -0,0 +1,7 @@
+qemu-system-arm highmem support broken with TCG
+Additional information:
+I initially bisected this to commit 39a1fd25287f ("target/arm: Fix handling of LPAE block descriptors"), which introduced an identical bug by masking the wrong address bits due to a type mismatch, but this was in turn fixed by commit c2360eaa0262 ("target/arm: Fix qemu-system-arm handling of LPAE block descriptors for highmem"). The bug resurfaced between qemu-7.1.0 and qemu-7.2.0 after commit f3639a64f602 ("target/arm: Use softmmu tlbs for page table walking"), but may be caused by the preceding 4a35855682ce ("target/arm: Plumb debug into S1Translate") which fails to boot for an unrelated reason.
+
+I reproduced this on qemu-7.2 as shipped by Debian as well as on qemu-9.1 (built locally).
+
+Part of this problem appeared to be hidden by the 'highmem=on' argument not having the intended effect during parts of the bisection, which I worked around by overriding the 'pa_bits' variable in machvirt_init().
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2601 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2601
new file mode 100644
index 00000000..07f88e19
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2601
@@ -0,0 +1,36 @@
+Executing LD1SB + MTE on Arm64 fails an assert
+Description of problem:
+I'm getting 
+```
+qemu-system-aarch64: ../tcg/tcg-op-gvec.c:91: simd_desc: Assertion `data == sextract32(data, 0, (32 - ((0 + 8) + 2)))' failed.
+```
+This is caused by the upper bits of `data` being set to 1, which violates the condition.
+Steps to reproduce:
+1. build QEMU with assertions enabled (e.g., `configure --enable-debug-tcg`).
+2. have a `LD1SB f{z25.d}, p3/z, [x14, x9]` (binary a5894dd9) instruction in the executed code.
+3. enable mte
+4. Let QEMU execute the ld1sb instruction.
+Additional information:
+![image](/uploads/8b2a68b986b94549da1abf4e076c5171/image.png){width=699 height=141}
+
+This issue happens because for ld1sb, nregs=0 in `sve.decode`:
+```
+# SVE contiguous load (scalar plus scalar)
+LD_zprr         1010010 .... ..... 010 ... ..... .....    @rprr_load_dt nreg=0 
+```
+As a result, in do_mem_zpa is called with n_reg=0, which becomes mte_n inside do_mem_zpa.
+Since mte_n==0, and mte_active, then 
+```c
+desc = FIELD_DP32(desc, MTEDESC, SIZEM1, (mte_n << msz) - 1);
+```
+sets (0) - 1 == -1 to the field, which also sets the upper bits of `desc`.
+The `desc` with upper bits set to 1 is used to call:
+```c
+desc = simd_desc(vsz, vsz, zt | desc);
+```
+Inside `simd_desc`, the last parameter is named `data` and it fails the assertion:
+```c
+tcg_debug_assert(data == sextract32(data, 0, SIMD_DATA_BITS))
+```
+
+#
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/271 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/271
new file mode 100644
index 00000000..ede2bc29
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/271
@@ -0,0 +1 @@
+ARM cpu emulation regression on QEMU 4.2.0
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2823 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2823
new file mode 100644
index 00000000..77541ec9
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2823
@@ -0,0 +1,43 @@
+func-aarch64-aarch64_rme_virt function test hangs especially when built with --enable-debug
+Description of problem:
+
+Steps to reproduce:
+1. Build with ../../configure --enable-debug
+2. ./pyvenv/bin/meson test --setup thorough --suite func-thorough func-aarch64-aarch64_rme_virt
+3. repeat until hang
+Additional information:
+Comparing a normal build to the hang:
+
+```
+2025-02-20 16:54:15,519: NOTICE:  Booting Trusted Firmware    | 2025-02-20 16:16:06,740: NOTICE:  Booting Trusted Firmware
+2025-02-20 16:54:15,519: NOTICE:  BL1: v2.11.0(release):f2f94 | 2025-02-20 16:16:06,740: NOTICE:  BL1: v2.11.0(release):f2f94
+2025-02-20 16:54:15,519: NOTICE:  BL1: Built : 17:54:58, Dec  | 2025-02-20 16:16:06,740: NOTICE:  BL1: Built : 17:54:58, Dec 
+2025-02-20 16:54:15,520: NOTICE:  BL1: Booting BL2            | 2025-02-20 16:16:06,741: NOTICE:  BL1: Booting BL2
+2025-02-20 16:54:15,522: NOTICE:  BL2: v2.11.0(release):f2f94 | 2025-02-20 16:16:06,743: NOTICE:  BL2: v2.11.0(release):f2f94
+2025-02-20 16:54:15,522: NOTICE:  BL2: Built : 17:55:12, Dec  | 2025-02-20 16:16:06,743: NOTICE:  BL2: Built : 17:55:12, Dec 
+2025-02-20 16:54:15,545: NOTICE:  BL2: Booting BL31           | 2025-02-20 16:16:06,762: NOTICE:  BL2: Booting BL31
+2025-02-20 16:54:15,550: NOTICE:  BL31: v2.11.0(release):f2f9 | 2025-02-20 16:16:06,768: NOTICE:  BL31: v2.11.0(release):f2f9
+2025-02-20 16:54:15,550: NOTICE:  BL31: Built : 17:55:22, Dec | 2025-02-20 16:16:06,768: NOTICE:  BL31: Built : 17:55:22, Dec
+2025-02-20 16:54:15,555: Booting RMM v.0.5.0(release) 1b6bdf8 | 2025-02-20 16:16:06,774: Booting RMM v.0.5.0(release) 1b6bdf8
+2025-02-20 16:54:15,556: RMM-EL3 Interface v.0.4              | 2025-02-20 16:16:06,774: RMM-EL3 Interface v.0.4
+2025-02-20 16:54:15,556: Boot Manifest Interface v.0.3        | 2025-02-20 16:16:06,775: Boot Manifest Interface v.0.3
+2025-02-20 16:54:15,556: RMI/RSI ABI v.1.0/1.0 built: Dec  2  | 2025-02-20 16:16:06,775: RMI/RSI ABI v.1.0/1.0 built: Dec  2 
+2025-02-20 16:54:15,587: UEFI firmware (version  built at 17: | 2025-02-20 16:16:06,837: UEFI firmware (version  built at 17:
+2025-02-20 16:54:15,876: ESC[2JESC[01;01HESC[=3hESC[2JESC[01;01HESC[2JESC[01;01HESC[= | 2025-02-20 16:16:07,420: ESC[2JESC[01;01HESC[=3hESC[2JESC[01;01HESC[2JESC[01;01HESC[=
+2025-02-20 16:54:15,898: EFI stub: Using DTB from configurati | 2025-02-20 16:16:07,421: 
+2025-02-20 16:54:15,898: EFI stub: Exiting boot services...   | 2025-02-20 16:16:07,421: 
+2025-02-20 16:54:16,170: [    0.000000] Booting Linux on phys | 2025-02-20 16:16:07,421: Synchronous Exception at 0x00000000B
+2025-02-20 16:54:16,171: [    0.000000] Linux version 6.12.0- | 2025-02-20 16:16:07,421: 
+2025-02-20 16:54:16,171: [    0.000000] KASLR enabled         | 2025-02-20 16:16:07,421: 
+2025-02-20 16:54:16,171: [    0.000000] random: crng init don | 2025-02-20 16:16:07,421: Synchronous Exception at 0x00000000B
+2025-02-20 16:54:16,171: [    0.000000] Machine model: linux, <
+2025-02-20 16:54:16,171: [    0.000000] efi: EFI v2.7 by EDK  <
+2025-02-20 16:54:16,171: [    0.000000] efi: SMBIOS=0xbf3c000 <
+2025-02-20 16:54:16,171: [    0.000000] OF: reserved mem: 0x0 <
+2025-02-20 16:54:16,171: [    0.000000] NUMA: Faking a node a <
+2025-02-20 16:54:16,171: [    0.000000] NODE_DATA(0) allocate <
+2025-02-20 16:54:16,171: [    0.000000] Zone ranges:          <
+2025-02-20 16:54:16,171: [    0.000000]   DMA      [mem 0x000 <
+2025-02-20 16:54:16,171: [    0.000000]   DMA32    empty      <
+2025-02-20 16:54:16,171: [    0.000000]   Normal   empty      <
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/2942 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2942
new file mode 100644
index 00000000..536f0741
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/2942
@@ -0,0 +1,65 @@
+arm: TCG debug assertion failure when handling an ISB or SB insn inside an IT block
+Description of problem:
+ARM thumb `IT` instruction triggers TCG debug asserts.
+
+```
+$ ./qemu-system-arm --version
+QEMU emulator version 10.0.0 (v10.0.0)
+
+$ ./qemu-system-arm -M stm32vldiscovery -nographic -device loader,file=raw-it-bug.hex -d in_asm,exec
+[...]
+Trace 0: 0x72a584000800 [00800400/0000000000000164/00000110/ff020000]
+----------------
+IN:
+0x00000108:  f000 f80a  bl       #0x120
+
+Trace 0: 0x72a584000940 [00800400/0000000000000108/00000110/ff020000]
+qemu-system-arm: ../tcg/tcg-op.c:3343: void tcg_gen_goto_tb(unsigned int): Assertion `(tcg_ctx->goto_tb_issue_mask & (1 << idx)) == 0' failed.
+```
+
+Expected behavior:
+```
+$ qemu-system-arm -M stm32vldiscovery -device loader,file=raw-hardfault.hex -d in_asm,exec,int
+[...]
+Trace 0: 0x7df6dc000800 [00800400/0000000000000164/00000110/ff020000]
+----------------
+IN:
+0x00000108:  f000 f80a  bl       #0x120
+
+Trace 0: 0x7df6dc000940 [00800400/0000000000000108/00000110/ff020000]
+----------------
+IN:
+0x00000120:  2302       movs     r3, #2
+0x00000122:  bf00       nop
+0x00000124:  f04f 25e0  mov.w    r5, #-0x1fff2000
+0x00000128:  f8d5 1d10  ldr.w    r1, [r5, #0xd10]
+0x0000012c:  f041 0014  orr      r0, r1, #0x14
+0x00000130:  f8c5 0d10  str.w    r0, [r5, #0xd10]
+0x00000134:  f8d5 0200  ldr.w    r0, [r5, #0x200]
+0x00000138:  f8d5 6100  ldr.w    r6, [r5, #0x100]
+0x0000013c:  4206       tst      r6, r0
+0x0000013e:  bf02       ittt     eq
+0x00000140:  f3bf 8f4f  dsbeq    sy
+0x00000144:  bf20       wfeeq
+
+Linking TBs 0x7df6dc000940 index 0 -> 0x7df6dc000a80
+Trace 0: 0x7df6dc000a80 [00800400/0000000000000120/00000110/ff020000]
+[...]
+Trace 0: 0x7df6dc001fc0 [00800400/0000000000000170/00000110/ff020000]
+Taking exception 3 [Prefetch Abort] on CPU 0
+...at fault address 0xdeadbeee
+...with CFSR.IACCVIOL
+...BusFault with BFSR.STKERR
+...taking pending nonsecure exception 3
+...loading from element 3 of non-secure vector table at 0xc
+...loaded new PC 0x111
+----------------
+IN:
+0x00000110:  e7fe       b        #0x110
+```
+Steps to reproduce:
+1. Build QEMU with `CONFIG_DEBUG_TCG` enabled, e.g. with `./configure --enable-debug`.
+1. Run Cortex-M firmware with `IT` instruction. (minimal example attached)
+Additional information:
+- Minimal Reproducer: [raw-it-bug.hex](/uploads/3ae30ab78f49bbc933e48c51f6bf2a2b/raw-it-bug.hex)
+- Reproduced on `main`, `v10.0.0` and `v9.1.0`.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/317 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/317
new file mode 100644
index 00000000..e19bf23f
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/317
@@ -0,0 +1 @@
+synchronous abort on accessing unused I/O ports on aarch64
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/333 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/333
new file mode 100644
index 00000000..bf6093df
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/333
@@ -0,0 +1 @@
+random errors on aarch64 when executing __aarch64_cas8_acq_rel
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/364 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/364
new file mode 100644
index 00000000..814a3306
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/364
@@ -0,0 +1 @@
+qemu-aarch64: incorrect signed comparison in ldsmax instructions
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/367 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/367
new file mode 100644
index 00000000..48db8047
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/367
@@ -0,0 +1 @@
+qemu-system-aarch64 crash on qemu 6.0 - Windows 10
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/381 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/381
new file mode 100644
index 00000000..b9ea3c9f
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/381
@@ -0,0 +1 @@
+ERROR:target/arm/translate-a64.c:13229:disas_simd_two_reg_misc_fp16: code should not be reached
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/385 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/385
new file mode 100644
index 00000000..870c7787
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/385
@@ -0,0 +1 @@
+ARM user regression since 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/403 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/403
new file mode 100644
index 00000000..15569dfb
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/403
@@ -0,0 +1 @@
+MTE false positives for unaligned accesses
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/503 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/503
new file mode 100644
index 00000000..0de93658
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/503
@@ -0,0 +1 @@
+QEMU aarch64 Segmentation fault on Mac OSX, machine raspi3
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/514 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/514
new file mode 100644
index 00000000..3c3fd8c4
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/514
@@ -0,0 +1,25 @@
+MTE reports false positive for "str" instruction with the SP as the base register.
+Description of problem:
+When PE executes "sp"-based store instruction with offset I got tag check fault exception. But according to arm spec. load or store that uses "sp" register should generate Tag Unchecked access.
+Steps to reproduce:
+Clang version: clang version 12.0.1. 
+I compiled my code using "-target aarch64-linux -march=armv8+memtag -fsanitize=memtag" for Clang. Clang generates following code:
+```
+0000000000000c14 <test_func>:
+     c14:       a9bc7bfd        stp     x29, x30, [sp, #-64]!
+     c18:       f9000bf7        str     x23, [sp, #16]
+     ...
+```
+Whole stack was mapped in translation tables as Tagged memory."SCTLR" register was configured to trigger synchronous exception on tag mismatch.
+When cpu executes firs instruction "stp     x29, x30, [sp, #-64]!" I got tag check fault exception: "0b010001 When FEAT_MTE is implemented Synchronous Tag Check Fault":
+ESR_EL1=0x96000051.
+
+According to ARM specification load or store that uses "sp" register should generate Tag Unchecked access:
+```
+A Tag Unchecked access will be generated for a load or store that uses either of the following:
+• A base register only, with the SP as the base register.
+• A base register plus immediate offset addressing form, with the SP as the base register.
+```
+Looks like qemu erroneously generates tag mismatch exceptions for SP-based loads and stores with immediate offset.
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/60 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/60
new file mode 100644
index 00000000..8a337110
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/60
@@ -0,0 +1 @@
+qemu-system-aarch64 (tcg):  cval + voff overflow not handled, causes qemu to hang
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/734 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/734
new file mode 100644
index 00000000..6b891d93
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/734
@@ -0,0 +1,28 @@
+aarch64 tlb range invalidate is not accurate
+Description of problem:
+In this (https://gitlab.com/qemu-project/qemu/-/commit/84940ed82552d3c7c7327c83076b02cee7978257) commit, tlb range invalidate support is added, and I think qemu's range calculation is wrong.
+
+In `tlbi_aa64_range_get_length` function, `num`, `scale`, `page_size_granule` is caculated as below.
+
+
+```
+    num = extract64(value, 39, 4);
+    scale = extract64(value, 44, 2);
+    page_size_granule = extract64(value, 46, 2);
+
+    page_shift = page_size_granule * 2 + 12;
+```
+
+As [Arm documentation](https://developer.arm.com/documentation/ddi0595/2021-06/AArch64-Instructions/TLBI-RVALE1--TLBI-RVALE1NXS--TLB-Range-Invalidate-by-VA--Last-level--EL1), NUM bits's length is 5, but the code above only extract 4bits.
+
+And `page_shift` also should be calculated as `(page_size_granule-1) <<1) + 12` rather than `page_size_granule * 2 + 12`.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+I found this issue while debugging a phenomenon that kernel panic occurs randomly in my qemu fork.
+
+I'm pretty sure this is one of the causes, but even if I roughly correct it, my problem has not been solved.
+
+I think my problem is TLB invalidate related issue, so if I find any more problems, I'll comment here.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/735 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/735
new file mode 100644
index 00000000..ab752840
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/735
@@ -0,0 +1,26 @@
+softmmu 'at' not behaving
+Description of problem:
+This looks like a bug to me, please correct if I'm wrong. The execution context is EL2 here and we run KVM vms on top of the system emulation. Anyway, here we have stopped in the EL2 and want to translate a virtual address '0' with 'at'. While the '0' itself is not mapped, something in the first gigabyte is, and the softmmu refuses to walk to it:
+
+0x0000000100004a3c <at_s12e1r+8>: 80 78 0c d5 at s12e1r, x0
+0x0000000100004a40 <at_s12e1r+12>: 01 74 38 d5 mrs x1, par_el1
+
+(gdb) info registers x0 x1
+x0             0x0                 0
+x1             0x809               2057
+
+So that would be translation fault level 0, stage 1 if I'm not mistaken.
+
+(gdb) info all-registers TCR_EL1 VTCR_EL2 TTBR1_EL1
+TCR_EL1        0x400035b5503510    18014629184681232
+VTCR_EL2       0x623590            6436240
+TTBR1_EL1      0x304000041731001   217298683118686209
+
+(gdb) p print_table(0x41731000)
+000:0x000000ffff9803 256:0x000000fffff803 507:0x00000041fbc803
+508:0x000000ff9ef803
+
+The first gigabyte is populated, yet the 'at' knows nothing about it. Did I miss something? This seems to be working fine on the hardware.
+Steps to reproduce:
+1. Stop in the EL2 while the linux is running (GDB)
+2. Use something along the lines of this function to translate any kernel virtual address: https://github.com/jkrh/kvms/blob/4c26c786be9971613b3b7f56121c1a1aa3b9585a/core/helpers.h#L74
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/788 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/788
new file mode 100644
index 00000000..1ce1ec88
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/788
@@ -0,0 +1 @@
+FEAT_PAuth trapping behaviour incorrectly emulated on Secure-EL0/1 with Secure-EL2 disabled
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/790 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/790
new file mode 100644
index 00000000..24cddd94
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/790
@@ -0,0 +1 @@
+Attribute bits in stage 1/stage 2 block descriptors are not fully masked during AArch64 page table walks
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/799 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/799
new file mode 100644
index 00000000..13c6c308
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/799
@@ -0,0 +1,47 @@
+TCG Optimizer crashes on AArch64 SVE2 instruction
+Description of problem:
+QEMU crashes due to an assertion in the TCG optimizer when optimizing an SVE2 instruction:
+```
+Unrecognized operation 145 in do_constant_folding.
+../tcg/optimize.c:458: tcg fatal error
+```
+Steps to reproduce:
+1. Compile the following minimized reproducer: (a pre-compiled image is provided for convenience - [reproducer.img](/uploads/0bddbfac55306a297fee59dd2f6923cf/reproducer.img))
+```asm
+.org 0x0
+entry:
+    mrs     x1, cptr_el3
+    orr     x9, x1, #0x100
+    msr     cptr_el3,   x9
+
+    msr     cptr_el2,   xzr
+
+    mov     x1, #0x3
+    mrs     x9, cpacr_el1
+    bfi     x9, x1, #16, #2
+    bfi     x9, x1, #20, #2
+    msr     cpacr_el1,  x9
+
+    mov     x9, 512
+    mov     x0, x9
+    asr     x0, x0, 7
+    sub     x9, x0, #1
+    msr     zcr_el1, x9
+
+    mov     x9, 512
+    mov     x0, x9
+    asr     x0, x0, 7
+    sub     x9, x0, #1
+    msr     zcr_el2, x9
+
+    mov     x9, 512
+    mov     x0, x9
+    asr     x0, x0, 7
+    sub     x9, x0, #1
+    msr     zcr_el3, x9
+
+    uqxtnt  z11.s, z22.d
+```
+2. Execute it using the command line given above.
+Additional information:
+I tested latest master as well, and the problem persists.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/826 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/826
new file mode 100644
index 00000000..b20309dc
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/826
@@ -0,0 +1,16 @@
+AArch64 SVE2 LDNT1SB (vector plus scalar) load address incorrectly calculated
+Description of problem:
+During execution of the following SVE2 instruction:
+`ldnt1sb {z6.d}, p3/z, [z14.d, x9]`
+with the following register state:
+```
+(gdb) p $p3
+$1 = {0x7, 0x0, 0x74, 0x0, 0x43, 0x0, 0x29, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x66, 0xe4, 0x64, 0x0, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0xb0, 0x8b, 0x49, 0x34, 0xfc, 0x7f, 0x0, 0x0, 0xe0, 0x71, 0x30, 0x1, 0x0, 0x0, 0x0, 0x0}
+(gdb) p $z14.d.u
+$2 = {0x3bdeaa30, 0x3bdeaa33, 0x3bdeaa36, 0x3bdeaa39, 0x3bdeaa3c, 0x3bdeaa3f, 0x3bdeaa42, 0x3bdeaa45}
+(gdb) p $x9
+$3 = 0x0
+```
+QEMU produces a data abort due to an address fault on address `0x5EE45E4E`, which it clearly should not have tried to load.
+Additional information:
+A quick look at the implementation of the LDNT1SB instruction in QEMU points to the following commit: https://gitlab.com/qemu-project/qemu/-/commit/cf327449816d5643106445420a0b06b0f38d4f01 which simply redirects to SVE's LD1SB handler. As these instructions use a new flavor of SVE scatter/gather loads (vector plus scalar) which SVE LD1SB does not support, I wonder if the LD1SB handler simply decodes it as the wrong instruction and treats it as a (scalar plus vector) instruction, which LD1SB does support, but whose address calculation is completely different.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/840 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/840
new file mode 100644
index 00000000..bc9174c3
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/840
@@ -0,0 +1,10 @@
+When O2 level is enabled raspi3b board crash randomly when creating abuffer of a differnt size
+Description of problem:
+Sometimes when running the code creating a framebuffer different from the default size ej:1024x768 qemu hangs and crash with a SIGV, making a weird screen that's painted with the original size and the background of the current window merged onto a large window. This happens when you resize a window without updating it's contents, so qemu is crashing before the first frame after reising the window.
+Steps to reproduce:
+1. Create a producedure similar to the one descrived below
+2. Run qemu with O2 enabled(debuggind disabled)
+3. You may need to run it multiple times to see the bug(like two or three times)
+Additional information:
+Here is the example procedure implemented on rust, the mailbox interface is test and it's sure that the procedure it's well implemented:
+[code.rs](/uploads/a28fe33a856fb843d80ffeb078bc6729/code.rs)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/876 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/876
new file mode 100644
index 00000000..8d819538
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/876
@@ -0,0 +1,34 @@
+snek-arm fails on s390x with qemu >6.1
+Description of problem:
+snek is a language inspired by python for embedded. The tests run snek code natively (in this case on s390x) as well as in python3 as well as emulated for arm.
+The latter is what fails...
+
+the Ubuntu testing has spotted this in:
+
+- https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/s390x/s/snek/20220211_065108_2144a@/log.gz
+- https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/s390x/s/snek/20220212_050524_3b7ee@/log.gz
+- https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/s390x/s/snek/20220214_080226_46968@/log.gz
+
+In there all work, but one test fails reproducible, that is `test/pass-slice.py`
+
+When eliminating the automation in makefiles and all that it comes down to:
+```
+$ qemu-system-arm -chardev stdio,mux=on,id=stdio0 -serial none -monitor none -semihosting-config enable=on,chardev=stdio0,arg='snek',arg=test/pass-slice.py -machine mps2-an385,accel=tcg -cpu cortex-m3 -kernel /usr/share/snek/snek-qemu-arm-1.7.elf -nographic -bios none
+fail: [::-5] (model 'o' impl '')
+```
+
+To be clear:
+- the test for python3 works on all platforms
+- the test for snek-native works on all platforms
+- the test for snek-arm work on all platforms except s390x
+- with qemu 6.0 this worked, but the more recent qemu 6.2 makes it fail
+- only some subtests of pass-slice.py fail (see below)
+
+I've gone into some details for the snek side of things in [the bug report there](https://github.com/keith-packard/snek/issues/58).
+Steps to reproduce:
+1. get an s390x system
+2. get the snek elf file for arm
+3. run qemu-system-arm as shown above
+
+P.S. I tried this on latest head (building qemu in an F35 container) and it fails there as well, hence I'm listing commit 2d88a3a595 as affected as well.
+We know 6.0 was ok, so likely 6.0->6.1 brought the issue, I have not yet checked if a bisect is feasible for this.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/890 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/890
new file mode 100644
index 00000000..cd278b40
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/890
@@ -0,0 +1 @@
+Misinterpretation of arm neon invalid insn
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/910 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/910
new file mode 100644
index 00000000..0ca9796d
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/910
@@ -0,0 +1 @@
+Black screen in qemu 6.2 with wayland, weston, gtk, virgl, ivi shell, Aarch64
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/925 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/925
new file mode 100644
index 00000000..cdb2e2b1
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/925
@@ -0,0 +1,18 @@
+AArch64 SVE2 LD/ST instructions segfault on MMIO addresses
+Description of problem:
+During execution of the following SVE2 instruction: `ld1b {z9.s}, p2/z, [x17, z26.s, sxtw]` with the following register state:
+```
+(gdb) p $x17
+$1 = 0xffffffe2
+(gdb) p $z26.s.u
+$2 = {0x0 <repeats 16 times>}
+(gdb) p $p2
+$3 = {0xc4, 0x0, 0x9d, 0x0, 0xe5, 0x0, 0x83, 0x0, 0x80, 0xce, 0x3f, 0x3, 0x0, 0x0, 0x0, 0x0, 0x46, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x56, 0x1a, 0x6e, 0x0, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xd8, 0x96, 0xee, 0xfc, 0x7f, 0x0, 0x0, 0x50, 0xce, 0x94, 0x1, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xd8, 0x96, 0xee, 0xfc, 0x7f, 0x0, 0x0, 0x10, 0x38, 0x40, 0x3, 0x0, 0x0, 0x0, 0x0}
+```
+QEMU segfaults due to a null pointer access. Note that after translation this address is an MMIO address that points to a UART device.
+Additional information:
+A quick look at the implementation of the SVE2 load/store host memory access functions I've noticed that the `TLB_MMIO` flag is ignored in `sve_probe_page`, which means that users use the (null) host address as if it was pointing to real memory. This function (or the ones above it) should (probably) throw the appropriate external data abort, otherwise this needs to be instrumented to support reading from MMIO mapped devices.
+
+<details><summary>Reproducer seed for my future self</summary>
+S6008340160849309262|Q|cd4t|pq|w5|lK124
+</details>
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/953 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/953
new file mode 100644
index 00000000..afe3f899
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/953
@@ -0,0 +1 @@
+qemu-system-aarch64 asserts trying to execute STXP on hosts without HAVE_CMPXCHG128
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/964 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/964
new file mode 100644
index 00000000..44a1767d
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/964
@@ -0,0 +1,40 @@
+arm64 defconfig kernel (4.14.275) no longer boots after FEAT_LPA implementation in TCG
+Description of problem:
+I am not really sure if this is a bug or merely a scenario where this is not expected to work. After 7a928f43d8724bdf0777d7fc67a5ad973a0bf4bf, the attached `Image.gz` (`ARCH=arm64 defconfig`, based on the latest `linux-4.14.y`) just hangs with no output when using `-cpu max` (or `-cpu max,lpa2=off` due to 69b2265d5fe8e0f401d75e175e0a243a7d505e53). At 0af312b6edd231e1c8d0dec12494a80bc39ac761, `-cpu max` works just fine, as shown by the bisect log below.
+
+```
+$ git bisect log
+# bad: [99eb313ddbbcf73c1adcdadceba1423b691c6d05] ui/cocoa: Use the standard about panel
+# good: [44f28df24767cf9dca1ddc9b23157737c4cbb645] Update version for v6.2.0 release
+git bisect start '99eb313ddbbcf73c1adcdadceba1423b691c6d05' 'v6.2.0'
+# good: [2fc1b44dd0e7ea9ad5920352fd04179e4d6836d9] target/riscv: rvv-1.0: Allow Zve32f extension to be turned on
+git bisect good 2fc1b44dd0e7ea9ad5920352fd04179e4d6836d9
+# good: [e64e27d5cb103b7764f1a05b6eda7e7fedd517c5] 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread
+git bisect good e64e27d5cb103b7764f1a05b6eda7e7fedd517c5
+# good: [747ffe28cad7129e1d326d943228fdcbe109530d] pnv/xive2: Add support XIVE2 P9-compat mode (or Gen1)
+git bisect good 747ffe28cad7129e1d326d943228fdcbe109530d
+# bad: [4377683df969e715e3cb2dbd258e44f9ff51f788] edid: Fix clock of Detailed Timing Descriptor
+git bisect bad 4377683df969e715e3cb2dbd258e44f9ff51f788
+# good: [755e8d7cb6ce2ba62d282ffbb367de391fe0cc3d] migration: Move static var in ram_block_from_stream() into global
+git bisect good 755e8d7cb6ce2ba62d282ffbb367de391fe0cc3d
+# bad: [6629bf78aac7e53f83fd0bcbdbe322e2302dfd1f] Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20220302' into staging
+git bisect bad 6629bf78aac7e53f83fd0bcbdbe322e2302dfd1f
+# good: [0af312b6edd231e1c8d0dec12494a80bc39ac761] target/arm: Implement FEAT_LVA
+git bisect good 0af312b6edd231e1c8d0dec12494a80bc39ac761
+# bad: [dc8bc9d6574aa563ed2fcc0ff495e77a2a2a8faa] target/arm: Report KVM's actual PSCI version to guest in dtb
+git bisect bad dc8bc9d6574aa563ed2fcc0ff495e77a2a2a8faa
+# bad: [d976de218c534735e307fc4a6c03e3ae764fd419] target/arm: Fix TLBIRange.base for 16k and 64k pages
+git bisect bad d976de218c534735e307fc4a6c03e3ae764fd419
+# bad: [13e481c9335582fc7eed12e24e8d4d7068b24ff8] target/arm: Extend arm_fi_to_lfsc to level -1
+git bisect bad 13e481c9335582fc7eed12e24e8d4d7068b24ff8
+# bad: [7a928f43d8724bdf0777d7fc67a5ad973a0bf4bf] target/arm: Implement FEAT_LPA
+git bisect bad 7a928f43d8724bdf0777d7fc67a5ad973a0bf4bf
+# first bad commit: [7a928f43d8724bdf0777d7fc67a5ad973a0bf4bf] target/arm: Implement FEAT_LPA
+```
+
+A `4.19.237` kernel boots right up with `-cpu max`/`-cpu max,lpa2=off`. Is this expected behavior given the age of the kernel or is there something else going on here? If this is expected, should we be using something like `-cpu cortex-a72` for these older kernels?
+Steps to reproduce:
+Run the above command with the attached `Image.gz` and `rootfs.cpio`.
+Additional information:
+[Image.gz](/uploads/7b25b70f210354663b8e391290d3f39c/Image.gz)
+[rootfs.cpio](/uploads/4793be1a500bdf615e212d3379c4c175/rootfs.cpio)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_TCG/998 b/gitlab/issues_text/target_arm/host_missing/accel_TCG/998
new file mode 100644
index 00000000..be2ff866
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_TCG/998
@@ -0,0 +1,60 @@
+AArch64: SCTLR_EL1.BT0 set incorrectly in user mode
+Description of problem:
+PACIASP normally acts as a BTI landing pad, but not in every situation. When SCTLR_EL1.BT is set, PACIASP checks that the indirect branch originates from X16 or X17 when the indirect branch is taken from a BTI guarded area. Linux sets this bit, ideally QEMU-user should too. This sample program should crash with a SIGILL if QEMU is working correctly, otherwise it will crash with a SIGSEGV.
+
+    #include <stdint.h>
+    #include <stdlib.h>
+    #include <unistd.h>
+    #include <string.h>
+    #include <stdio.h>
+    #include <sys/mman.h>
+
+    // PACIASP is a valid BTI landing pad, but there are some conditions
+    // under Linux which sets SCTLR_ELx.BT0 = 1. In this mode, a branch
+    // onto a PACIASP landing pad is only valid if it originates from
+    // x16 or x17 (i.e. br x17 is OK, br x3 is not).
+    // More info on page D5-4851 of the Arm Architecture Reference Manual (ARM DDI 0487H.a).
+
+    // Sample function which starts with a paciasp instruction
+    // (comes from -mbranch-protection=pac-ret+leaf)
+    void indirect_fn(int i) {
+        // paciasp instruction inserted here - should crash with SIGILL here if everything's operating OK.
+        i = i+1;
+        // Can't access this function from the copied location, so will segfault.
+        fprintf(stderr, "reachable\n");
+    }
+
+    int main(int argc, char **argv) {
+        // It's difficult to get a whole binary BTI compatible without the appropriate crtbegin etc
+        // so instead map a page and copy the sample function there.
+        void *e = mmap(0, getpagesize(), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+        if (e == MAP_FAILED) {
+            return 1;
+        }
+        memcpy(e, (void*)indirect_fn, 64);
+        mprotect(e, getpagesize(), PROT_READ | PROT_EXEC | PROT_BTI);
+
+        // paciasp is a valid landing pad if the branch comes from an unprotected area,
+        // so to ensure that we're protected - assemble an intermediate shim that's also PROT_BTI.
+        void *f = mmap(0, getpagesize(), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+        if (f == MAP_FAILED) {
+            return 1;
+        }
+        uint32_t *x = (uint32_t*)f;
+        x[0] = 0xd503245fuL; // bti c
+        x[1] = 0xd61f0060uL; // br x1 - n.b. must be BR
+        mprotect(f, getpagesize(), PROT_READ | PROT_EXEC | PROT_BTI);
+
+        // Jump to the shim
+        asm volatile (
+            "mov x3, %0\n"
+            "mov x2, %1\n"
+            "blr x2\n"
+        : : "p"(e), "p"(f) : "x2", "x3");
+
+        // Execution should not reach here
+        return 1;
+    }
+Steps to reproduce:
+1. Compile with `clang-12 -g --sysroot=/work/home/fedora-rootfs/fedora_aarch64 -o sample --target=aarch64-linux-gnu -mbranch-protection=pac-ret+leaf -march=armv8-a -O1 -g sample.c` or similar.
+2. Run with `../qemu/build/qemu-aarch64 --cpu max -L ~/fedora-rootfs/fedora_aarch64 sample`
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_Xen/2174 b/gitlab/issues_text/target_arm/host_missing/accel_Xen/2174
new file mode 100644
index 00000000..dd004279
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_Xen/2174
@@ -0,0 +1 @@
+XenBus machines have almost no hotplug support
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1039 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1039
new file mode 100644
index 00000000..17962290
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1039
@@ -0,0 +1 @@
+Building qemu in MSYS2 clangarm64
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/105 b/gitlab/issues_text/target_arm/host_missing/accel_missing/105
new file mode 100644
index 00000000..43774135
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/105
@@ -0,0 +1 @@
+Gdb hangs when trying to single-step after an invalid instruction
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1056 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1056
new file mode 100644
index 00000000..91437af9
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1056
@@ -0,0 +1 @@
+Bad Performance of Windows 11 ARM64 VM on Windows 11 Qemu 7.0 Host System
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1078 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1078
new file mode 100644
index 00000000..3d737eae
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1078
@@ -0,0 +1,44 @@
+qemu-system-arm: unable to use LPAE
+Description of problem:
+Failed to run qemu: qemu-system-arm: Addressing limited to 32 bits,
+but memory exceeds it by 1073741824 bytes
+Steps to reproduce:
+1. ./configure --target-list=arm-softmmu
+2. make
+3.
+./qemu-system-arm \
+-machine virt,highmem=on \
+-cpu cortex-a15 -smp 4 \
+-m 4096 \
+-kernel ./zImage \
+-drive id=disk0,file=./rootfs.ext4,if=none,format=raw \
+-object rng-random,filename=/dev/urandom,id=rng0 \
+-device virtio-rng-pci,rng=rng0 \
+-device virtio-blk-device,drive=disk0 \
+-device virtio-gpu-pci \
+-serial mon:stdio -serial null \
+-nographic \
+-append 'root=/dev/vda rw mem=4096M ip=dhcp console=ttyAMA0 console=hvc0'
+Additional information:
+We set physical address bits to 40 if ARM_FEATURE_LPAE is enabled. But ARM_FEATURE_V7VE also implies ARM_FEATURE_LPAE as set later in arm_cpu_realizefn.
+
+We should add condition for ARM_FEATURE_V7VE, otherwise we would not be able to use highmem larger than 3GB even though we have enabled highmem, since we would fail and return right from machvirt_init. 
+
+I have already made a patch to fix this issue.
+https://gitlab.com/realhezhe/qemu/-/commit/4dad8167c1c1a7695af88d8929e8d7f6399177de
+`hw/arm/virt.c`
+```c
+        if (object_property_get_bool(cpuobj, "aarch64", NULL)) {
+            pa_bits = arm_pamax(armcpu);
+        } else if (arm_feature(&armcpu->env, ARM_FEATURE_LPAE)) {
+        } else if (arm_feature(&armcpu->env, ARM_FEATURE_LPAE)
+                || arm_feature(&armcpu->env, ARM_FEATURE_V7VE)) {
+            /* v7 with LPAE */
+            pa_bits = 40;
+        } else {
+```
+
+After applying the patch, I can make sure that the pa_bits has already been set to 40, but qemu hangs later. By bisecting I found if the following commit is reverted qemu can boot up successfully..
+39a1fd2528 ("target/arm: Fix handling of LPAE block descriptors")
+
+It can't be quickly determined what's going on here at my side. Maybe the author can help give some hints. Thanks.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1103 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1103
new file mode 100644
index 00000000..0f257a84
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1103
@@ -0,0 +1 @@
+VTCR fields are not checked when building parameters for aarch64 secure EL2 page table walk
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1104 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1104
new file mode 100644
index 00000000..2ea425d4
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1104
@@ -0,0 +1 @@
+PAN support for AArch32
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1105 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1105
new file mode 100644
index 00000000..0f7d4d0d
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1105
@@ -0,0 +1,3 @@
+QEMU gdbstub should support PAC for aarch64
+Additional information:
+The fix should probably be in gdbstub.c
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1109 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1109
new file mode 100644
index 00000000..1fd78cf1
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1109
@@ -0,0 +1,42 @@
+rpi3b frame buffer segfault
+Description of problem:
+I'm compiling a series of bare metal Raspberry Pi labs for the RPi 3B.  One particular lab that I tried to compile and run, which makes use of the framebuffer, causes QEMU to segfault when trying to draw to the framebuffer.  It looks like the value of `dst` passed into `draw_line_s16` is bogus and this causes the segfault.  I'm not familiar enough with the code in QEMU to immediately know why `dst` is bogus.
+
+The lab I'm trying to run (the code compiled to `kernel8.img`) is here: https://github.com/bztsrc/raspi3-tutorial/tree/master/09_framebuffer
+
+A gdb stacktrace of the segfault is here:
+
+```
+Thread 1 "qemu-system-aar" received signal SIGSEGV, Segmentation fault.
+0x00005555559580c0 in rgb_to_pixel32 (b=<optimized out>, g=<optimized out>, r=<optimized out>)
+    at /home/rhett/qemu/include/ui/pixel_ops.h:46
+46	    return (r << 16) | (g << 8) | b;
+(gdb) bt
+#0  0x00005555559580c0 in rgb_to_pixel32 (b=<optimized out>, g=<optimized out>, r=<optimized out>)
+    at /home/rhett/qemu/include/ui/pixel_ops.h:46
+#1  draw_line_src16
+    (opaque=opaque@entry=0x7fffe84d1c30, dst=dst@entry=0x7fffe8235010 <error: Cannot access memory at address 0x7fffe8235010>, src=0x7fff94300004 "", src@entry=0x7fff94300000 "", width=639, width@entry=640, deststep=deststep@entry=0) at ../hw/display/bcm2835_fb.c:131
+#2  0x0000555555953977 in framebuffer_update_display
+    (ds=<optimized out>, mem_section=<optimized out>, cols=640, rows=480, src_width=1280, dest_row_pitch=2560, dest_col_pitch=0, invalidate=1, fn=0x555555957fe0 <draw_line_src16>, opaque=0x7fffe84d1c30, first_row=0x7fffffffdb90, last_row=0x7fffffffdb94)
+    at ../hw/display/framebuffer.c:107
+#3  0x0000555555957eeb in fb_update_display (opaque=0x7fffe84d1c30) at ../hw/display/bcm2835_fb.c:203
+#4  0x00005555558a9146 in graphic_hw_update (con=0x555556b9bc00) at ../ui/console.c:230
+#5  0x00005555558a7fea in dpy_refresh (s=0x5555571c6aa0) at ../ui/console.c:1842
+#6  gui_update (opaque=opaque@entry=0x5555571c6aa0) at ../ui/console.c:165
+#7  0x0000555556068ecd in timerlist_run_timers (timer_list=0x555556b15350) at ../util/qemu-timer.c:576
+#8  timerlist_run_timers (timer_list=0x555556b15350) at ../util/qemu-timer.c:501
+#9  0x00005555560690c0 in qemu_clock_run_timers (type=<optimized out>) at ../util/qemu-timer.c:672
+#10 qemu_clock_run_all_timers () at ../util/qemu-timer.c:672
+#11 0x0000555556064bf6 in main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:607
+#12 0x0000555555b0a4f9 in qemu_main_loop () at ../softmmu/runstate.c:726
+#13 0x000055555589ec74 in qemu_main (envp=0x0, argv=<optimized out>, argc=<optimized out>) at ../softmmu/main.c:36
+#14 main (argc=<optimized out>, argv=<optimized out>) at ../softmmu/main.c:45
+```
+Steps to reproduce:
+1. Clone the git repo for the labs I linked above
+2. `cd raspi3-tutorial/09_framebuffer`
+3. `make`
+4. `make run`
+5. Segfault
+
+I have found this on QEMU 5.2, QEMU 7.0, and the bleeding edge of the github repo
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1121 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1121
new file mode 100644
index 00000000..26f89365
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1121
@@ -0,0 +1,70 @@
+Segmentation fault in aspeed-hace
+Description of problem:
+
+Steps to reproduce:
+1. run qemu-machine nf5280m7-bmc
+2. it will seg falult when load fitimage
+Additional information:
+Captured by gdb
+
+```
+0x00007ffff6e08a06 in has_padding (pad_offset=<synthetic pointer>, total_msg_len=<synthetic pointer>, req_len=17, total_req_len=56476, iov=0x7ffff5e973c0) at ../hw/misc/aspeed_hace.c:129
+129	       if (padding[*pad_offset] == 0x80) {
+(gdb) p padding_size
+$1 = 45
+(gdb) p *padding_offset
+No symbol "padding_offset" in current context.
+(gdb) p *pad_offset
+$2 = 4294967268
+(gdb) bt
+#0  0x00007ffff6e08a06 in has_padding (pad_offset=<synthetic pointer>, total_msg_len=<synthetic pointer>, req_len=17, total_req_len=56476, 
+    iov=0x7ffff5e973c0) at ../hw/misc/aspeed_hace.c:129
+#1  gen_acc_mode_iov (cache=0x7ffff7fd5600 <iov_cache>, total_req_len=0x7ffff7fd55e4 <total_len>, count=0x7ffff7fd55e0 <count>, 
+    req_len=0x7ffff5e973a8, id=<optimized out>, iov=0x7ffff5e973b0) at ../hw/misc/aspeed_hace.c:176
+#2  do_hash_operation (s=s@entry=0x7ffff60077b0, algo=3, sg_mode=sg_mode@entry=true, acc_mode=acc_mode@entry=true)
+    at ../hw/misc/aspeed_hace.c:235
+#3  0x00007ffff6e09001 in aspeed_hace_write (opaque=<optimized out>, addr=12, data=262488, size=<optimized out>)
+    at ../hw/misc/aspeed_hace.c:372
+#4  0x00007ffff706ad54 in memory_region_write_accessor (mr=mr@entry=0x7ffff6007ad0, addr=48, value=value@entry=0x7ffff5e98548, 
+    size=size@entry=4, shift=<optimized out>, mask=mask@entry=4294967295, attrs=...) at ../softmmu/memory.c:492
+#5  0x00007ffff7068266 in access_with_adjusted_size_aligned (addr=addr@entry=48, value=value@entry=0x7ffff5e98548, size=size@entry=4, 
+    access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x7ffff706acd0 <memory_region_write_accessor>, 
+    mr=0x7ffff6007ad0, attrs=...) at ../softmmu/memory.c:553
+#6  0x00007ffff706c948 in memory_region_dispatch_write (mr=mr@entry=0x7ffff6007ad0, addr=addr@entry=48, data=<optimized out>, 
+    data@entry=262488, op=op@entry=MO_32, attrs=...) at ../softmmu/memory.c:1650
+#7  0x00007ffff7157ea9 in io_writex (env=env@entry=0x7ffff5fe7f10, iotlbentry=0x7fff6803f200, mmu_idx=mmu_idx@entry=7, val=val@entry=262488, 
+    addr=addr@entry=510459952, retaddr=retaddr@entry=140736149505328, op=MO_32) at ../accel/tcg/cputlb.c:1429
+#8  0x00007ffff715c7dc in store_helper (op=MO_32, retaddr=140736149505328, oi=<optimized out>, val=262488, addr=510459952, 
+    env=0x7ffff5fe7f10) at ../accel/tcg/cputlb.c:2363
+#9  full_le_stl_mmu (env=0x7ffff5fe7f10, addr=<optimized out>, val=262488, oi=<optimized out>, retaddr=140736149505328)
+    at ../accel/tcg/cputlb.c:2451
+#10 0x00007fffb032c530 in code_gen_buffer ()
+#11 0x00007ffff714eace in cpu_tb_exec (cpu=cpu@entry=0x7ffff5fde1b0, itb=itb@entry=0x7fffb033e7c0 <code_gen_buffer+3401619>, 
+    tb_exit=tb_exit@entry=0x7ffff5e98c2c) at ../accel/tcg/cpu-exec.c:357
+#12 0x00007ffff714fc68 in cpu_loop_exec_tb (tb_exit=0x7ffff5e98c2c, last_tb=<synthetic pointer>, 
+    tb=0x7fffb033e7c0 <code_gen_buffer+3401619>, cpu=0x7ffff5fde1b0) at ../accel/tcg/cpu-exec.c:847
+#13 cpu_exec (cpu=cpu@entry=0x7ffff5fde1b0) at ../accel/tcg/cpu-exec.c:1006
+#14 0x00007ffff7163d54 in tcg_cpus_exec (cpu=cpu@entry=0x7ffff5fde1b0) at ../accel/tcg/tcg-accel-ops.c:68
+#15 0x00007ffff7163ea7 in mttcg_cpu_thread_fn (arg=arg@entry=0x7ffff5fde1b0) at ../accel/tcg/tcg-accel-ops-mttcg.c:96
+#16 0x00007ffff7344c31 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:556
+#17 0x00007ffff74c74eb in start_thread ()
+#18 0x00007ffff75649c0 in clone3 ()
+```
+the uboot: https://github.com/openbmc/u-boot/commit/0f245563c2cb3a6b4f1206db4f1a9f0325406094
+
+we should remove the hash check, otherwise,  the boot will stop at uboot-cli
+```
+diff --git a/common/image-fit.c b/common/image-fit.c
+index 3c8667f93d..c655b297e5 100644
+--- a/common/image-fit.c
++++ b/common/image-fit.c
+@@ -1193,7 +1193,7 @@ static int fit_image_check_hash(const void *fit, int noffset, const void *data,
+                return -1;
+        } else if (memcmp(value, fit_value, value_len) != 0) {
+                *err_msgp = "Bad hash value";
+-               return -1;
++               return 0;
+        }
+ 
+        return 0;
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1122 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1122
new file mode 100644
index 00000000..c47102c5
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1122
@@ -0,0 +1,128 @@
+ARMv7M (Cortex M) NVIC does not make number of priority bits a board/SoC-configurable parameter
+Description of problem:
+In FreeRTOS code for function of `xPortStartScheduler()` in [`main/portable/GCC/ARM_CM4F/port.c`](https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/portable/GCC/ARM_CM4F/port.c#L293) file code sets the value of 0x400 register of NVIC to the maximum bits and expect to read back only maximum priority bits that are supported by the platform. The QEMU code doesn't unset these bits (same 0xff value written is read back):
+```
+NVIC: priority [0x400] = 0x00
+NVIC[NS]: [0x400] -> 0x00000000
+NVIC: priority [0x400] = 0xff
+NVIC[NS]: [0x400] <- 0x000000ff
+nvic_recompute_state NVIC state recomputed: vectpending 0 vectpending_prio 256 exception_prio 256
+NVIC: priority [0x400] = 0x00
+NVIC[NS]: [0x400] -> 0x000000ff
+```
+Logging function for reading and writing added in `hw/intc/armv7_nvic.c` like these:
+writing:
+```c
+    case 0x400 ... 0x5ef: /* NVIC Priority */
+        startvec = (offset - 0x400) + NVIC_FIRST_IRQ; /* vector # */
+
+        for (i = 0; i < size && startvec + i < s->num_irq; i++) {
+            if (attrs.secure || s->itns[startvec + i]) {
+                qemu_log("NVIC: priority [0x%03x] = 0x%02llx\n", offset, (value >> (i * 8)) & 0xff);
+                set_prio(s, startvec + i, false, (value >> (i * 8)) & 0xff);
+            }
+        }
+        qemu_log("NVIC[%s]: [0x%03x] <- 0x%08llx\n", attrs.secure ? "S" : "NS", offset, value);
+
+        nvic_irq_update(s);
+        goto exit_ok;
+```
+reading:
+```c
+    case 0x400 ... 0x5ef: /* NVIC Priority */
+        val = 0;
+        startvec = offset - 0x400 + NVIC_FIRST_IRQ; /* vector # */
+
+        // TODO: should return either 0x70 or 0x78
+        for (i = 0; i < size && startvec + i < s->num_irq; i++) {
+            qemu_log("NVIC: priority [0x%03x] = 0x%02x\n", offset, 8 * i);
+            if (attrs.secure || s->itns[startvec + i]) {
+                val |= s->vectors[startvec + i].prio << (8 * i);
+            }
+        }
+        qemu_log("NVIC[%s]: [0x%03x] -> 0x%08x\n", attrs.secure ? "S" : "NS", offset, val);
+        break;
+```
+Steps to reproduce:
+1. Run FreeRTOS for any ARMv7 Cortex-M platform with NVIC
+2. Observe failure to proceed to `prvPortStartFirstTask();` function.
+Additional information:
+Here is the piece of standard FreeRTOS code that runs that check:
+```c
+   /* configMAX_SYSCALL_INTERRUPT_PRIORITY must not be set to 0.
+     * See https://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html */
+    configASSERT( configMAX_SYSCALL_INTERRUPT_PRIORITY );
+
+    /* This port can be used on all revisions of the Cortex-M7 core other than
+     * the r0p1 parts.  r0p1 parts should use the port from the
+     * /source/portable/GCC/ARM_CM7/r0p1 directory. */
+    configASSERT( portCPUID != portCORTEX_M7_r0p1_ID );
+    configASSERT( portCPUID != portCORTEX_M7_r0p0_ID );
+
+    #if ( configASSERT_DEFINED == 1 )
+        {
+            volatile uint32_t ulOriginalPriority;
+            volatile uint8_t * const pucFirstUserPriorityRegister = ( volatile uint8_t * const ) ( portNVIC_IP_REGISTERS_OFFSET_16 + portFIRST_USER_INTERRUPT_NUMBER );
+            volatile uint8_t ucMaxPriorityValue;
+
+            /* Determine the maximum priority from which ISR safe FreeRTOS API
+             * functions can be called.  ISR safe functions are those that end in
+             * "FromISR".  FreeRTOS maintains separate thread and ISR API functions to
+             * ensure interrupt entry is as fast and simple as possible.
+             *
+             * Save the interrupt priority value that is about to be clobbered. */
+            ulOriginalPriority = *pucFirstUserPriorityRegister;
+
+            /* Determine the number of priority bits available.  First write to all
+             * possible bits. */
+            *pucFirstUserPriorityRegister = portMAX_8_BIT_VALUE;
+
+            /* Read the value back to see how many bits stuck. */
+            ucMaxPriorityValue = *pucFirstUserPriorityRegister;
+
+            /* Use the same mask on the maximum system call priority. */
+            ucMaxSysCallPriority = configMAX_SYSCALL_INTERRUPT_PRIORITY & ucMaxPriorityValue;
+
+            /* Calculate the maximum acceptable priority group value for the number
+             * of bits read back. */
+            ulMaxPRIGROUPValue = portMAX_PRIGROUP_BITS;
+
+            while( ( ucMaxPriorityValue & portTOP_BIT_OF_BYTE ) == portTOP_BIT_OF_BYTE )
+            {
+                ulMaxPRIGROUPValue--;
+                ucMaxPriorityValue <<= ( uint8_t ) 0x01;
+            }
+
+            #ifdef __NVIC_PRIO_BITS
+                {
+                    /* Check the CMSIS configuration that defines the number of
+                     * priority bits matches the number of priority bits actually queried
+                     * from the hardware. */
+                    configASSERT( ( portMAX_PRIGROUP_BITS - ulMaxPRIGROUPValue ) == __NVIC_PRIO_BITS );
+                }
+            #endif
+
+            #ifdef configPRIO_BITS
+                {
+                    /* Check the FreeRTOS configuration that defines the number of
+                     * priority bits matches the number of priority bits actually queried
+                     * from the hardware. */
+                    configASSERT( ( portMAX_PRIGROUP_BITS - ulMaxPRIGROUPValue ) == configPRIO_BITS );
+                }
+            #endif
+
+            /* Shift the priority group value back to its position within the AIRCR
+             * register. */
+            ulMaxPRIGROUPValue <<= portPRIGROUP_SHIFT;
+            ulMaxPRIGROUPValue &= portPRIORITY_GROUP_MASK;
+
+            /* Restore the clobbered interrupt priority register to its original
+             * value. */
+            *pucFirstUserPriorityRegister = ulOriginalPriority;
+        }
+    #endif /* configASSERT_DEFINED */
+```
+
+See also these pages:
+- https://www.freertos.org/RTOS-Cortex-M3-M4.html
+- https://www.freertos.org/freertos-on-qemu-mps2-an385-model.html
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1123 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1123
new file mode 100644
index 00000000..8e960cf3
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1123
@@ -0,0 +1,91 @@
+Xilinx ZynqMP CAN controller logical error - mixed RX and TX channels
+Description of problem:
+In the code of CAN controller of Xilinx ZynqMP board (`hw/net/can/xlnx-zynqmp-can.c`) in function `update_rx_fifo()` there seems to be a typo or logical error mixing RX and TX buffers:
+```c
+    /* Store the message in fifo if it passed through any of the filters. */
+    if (filter_pass && frame->can_dlc <= MAX_DLC) {
+
+        if (fifo32_is_full(&s->rx_fifo)) {
+            ARRAY_FIELD_DP32(s->regs, INTERRUPT_STATUS_REGISTER, RXOFLW, 1);
+        } else {
+            timestamp = CAN_TIMER_MAX - ptimer_get_count(s->can_timer);
+
+            fifo32_push(&s->rx_fifo, frame->can_id);
+
+            fifo32_push(&s->rx_fifo, deposit32(0, R_RXFIFO_DLC_DLC_SHIFT,
+                                               R_RXFIFO_DLC_DLC_LENGTH,
+                                               frame->can_dlc) |
+                                     deposit32(0, R_RXFIFO_DLC_RXT_SHIFT,
+                                               R_RXFIFO_DLC_RXT_LENGTH,
+                                               timestamp));
+
+            /* First 32 bit of the data. */
+            fifo32_push(&s->rx_fifo, deposit32(0, R_TXFIFO_DATA1_DB3_SHIFT,
+                                               R_TXFIFO_DATA1_DB3_LENGTH,
+                                               frame->data[0]) |
+                                     deposit32(0, R_TXFIFO_DATA1_DB2_SHIFT,
+                                               R_TXFIFO_DATA1_DB2_LENGTH,
+                                               frame->data[1]) |
+                                     deposit32(0, R_TXFIFO_DATA1_DB1_SHIFT,
+                                               R_TXFIFO_DATA1_DB1_LENGTH,
+                                               frame->data[2]) |
+                                     deposit32(0, R_TXFIFO_DATA1_DB0_SHIFT,
+                                               R_TXFIFO_DATA1_DB0_LENGTH,
+                                               frame->data[3]));
+```
+Additional information:
+Possible fix:
+```diff
+ git diff                                                                                                                                                                                              12:29:23
+diff --git a/hw/net/can/xlnx-zynqmp-can.c b/hw/net/can/xlnx-zynqmp-can.c
+index 82ac48cee2..e93e6c5e19 100644
+--- a/hw/net/can/xlnx-zynqmp-can.c
++++ b/hw/net/can/xlnx-zynqmp-can.c
+@@ -696,30 +696,30 @@ static void update_rx_fifo(XlnxZynqMPCANState *s, const qemu_can_frame *frame)
+                                                timestamp));
+
+             /* First 32 bit of the data. */
+-            fifo32_push(&s->rx_fifo, deposit32(0, R_TXFIFO_DATA1_DB3_SHIFT,
+-                                               R_TXFIFO_DATA1_DB3_LENGTH,
++            fifo32_push(&s->rx_fifo, deposit32(0, R_RXFIFO_DATA1_DB3_SHIFT,
++                                               R_RXFIFO_DATA1_DB3_LENGTH,
+                                                frame->data[0]) |
+-                                     deposit32(0, R_TXFIFO_DATA1_DB2_SHIFT,
+-                                               R_TXFIFO_DATA1_DB2_LENGTH,
++                                     deposit32(0, R_RXFIFO_DATA1_DB2_SHIFT,
++                                               R_RXFIFO_DATA1_DB2_LENGTH,
+                                                frame->data[1]) |
+-                                     deposit32(0, R_TXFIFO_DATA1_DB1_SHIFT,
+-                                               R_TXFIFO_DATA1_DB1_LENGTH,
++                                     deposit32(0, R_RXFIFO_DATA1_DB1_SHIFT,
++                                               R_RXFIFO_DATA1_DB1_LENGTH,
+                                                frame->data[2]) |
+-                                     deposit32(0, R_TXFIFO_DATA1_DB0_SHIFT,
+-                                               R_TXFIFO_DATA1_DB0_LENGTH,
++                                     deposit32(0, R_RXFIFO_DATA1_DB0_SHIFT,
++                                               R_RXFIFO_DATA1_DB0_LENGTH,
+                                                frame->data[3]));
+             /* Last 32 bit of the data. */
+-            fifo32_push(&s->rx_fifo, deposit32(0, R_TXFIFO_DATA2_DB7_SHIFT,
+-                                               R_TXFIFO_DATA2_DB7_LENGTH,
++            fifo32_push(&s->rx_fifo, deposit32(0, R_RXFIFO_DATA2_DB7_SHIFT,
++                                               R_RXFIFO_DATA2_DB7_LENGTH,
+                                                frame->data[4]) |
+-                                     deposit32(0, R_TXFIFO_DATA2_DB6_SHIFT,
+-                                               R_TXFIFO_DATA2_DB6_LENGTH,
++                                     deposit32(0, R_RXFIFO_DATA2_DB6_SHIFT,
++                                               R_RXFIFO_DATA2_DB6_LENGTH,
+                                                frame->data[5]) |
+-                                     deposit32(0, R_TXFIFO_DATA2_DB5_SHIFT,
+-                                               R_TXFIFO_DATA2_DB5_LENGTH,
++                                     deposit32(0, R_RXFIFO_DATA2_DB5_SHIFT,
++                                               R_RXFIFO_DATA2_DB5_LENGTH,
+                                                frame->data[6]) |
+-                                     deposit32(0, R_TXFIFO_DATA2_DB4_SHIFT,
+-                                               R_TXFIFO_DATA2_DB4_LENGTH,
++                                     deposit32(0, R_RXFIFO_DATA2_DB4_SHIFT,
++                                               R_RXFIFO_DATA2_DB4_LENGTH,
+                                                frame->data[7]));
+
+             ARRAY_FIELD_DP32(s->regs, INTERRUPT_STATUS_REGISTER, RXOK, 1);
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1141 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1141
new file mode 100644
index 00000000..f9a37b4d
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1141
@@ -0,0 +1,10 @@
+virtio-gpu-gl-pci not working with arm/aarch64
+Description of problem:
+Since migration to using virtio-gpu-gl-pci instead of virtio-gpu-pci (commit 17cdac0b51bc4ad7a68c3e5e0b1718729b74d512, used git-bisect to find the problem) my arm guests fail to load. If I use -device virtio-gpu-gl-pci, I don't get any image on the virtual guest screen. If I use -device virtio-gpu-pci, I can boot the guest and get the image, but GL acceleration is not working. Changing sdl to gtk doesn't help.
+Steps to reproduce:
+1. Download debian netinstall boot iso for arm (https://cdimage.debian.org/debian-cd/current/armhf/iso-cd/debian-11.4.0-armhf-netinst.iso)
+2. Copy edk2-arm-code.fd and edk2-arm-vars.fd files from build dir.
+3. Run command line ```qemu-system-arm -machine virt -m 512 -cdrom debian.iso -device virtio-gpu-gl-pci -display sdl,gl=on,show-cursor=on -pflash edk2-arm-code.fd -pflash edk2-arm-vars.fd```, get a black virtual screen.
+4. Run command line ```qemu-system-arm -machine virt -m 512 -cdrom debian.iso -device virtio-gpu-pci -display sdl,gl=on,show-cursor=on -pflash edk2-arm-code.fd -pflash edk2-arm-vars.fd```, get an image on the virtual screen.
+Additional information:
+I have an x86_64 guest which uses virgl, and it runs fine after 17cdac0b51bc4ad7a68c3e5e0b1718729b74d512 with only changing virtio-gpu-pci to virtio-gpu-gl-pci
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1145 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1145
new file mode 100644
index 00000000..40bfd02b
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1145
@@ -0,0 +1,27 @@
+Support register name resolution in debugger part of monitor for `x` commands for ARM platforms
+Additional information:
+From the looks of `get_monitor_def()` function from `monitor/misc.c` it seems to be cross-target but somehow still doesn't work for some targets anyway.
+
+Then grepping for the actual target implementation, it seems only i386, PPC, SPARC, and M68K support it, but nor ARM, MIPS, RISC V, etc:
+```
+[i] ℤ rg monitor_defs                                                                                                                                                                                       
+target/sparc/monitor.c
+59:const MonitorDef monitor_defs[] = {
+162:const MonitorDef *target_monitor_defs(void)
+164:    return monitor_defs;
+
+target/ppc/monitor.c
+86:const MonitorDef monitor_defs[] = {
+102:const MonitorDef *target_monitor_defs(void)
+104:    return monitor_defs;
+
+target/i386/monitor.c
+611:const MonitorDef monitor_defs[] = {
+647:const MonitorDef *target_monitor_defs(void)
+649:    return monitor_defs;
+
+target/m68k/monitor.c
+25:static const MonitorDef monitor_defs[] = {
+59:const MonitorDef *target_monitor_defs(void)
+61:    return monitor_defs;
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1230 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1230
new file mode 100644
index 00000000..3d412e23
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1230
@@ -0,0 +1,23 @@
+qtest-aarch64/migration-test non-deterministic test failure
+Description of problem:
+The test suite fails:
+```
+Summary of Failures:
+
+ 32/619 qemu:qtest+qtest-aarch64 / qtest-aarch64/migration-test                   ERROR          161.19s   killed by signal 6 SIGABRT
+
+
+Ok:                 552 
+Expected Fail:      0   
+Fail:               1   
+Unexpected Pass:    0   
+Skipped:            66  
+Timeout:            0   
+
+Full log written to /tmp/guix-build-qemu-7.1.0.drv-0/qemu-7.1.0/b/qemu/meson-logs/testlog.txt
+make: *** [Makefile.mtest:25: do-meson-check] Error 1
+```
+
+See the full build log below.
+Additional information:
+[qt60pm4fcc63jcbwfgz86z6cwqgx4zgm-qemu-7.1.0.txt.gz](/uploads/6d7f0da152193213a7fe694e2d535879/qt60pm4fcc63jcbwfgz86z6cwqgx4zgm-qemu-7.1.0.txt.gz)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/124 b/gitlab/issues_text/target_arm/host_missing/accel_missing/124
new file mode 100644
index 00000000..6a98bd5f
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/124
@@ -0,0 +1 @@
+SIGSEGV when reading ARM GIC registers through GDB stub
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1245 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1245
new file mode 100644
index 00000000..3f0cbbf4
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1245
@@ -0,0 +1 @@
+arm: cp15 support
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1255 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1255
new file mode 100644
index 00000000..438f1af4
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1255
@@ -0,0 +1,11 @@
+32bit qemu-arm fails to run systemctl "Allocating guest commpage: Cannot allocate memory"
+Description of problem:
+I am using a bare minimal install of the latest 32 bit version of debian with only ssh installed. I have compiled qemu from the latest git with "./configure --target-list=arm-linux-user --static --disable-pie". When I try to run systemctl from the latest version of raspbian, I experience the error: "Allocating guest commpage: Cannot allocate memory".
+Steps to reproduce:
+1. Download and extract the included systemctl and required libs. [systemctl+libs.tgz](/uploads/a2834ed651a981fded4bcc19ea9ca31b/systemctl+libs.tgz)
+2. run "qemu-arm -L ./ systemctl --version"
+Additional information:
+- I think this is related to [Issue 690](https://gitlab.com/qemu-project/qemu/-/issues/690).
+- When I run "qemu-arm -L ./ -B 0x20000 systemctl --version" there is no error.
+- The error still happens when setting vm.mmap_min_addr to 0.
+- The error does not occur on v5.0.0, but does occur on v5.1.0 and v6.1.0.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1263 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1263
new file mode 100644
index 00000000..831ea183
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1263
@@ -0,0 +1 @@
+arm/imx EPIT timer interrupt does not fire properly on sabrelight
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/127 b/gitlab/issues_text/target_arm/host_missing/accel_missing/127
new file mode 100644
index 00000000..7d585545
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/127
@@ -0,0 +1 @@
+linux-user missing cmsg IP_PKTINFO support ("Unsupported ancillary data: 0/8")
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1280 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1280
new file mode 100644
index 00000000..a32e7733
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1280
@@ -0,0 +1,8 @@
+qemu-system-arm 7.1 can not boot my cortex-m55 image
+Steps to reproduce:
+```
+1.qemu-system-arm -cpu cortex-m55 -machine mps3-an547 -nographic -vga none -monitor none -semihosting -semihosting-config enable=on,target=native -kernel qemu_simu.elf
+2.arm-none-eabi-gdb -ex "target extended-remote localhost:1234" qemu_simu.elf
+```
+Additional information:
+[qemu_simu.tar.gz](/uploads/b8b3bf0f4868fdbb22b19027f685b4f0/qemu_simu.tar.gz)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1297 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1297
new file mode 100644
index 00000000..812e914b
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1297
@@ -0,0 +1 @@
+qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1326 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1326
new file mode 100644
index 00000000..f8e3cec7
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1326
@@ -0,0 +1,58 @@
+qemu-system-aarch64: piix3 or ehci usb controller and usb kbd don't work
+Description of problem:
+the usb device initialization failed in vm, and  can not input in vnc console 
+
+message for virtual machine:
+
+```
+root@localhost ~]# dmesg | grep -i usb
+[    0.925798] ACPI: bus type USB registered
+[    0.927204] usbcore: registered new interface driver usbfs
+[    0.928980] usbcore: registered new interface driver hub
+[    0.930746] usbcore: registered new device driver usb
+[    2.329004] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
+[    2.332659] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
+[    2.336069] uhci_hcd: USB Universal Host Controller Interface driver
+[    2.342659] uhci_hcd 0000:02:02.0: new USB bus registered, assigned bus number 1
+[    2.348905] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 4.18
+[    2.352268] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
+[    2.354598] usb usb1: Product: UHCI Host Controller
+[    2.356194] usb usb1: Manufacturer: Linux 4.18.0-305.3.1.el8.aarch64 uhci_hcd
+[    2.358474] usb usb1: SerialNumber: 0000:02:02.0
+[    2.360228] hub 1-0:1.0: USB hub found
+[    2.363347] usbcore: registered new interface driver usbserial_generic
+[    2.365456] usbserial: USB Serial support registered for generic
+[    2.384154] usbcore: registered new interface driver usbhid
+[    2.385962] usbhid: USB HID core driver
+[    2.730277] usb 1-1: new full-speed USB device number 2 using uhci_hcd
+[   18.509908] usb 1-1: device descriptor read/64, error -110
+[   34.509908] usb 1-1: device descriptor read/64, error -110
+[   34.779906] usb 1-1: new full-speed USB device number 3 using uhci_hcd
+[   50.509910] usb 1-1: device descriptor read/64, error -110
+[   66.509907] usb 1-1: device descriptor read/64, error -110
+[   66.629982] usb usb1-port1: attempt power cycle
+[   67.119904] usb 1-1: new full-speed USB device number 4 using uhci_hcd
+[   78.079921] usb 1-1: device not accepting address 4, error -110
+[   78.229962] usb 1-1: new full-speed USB device number 5 using uhci_hcd
+[   89.079917] usb 1-1: device not accepting address 5, error -110
+[   89.082006] usb usb1-port1: unable to enumerate USB device
+[   89.229908] usb 1-2: new full-speed USB device number 6 using uhci_hcd
+[  105.009910] usb 1-2: device descriptor read/64, error -110
+[  121.009910] usb 1-2: device descriptor read/64, error -110
+[  121.279907] usb 1-2: new full-speed USB device number 7 using uhci_hcd
+[  137.009910] usb 1-2: device descriptor read/64, error -110
+[  153.009925] usb 1-2: device descriptor read/64, error -110
+[  153.129984] usb usb1-port2: attempt power cycle
+[  153.619917] usb 1-2: new full-speed USB device number 8 using uhci_hcd
+[  164.579912] usb 1-2: device not accepting address 8, error -110
+[  164.729913] usb 1-2: new full-speed USB device number 9 using uhci_hcd
+[  175.329921] usb 1-2: device not accepting address 9, error -110
+[  175.331973] usb usb1-port2: unable to enumerate USB device
+```
+Steps to reproduce:
+1.  ./configure
+2. make -j60
+3.virsh create vm.xml
+[vm.xml](/uploads/9f946b3637f68c9cd029dfb650f5bd57/vm.xml)
+Additional information:
+the commit "1c2cb7e0b3" cause the problem, but i don't know the reason
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1327 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1327
new file mode 100644
index 00000000..5c86b640
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1327
@@ -0,0 +1,90 @@
+vhost-user-test outputs scary messages
+Description of problem:
+The qos-test seems to output failure messages when run in verbose mode, see e.g.:
+
+https://gitlab.com/qemu-project/qemu/-/jobs/3340919275#L5615
+
+```
+――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
+stderr:
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22)
+qemu-system-aarch64: -chardev socket,id=chr-reconnect,path=/tmp/vhost-test-9B51V1/reconnect.sock,server=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-9B51V1/reconnect.sock,server=on
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22)
+qemu-system-aarch64: -chardev socket,id=chr-connect-fail,path=/tmp/vhost-test-49UUV1/connect-fail.sock,server=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-49UUV1/connect-fail.sock,server=on
+qemu-system-aarch64: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: Failed to read msg header. Read 0 instead of 12. Original request 1.
+qemu-system-aarch64: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: vhost_backend_init failed: Protocol error
+qemu-system-aarch64: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: failed to init vhost_net for queue 0
+qemu-system-aarch64: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-49UUV1/connect-fail.sock,server=on
+qemu-system-aarch64: Failed to write msg. Wrote -1 instead of 20.
+qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22)
+qemu-system-aarch64: -chardev socket,id=chr-flags-mismatch,path=/tmp/vhost-test-LTKOV1/flags-mismatch.sock,server=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-LTKOV1/flags-mismatch.sock,server=on
+qemu-system-aarch64: Failed to write msg. Wrote -1 instead of 52.
+qemu-system-aarch64: vhost_set_mem_table failed: Invalid argument (22)
+qemu-system-aarch64: unable to start vhost net: 22: falling back on userspace virtio
+vhost lacks feature mask 0x40000000 for backend
+qemu-system-aarch64: failed to init vhost_net for queue 0
+qemu-system-aarch64: Failed to write msg. Wrote -1 instead of 20.
+qemu-system-aarch64: vhost_set_vring_num failed: Invalid argument (22)
+qemu-system-aarch64: unable to start vhost net: 22: falling back on userspace virtio
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost VQ 2 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost VQ 3 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_call failed: Invalid argument (22)
+qemu-system-aarch64: Failed to set msg fds.
+qemu-system-aarch64: vhost_set_vring_call failed: Invalid argument (22)
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1399 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1399
new file mode 100644
index 00000000..fc0dcd7f
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1399
@@ -0,0 +1,72 @@
+Early faults when direct booting large Linux kernel images on x86_64 and aarch64 guests.
+Description of problem:
+When attempting to load a Linux kernel image for direct boot via the `-kernel` command line option, a triple fault occurs shortly after attempting to hand off execution to the kernel if the kernel image is ‘large’ in size (this can be easily reproduced with a custom kernel build by embedding an initramfs in the kernel that includes a few large but mostly incompressible files). I’m not certain of the exact cutoff, but a 75 MB kernel image on x86_64, and a 67 MB kernel image on AArch64 both exhibit the issue, while a 13 MB kernel image on x86_64 does not.
+Steps to reproduce:
+1. Attempt to direct boot an exceptionally large kernel image as an x86_64 or aarch64 guest.
+Additional information:
+I have not yet been able to track down exactly where the initial fault is happening, and am not even certain that it’s in Linux’s early boot code, but the fact that this is reproducible across multiple architectures and is unaffected by things like KASLR and the exact compression algorithm for the guest kernel suggests to me that it’s more likely to be an issue in QEMU’s loader code for direct kernel boot than in the Linux kernel itself.
+
+Running on x86_64, the initial fault appears to be a general protection fault, followed by a double and then triple fault. Output from running QEMU as above with `-d int,guest_error -no-reboot’:
+
+```
+check_exception old: 0xffffffff new 0xd
+     0: v=0d e=0000 i=0 cpl=0 IP=0010:000000000789f7f0 pc=000000000789f7f0 SP=0018:00000000078e6fd8 env->regs[R_EAX]=0000000000000000
+RAX=0000000000000000 RBX=6fb84fe3052f53e2 RCX=00000000fb600000 RDX=00000000078fbed0
+RSI=00000000078f6000 RDI=00000000078e80e0 RBP=00000000078e80e0 RSP=00000000078e6fd8
+R8 =00000000078fb000 R9 =00000000fb600000 R10=000fffffffe00000 R11=0000000000000000
+R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000
+RIP=000000000789f7f0 RFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0000 0000000000000000 00000000 00000000
+CS =0010 0000000000000000 ffffffff 00af9a00 DPL=0 CS64 [-R-]
+SS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
+DS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
+FS =0000 0000000000000000 00000000 00000000
+GS =0000 0000000000000000 00000000 00000000
+LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT
+TR =0020 0000000000000000 00000fff 00808900 DPL=0 TSS64-avl
+GDT=     00000000078b1030 0000002f
+IDT=     00000000078b1070 000001ff
+CR0=80050033 CR2=6fb84fe3052f53ee CR3=00000000078f6000 CR4=00000020
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
+DR6=00000000ffff0ff0 DR7=0000000000000400
+CCS=0000000000000018 CCD=6fb84fe3052f53e2 CCO=LOGICQ
+EFER=0000000000000500
+check_exception old: 0xd new 0xd
+     1: v=08 e=0000 i=0 cpl=0 IP=0010:000000000789f7f0 pc=000000000789f7f0 SP=0018:00000000078e6fd8 env->regs[R_EAX]=0000000000000000
+RAX=0000000000000000 RBX=6fb84fe3052f53e2 RCX=00000000fb600000 RDX=00000000078fbed0
+RSI=00000000078f6000 RDI=00000000078e80e0 RBP=00000000078e80e0 RSP=00000000078e6fd8
+R8 =00000000078fb000 R9 =00000000fb600000 R10=000fffffffe00000 R11=0000000000000000
+R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000
+RIP=000000000789f7f0 RFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0000 0000000000000000 00000000 00000000
+CS =0010 0000000000000000 ffffffff 00af9a00 DPL=0 CS64 [-R-]
+SS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
+DS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
+FS =0000 0000000000000000 00000000 00000000
+GS =0000 0000000000000000 00000000 00000000
+LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT
+TR =0020 0000000000000000 00000fff 00808900 DPL=0 TSS64-avl
+GDT=     00000000078b1030 0000002f
+IDT=     00000000078b1070 000001ff
+CR0=80050033 CR2=6fb84fe3052f53ee CR3=00000000078f6000 CR4=00000020
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
+DR6=00000000ffff0ff0 DR7=0000000000000400
+CCS=0000000000000018 CCD=6fb84fe3052f53e2 CCO=LOGICQ
+EFER=0000000000000500
+check_exception old: 0x8 new 0xd
+```
+
+Running on AArch64, the emulated CPU gets stuck in a loop trying to handle ‘exception 5’, showing the following output when run as above with `-d int, guest_error -no-reboot`, repeated infinitely until the emulator gets killed:
+
+```
+Taking exception 5 [IRQ] on CPU 0
+...from EL1 to EL1
+...with ESR 0x15/0x56000000
+...with ELR 0xffffffef0dee4098
+...to EL1 PC 0xffffffef0d810a80 PSTATE 0x3c5
+Exception return from AArch64 EL1 to AArch64 EL1 PC 0xffffffef0dee4098
+```
+
+I have also attempted to reproduce this on 64-bit little-endian POWER using qemu-system-ppc64 and an equivalent kernel config, and was _not_ able to reproduce it there with a 69 MB kernel image.
+
+I can provide Linux kernel configs for the affected kernels upon request, but am not (currently) able to provide full system images (the project I was working on when I came across this is not yet public).
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1407 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1407
new file mode 100644
index 00000000..f73a860d
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1407
@@ -0,0 +1,76 @@
+Assertion failure in fimd_update_memory_section()
+Description of problem:
+It seems the frame buffer is not properly initialized before usage.
+Steps to reproduce:
+```
+export QEMU=/path/to/qemu-system-arm
+
+cat << EOF | $QEMU \
+-machine smdkc210 -monitor none -serial none \
+-display none -nodefaults -qtest stdio
+writel 0x11c00020 0x3454d403
+writel 0x11c00000 0x61988eaf
+EOF
+```
+Additional information:
+```
+==13250==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x5590b12d2240). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 3376651198
+INFO: Loaded 1 modules   (583356 inline 8-bit counters): 583356 [0x5590b4672000, 0x5590b47006bc), 
+INFO: Loaded 1 PC tables (583356 PCs): 583356 [0x5590b3d8b3b0,0x5590b4671f70), 
+/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+Matching objects by name , *exynos4210.fimd*
+This process will fuzz the following MemoryRegions:
+  * exynos4210.fimd[0] (size 4114)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * exynos4210.fimd, EVENT_TYPE_MMIO_READ, 0x11c00000 +0x4114, 4,4
+  * exynos4210.fimd, EVENT_TYPE_MMIO_WRITE, 0x11c00000 +0x4114, 4,4
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 227Mb
+Running: poc-qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd-crash-eda3de9b6941dd8c14e22959b56dbe5d8d07dae3
+qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd: ../hw/display/exynos4210_fimd.c:1152: void fimd_update_memory_section(Exynos4210fimdState *, unsigned int): Assertion `w->mem_section.mr' failed.
+==13250== ERROR: libFuzzer: deadly signal
+    #0 0x5590acce30ee in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
+    #1 0x5590acc31d61 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x5590acc0ac96 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18
+    #3 0x5590acc0ad62 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1
+    #4 0x5590acc0ad62 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19
+    #5 0x7f9ed33c741f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f)
+    #6 0x7f9ed31d900a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+    #7 0x7f9ed31d900a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+    #8 0x7f9ed31b8858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
+    #9 0x7f9ed31b8728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3
+    #10 0x7f9ed31c9fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3
+    #11 0x5590ad56dce3 in fimd_update_memory_section /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/exynos4210_fimd.c:1152:5
+    #12 0x5590ad565fb7 in exynos4210_fimd_enable /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/exynos4210_fimd.c:1198:13
+    #13 0x5590ad5590a3 in exynos4210_fimd_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/exynos4210_fimd.c:1387:13
+    #14 0x5590b03e7bc3 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:493:5
+    #15 0x5590b03e7501 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18
+    #16 0x5590b03e5e26 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1515:16
+    #17 0x5590b047669e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2825:23
+    #18 0x5590b046444b in flatview_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2867:12
+    #19 0x5590b0463f08 in address_space_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2963:18
+    #20 0x5590acd23d38 in qemu_writel /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1096:5
+    #21 0x5590acd220a3 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1245:28
+    #22 0x5590b12cd6bf in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5
+    #23 0x5590b12c4a3d in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9
+    #24 0x5590b12c47e4 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9
+    #25 0x5590acd2b07c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12
+    #26 0x5590b12d250b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18
+    #27 0x5590acc0b806 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17
+    #28 0x5590acbee434 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #29 0x5590acbf93de in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19
+    #30 0x5590acbe59c6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #31 0x7f9ed31ba082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #32 0x5590acbe5a1d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd+0x31cea1d)
+
+NOTE: libFuzzer has rudimentary signal handlers.
+      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
+SUMMARY: libFuzzer: deadly signal
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1408 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1408
new file mode 100644
index 00000000..f07cb933
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1408
@@ -0,0 +1,87 @@
+Out of bounds in imx_usbphy_read()
+Description of problem:
+The size of the memory region of imx-usb-phy is 0x1000.
+
+```
+memory_region_init_io(&s->iomem, OBJECT(s), &imx_usbphy_ops, s,
+                          "imx-usbphy", 0x1000);
+```
+
+A read to s->usbphy[33] will easily overflow.
+
+```
+static uint64_t imx_usbphy_read(void *opaque, hwaddr offset, unsigned size)
+{
+    // ...
+    default:
+        value = s->usbphy[index];
+        break;
+    }
+```
+
+Maybe we should drop this read in default branch.
+Steps to reproduce:
+```
+export QEMU=/path/to/qemu-system-arm
+
+cat << EOF | $QEMU \
+-machine sabrelite -monitor none -serial none \
+-display none -nodefaults -qtest stdio
+readl 0x20c9870
+EOF
+```
+Additional information:
+```
++ DEFAULT_INPUT_MAXSIZE=10000000
++ ./qemu-videzzo-arm-target-videzzo-fuzz-imx-usb-phy -max_len=10000000 -detect_leaks=0 ./crash-2f5e9c8ec69dd69f8db69aaa84dde878482b8690.minimized
+==14370==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x561837db1240). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 1679742864
+INFO: Loaded 1 modules   (583356 inline 8-bit counters): 583356 [0x56183b151000, 0x56183b1df6bc),
+INFO: Loaded 1 PC tables (583356 PCs): 583356 [0x56183a86a3b0,0x56183b150f70),
+./qemu-videzzo-arm-target-videzzo-fuzz-imx-usb-phy: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+Matching objects by name , *imx-usbphy*
+This process will fuzz the following MemoryRegions:
+  * imx-usbphy[0] (size 1000)
+  * imx-usbphy[0] (size 1000)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * imx-usbphy, EVENT_TYPE_MMIO_READ, 0x20c9000 +0x1000, 4,4
+  * imx-usbphy, EVENT_TYPE_MMIO_WRITE, 0x20c9000 +0x1000, 4,4
+  * imx-usbphy, EVENT_TYPE_MMIO_READ, 0x20ca000 +0x1000, 4,4
+  * imx-usbphy, EVENT_TYPE_MMIO_WRITE, 0x20ca000 +0x1000, 4,4
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 222Mb
+Running: ./crash-2f5e9c8ec69dd69f8db69aaa84dde878482b8690.minimized
+../hw/usb/imx-usb-phy.c:93:17: runtime error: index 540 out of bounds for type 'uint32_t [33]'
+    #0 0x5618357ddb2a in imx_usbphy_read /root/videzzo/videzzo_qemu/qemu/out-san/../hw/usb/imx-usb-phy.c:93:17
+    #1 0x561836f07a0b in memory_region_read_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:441:11
+    #2 0x561836ec6501 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18
+    #3 0x561836ec38cc in memory_region_dispatch_read1 /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1425:16
+    #4 0x561836ec3008 in memory_region_dispatch_read /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1458:9
+    #5 0x561836f415ad in flatview_read_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2892:23
+    #6 0x561836f42bb8 in flatview_read /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2934:12
+    #7 0x561836f42678 in address_space_read_full /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2947:18
+    #8 0x5618337f4b41 in address_space_read /root/videzzo/videzzo_qemu/qemu/include/exec/memory.h:2873:18
+    #9 0x5618337f4b41 in qemu_readl /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1037:5
+    #10 0x5618337f2c06 in dispatch_mmio_read /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1051:35
+    #11 0x561837dac6bf in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5
+    #12 0x561837da3a3d in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9
+    #13 0x561837da37e4 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9
+    #14 0x56183380a07c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12
+    #15 0x561837db150b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18
+    #16 0x5618336ea806 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17
+    #17 0x5618336cd434 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #18 0x5618336d83de in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19
+    #19 0x5618336c49c6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #20 0x7f74d2914082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #21 0x5618336c4a1d in _start (/root/bugs/metadata/imx_usb_phy-00/qemu-videzzo-arm-target-videzzo-fuzz-imx-usb-phy+0x31cea1d)
+
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/usb/imx-usb-phy.c:93:17 in
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+0x0,0x8,0x70,0x98,0xc,0x2,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,
+\x00\x08p\x98\x0c\x02\x00\x00\x00\x00\x04\x00\x00\x00
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1415 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1415
new file mode 100644
index 00000000..e97c1cb4
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1415
@@ -0,0 +1,89 @@
+Abort in xlnx_dp_change_graphic_fmt()
+Description of problem:
+xlnx_dp_change_graphic_fmt() will directly abort if either graphic format or the
+video format is not supported.
+
+Replacing abort() in xlnx_dp_change_graphic_fmt() to `return` might be OK but I
+am not sure what side effect there is.
+Steps to reproduce:
+```
+export QEMU=/path/to/to/qemu-system-aarch64
+
+cat << EOF | $QEMU \
+-machine xlnx-zcu102 -monitor none -serial none \
+-display none -nodefaults -qtest stdio
+writel 0xfd4ab000 0xcf6e998
+EOF
+```
+Additional information:
+```
+==20455==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x564934146c90). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 4022227410
+INFO: Loaded 1 modules   (618619 inline 8-bit counters): 618619 [0x5649372a5000, 0x56493733c07b), 
+INFO: Loaded 1 PC tables (618619 PCs): 618619 [0x564936933f40,0x5649372a46f0), 
+./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
+Matching objects by name , *.core*, *.v_blend*, *.av_buffer_manager*, *.audio*
+This process will fuzz the following MemoryRegions:
+  * xlnx.v-dp.audio[0] (size 50)
+  * xlnx.v-dp.av_buffer_manager[0] (size 238)
+  * xlnx.v-dp.core[0] (size 3b0)
+  * xlnx.v-dp.v_blend[0] (size 1e0)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * xlnx.v-dp.core, EVENT_TYPE_MMIO_READ, 0xfd4a0000 +0x3b0, 4,4
+  * xlnx.v-dp.core, EVENT_TYPE_MMIO_WRITE, 0xfd4a0000 +0x3b0, 4,4
+  * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_READ, 0xfd4aa000 +0x1e0, 4,4
+  * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_WRITE, 0xfd4aa000 +0x1e0, 4,4
+  * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_READ, 0xfd4ab000 +0x238, 4,4
+  * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_WRITE, 0xfd4ab000 +0x238, 4,4
+  * xlnx.v-dp.audio, EVENT_TYPE_MMIO_READ, 0xfd4ac000 +0x50, 1,4
+  * xlnx.v-dp.audio, EVENT_TYPE_MMIO_WRITE, 0xfd4ac000 +0x50, 1,4
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 489Mb
+Running: crash-8b178268936b24c569a421d702ef5b6d911c99e7
+aarch64: xlnx_dp_change_graphic_fmt: unsupported graphic format 2304
+==20455== ERROR: libFuzzer: deadly signal
+    #0 0x56492f51f10e in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
+    #1 0x56492f46dd81 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x56492f446cb6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18
+    #3 0x56492f446d82 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1
+    #4 0x56492f446d82 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19
+    #5 0x7f7a315a641f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f)
+    #6 0x7f7a313b800a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+    #7 0x7f7a313b800a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+    #8 0x7f7a31397858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
+    #9 0x56492f54f65a in __wrap_abort /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/less_crashes_wrappers.c:24:12
+    #10 0x56492fe7e0d7 in xlnx_dp_change_graphic_fmt /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:644:9
+    #11 0x56492fe7be58 in xlnx_dp_avbufm_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:1046:9
+    #12 0x5649330fa313 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5
+    #13 0x5649330f9c51 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18
+    #14 0x5649330f8576 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16
+    #15 0x56493318672e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23
+    #16 0x56493317486b in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12
+    #17 0x564933174328 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18
+    #18 0x56492f55f0cb in qemu_writel /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1088:5
+    #19 0x56492f55d544 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1229:28
+    #20 0x56493414264f in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5
+    #21 0x5649341399cb in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9
+    #22 0x5649341398a0 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9
+    #23 0x56492f56610c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1504:12
+    #24 0x564934146f32 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18
+    #25 0x56492f447826 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17
+    #26 0x56492f42a454 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #27 0x56492f4353fe in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19
+    #28 0x56492f4219e6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #29 0x7f7a31399082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #30 0x56492f421a3d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp+0x3291a3d)
+
+NOTE: libFuzzer has rudimentary signal handlers.
+      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
+SUMMARY: libFuzzer: deadly signal
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+0x0,0xc,0x1c,0xb0,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x4,0x2,0x48,0x40,0x1,0x0,0x0,0x0,0x0,0x0,0x0,0xa,0x20,0xa1,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x0,0xe,0x8,0xc0,0x4a,0xfd,0x0,0x0,0x0,0x0,0x2,0x0,0x0,0x0,0x0,0x8,0x0,0x0,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x4,0x2,0x3e,0xc6,0x1,0x0,0x0,0x0,0x0,0x0,0x0,0xc,0x78,0xb1,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x1,0x9,0x4,0x2,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0xc2,0x1b,0xe,0x7b,0x0,0x0,0x0,0x0,0x1,0xb,0x84,0xa1,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0xd8,0x1f,0x9a,0x30,0x0,0x0,0x0,0x0,0x0,0x8,0x70,0x0,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x1,0x9,0xec,0x2,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x50,0x62,0xd6,0x13,0x0,0x0,0x0,0x0,0x0,0xa,0x18,0xa0,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x1,0xd,0x0,0xb0,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x98,0xe9,0xf6,0xc,0x0,0x0,0x0,0x0,
+\x00\x0c\x1c\xb0J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\x04\x02H@\x01\x00\x00\x00\x00\x00\x00\x0a \xa1J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\x00\x0e\x08\xc0J\xfd\x00\x00\x00\x00\x02\x00\x00\x00\x00\x08\x00\x00J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\x04\x02>\xc6\x01\x00\x00\x00\x00\x00\x00\x0cx\xb1J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\x01\x09\x04\x02J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\xc2\x1b\x0e{\x00\x00\x00\x00\x01\x0b\x84\xa1J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\xd8\x1f\x9a0\x00\x00\x00\x00\x00\x08p\x00J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\x01\x09\xec\x02J\xfd\x00\x00\x00\x00\x04\x00\x00\x00Pb\xd6\x13\x00\x00\x00\x00\x00\x0a\x18\xa0J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\x01\x0d\x00\xb0J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\x98\xe9\xf6\x0c\x00\x00\x00\x00
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1421 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1421
new file mode 100644
index 00000000..3cbdc1e4
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1421
@@ -0,0 +1,19 @@
+GDB memory reads fail on Cortex-M33
+Description of problem:
+GDB fails to read memory from the guest.  There appear to be at least two problems:
+
+1. In `arm_cpu_get_phys_page_attrs_debug`, `arm_is_secure(env)` returns false, because the implementation doesn't seem to know about Armv7-M or Armv8-M secure states.  However, `arm_mmu_idx(env)` does know how to check `env->v7m.secure`, so it returns `ARMMMUIdx_MSPriv` (the S stands for secure).  The mismatch between an apparently non-secure access to a secure MMU seems to cause the read to fail laster.
+2. With the MPU enabled (not the case in this repro, but I can provide one), `cpu_memory_rw_debug` computes `page = addr & TARGET_PAGE_MASK`, and uses the page to compute permissions.  However, TARGET_PAGE_MASK is based on 4K pages on this platform, but the MPU granularity is 32 bytes.  So the wrong page is used for checking.
+Steps to reproduce:
+```
+# Sorry for the large clone.  It's mostly unused files in CMSIS.
+git clone --recursive -b qemu-repro-1 https://github.com/dreiss/mpu_experiments
+cd mpu_experiments
+git checkout origin/qemu-repro-1
+cmake -S . -B build -DBOARD=qemu-mps2-an505 -DAPP=mpu_stacktrace -DCMAKE_BUILD_TYPE=Debug
+cmake --build build
+/path/to/qemu-system-arm -machine mps2-an505 -nographic -kernel build/kernel.elf -s -S -d int
+# Open a separate terminal and cd into mpu_experiments
+gdb build/kernel.elf -ex 'target remote :1234' -ex 'break base_case' -ex continue -ex backtrace -ex quit
+# Note the memory read failures in the backtrace.
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1424 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1424
new file mode 100644
index 00000000..7203ffc6
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1424
@@ -0,0 +1,103 @@
+Overflow in xlnx_dp_aux_push_tx_fifo()
+Description of problem:
+Invoking xlnx_dp_aux_push_tx_fifo() 17 times overflow the s->tx_fifo.
+Steps to reproduce:
+```
+export QEMU=/path/to/qemu-system-aarch64
+
+cat << EOF | $QEMU \
+-machine xlnx-zcu102 -monitor none -serial none \
+-display none -nodefaults -qtest stdio
+writel 0xfd4a0104 0x6fed53ba
+writel 0xfd4a0104 0x66554466
+writel 0xfd4a0104 0x6fed53ba
+writel 0xfd4a0104 0x6fed53ba
+writel 0xfd4a0104 0x666e0fa2
+writel 0xfd4a0104 0x666e0fa2
+writel 0xfd4a0104 0x666e0fa2
+writel 0xfd4a0104 0x6fed53ba
+writel 0xfd4a0104 0x6fed53ba
+writel 0xfd4a0104 0x66554466
+writel 0xfd4a0104 0x66554466
+writel 0xfd4a0104 0x66554466
+writel 0xfd4a0104 0x66554466
+writel 0xfd4a0104 0x66554466
+writel 0xfd4a0104 0x6fed53ba
+writel 0xfd4a0104 0x6fed53ba
+writel 0xfd4a0104 0x6fed53ba
+EOF
+```
+Additional information:
+```
+root@621cbd136b6f:~/bugs/metadata/xlnx_dp-07# bash -x xlnx_dp-07.videzzo 
++ DEFAULT_INPUT_MAXSIZE=10000000
++ ./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp -max_len=10000000 -detect_leaks=0 ./poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp-crash-8070de484ac8d4d9bfff9b439311058e05b8b40f.minimized
+==47609==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x564c9e37c2b0). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 2128347645
+INFO: Loaded 1 modules   (600768 inline 8-bit counters): 600768 [0x564ca198f000, 0x564ca1a21ac0), 
+INFO: Loaded 1 PC tables (600768 PCs): 600768 [0x564ca1063b10,0x564ca198e710), 
+./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+Matching objects by name , *.core*, *.v_blend*, *.av_buffer_manager*, *.audio*
+This process will fuzz the following MemoryRegions:
+  * xlnx.v-dp.core[0] (size 3b0)
+  * xlnx.v-dp.v_blend[0] (size 1e0)
+  * xlnx.v-dp.audio[0] (size 50)
+  * xlnx.v-dp.av_buffer_manager[0] (size 238)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * xlnx.v-dp.core, EVENT_TYPE_MMIO_READ, 0xfd4a0000 +0x3b0, 4,4
+  * xlnx.v-dp.core, EVENT_TYPE_MMIO_WRITE, 0xfd4a0000 +0x3b0, 4,4
+  * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_READ, 0xfd4aa000 +0x1e0, 4,4
+  * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_WRITE, 0xfd4aa000 +0x1e0, 4,4
+  * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_READ, 0xfd4ab000 +0x238, 4,4
+  * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_WRITE, 0xfd4ab000 +0x238, 4,4
+  * xlnx.v-dp.audio, EVENT_TYPE_MMIO_READ, 0xfd4ac000 +0x50, 1,4
+  * xlnx.v-dp.audio, EVENT_TYPE_MMIO_WRITE, 0xfd4ac000 +0x50, 1,4
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 510Mb
+Running: ./poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp-crash-8070de484ac8d4d9bfff9b439311058e05b8b40f.minimized
+qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: ../util/fifo8.c:43: void fifo8_push_all(Fifo8 *, const uint8_t *, uint32_t): Assertion `fifo->num + num <= fifo->capacity' failed.
+==47609== ERROR: libFuzzer: deadly signal
+    #0 0x564c998420fe in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
+    #1 0x564c99790d71 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x564c99769ca6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18
+    #3 0x564c99769d72 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1
+    #4 0x564c99769d72 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19
+    #5 0x7f8ef929941f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f)
+    #6 0x7f8ef90ab00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+    #7 0x7f8ef90ab00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+    #8 0x7f8ef908a858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
+    #9 0x7f8ef908a728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3
+    #10 0x7f8ef909bfd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3
+    #11 0x564c9e1cdbb3 in fifo8_push_all /root/videzzo/videzzo_qemu/qemu/out-san/../util/fifo8.c:43:5
+    #12 0x564c9a189c13 in xlnx_dp_aux_push_tx_fifo /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/xlnx_dp.c:467:5
+    #13 0x564c9a1842f2 in xlnx_dp_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/xlnx_dp.c:857:9
+    #14 0x564c9d491e93 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:493:5
+    #15 0x564c9d4917d1 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18
+    #16 0x564c9d4900f6 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1515:16
+    #17 0x564c9d5209ce in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2825:23
+    #18 0x564c9d50e77b in flatview_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2867:12
+    #19 0x564c9d50e238 in address_space_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2963:18
+    #20 0x564c99882d48 in qemu_writel /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1096:5
+    #21 0x564c998810b3 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1245:28
+    #22 0x564c9e37772f in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5
+    #23 0x564c9e36eaad in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9
+    #24 0x564c9e36e854 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9
+    #25 0x564c9988a08c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12
+    #26 0x564c9e37c57b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18
+    #27 0x564c9976a816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17
+    #28 0x564c9974d444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #29 0x564c997583ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19
+    #30 0x564c997449d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #31 0x7f8ef908c082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #32 0x564c99744a2d in _start (/root/bugs/metadata/xlnx_dp-07/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp+0x3453a2d)
+
+NOTE: libFuzzer has rudimentary signal handlers.
+      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
+SUMMARY: libFuzzer: deadly signal
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1425 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1425
new file mode 100644
index 00000000..152cf474
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1425
@@ -0,0 +1,84 @@
+Assertion failed in transfer_fifo()
+Description of problem:
+In transfer_fifo(), fifo32_pop() fails since less than 32 bytes are in the fifo.
+Steps to reproduce:
+```
+export QEMU=/path/to/qemu-system-aarch64
+
+cat << EOF | $QEMU \
+-machine xlnx-zcu102 -monitor none -serial none \
+-display none -nodefaults -qtest stdio -audio none
+writel 0xff070000 0x0f73720a
+writel 0xff07003c 0x1f37ee63
+EOF
+```
+Additional information:
+```
+==31717==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x55871da359f0). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 1734665286
+INFO: Loaded 1 modules   (618606 inline 8-bit counters): 618606 [0x558720b94000, 0x558720c2b06e), 
+INFO: Loaded 1 PC tables (618606 PCs): 618606 [0x558720222e60,0x558720b93540), 
+/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+Matching objects by name , *xlnx.zynqmp-can*
+This process will fuzz the following MemoryRegions:
+  * xlnx.zynqmp-can[1] (size 84)
+  * xlnx.zynqmp-can[0] (size 84)
+  * xlnx.zynqmp-can[1] (size 84)
+  * xlnx.zynqmp-can[0] (size 84)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * xlnx.zynqmp-can, EVENT_TYPE_MMIO_READ, 0xff070000 +0x84, 4,4
+  * xlnx.zynqmp-can, EVENT_TYPE_MMIO_WRITE, 0xff070000 +0x84, 4,4
+  * xlnx.zynqmp-can, EVENT_TYPE_MMIO_READ, 0xff060000 +0x84, 4,4
+  * xlnx.zynqmp-can, EVENT_TYPE_MMIO_WRITE, 0xff060000 +0x84, 4,4
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 491Mb
+Running: poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can-crash-97ef02583c679111ba6ad823f573f139fac7c72e
+qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can: ../util/fifo8.c:62: uint8_t fifo8_pop(Fifo8 *): Assertion `fifo->num > 0' failed.
+==31717== ERROR: libFuzzer: deadly signal
+    #0 0x558718e0e10e in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
+    #1 0x558718d5cd81 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x558718d35cb6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18
+    #3 0x558718d35d82 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1
+    #4 0x558718d35d82 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19
+    #5 0x7f3ad4eba41f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f)
+    #6 0x7f3ad4ccc00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+    #7 0x7f3ad4ccc00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+    #8 0x7f3ad4cab858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
+    #9 0x7f3ad4cab728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3
+    #10 0x7f3ad4cbcfd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3
+    #11 0x55871d6eeac9 in fifo8_pop /root/videzzo/videzzo_qemu/qemu/build-san-6/../util/fifo8.c:62:5
+    #12 0x55871a33f303 in fifo32_pop /root/videzzo/videzzo_qemu/qemu/include/qemu/fifo32.h:137:17
+    #13 0x55871a334bb5 in transfer_fifo /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/net/can/xlnx-zynqmp-can.c:455:23
+    #14 0x55871a32d4c0 in can_tx_post_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/net/can/xlnx-zynqmp-can.c:830:9
+    #15 0x558719393dcb in register_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/register.c:122:9
+    #16 0x558719397de8 in register_write_memory /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/register.c:203:5
+    #17 0x55871c9e9073 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5
+    #18 0x55871c9e89b1 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18
+    #19 0x55871c9e72d6 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16
+    #20 0x55871ca7548e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23
+    #21 0x55871ca635cb in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12
+    #22 0x55871ca63088 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18
+    #23 0x558718e4e0cb in qemu_writel /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1081:5
+    #24 0x558718e4c544 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1222:28
+    #25 0x55871da313af in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5
+    #26 0x55871da2872b in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9
+    #27 0x55871da28600 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9
+    #28 0x558718e5510c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1497:12
+    #29 0x55871da35c92 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18
+    #30 0x558718d36826 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17
+    #31 0x558718d19454 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #32 0x558718d243fe in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19
+    #33 0x558718d109e6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #34 0x7f3ad4cad082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #35 0x558718d10a3d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can+0x3291a3d)
+
+NOTE: libFuzzer has rudimentary signal handlers.
+      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
+SUMMARY: libFuzzer: deadly signal
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1427 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1427
new file mode 100644
index 00000000..5ac891d3
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1427
@@ -0,0 +1,374 @@
+Fifo overflow in transfer_fifo()
+Description of problem:
+In transfer_fifo(), fifo32_push() fails since less than 32 bytes are free in the
+fifo.
+Steps to reproduce:
+```
+export QEMU=/path/to/qemu-system-aarch64
+
+cat << EOF | $QEMU \
+-machine xlnx-zcu102 -monitor none -serial none \
+-display none -nodefaults -qtest stdio
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x554439e4
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x7439dad1
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x554439e4
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x7439dad1
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070030 0x5b33c2da
+writel 0xff070004 0x6847773b
+writel 0xff070030 0x5b33c2da
+writel 0xff070000 0x7a9e77fa
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070038 0x0bbac0b1
+readl 0xff070054
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff070038 0x3730c1d8
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070038 0x3730c1d8
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070038 0x3730c1d8
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070038 0x3730c1d8
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070038 0x3730c1d8
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070038 0x3730c1d8
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070038 0x3730c1d8
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070038 0x3730c1d8
+writel 0xff07003c 0x1f9c3bcd
+writel 0xff070038 0x3730c1d8
+writel 0xff07003c 0x1f9c3bcd
+EOF
+```
+Additional information:
+```
+==60953==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x55c4943a85f0). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 1771329340
+INFO: Loaded 1 modules   (600781 inline 8-bit counters): 600781 [0x55c4979bb000, 0x55c497a4dacd), 
+INFO: Loaded 1 PC tables (600781 PCs): 600781 [0x55c49708fbf0,0x55c4979ba8c0), 
+./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+Matching objects by name , *xlnx.zynqmp-can*
+This process will fuzz the following MemoryRegions:
+  * xlnx.zynqmp-can[1] (size 84)
+  * xlnx.zynqmp-can[0] (size 84)
+  * xlnx.zynqmp-can[1] (size 84)
+  * xlnx.zynqmp-can[0] (size 84)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * xlnx.zynqmp-can, EVENT_TYPE_MMIO_READ, 0xff070000 +0x84, 4,4
+  * xlnx.zynqmp-can, EVENT_TYPE_MMIO_WRITE, 0xff070000 +0x84, 4,4
+  * xlnx.zynqmp-can, EVENT_TYPE_MMIO_READ, 0xff060000 +0x84, 4,4
+  * xlnx.zynqmp-can, EVENT_TYPE_MMIO_WRITE, 0xff060000 +0x84, 4,4
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 509Mb
+Running: poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can-crash-8c83f08fb7643e6eb55af43e76de522c6f5fcef2.minimized.minimized
+qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can: ../util/fifo8.c:34: void fifo8_push(Fifo8 *, uint8_t): Assertion `fifo->num < fifo->capacity' failed.
+==60953== ERROR: libFuzzer: deadly signal
+    #0 0x55c48f86e0fe in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
+    #1 0x55c48f7bcd71 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x55c48f795ca6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18
+    #3 0x55c48f795d72 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1
+    #4 0x55c48f795d72 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19
+    #5 0x7fe36599541f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f)
+    #6 0x7fe3657a700a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+    #7 0x7fe3657a700a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+    #8 0x7fe365786858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
+    #9 0x7fe365786728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3
+    #10 0x7fe365797fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3
+    #11 0x55c4941f98ef in fifo8_push /root/videzzo/videzzo_qemu/qemu/out-san/../util/fifo8.c:34:5
+    #12 0x55c490d83bb0 in fifo32_push /root/videzzo/videzzo_qemu/qemu/include/qemu/fifo32.h:94:9
+    #13 0x55c490d79d17 in transfer_fifo /root/videzzo/videzzo_qemu/qemu/out-san/../hw/net/can/xlnx-zynqmp-can.c:476:21
+    #14 0x55c490d71a00 in can_tx_post_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/net/can/xlnx-zynqmp-can.c:836:9
+    #15 0x55c48fdfaf9b in register_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/core/register.c:122:9
+    #16 0x55c48fdfefb8 in register_write_memory /root/videzzo/videzzo_qemu/qemu/out-san/../hw/core/register.c:203:5
+    #17 0x55c4934be1d3 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:493:5
+    #18 0x55c4934bdb11 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18
+    #19 0x55c4934bc436 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1515:16
+    #20 0x55c49354cd0e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2825:23
+    #21 0x55c49353aabb in flatview_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2867:12
+    #22 0x55c49353a578 in address_space_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2963:18
+    #23 0x55c48f8aed48 in qemu_writel /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1096:5
+    #24 0x55c48f8ad0b3 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1245:28
+    #25 0x55c4943a3a6f in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5
+    #26 0x55c49439aded in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9
+    #27 0x55c49439ab94 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9
+    #28 0x55c48f8b608c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12
+    #29 0x55c4943a88bb in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18
+    #30 0x55c48f796816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17
+    #31 0x55c48f779444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #32 0x55c48f7843ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19
+    #33 0x55c48f7709d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #34 0x7fe365788082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #35 0x55c48f770a2d in _start (/root/bugs/metadata/xlnx_zynqmp_can-01/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can+0x3454a2d)
+
+NOTE: libFuzzer has rudimentary signal handlers.
+      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
+SUMMARY: libFuzzer: deadly signal
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1436 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1436
new file mode 100644
index 00000000..77e7be07
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1436
@@ -0,0 +1,61 @@
+Out of memory in hw/omap-dss for ARM
+Description of problem:
+In omap-dss, g_realloc() can allocate a large buffer using out of the memory.
+
+- [1] set pixels to any value
+- [2] double pixels
+- [3] allocate a large buffer
+
+```
+static void omap_rfbi_write(...) {
+   switch (addr) {
+     case 0x44: /* RFBI_PIXELCNT */
+        s->rfbi.pixels = value; // ------------------------------------> [1]
+        break;
+
+static void omap_rfbi_transfer_start(struct omap_dss_s *s) {
+    len = s->rfbi.pixels * 2;  // -------------------------------------> [2]
+    if (!data) {
+        if (len > bounce_len) {
+            bounce_buffer = g_realloc(bounce_buffer, len); // ---------> [3]
+        }
+```
+Steps to reproduce:
+```
+export QEMU=/path/to/qemu-system-arm
+
+cat << EOF | $QEMU \
+-machine n810,accel=qtest -m 128M -qtest stdio -monitor none -serial none \
+-display none -nodefaults -qtest stdio
+writel 0x48050440 0x74a57907
+writel 0x48050858 0x34982d63
+writel 0x48050840 0x65a61a51
+EOF
+```
+Additional information:
+```
+
+=================================================================
+==1029323==ERROR: AddressSanitizer: requested allocation size 0xfffffffffffffffe (0x800 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T0)
+    #0 0x7f4650b4ec3e in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:163
+    #1 0x7f464fa27f3f in g_realloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57f3f)
+    #2 0x55cf6212c85b in omap_rfbi_write ../hw/display/omap_dss.c:761
+    #3 0x55cf636b9c9b in memory_region_write_accessor ../softmmu/memory.c:493
+    #4 0x55cf636ba132 in access_with_adjusted_size ../softmmu/memory.c:555
+    #5 0x55cf636c76f8 in memory_region_dispatch_write ../softmmu/memory.c:1515
+    #6 0x55cf637049b9 in flatview_write_continue ../softmmu/physmem.c:2825
+    #7 0x55cf63704ddc in flatview_write ../softmmu/physmem.c:2867
+    #8 0x55cf637057c4 in address_space_write ../softmmu/physmem.c:2963
+    #9 0x55cf63716261 in qtest_process_command ../softmmu/qtest.c:533
+    #10 0x55cf6371ac52 in qtest_process_inbuf ../softmmu/qtest.c:802
+    #11 0x55cf6371ad43 in qtest_read ../softmmu/qtest.c:814
+    #12 0x55cf63d4d5e5 in qemu_chr_be_write_impl ../chardev/char.c:201
+    #13 0x55cf63d4d68c in qemu_chr_be_write ../chardev/char.c:213
+    #14 0x55cf63d544c9 in fd_chr_read ../chardev/char-fd.c:72
+    #15 0x55cf63938b9b in qio_channel_fd_source_dispatch ../io/channel-watch.c:84
+    #16 0x7f464fa2204d in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5204d)
+
+==1029323==HINT: if you don't care about these errors you may set allocator_may_return_null=1
+SUMMARY: AddressSanitizer: allocation-size-too-big ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:163 in __interceptor_realloc
+==1029323==ABORTING
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1444 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1444
new file mode 100644
index 00000000..20912d48
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1444
@@ -0,0 +1,42 @@
+ld.so on aarch64 crashes (SIGSEGV) qemu-aarch64-static to verify attached executable
+Description of problem:
+I'm currently managing an automation to build a linux distribution from nothing.
+The issues is when I try to cross compile gobject-introspection for aarch64 (it is currently working on arm) because the g-ir-compile phase requires a binary verification using ld-linux-aarch64-so-1 --verify GLib-2.0 process used by ldd, that crashes qemu-aarch64-static.
+Original command is: ${SYSROOT}/lib/ld-linux-aarch64-so-1 --verify ${HOME}/builds/gobject-introspection_1.75.4/tmp-introspectnpyrhpje/GLib-2.0.
+I simplified the problem bringing out the ld.so and GLib-2.0 binary to obtain the same result.
+
+This happens with glibc 2.35 and glibc 2.36 on aarch64 built with a gcc-12.2 cross compiler (x86 -> aarch64).
+
+[GLib-2.0](/uploads/47932b18278835fb13ef0de4c34872fa/GLib-2.0)
+
+[ld-linux-aarch64.so.1](/uploads/0ee01949285bea8ccfcebdc88a1d5b33/ld-linux-aarch64.so.1)
+
+I tried to debug the SIGSEGV but it's out completely out of my capacity.
+Steps to reproduce:
+1. Copy the 2 attached files in a directory:
+2. Run: qemu-aarch64-static ./ld-linux-aarch64.so.1 --verify ./GLib-2.0
+3. Result: Segmentation fault.
+Additional information:
+I attach the output of gdb after install qemu debug symbols:
+
+```
+Thread 1 "qemu-aarch64-st" received signal SIGSEGV, Segmentation fault.
+0x0000000000401088 in ?? ()
+(gdb) bt
+#0  0x0000000000401088 in ?? ()
+#1  0x00000000006aa439 in g_malloc0 ()
+#2  0x000000000061bb4b in page_find_alloc (index=index@entry=1024, alloc=alloc@entry=1)
+    at ../accel/tcg/translate-all.c:494
+#3  0x000000000061db12 in page_set_flags (start=start@entry=4194304, end=end@entry=4206592, flags=9, flags@entry=73)
+    at ../accel/tcg/translate-all.c:2288
+#4  0x0000000000629f10 in target_mmap (start=<optimized out>, start@entry=4194304, len=<optimized out>,
+    len@entry=12288, target_prot=target_prot@entry=1, flags=2066, fd=fd@entry=3, offset=offset@entry=0)
+    at ../linux-user/mmap.c:629
+#5  0x0000000000641e1d in do_syscall1 (cpu_env=0x9e8c10, num=222, arg1=4194304, arg2=12288, arg3=1,
+    arg4=<optimized out>, arg5=3, arg6=0, arg8=<optimized out>, arg7=<optimized out>) at ../linux-user/syscall.c:9961
+#6  0x0000000000644c8c in do_syscall (cpu_env=cpu_env@entry=0x9e8c10, num=222, arg1=4194304, arg2=12288, arg3=1,
+    arg4=2066, arg5=3, arg6=0, arg7=0, arg8=0) at ../linux-user/syscall.c:13203
+#7  0x000000000040fca8 in cpu_loop (env=env@entry=0x9e8c10) at ../linux-user/aarch64/cpu_loop.c:93
+#8  0x000000000040267f in main (argc=<optimized out>, argv=0x7fffffffdfc8, envp=<optimized out>)
+    at ../linux-user/main.c:897
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1488 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1488
new file mode 100644
index 00000000..286f8dfa
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1488
@@ -0,0 +1,35 @@
+Memory not accessible from GDB when using mps3-an547
+Description of problem:
+Memory (including variables) is not accessible when connecting to the emulated machine via GDB
+Steps to reproduce:
+1. Create minimal program `main.c`:
+    ```c
+    int main(void) {
+        int myvar = 42;
+        for(;;)
+    }
+    ```
+2. Compile
+   ```bash
+    arm-none-eabi-gcc -c -o build/main.o -c -mcpu=cortex-m55 -mfloat-abi=hard -mthumb -funsigned-char -mlittle-endian -O0 -g -std=c11  main.c
+    ```
+    (ARM startup files and include directories omitted for brevity)
+3. Link 
+    ```bash
+    arm-none-eabi-g++ -o build/test.elf build/main.o -mcpu=cortex-m55 -mfloat-abi=hard -mthumb -funsigned-char -mlittle-endian --entry=Reset_Handler -static -T./platform.ld -O0 -g
+    ```
+    (ARM startup files omitted for brevity)
+4. Run binary in QEMU:
+   ```bash
+    qemu-system-arm --machine mps3-an547 -serial mon:stdio -kernel test.elf -gdb tcp::1234 -S
+    ```
+5. Attach using GDB `arm-none-eabi-gdb build/test.elf` and set break point to infinite loop
+   ```gdb
+   target remote :1234
+   break main.c:18
+   continue
+   print myvar
+   ```
+
+Expected Output: 42  
+Actual Output: `Cannot access memory at address 0x11fffe4`
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1491 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1491
new file mode 100644
index 00000000..37d0f298
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1491
@@ -0,0 +1 @@
+imx_epit will stop unexpectedly when couter rollover
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1493 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1493
new file mode 100644
index 00000000..39f94a69
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1493
@@ -0,0 +1,85 @@
+Devision by zero in uart_parameters_setup()
+Description of problem:
+s->r[R_BRGR] could be zero but there is no check[1].
+
+```
+static void uart_parameters_setup(CadenceUARTState *s)
+{
+    QEMUSerialSetParams ssp;
+    unsigned int baud_rate, packet_size, input_clk;
+    input_clk = clock_get_hz(s->refclk);
+
+    baud_rate = (s->r[R_MR] & UART_MR_CLKS) ? input_clk / 8 : input_clk;
+    baud_rate /= (s->r[R_BRGR] * (s->r[R_BDIV] + 1)); // ----> [1]
+```
+Steps to reproduce:
+Build with ASan.
+
+```
+export QEMU=/path/to/qemu-system-aarch64
+
+cat << EOF | $QEMU \
+-machine xlnx-zcu102 -monitor none -serial none \
+-display none -nodefaults -qtest stdio
+writel 0xff000018 0x12330000
+writew 0xff000004 0xbcc4
+EOF
+```
+Additional information:
+```
+==23==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x55555d6bab70). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 4102190864
+INFO: Loaded 1 modules   (603606 inline 8-bit counters): 603606 [0x555560d6e000, 0x555560e015d6), 
+INFO: Loaded 1 PC tables (603606 PCs): 603606 [0x5555604379b0,0x555560d6d710), 
+./qemu-videzzo-aarch64-target-videzzo-fuzz-cadence-uart: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+Matching objects by name , *uart*
+This process will fuzz the following MemoryRegions:
+  * uart[0] (size 1000)
+  * uart[0] (size 1000)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * uart, EVENT_TYPE_MMIO_READ, 0xff000000 +0x1000, 1,4
+  * uart, EVENT_TYPE_MMIO_WRITE, 0xff000000 +0x1000, 1,4
+  * uart, EVENT_TYPE_MMIO_READ, 0xff010000 +0x1000, 1,4
+  * uart, EVENT_TYPE_MMIO_WRITE, 0xff010000 +0x1000, 1,4
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 512Mb
+Running: ./poc-qemu-videzzo-aarch64-target-videzzo-fuzz-cadence-uart-crash-cef41ca061384b94899472d8e2e6b5a86b62d259.minimized
+../hw/char/cadence_uart.c:181:15: runtime error: division by zero
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/char/cadence_uart.c:181:15 in 
+AddressSanitizer:DEADLYSIGNAL
+=================================================================
+==23==ERROR: AddressSanitizer: FPE on unknown address 0x555558fee913 (pc 0x555558fee913 bp 0x7fffffffb5f0 sp 0x7fffffffb220 T0)
+    #0 0x555558fee913 in uart_parameters_setup /root/videzzo/videzzo_qemu/qemu/out-san/../hw/char/cadence_uart.c:181:15
+    #1 0x555558fe8165 in uart_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/char/cadence_uart.c:471:9
+    #2 0x55555c7bee3e in memory_region_write_with_attrs_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:514:12
+    #3 0x55555c7be051 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18
+    #4 0x55555c7bcd1e in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1522:13
+    #5 0x55555c84ce1e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2826:23
+    #6 0x55555c83abcb in flatview_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2868:12
+    #7 0x55555c83a688 in address_space_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2964:18
+    #8 0x555558b3e91e in qemu_writew /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1101:5
+    #9 0x555558b3d173 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1253:28
+    #10 0x55555d6b5fef in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5
+    #11 0x55555d6ad36d in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9
+    #12 0x55555d6ad114 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9
+    #13 0x555558b4646c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1530:12
+    #14 0x55555d6bae3b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18
+    #15 0x555558a26bf6 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17
+    #16 0x555558a09824 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #17 0x555558a147ce in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19
+    #18 0x555558a00db6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #19 0x7ffff607a082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #20 0x555558a00e0d in _start (/root/bugs/metadata/cadence_uart-00/qemu-videzzo-aarch64-target-videzzo-fuzz-cadence-uart+0x34ace0d)
+
+AddressSanitizer can not provide additional info.
+SUMMARY: AddressSanitizer: FPE /root/videzzo/videzzo_qemu/qemu/out-san/../hw/char/cadence_uart.c:181:15 in uart_parameters_setup
+==23==ABORTING
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+0x1,0x9,0x18,0x0,0x0,0xff,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x0,0x0,0x33,0x12,0x0,0x0,0x0,0x0,0x1,0x9,0x4,0x0,0x0,0xff,0x0,0x0,0x0,0x0,0x2,0x0,0x0,0x0,0xc4,0xbc,0x4e,0x4c,0x0,0x0,0x0,0x0,
+\x01\x09\x18\x00\x00\xff\x00\x00\x00\x00\x04\x00\x00\x00\x00\x003\x12\x00\x00\x00\x00\x01\x09\x04\x00\x00\xff\x00\x00\x00\x00\x02\x00\x00\x00\xc4\xbcNL\x00\x00\x00\x00
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1514 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1514
new file mode 100644
index 00000000..cffca643
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1514
@@ -0,0 +1 @@
+Cpu flags for ARM is surprising
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1552 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1552
new file mode 100644
index 00000000..5cdca23b
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1552
@@ -0,0 +1,15 @@
+newer version(>=5.2.0) of qemu-system-aarch64 cannot debug arm64 linux kernel
+Description of problem:
+
+Steps to reproduce:
+1. Run QEMU in on teminal.
+2. Run gdb-multiarch in another terminal, for example: gdb-multiarch ./linux-5.10.4/vmlinux
+3. In gdb-multiarch, enter three commands in sequence："target remote localhost:1234"、"b do_sys_open"、"continue"
+4. GDB breakpoint cannot take effect
+5. If using qemu-system-aarch64 5.0.0(manually compiled)，GDB breakpoint can take effect.
+Additional information:
+I tested this problem using different combinations：  
+Host Os：Ubuntu18/Ubuntu20/Ubuntu22  
+ARM64 Linux Kernel: 5.4.50/5.10.4  
+QEMU：qemu 2.11/qemu 4.2/qemu 5.0/qemu 5.2/qemu 6.2/qemu 7  
+Finally, I found out that arm64 linux kernel cannot be debugged since qemu-system-aarch64 5.2.0.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1575 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1575
new file mode 100644
index 00000000..3cfd6988
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1575
@@ -0,0 +1 @@
+how to implement a heterogeneous machine(several sysbus/mem map)?
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1600 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1600
new file mode 100644
index 00000000..08747c63
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1600
@@ -0,0 +1,25 @@
+Aarch64/FEAT_SEL2  secure S1 translation for a NS page resolves to the secure IPA space
+Description of problem:
+Follow up to https://lists.trustedfirmware.org/archives/list/hafnium@lists.trustedfirmware.org/thread/ZUHRGWVDPUQ5CK6SRWZ7AMI5IKVS6J47/
+
+In context of Hafnium project (SEL2 / SPM firmware), implementing secure/non-secure page tables split rooted by VTTBR/VSTTBR in TZ secure world.
+Observing transactions always resolve to the secure IPA space (hence to the page tables rooted to by VSTTBR) whichever the state of the S1 MMU translation NS bit.
+Access to a page mapped NS from the SEL1 Trusted OS, causes a S2 page fault even though mapped in page tables rooted to by VTTBR.
+
+The VTCR_EL2/VSTCR_EL2 settings at SEL2 are as follows:
+VTCR_EL2.NSA/NSW=10b
+VSTCR_EL2.SA/SW=00b
+
+Note the same set of changes (https://review.trustedfirmware.org/q/topic:%2522od/split-vttbr%2522+status:open) run fine for the same scenario on FVP.
+Steps to reproduce:
+1. build qemu master 60ca584b8af0de525656f959991a440f8c191f12
+2. unzip [qemu-sel2-vttbr-fail.zip](/uploads/ec556347c32d97f79c140c5bccf45c6b/qemu-sel2-vttbr-fail.zip)
+3. Run
+
+```
+<...>/qemu/build/aarch64-softmmu/qemu-system-aarch64 -nographic -serial file:uart0.log -serial file:uart1.log -smp 2 -machine virt,secure=on,mte=on,gic-version=3,virtualization=true -cpu max,sme=off,pauth-impdef=on -d unimp -semihosting-config enable=on,target=native -m 1057 -bios bl1.bin -initrd rootfs.cpio.gz -kernel Image -no-acpi -append 'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2 nokaslr'  -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0,max-bytes=1024,period=1000 -netdev user,id=vmnic -device virtio-net-device,netdev=vmnic
+```
+Additional information:
+[qemu-60ca58-qemu-tfa-hf-linux-fail.txt](/uploads/1db0155fc49140cf52913cd75b7494c1/qemu-60ca58-qemu-tfa-hf-linux-fail.txt) illustrates the failure, linux boot stops, after sharing a NS page to the TOS, and the TOS retrieving the page, mapping as NS and accessing it (ends in a dead loop, because of the S2 PF in the TOS).
+
+[qemu-tfa-hf-linux-pass.txt](/uploads/4e672617838e40fe3614c127531443b5/qemu-tfa-hf-linux-pass.txt) shows the expected output where the NS mem sharing operation succeeds.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1608 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1608
new file mode 100644
index 00000000..1cc934a4
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1608
@@ -0,0 +1 @@
+QEMU gives wrong MPIDR value for Arm CPU types with MT=1
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1627 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1627
new file mode 100644
index 00000000..2f84a165
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1627
@@ -0,0 +1,39 @@
+Aarch64: VTCR.T0SZ / iasize test for Aarch32 guests wrong
+Description of problem:
+With QEMU 8 we are no longer able to execute Aarch32 guest code on an Aarch64 host. We use virtualization for the QEMU guest:
+- The QEMU guest kernel (L4Re kernel) runs at EL2 in AArch64 mode.
+- The L4Re guest code runs at EL1 in AAarch32 mode.
+
+It seems that the check for T0SZ / iasize in `ptw.c` / `check_s2_mmu_setup()` is too strict:
+```
+if (is_aa64) {
+    /*
+     * AArch64.S2InvalidTxSZ: While we checked tsz_oob near the top of
+     * get_phys_addr_lpae, that used aa64_va_parameters which apply
+     * to aarch64.  If Stage1 is aarch32, the min_txsz is larger.
+     * See AArch64.S2MinTxSZ, where min_tsz is 24, translated to
+     * inputsize is 64 - 24 = 40.
+     */
+    if (iasize < 40 && !arm_el_is_aa64(&cpu->env, 1)) {
+        goto fail;
+    }
+```
+The above test fails for us when executing Aarch32 EL1 code on Aarch64 EL2.
+
+Please note that the comment talks about `S2MinTxSZ` / `min_tsz`, so if the **minimum** value of `T0SZ` is 24, then the **maximum** value of `iasize` is `64-24=40` so the following comparison would be more appropriate (I replaces `<` by `>`):
+```
+if (iasize > 40 && !arm_el_is_aa64(&cpu->env, 1)) {
+    goto fail;
+}
+```
+However, the minimum value of `VTCR_EL2.T0SZ` is either 16 or 12, see `VTCR_EL2.DS`:
+- `VTCR_EL2.DS=0b0`: **minimum** value of `VTCR_EL2.T0SZ` is 16 => **maximum** value of `iasize` is 48,
+- `VTCR_EL2.DS=0b1`: **minimum** value of `VTCR_EL2.T0SZ` is 12 => **maximum** value of `iasize` is 52.
+
+Regarding the minimum of `iasize` / maximum of `VTCR_EL2.T0SZ`, see `ID_AA64MMFR_EL1.ST`:
+- `ID_AA64MMFR2_EL1.ST=0b0000`: **maximum** value of `VTCR_EL2.T0SZ` is 39 => **minimum** value of `iasize` is 25,
+- `ID_AA64MMFR2_EL1.ST=0b0001`: **maximum** value of `VTCR_EL2.T0SZ` is 48 => **minimum** value of `iasize` is 16 (or 47/17 for 64KiB granules).
+
+Our system executes Aarch32 EL1 code fine on Aarch64 EL2 if I weaken the comparison.
+Additional information:
+Sorry for not providing a test build but I'm not sure if it's worth to provide a custom build of our L4Re system, but I will happily provide one if you insist.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1640 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1640
new file mode 100644
index 00000000..5284aa9e
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1640
@@ -0,0 +1,25 @@
+aarch64: usb_mtp_get_data: Assertion `(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed
+Description of problem:
+When attempting to write to an MTP device in QEMU 8.0.0 on arm64, QEMU will crash at runtime with the following error:
+`qemu-system-aarch64: ../hw/usb/dev-mtp.c:1819: usb_mtp_get_data: Assertion '(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed.`
+
+This was observed in Nixpkgs where we use QEMU to provide automated testing of MTP devices for GVFS and jmtpfs, the full log for that test run that crashes due to this QEMU regression on arm64 is available here https://hydra.nixos.org/build/218858556/nixlog/1
+Steps to reproduce:
+1. Launch a QEMU virtual machine with `-usb -device usb-mtp,rootdir=/tmp,readonly=false` using any QEMU version above 6.0.0
+2. Mount the MTP device using something like:
+   ```
+   mkdir mtpDevice && jmtpfs mtpDevice
+   ```
+3. Try to write to the mtp device:
+   ```
+   dd if=/dev/urandom of=./mtpDevice/file
+   ```
+4. Observe that QEMU will crash when trying to write to the device, like this:
+   ```
+   client # 10+0 records in
+   client # 10+0 records out
+   client # 10485760 bytes (10 MB, 10 MiB) copied, 0.0318363 s, 329 MB/s
+   client # qemu-system-aarch64: ../hw/usb/dev-mtp.c:1819: usb_mtp_get_data: Assertion '(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed.error
+   ```
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1651 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1651
new file mode 100644
index 00000000..46563620
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1651
@@ -0,0 +1 @@
+bcm2835 timer jumps to max delay
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1657 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1657
new file mode 100644
index 00000000..d019c9cd
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1657
@@ -0,0 +1,33 @@
+Unable to use ide hard drive when using xlnx-zcu102 board
+Description of problem:
+I have only recently started using qemu and am reading content related to ahci. When I started QEMU using the above command line (I did not specify the Linux kernel because I only wanted to see which devices were initialized on the motherboard), I found the following devices in the device tree:
+ ```
+dev: sysbus-ahci, id ""
+
+gpio-out "sysbus-irq" 1
+
+num-ports = 2 (0x2)
+
+mmio 00000000fd0c0000/0000000000001000
+
+bus: ide.1
+
+type IDE
+
+bus: ide.0
+
+type IDE
+ ```
+
+I think this is similar to the ICH9 ahci device, so I tried to mount an IDE hard drive（using command line：-drive file=./testide.img）but failed. QEMU shows
+ ```
+qemu-system-aarch64: -drive file=./ testide.img: machine type does not support if=ide,bus=0,unit=0
+ ```
+So if the ide bus generated by sysbus ahci cannot mount a hard drive, what device should it mount?
+It will be grateful if anyone can answer this question.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/172 b/gitlab/issues_text/target_arm/host_missing/accel_missing/172
new file mode 100644
index 00000000..8e5363ed
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/172
@@ -0,0 +1 @@
+qemu seems to lack support for pid namespace.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1761 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1761
new file mode 100644
index 00000000..86a42eb1
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1761
@@ -0,0 +1 @@
+vexpress-a9 board maps both RAM and flash at address 0
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1763 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1763
new file mode 100644
index 00000000..b168399b
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1763
@@ -0,0 +1,12 @@
+ldd fails with qemu-aarch64
+Description of problem:
+see the original issue for full details https://github.com/multiarch/qemu-user-static/issues/172
+Steps to reproduce:
+1. docker run --rm -it arm64v8/ubuntu:16.04 ldd /bin/ls
+
+Also possible on other newer OSs (eg: Ubuntu:18.04) with different compiled binaries.
+Additional information:
+```
+WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested
+ldd: exited with unknown exit code (139)
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1772 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1772
new file mode 100644
index 00000000..82135aef
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1772
@@ -0,0 +1,12 @@
+MPS2 AN521 has the wrong number of MPU region defined
+Description of problem:
+The AN521 is integrating SSE-200 on the MPS2+ FPGA prototyping board.
+The current implementation in qemu behaves as though there are 16MPU regions when it really only has 8, as describes as `MPU_NS` and `MPU_S` core configuration parameters in the SSE-200's [Techincal Reference Manual](https://developer.arm.com/documentation/101104/0200/functional-description/cpu-elements/cortex-m33-configurations?lang=en).
+Steps to reproduce:
+1. Prepare your Zephyr dev environment
+2. fix `boards/arm/mps2_an521/mps2_an521.dts` to set `arm,num-mpu-regions`  to the appropriate value of 8.
+3. build a Zephyr test such as `west build -p -b mps2_an521 -T tests/kernel/interrupt/arch.interrupt` 
+4. run `qemu-system-arm -machine mps2-an521 -chardev stdio,id=con,mux=on -serial chardev:con -kernel ./build/zephyr/zephyr.elf`
+Additional information:
+With matching MPU region number in QEMU and Zephyr's DTS, the application shows the test suite's progress & outcome.
+If there's a mismatch, the application will enter a fault and not display the expected traces.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1802 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1802
new file mode 100644
index 00000000..9389dd8e
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1802
@@ -0,0 +1,9 @@
+windows serial COM PollingFunc don't sleep if guest uart can't write
+Description of problem:
+If two or more characters are sent from the host to the guest via Windows Com/Serial, everything freezes.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+I fix it in qemu/chardev/char-win.c see attached file
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1819 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1819
new file mode 100644
index 00000000..5346c9b4
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1819
@@ -0,0 +1,10 @@
+segmentation fault for rpm -qa command on centos:centos7 linux/arm/v7 architecture for docker container in shell.
+Description of problem:
+
+Steps to reproduce:
+1. docker pull centos:centos7@sha256:6887440ab977f751d6675157b73e42428d8ac05cf244c5d09ba036cc22d40d13 //pull an image centos:centos7 linux/arm/v7 tag
+2. docker run -it b22fdcc90005 //docker run in interactive mode just pulled image
+3. on shell run command -\> rpm -qa.
+4. docker run -it b22fdcc90005
+
+   WARNING: The requested image's platform (linux/arm/v7) does not match the detected host platform (linux/amd64) and no specific platform was requested \[root@e23bc92686e8 /\]# rpm -qa Segmentation fault (core dumped)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1825 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1825
new file mode 100644
index 00000000..7fc19af7
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1825
@@ -0,0 +1,14 @@
+pigz crashes when running in an aarch64 chroot (entered through qemu-binfmt) with qemu 8.1.0-rc*, qemu 8.0.3 is ok
+Description of problem:
+If qemu 8.1.0-rc1, -rc2 or -rc3 is used, pigz crashes.
+```
+# chroot /chroot/aarch64 pigz /tmp/test
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+```
+With qemu 8.0.3 on the same chroot enviroment, it works and produces the expected /chroot/aarch64/tmp/test.gz
+Steps to reproduce:
+1. Install an aarch64 chroot environment on x86_64
+2. Try using pigz to compress a file inside the chroot environment using qemu-binfmt
+Additional information:
+Unfortunately `git bisect`-ing the issue isn't easy because many snapshots between 8.0.0 (good) and 8.1.0-rc1 (first known bad) don't compile.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1850 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1850
new file mode 100644
index 00000000..ceda953a
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1850
@@ -0,0 +1,29 @@
+AARCH64 Illegal Instruction (CurrentEL)
+Description of problem:
+While emulating Aarch64 in QEMU, whenever the instruction `CurrentEL` is executed,
+QEMU crashes with the following message.
+
+`qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+Illegal instruction (core dumped)`
+
+I've tried both QEMU user space translation (qemu-aarch64-static) and QEMU emulation (qemu-system-aarch64),
+and both fail with the above message.
+
+C Code to reproduce bug, courtesy of https://github.com/cirosantilli/linux-kernel-module-cheat/blob/35684b1b7e0a04a68987056cb15abd97e3d2f0cc/baremetal/arch/aarch64/el.c
+```
+#include <stdio.h>
+#include <inttypes.h>
+
+int main(void) {
+        register uint64_t x0 __asm__ ("x0");
+	__asm__ ("mrs x0, CurrentEL;" : : : "%x0");
+	printf("%" PRIu64 "\n", x0 >> 2);
+	return 0;
+}
+```
+Steps to reproduce:
+1. Copy C code above into file.
+2. Compile code `gcc ./main.c --static`
+3. Execute elf bin `./a.out`
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1852 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1852
new file mode 100644
index 00000000..5046531a
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1852
@@ -0,0 +1,110 @@
+aarch64: crash failed  to analyze vmcore  of dump-guest-memory
+Description of problem:
+```
+1、 dump guest memory
+virsh qemu-monitor-command 3  --hmp "dump-guest-memory  /home/ecs3.kdump"
+2、crash kdump failed
+[root@ceasphere-node-1 home]# ./crash  ./vmlinux ./ecs3.kdump
+
+crash 7.2.9-2.el8
+Copyright (C) 2002-2020  Red Hat, Inc.
+Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
+Copyright (C) 1999-2006  Hewlett-Packard Co
+Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
+Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
+Copyright (C) 2005, 2011  NEC Corporation
+Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
+Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
+This program is free software, covered by the GNU General Public License,
+and you are welcome to change it and/or distribute copies of it under
+certain conditions.  Enter "help copying" to see the conditions.
+This program has absolutely no warranty.  Enter "help warranty" for details.
+
+crash: read error: kernel virtual address: ffff000010e0ba48  type: "vabits_user"
+GNU gdb (GDB) 7.6
+Copyright (C) 2013 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
+and "show warranty" for details.
+This GDB was configured as "aarch64-unknown-linux-gnu"...
+
+crash: read error: kernel virtual address: ffff000011a609b8  type: "possible"
+WARNING: cannot read cpu_possible_map
+crash: read error: kernel virtual address: ffff000011a60bb8  type: "present"
+WARNING: cannot read cpu_present_map
+crash: read error: kernel virtual address: ffff000011a607b8  type: "online"
+WARNING: cannot read cpu_online_map
+crash: read error: kernel virtual address: ffff000011a60db8  type: "active"
+WARNING: cannot read cpu_active_map
+crash: read error: kernel virtual address: ffff0000123da120  type: "shadow_timekeeper xtime_sec"
+crash: read error: kernel virtual address: ffff000011a6a6ac  type: "init_uts_ns"
+crash: ./vmlinux and ./ecs3.kdump do not match!
+
+Usage:
+
+  crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS]     (dumpfile form)
+  crash [OPTION]... [NAMELIST]                          (live system form)
+
+Enter "crash -h" for details.
+```
+Steps to reproduce:
+1. virsh create vm.xml
+2. virsh qemu-monitor-command 3  --hmp "dump-guest-memory  /home/ecs3.kdump"
+3. crash  ./vmlinux ./ecs3.kdump
+Additional information:
+The vmcore by 'echo  c > /proc/sysrq-trigger'  in guest is ok, crash work.
+
+```
+[root@ceasphere-node-1 home]# crash ./vmlinux  ./vmcore
+
+crash 8.0.3-1.el9
+Copyright (C) 2002-2022  Red Hat, Inc.
+Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
+Copyright (C) 1999-2006  Hewlett-Packard Co
+Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
+Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
+Copyright (C) 2005, 2011, 2020-2022  NEC Corporation
+Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
+Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
+Copyright (C) 2015, 2021  VMware, Inc.
+This program is free software, covered by the GNU General Public License,
+and you are welcome to change it and/or distribute copies of it under
+certain conditions.  Enter "help copying" to see the conditions.
+This program has absolutely no warranty.  Enter "help warranty" for details.
+
+GNU gdb (GDB) 10.2
+Copyright (C) 2021 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+Type "show copying" and "show warranty" for details.
+This GDB was configured as "aarch64-unknown-linux-gnu".
+Type "show configuration" for configuration details.
+Find the GDB manual and other documentation resources online at:
+    <http://www.gnu.org/software/gdb/documentation/>.
+
+For help, type "help".
+Type "apropos word" to search for commands related to "word"...
+
+      KERNEL: ./vmlinux
+    DUMPFILE: ./vmcore  [PARTIAL DUMP]
+        CPUS: 4
+        DATE: Wed Aug 30 09:06:01 CST 2023
+      UPTIME: 00:01:08
+LOAD AVERAGE: 0.91, 0.34, 0.12
+       TASKS: 158
+    NODENAME: localhost
+     RELEASE: 4.18.0-305.3.1.el8.aarch64
+     VERSION: #1 SMP Tue Jun 1 16:22:50 UTC 2021
+     MACHINE: aarch64  (unknown Mhz)
+      MEMORY: 16 GB
+       PANIC: "sysrq: SysRq : Trigger a crash"
+         PID: 1310
+     COMMAND: "bash"
+        TASK: ffff8003d47d3200  [THREAD_INFO: ffff8003d47d3200]
+         CPU: 1
+       STATE: TASK_RUNNING (SYSRQ)
+
+crash>
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1874 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1874
new file mode 100644
index 00000000..9537a951
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1874
@@ -0,0 +1,17 @@
+QGA：Whether arm windows VMS are supported？
+Description of problem:
+Whether qga can be used within an arm windows virtual machine?
+
+Windows reports an error (Failed to pCatalog->InstallComponent.(Error: 80110401) Errors occurred accessing one or more objects - the ErrorInfo collection may have more detail) when I try to install msi. Windows reports a warning(Catalog Event ID 5488: Unable to load DLL qga-vss.dll) (Unable to validate DLL entry points) in Event Viewer.
+
+I get msi from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-qemu-ga/qemu-ga-win-105.0.2-1.el9/qemu-ga-x86_64.msi  
+Either gqa does not support ARM or this msi is only for X86 architecture?
+
+![image](/uploads/bd99f46b1d9b7fdcb1b9418422bd84a8/image.png)
+![image](/uploads/e64a139e520a6b935ba05431b6697a8a/image.png)
+![image](/uploads/f15010bb2d9bf3fef16a3fb8230a67ce/image.png)
+Steps to reproduce:
+1. Start arm windows 11 vm.
+2. Install qemu guest agent.
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1878 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1878
new file mode 100644
index 00000000..ec7eef55
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1878
@@ -0,0 +1,29 @@
+QEMU doesn't implement ARMv4/v5 legacy SCTLR.U==0 load-and-rotate unaligned access handling
+Description of problem:
+**ldr r7, \[r0, r1\]** works differently on real device and QEMU. Probably all **ldr Rd, \[Rs\]** commands works wrongly in QEMU with Raspberry Pi emulation.
+Steps to reproduce:
+1. Launch the attached software **kernel_qemu.img** in QEMU.
+2. Launch the attached software **kerenel.img** on real Raspberry Pi 1B+.
+3. Look at the r7. It contains different data.
+Additional information:
+**kernel_qemu.img** and **kerenel.img** are the same program. It just compiled with different origins - 0x8000 for real device and 0x10000 for QEMU. But code inside the program works at the same addresses.
+
+r0 = 0x183a4
+
+r1 = 0x817
+
+**\[r0, r1\]** points to byte 0x42 in memory with such data:
+
+**0x80 0x15 0x22 \[0x42\] 0x03 0x21 0x87**
+
+After **ldr r7, \[r0, r1\]** execution real device puts to r7: **0x22158042**
+
+After **ldr r7, \[r0, r1\]** execution QEMU puts to r7: **0x87210342**
+
+QEMU:
+
+![QEMU.png](/uploads/51ecbf1689d36f969cb482f2613ccb58/QEMU.png)
+
+Real Raspberry Pi 1B+: ![real.jpg](/uploads/2a9cc3f4bc33d7f254c549e5086070a7/real.jpg)
+
+[kernel_qemu.img](/uploads/ae6a7490660569d5fe56adc9f4dde85d/kernel_qemu.img) [kernel.img](/uploads/48c94a66370c1fe8720fe89603c45c7b/kernel.img)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1899 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1899
new file mode 100644
index 00000000..f2989b17
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1899
@@ -0,0 +1,41 @@
+AArch64: Wrong SCR_EL3 after turning on secondary cores via PSCI
+Description of problem:
+The system fails to boot when using "direct kernel boot" with EL3 enabled. After the guest OS enables secondary cores via PSCI, those have an incorrectly set up `SCR_EL3`. When the OS then executes an intruction which traps into (QEMU provided fake) EL3, the core ends up in an endless loop of "Undefined Instruction" exceptions.
+
+This is nicely visible with `-serial stdio -append "earlycon=pl011,0x9000000 console=/dev/ttyAMA0" -d int`:
+
+```plaintext
+[    0.173173][    T1] smp: Bringing up secondary CPUs ...
+(...)
+Taking exception 11 [Hypervisor Call] on CPU 0
+...from EL1 to EL2
+...with ESR 0x16/0x5a000000
+...handled as PSCI call
+Taking exception 5 [IRQ] on CPU 0
+...from EL1 to EL1
+...with ESR 0x16/0x5a000000
+...with ELR 0xffffa9ff8b593438
+...to EL1 PC 0xffffa9ff8aa11280 PSTATE 0x3c5
+Exception return from AArch64 EL1 to AArch64 EL1 PC 0xffffa9ff8b593438
+Exception return from AArch64 EL1 to AArch64 EL1 PC 0x41f7832c
+Taking exception 1 [Undefined Instruction] on CPU 1
+...from EL1 to EL3
+...with ESR 0x18/0x62300882
+...with ELR 0xffffa9ff8aa3d0d8
+...to EL3 PC 0x400 PSTATE 0x3cd
+Taking exception 1 [Undefined Instruction] on CPU 1
+...from EL3 to EL3
+...with ESR 0x0/0x2000000
+...with ELR 0x400
+...to EL3 PC 0x200 PSTATE 0x3cd
+(repeats forever, CPU 1 is stuck)
+```
+Steps to reproduce:
+1. `qemu-system-aarch64 -M virt,secure=on -cpu max -smp 1 -kernel linux` works
+2. `qemu-system-aarch64 -M virt,secure=on -cpu max -smp 2 -kernel linux` does not
+Additional information:
+The setup for `SCR_EL3` is done by `do_cpu_reset` in hw/arm/boot.c, but this is only called on full system reset. The PSCI call ends up in `arm_set_cpu_on_async_work` (target/arm/arm-powerctl.c) which calls `cpu_reset`. This clears `SCR_EL3` to the architectural reset value, not the one needed for direct kernel boot.
+
+`arm_set_cpu_on_async_work` has code for `SCR_HCE`, but none of the other flags handled by `do_cpu_reset`. It would probably work after copying all of `do_cpu_reset` into `arm_set_cpu_on_async_work`, but that seems wrong. I prepared a patch which makes `do_cpu_reset` public such that `arm_set_cpu_on_async_work` can call it (works here), but I'm not sure whether that's the right way.
+
+CC @pm215
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1909 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1909
new file mode 100644
index 00000000..37d2e5a6
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1909
@@ -0,0 +1,50 @@
+regression: 8.0.0 segfaults on coverage counter increment
+Description of problem:
+With qemu 8.0.0, my test program segfaults while incrementing a gcov counter:
+
+```
+Breakpoint 2, 0x00000000004bc9a8 in __CortexA53843419_464004 ()
+(gdb) x/2i $pc
+=> 0x4bc9a8 <__CortexA53843419_464004>:	str	x8, [x9, #2512]
+   0x4bc9ac <__CortexA53843419_464004+4>:	b	0x464008 <mock_hyp_params_Destroy+24>
+(gdb) p $x8
+$10 = 1
+(gdb) p $x9
+$11 = 5234688
+(gdb) x/x $x9+2512
+0x4fe9d0 <__llvm_gcov_ctr.5>:	0x00000000
+(gdb) stepi
+
+Program received signal SIGSEGV, Segmentation fault.
+0x00000000004bc9a8 in __CortexA53843419_464004 ()
+(gdb) x/x $x9+2512
+0x4fe9d0 <__llvm_gcov_ctr.5>:	0x00000000
+(gdb) shell llvm-objdump --syms --arch-name=aarch64 ./build/gcov/out/test_hyp-props.out | grep  4fe9d0
+00000000004fe9d0 l     O .bss	0000000000000008 __llvm_gcov_ctr.5
+(gdb) shell qemu-aarch64 --version
+qemu-aarch64 version 8.0.0
+Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
+(gdb) 
+```
+
+With qemu 6.2.0, it doesn't segfault (at least not at this point, you
+may ignore the segfault at the end due to a bug in the test program).
+```
+$ /usr/bin/qemu-aarch64  --version
+qemu-aarch64 version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.12)
+Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
+
+$ /usr/bin/qemu-aarch64  ./build/gcov/out/test_hyp-props.out
+test_hyp-props.c:13:test__setup_str_prop:PASS
+test_hyp-props.c:14:test__log_print_handler:PASS
+test_hyp-props.c:15:test__setup_log_print_prop:PASS
+test_hyp-props.c:16:test__vm_vcpu_abort_reset_handler:PASS
+test_hyp-props.c:17:test__vm_info_alloc:PASS
+test_hyp-props.c:18:test__memory_status_get:PASS
+test_hyp-props.c:19:test__memory_status_get_fail:PASS
+Segmentation fault (core dumped)
+```
+Steps to reproduce:
+1. Compile and link statically (with ld.lld) a test program, with clang, targetting aarch64 with: -target aarch64-linux-android -mcpu=cortex-a53, using --coverage option to generate gcov coverage.
+2. Run it with qemu-aarch64 8.0.0
+3. Hopefully, it will segfault early for no good reason.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1913 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1913
new file mode 100644
index 00000000..21f7fbfb
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1913
@@ -0,0 +1,19 @@
+Regression in 8.1.1: qemu-aarch64-static running ldconfig
+Description of problem:
+Since updating to 8.1.1, qemu crashes when running ldconfig in my sysroot (It's a more or less default Ubuntu 22.04 arm64 rootfs)
+Steps to reproduce:
+1. Download the arm64 ubuntu base from https://cdimage.ubuntu.com/ubuntu-base/releases/jammy/release/
+2. Extract it
+3. Run `qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs` where `rootfs` is where you extracted it with qemu 8.1.1
+
+```bash
+$ qemu-aarch64-static --version
+qemu-aarch64 version 8.1.0
+$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs
+<works>
+$ sudo pacman -U /var/cache/pacman/pkg/qemu-user-static*-8.1.1*.zst
+$ qemu-aarch64-static --version
+qemu-aarch64 version 8.1.1
+$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs
+<segfault>
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1920 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1920
new file mode 100644
index 00000000..393bda77
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1920
@@ -0,0 +1,11 @@
+regrssion on 8.1.x: java/maven fails to run on qemu-aarch64
+Description of problem:
+Java process crashes when running simple "mvn -version" command inside qemu-aarch64. "java -version" works.
+Last known working version: 8.0.3 (qemu-8.0.3-4.fc39)
+Failing versions: 8.1.1 (qemu-8.1.1-1.fc39) and 8.1.0 (qemu-8.1.0-1.fc39)
+The same image works on native arm64 machine.
+Steps to reproduce:
+1. podman run --platform linux/arm64 docker.io/library/maven:3.9-eclipse-temurin-20 mvn -version
+2. should display few lines of version information and not a NullPointerException
+Additional information:
+podman version 4.7.0
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1938 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1938
new file mode 100644
index 00000000..32f6ed76
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1938
@@ -0,0 +1,36 @@
+[ARM/PL011] Wrong UART register spacing reported in DBG2/SPCR
+Description of problem:
+QEMU reports the UART address on aarch64 (for PL011 UART) via the ACPI DBG2 and SPCR tables using the ACPI GAS structure. According to MSFT documentation at https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table:
+
+> * The Register Bit Width field contains the register stride and must be a power of 2 that is at least as large as the access size. On 32-bit platforms this value cannot exceed 32. On 64-bit platforms this value cannot exceed 64.
+> * The Access Size field is used to determine whether byte, WORD, DWORD, or QWORD accesses are to be used. QWORD accesses are only valid on 64-bit architectures.
+
+For the PL011, the MMIO registers are:
+* spaced 4 bytes apart; therefore the reported bit width should be 32 instead of 8.
+* 16 bits wide; therefore the access width should be 2 instead of 1.
+
+In other words:
+```
+diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
+index 6b674231c2..cd284676d7 100644
+--- a/hw/arm/virt-acpi-build.c
++++ b/hw/arm/virt-acpi-build.c
+@@ -482,7 +482,7 @@ build_spcr(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
+     build_append_int_noprefix(table_data, 3, 1); /* ARM PL011 UART */
+     build_append_int_noprefix(table_data, 0, 3); /* Reserved */
+     /* Base Address */
+-    build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 8, 0, 1,
++    build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 32, 0, 2,
+                      vms->memmap[VIRT_UART].base);
+     /* Interrupt Type */
+     build_append_int_noprefix(table_data,
+@@ -673,7 +673,7 @@ build_dbg2(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
+     build_append_int_noprefix(table_data, 34, 2);
+ 
+     /* BaseAddressRegister[] */
+-    build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 8, 0, 1,
++    build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 32, 0, 2,
+                      vms->memmap[VIRT_UART].base);
+ 
+     /* AddressSize[] */
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1948 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1948
new file mode 100644
index 00000000..7caef5c3
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1948
@@ -0,0 +1,3 @@
+ARM GICv3 cannot support irq number > 992
+Description of problem:
+If we want to create a gic with supported irq number 992, we need to set the `num-irq` property to 992 + 32 while 32 is the extra SGI number. But there is a problem, when QEMU initialize GICv3, it will check the variable `num_irq <= 1020 && (num_irq & 32) == 0`, which will lead to error abort. So there is no way to bypass the ```num_irq <= 1020``` check and we cannot use irq number bigger than 992 while in ARM GIC specification, irq number < 1020 should all be aviliable to use.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1950 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1950
new file mode 100644
index 00000000..288f8171
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1950
@@ -0,0 +1,9 @@
+[AARCH64] GP bit (BTI) lost during two stages translation
+Description of problem:
+I noticed that the BTI faults were not reported.
+That's because the GP (guarded page) information is lost during the two stages translation in get_phys_addr_twostage().
+The "guarded" information is correctly retrieved by the first call to get_phys_addr_nogpc() but overwritten by the the second call to get_phys_addr_nogpc().
+The call to combine_cacheattrs() copies cacheattrs1.guarded but this field is never modified.
+
+The attached patch fixes the issue for me.
+[get_phys_addr_twostage_bti_gp_bit_lost_master.patch](/uploads/2fbe8090f92c43a63e39ee66ab2daf47/get_phys_addr_twostage_bti_gp_bit_lost_master.patch)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1960 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1960
new file mode 100644
index 00000000..0d329165
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1960
@@ -0,0 +1,22 @@
+Invalid pmu interrupt id in arm virt machine device-tree
+Description of problem:
+commit 9036e917f8357f4e5965ebfecdab5964d40e6a40 changes the definition of PPI interrupt ID, but forgets to modify the PMU device tree. 
+The following patch can solve this problem：
+```
+diff --git a/hw/arm/virt.c b/hw/arm/virt.c
+index dd6bb80ce2..1d118974ee 100644
+--- a/hw/arm/virt.c
++++ b/hw/arm/virt.c
+@@ -663,7 +663,7 @@ static void fdt_add_pmu_nodes(const VirtMachineState *vms)
+         qemu_fdt_setprop(ms->fdt, "/pmu", "compatible",
+                          compat, sizeof(compat));
+         qemu_fdt_setprop_cells(ms->fdt, "/pmu", "interrupts",
+-                               GIC_FDT_IRQ_TYPE_PPI, VIRTUAL_PMU_IRQ, irqflags);
++                               GIC_FDT_IRQ_TYPE_PPI, INTID_TO_PPI(VIRTUAL_PMU_IRQ), irqflags);
+     }
+ }
+```
+Steps to reproduce:
+NA
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/198 b/gitlab/issues_text/target_arm/host_missing/accel_missing/198
new file mode 100644
index 00000000..b93ca3d8
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/198
@@ -0,0 +1 @@
+USB Ethernet device (RNDIS) does not work on several tested operating systems
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1985 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1985
new file mode 100644
index 00000000..735f0199
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1985
@@ -0,0 +1 @@
+Possible infinite loop in target/arm/sme_helper.c: helper_sme_fmopa_h
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/1993 b/gitlab/issues_text/target_arm/host_missing/accel_missing/1993
new file mode 100644
index 00000000..deb3caf1
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/1993
@@ -0,0 +1,50 @@
+test-hmp fails on aarch64 target when CFI is enabled
+Description of problem:
+QEMU crashes during test-hmp when CFI is enabled
+Steps to reproduce:
+1. ../qemu/configure --cc=clang --cxx=clang++ --enable-cfi --enable-cfi-debug --enable-safe-stack --disable-slirp --target-list=aarch64-softmmu --disable-docs
+2. make -j$(nproc)
+3. V=2 QTEST_QEMU_BINARY=./qemu-system-aarch64 tests/qtest/test-hmp --verbose
+Additional information:
+The error messages look like this:
+```
+	info qtree
+UndefinedBehaviorSanitizer:DEADLYSIGNAL
+==677987==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address (pc 0x55fec2a3b7ce bp 0x7feef35ff970 sp 0x7fffbc8acd20 T677987)
+==677987==The signal is caused by a READ memory access.
+==677987==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
+    #0 0x55fec2a3b7ce in start_list.83665.cfi /tmp/qemu-cfi/../../home/thuth/devel/qemu/qapi/string-output-visitor.c:291:18
+    #1 0x55fec2a34dbe in visit_start_list /tmp/qemu-cfi/../../home/thuth/devel/qemu/qapi/qapi-visit-core.c:80:10
+    #2 0x55fec27dcb58 in get_prop_array.cfi /tmp/qemu-cfi/../../home/thuth/devel/qemu/hw/core/qdev-properties.c:698:10
+    #3 0x55fec27e7173 in object_property_get /tmp/qemu-cfi/../../home/thuth/devel/qemu/qom/object.c:1415:5
+    #4 0x55fec27e87a4 in object_property_print /tmp/qemu-cfi/../../home/thuth/devel/qemu/qom/object.c:1692:10
+    #5 0x55fec224dd72 in qdev_print_props /tmp/qemu-cfi/../../home/thuth/devel/qemu/system/qdev-monitor.c:761:21
+    #6 0x55fec224dd72 in qdev_print /tmp/qemu-cfi/../../home/thuth/devel/qemu/system/qdev-monitor.c:813:9
+    #7 0x55fec224dd72 in qbus_print /tmp/qemu-cfi/../../home/thuth/devel/qemu/system/qdev-monitor.c:831:9
+    #8 0x55fec22bd945 in handle_hmp_command_exec /tmp/qemu-cfi/../../home/thuth/devel/qemu/monitor/hmp.c:1106:9
+    #9 0x55fec22bcfeb in handle_hmp_command /tmp/qemu-cfi/../../home/thuth/devel/qemu/monitor/hmp.c:1158:9
+    #10 0x55fec22c020e in qmp_human_monitor_command /tmp/qemu-cfi/../../home/thuth/devel/qemu/monitor/qmp-cmds.c:182:5
+    #11 0x55fec29cfe0b in qmp_marshal_human_monitor_command.cfi /tmp/qemu-cfi/qapi/qapi-commands-misc.c:347:14
+    #12 0x55fec2a3c470 in do_qmp_dispatch_bh.cfi /tmp/qemu-cfi/../../home/thuth/devel/qemu/qapi/qmp-dispatch.c:128:5
+    #13 0x55fec2a63fc4 in aio_bh_call /tmp/qemu-cfi/../../home/thuth/devel/qemu/util/async.c:169:5
+    #14 0x55fec2a6418f in aio_bh_poll /tmp/qemu-cfi/../../home/thuth/devel/qemu/util/async.c:216:13
+    #15 0x55fec2a49deb in aio_dispatch /tmp/qemu-cfi/../../home/thuth/devel/qemu/util/aio-posix.c:423:5
+    #16 0x55fec2a64ffa in aio_ctx_dispatch.cfi /tmp/qemu-cfi/../../home/thuth/devel/qemu/util/async.c:358:5
+    #17 0x7feef8d6ae5b  (/lib64/libglib-2.0.so.0+0x5be5b) (BuildId: c5377a60d8282e2a61a4af1201dc10c9666139c2)
+    #18 0x7feef8d6b124 in g_main_context_dispatch (/lib64/libglib-2.0.so.0+0x5c124) (BuildId: c5377a60d8282e2a61a4af1201dc10c9666139c2)
+    #19 0x55fec2a6656b in glib_pollfds_poll /tmp/qemu-cfi/../../home/thuth/devel/qemu/util/main-loop.c:290:9
+    #20 0x55fec2a6656b in os_host_main_loop_wait /tmp/qemu-cfi/../../home/thuth/devel/qemu/util/main-loop.c:313:5
+    #21 0x55fec2a6656b in main_loop_wait /tmp/qemu-cfi/../../home/thuth/devel/qemu/util/main-loop.c:592:11
+    #22 0x55fec22553e6 in qemu_main_loop /tmp/qemu-cfi/../../home/thuth/devel/qemu/system/runstate.c:782:9
+    #23 0x55fec27da3f5 in qemu_default_main.cfi /tmp/qemu-cfi/../../home/thuth/devel/qemu/system/main.c:37:14
+    #24 0x7feef7aff149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) (BuildId: 651b2bed7ecaf18098a63b8f10299821749766e6)
+    #25 0x7feef7aff20a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2820a) (BuildId: 651b2bed7ecaf18098a63b8f10299821749766e6)
+    #26 0x55fec1e865b4 in _start (/tmp/qemu-cfi/qemu-system-aarch64+0x5435b4) (BuildId: c8a2f51d83ddef5c97f11783d94381f60c82c2ac)
+
+UndefinedBehaviorSanitizer can not provide additional info.
+SUMMARY: UndefinedBehaviorSanitizer: SEGV /tmp/qemu-cfi/../../home/thuth/devel/qemu/qapi/string-output-visitor.c:291:18 in start_list.83665.cfi
+==677987==ABORTING
+Broken pipe
+../../home/thuth/devel/qemu/tests/qtest/libqtest.c:195: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0)
+Aborted (core dumped)
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2053 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2053
new file mode 100644
index 00000000..472aff3c
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2053
@@ -0,0 +1 @@
+virtio is broken in qemu-system-arm
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2066 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2066
new file mode 100644
index 00000000..b63dcd16
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2066
@@ -0,0 +1 @@
+Feature Request: UART 8250 Support in QEMU Virt Machine for aarch64
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2084 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2084
new file mode 100644
index 00000000..63aefda5
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2084
@@ -0,0 +1 @@
+"qemu-system-arm -machine virt -cpu cortex-a9" error message includes a lot of "(null)"s
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2106 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2106
new file mode 100644
index 00000000..d79e0ff8
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2106
@@ -0,0 +1,55 @@
+QEMU build fail on Solaris 11.4 because "FSCALE" #defined by sys/param.h
+Description of problem:
+Building `target/arm/tcg/translate-sve.c` fails on Solaris 11.4 because system's
+`/usr/include/sys/param.h` has `#define FSCALE (1 << FSHIFT)` which results
+in `DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)` at `translate-sve.c:3864`
+attempting to expand the `#define` substitution instead of the text `FSCALE`.<p>I have not determined what the sequence of includes was that brought in `sys/param.h`<p>A workaround is to `#undef FSCALE`, but that may not be an appropriate long-term fix.
+Steps to reproduce:
+1. mkdir build && cd build
+2. ../configure --disable-docs --disable-rdma --enable-slirp
+3. gmake
+Additional information:
+Full diagnostic output:
+```
+[1865/5402] Compiling C object libqemu-aarch64-softmmu.fa.p/target_arm_tcg_translate-sve.c.o
+FAILED: libqemu-aarch64-softmmu.fa.p/target_arm_tcg_translate-sve.c.o 
+cc -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -Isubprojects/dtc/libfdt -I../subprojects/dtc/libfdt -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/glib-2.0 -I/usr/lib/sparcv9/glib-2.0/include -I/usr/include/pcre -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -fstack-protector-strong -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -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 -Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -Wshadow=local -iquote . -iquote /opt/qemu -iquote /opt/qemu/include -iquote /opt/qemu/host/include/generic -iquote /opt/qemu/tcg/sparc64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -D_XOPEN_SOURCE=600 -D__EXTENSIONS__ -fPIE -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/target_arm_tcg_translate-sve.c.o -MF libqemu-aarch64-softmmu.fa.p/target_arm_tcg_translate-sve.c.o.d -o libqemu-aarch64-softmmu.fa.p/target_arm_tcg_translate-sve.c.o -c ../target/arm/tcg/translate-sve.c
+In file included from ../target/arm/tcg/translate-sve.c:21:
+../target/arm/tcg/translate.h:728:17: error: pasting "trans_" and "(" does not give a valid preprocessing token
+  728 |     static bool trans_##NAME(DisasContext *s, arg_##NAME *a) \
+      |                 ^~~~~~
+../target/arm/tcg/translate-sve.c:3854:5: note: in expansion of macro ‘TRANS_FEAT’
+ 3854 |     TRANS_FEAT(NAME, FEAT, gen_gvec_fpst_arg_zpzz, name##_zpzz_fns[a->esz], a)
+      |     ^~~~~~~~~~
+../target/arm/tcg/translate-sve.c:3864:1: note: in expansion of macro ‘DO_ZPZZ_FP’
+ 3864 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)
+      | ^~~~~~~~~~
+../target/arm/tcg/translate-sve.c:3864:12: error: expected declaration specifiers or ‘...’ before numeric constant
+ 3864 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)
+      |            ^~~~~~
+../target/arm/tcg/translate.h:728:25: note: in definition of macro ‘TRANS_FEAT’
+  728 |     static bool trans_##NAME(DisasContext *s, arg_##NAME *a) \
+      |                         ^~~~
+../target/arm/tcg/translate-sve.c:3864:1: note: in expansion of macro ‘DO_ZPZZ_FP’
+ 3864 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)
+      | ^~~~~~~~~~
+../target/arm/tcg/translate.h:728:47: error: pasting "arg_" and "(" does not give a valid preprocessing token
+  728 |     static bool trans_##NAME(DisasContext *s, arg_##NAME *a) \
+      |                                               ^~~~
+../target/arm/tcg/translate-sve.c:3854:5: note: in expansion of macro ‘TRANS_FEAT’
+ 3854 |     TRANS_FEAT(NAME, FEAT, gen_gvec_fpst_arg_zpzz, name##_zpzz_fns[a->esz], a)
+      |     ^~~~~~~~~~
+../target/arm/tcg/translate-sve.c:3864:1: note: in expansion of macro ‘DO_ZPZZ_FP’
+ 3864 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)
+      | ^~~~~~~~~~
+In file included from ../target/arm/tcg/translate-sve.c:86:
+libqemu-aarch64-softmmu.fa.p/decode-sve.c.inc:1112:13: warning: ‘trans_FSCALE’ used but never defined
+ 1112 | static bool trans_FSCALE(DisasContext *ctx, arg_FSCALE *a);
+      |             ^~~~~~~~~~~~
+../target/arm/tcg/translate-sve.c:3864:30: warning: ‘sve_fscalbn_zpzz_fns’ defined but not used [-Wunused-const-variable=]
+ 3864 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)
+      |                              ^~~~~~~~~~~
+../target/arm/tcg/translate-sve.c:3850:42: note: in definition of macro ‘DO_ZPZZ_FP’
+ 3850 |     static gen_helper_gvec_4_ptr * const name##_zpzz_fns[4] = { \
+      |                                          ^~~~
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/211 b/gitlab/issues_text/target_arm/host_missing/accel_missing/211
new file mode 100644
index 00000000..7f5c32d6
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/211
@@ -0,0 +1 @@
+qemu-aarch64-static segfault if /proc not mounted inside chroot
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2120 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2120
new file mode 100644
index 00000000..7aff6202
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2120
@@ -0,0 +1 @@
+arm64: Typo in isar_feature_aa64_tidcp1
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2155 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2155
new file mode 100644
index 00000000..3d2f8e4e
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2155
@@ -0,0 +1,23 @@
+LoadVM assert on ARM_FEATURE_M for Cortex M3
+Description of problem:
+This appears to be a similar issue to https://gitlab.com/qemu-project/qemu/-/issues/1775 and https://gitlab.com/qemu-project/qemu/-/issues/1658
+
+When running `loadvm`  qemu aborts with this error:
+
+"qemu/target/arm/helper.c:12383: arm_security_space_below_el3: Assertion `!arm_feature(env, ARM_FEATURE_M)' failed."
+
+I've traced the error to `pmu_counter_enabled` in `qemu\target\arm\helper.c:1172`   
+ [uint64_t mdcr_el2 = arm_mdcr_el2_eff(env)](https://gitlab.com/qemu-project/qemu/-/blob/v8.2.0/target/arm/helper.c?ref_type=tags#L1172)  (link is to 8.2.0 release tag)
+
+
+The issue is caused by attempting to get the MDCR_EL2 register  prior to checking if the CPU has ARM_FEATURE_PMU support. 
+
+A simple fix seems to be to check for `ARM_PMU_ENABLED` and returning early if it is not enabled.
+Steps to reproduce:
+1. Start emulation and connect monitor
+2. savevm <snapshot-name>
+3. Loadvm <snapshot-name>
+Additional information:
+See screenshot for stack trace
+
+![armCortexM3LoadVMStackTrace](/uploads/fcfd927f4d373922715c8787dbb9cc26/armCortexM3LoadVMStackTrace.png)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2213 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2213
new file mode 100644
index 00000000..8719a063
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2213
@@ -0,0 +1,15 @@
+QEMU fails with duplicate SaveStateEntry when using two legacy virtio input devices
+Description of problem:
+QEMU bails out when it is started with two virtio-input devices running in legacy virtio mode, using two different transports (like PCI and CCW on s390x).
+Steps to reproduce:
+```
+qemu-system-s390x -M s390-ccw-virtio-2.6 -cpu max -nographic -device virtio-multitouch-pci -device virtio-tablet-ccw
+```
+fails with:
+```
+qemu-system-s390x: -device virtio-tablet-ccw: savevm_state_handler_insert: Detected duplicate SaveStateEntry: id=virtio-input, instance_id=0x0
+```
+Additional information:
+The problem does *not* occur if using modern virtio devices (which automatically happens for -M s390-ccw-virtio-2.7 and newer) or if using virtio-input devices with the same transport (e.g. two PCI devices instead of one PCI and one CCW).
+
+Also note that the problem only occurs since QEMU 8.1 since older versions did not check for duplicate SaveStateEntries (see commit caa91b3c44cdb2d2921e25 ).
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2226 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2226
new file mode 100644
index 00000000..59c8bcc6
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2226
@@ -0,0 +1,56 @@
+arm HSTR trap settings routed to EL1 instead of EL2
+Description of problem:
+ARM's HSTR register is used to trap CP15 access from EL1/0. qemu's implementation seems to be inconsistent with ARM's documentation.
+
+Take the system register VBAR for example, the following pseudo code is grabbed from ARM DDI 0487J.a ID042523 G8-10651, which is the logics behind when reading VBAR.
+```
+if PSTATE.EL == EL0 then
+    UNDEFINED;
+elsif PSTATE.EL == EL1 then
+    if EL2Enabled() && !ELUsingAArch32(EL2) && HSTR_EL2.T12 == '1' then
+        AArch64.AArch32SystemAccessTrap(EL2, 0x03);
+    elsif EL2Enabled() && ELUsingAArch32(EL2) && HSTR.T12 == '1' then
+        AArch32.TakeHypTrapException(0x03);
+    elsif HaveEL(EL3) && ELUsingAArch32(EL3) then
+        R[t] = VBAR_NS;
+    else
+        R[t] = VBAR;
+elsif PSTATE.EL == EL2 then
+    if HaveEL(EL3) && ELUsingAArch32(EL3) then
+        R[t] = VBAR_NS;
+    else
+        R[t] = VBAR;
+elsif PSTATE.EL == EL3 then
+    if SCR.NS == '0' then
+        R[t] = VBAR_S;
+    else
+        R[t] = VBAR_NS;
+```
+
+The main logics in my attached test program are:
+1. Setting EL2 and EL1's exception table
+2. Set HSTR.T12
+3. ERET to EL1, and read VBAR from EL1
+
+As the document mentions, when CPU running on EL1 && HSTR.T12 is set, HypTrapException 0x3 should be taken, which is EL2. But the test program shows, on such circumstances, CPU is being routed to EL1's undefined exception.
+Steps to reproduce:
+1. Clone this repo https://github.com/roolrz/reproduce-qemu-arm-hstr-issue
+2. Use make to build the test program
+3. Use following command to launch it
+```
+qemu-system-arm \
+	-nographic \
+	-cpu cortex-a7 \
+	-M virt,virtualization=on \
+	-m 1G \
+	-kernel el2.elf
+```
+4. The following message is printed by the program, problem reproduced
+```
+EL2 Booted
+Jumping to el1
+el1 reached, triggering trap
+EL1 undefined sync triggered
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2227 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2227
new file mode 100644
index 00000000..2e847d0b
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2227
@@ -0,0 +1,36 @@
+Crash when using the ast2600-a3 device with the "virt" aarch64 machine
+Description of problem:
+QEMU crashes with a segmentation fault when trying to use the "ast2600-a3" device with the "virt" machine.
+Steps to reproduce:
+1. Run ``./qemu-system-aarch64 -display none -machine virt -device ast2600-a3``
+Additional information:
+Backtrace indicates that it is crashing in the aspeed_soc_ast2600_realize() function:
+
+```
+#0  memory_region_update_container_subregions (subregion=0x555558c4b630) at ../../devel/qemu/system/memory.c:2637
+#1  memory_region_add_subregion_common (mr=<optimized out>, offset=<optimized out>, subregion=0x555558c4b630) at ../../devel/qemu/system/memory.c:2661
+#2  0x0000555555d1bd40 in aspeed_soc_ast2600_realize (dev=<optimized out>, errp=0x7fffffffd870) at ../../devel/qemu/hw/arm/aspeed_ast2600.c:301
+#3  0x0000555555ff26ab in device_set_realized (obj=<optimized out>, value=<optimized out>, errp=0x7fffffffda00) at ../../devel/qemu/hw/core/qdev.c:510
+#4  0x0000555555ff6edd in property_set_bool (obj=0x555558c4b360, v=<optimized out>, name=<optimized out>, opaque=0x555557cd5b50, errp=0x7fffffffda00)
+    at ../../devel/qemu/qom/object.c:2358
+#5  0x0000555555ffa25b in object_property_set (obj=obj@entry=0x555558c4b360, name=name@entry=0x5555563794ed "realized", v=v@entry=0x555558ce0650, errp=errp@entry=0x7fffffffda00)
+    at ../../devel/qemu/qom/object.c:1472
+#6  0x0000555555ffdb9f in object_property_set_qobject
+    (obj=obj@entry=0x555558c4b360, name=name@entry=0x5555563794ed "realized", value=value@entry=0x555558cdf270, errp=errp@entry=0x7fffffffda00)
+    at ../../devel/qemu/qom/qom-qobject.c:28
+#7  0x0000555555ffa8c4 in object_property_set_bool (obj=obj@entry=0x555558c4b360, name=name@entry=0x5555563794ed "realized", value=value@entry=true, errp=errp@entry=0x7fffffffda00)
+    at ../../devel/qemu/qom/object.c:1541
+#8  0x0000555555ff319c in qdev_realize (dev=dev@entry=0x555558c4b360, bus=bus@entry=0x0, errp=errp@entry=0x7fffffffda00) at ../../devel/qemu/hw/core/qdev.c:292
+#9  0x0000555555c11be3 in qdev_device_add_from_qdict (opts=opts@entry=0x555558c4a2d0, from_json=from_json@entry=false, errp=0x7fffffffda00, errp@entry=0x55555725b478 <error_fatal>)
+    at ../../devel/qemu/system/qdev-monitor.c:718
+#10 0x0000555555c12051 in qdev_device_add (opts=0x555557cd2a10, errp=errp@entry=0x55555725b478 <error_fatal>) at ../../devel/qemu/system/qdev-monitor.c:737
+#11 0x0000555555c1720f in device_init_func (opaque=<optimized out>, opts=<optimized out>, errp=0x55555725b478 <error_fatal>) at ../../devel/qemu/system/vl.c:1200
+#12 0x00005555561a29c1 in qemu_opts_foreach
+    (list=<optimized out>, func=func@entry=0x555555c17200 <device_init_func>, opaque=opaque@entry=0x0, errp=errp@entry=0x55555725b478 <error_fatal>)
+    at ../../devel/qemu/util/qemu-option.c:1135
+#13 0x0000555555c19aea in qemu_create_cli_devices () at ../../devel/qemu/system/vl.c:2637
+#14 qmp_x_exit_preconfig (errp=<optimized out>) at ../../devel/qemu/system/vl.c:2705
+#15 0x0000555555c1d67f in qmp_x_exit_preconfig (errp=<optimized out>) at ../../devel/qemu/system/vl.c:2699
+#16 qemu_init (argc=<optimized out>, argv=<optimized out>) at ../../devel/qemu/system/vl.c:3736
+#17 0x00005555558f6f59 in main (argc=<optimized out>, argv=<optimized out>) at ../../devel/qemu/system/main.c:47
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2228 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2228
new file mode 100644
index 00000000..941a3d7f
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2228
@@ -0,0 +1,8 @@
+hw/core/gpio.c:108: qdev_get_gpio_in_named: Assertion n >= 0 && n < gpio_list->num_in failed
+Description of problem:
+It's quite easy to trigger the assertion ``hw/core/gpio.c:108: qdev_get_gpio_in_named: Assertion n >= 0 && n < gpio_list->num_in failed``
+Steps to reproduce:
+Run one of the following command lines:
+1. ``./qemu-system-aarch64 -display none -machine qcom-dc-scm-v1-bmc -device max1111``
+2. ``./qemu-system-aarch64 -display none -machine fby35-bmc -device max1110``
+3. ``./qemu-system-aarch64 -display none -machine yosemitev2-bmc -device corgi-ssp``
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/224 b/gitlab/issues_text/target_arm/host_missing/accel_missing/224
new file mode 100644
index 00000000..337d21a8
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/224
@@ -0,0 +1 @@
+Wrong interrupts generated for I.MX6 FEC controller
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2279 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2279
new file mode 100644
index 00000000..c43e4e43
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2279
@@ -0,0 +1,25 @@
+Debugging with Lauterbach Trace32 -> Cortex-A76, no SP register update
+Description of problem:
+We do not see changes in the SP_EL1 register value when debugging the QEMU application with Lauterbach Trace32.
+Steps to reproduce:
+1. Compile bare metal code that uses push and pop instructions (stack).
+2. Run QEMU with bare metal code.
+3. Connect via Lauterbach Trace32 and check the displayed SP register value.
+Additional information:
+![T32_badA76_SP_reg_display](/uploads/e6af1ac3e32072274089e6dc0cdf0266/T32_badA76_SP_reg_display.png)
+This is a screenshot from QEMU 8.0.0, but updating to QEMU 8.2.0 does not resolve the problem.
+
+I have discussed this with Lauterbach Trace32 support with these results:
+- Trace32 uses RSP protocol `p` packets to read some registers, including SP_EL1. GDB seems to use `g` packet.
+- QEMU responds to `p` packet with an invalid value, which causes Trace32 to display invalid value.
+
+Some related RSP protocol logs from Trace32.
+![T32_sp_1](/uploads/cbe34d19d3ede30549e6c4d781bb6630/T32_sp_1.png)
+![T32_sp_2](/uploads/73e22dbf83ec00b939077dfeb7bfa208/T32_sp_2.png)
+
+Different part of RSP protocol log:
+```
+Sending packet: $p20#d2 ...
+receiving packet: ec00004000000000
+```
+So it looks like Trace32 can receive different values that zero as response to `p` packet.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2300 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2300
new file mode 100644
index 00000000..c8f3f060
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2300
@@ -0,0 +1 @@
+Unintialized variable in double_cpdo.c
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2304 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2304
new file mode 100644
index 00000000..29de268d
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2304
@@ -0,0 +1,38 @@
+Disabling SVE via `-cpu max,sve=off` leaves SVE2 advertised by `getauxval`
+Description of problem:
+The documentation on https://qemu-project.gitlab.io/qemu/system/arm/cpu-features.html suggests that it should be possible to disable SVE support by passing `-cpu max,sve=off` on the command line, however this appears to only disable the SVE support advertised in the return value from `getauxval(AT_HWCAP)`. In particular it leaves SVE2 reported as enabled. This leaves the feature set advertised by `getauxval` in an inconsistent state since SVE is mandatory if SVE2 is available.
+
+This may also affect other feature dependencies for example FEAT_SVE_BITPerm also requiring SVE2 to be available, I've not checked exhaustively.
+
+For example, given the following code:
+
+    #include <sys/auxv.h>
+    #include <stdio.h>
+
+    int main() {
+      unsigned long hwcap = getauxval(AT_HWCAP);
+      unsigned long hwcap2 = getauxval(AT_HWCAP2);
+
+      if (hwcap & HWCAP_SVE) {
+        printf("have sve!\n");
+      } else {
+        printf("don't have sve!\n");
+      }
+      if (hwcap2 & HWCAP2_SVE2) {
+        printf("have sve2!\n");
+      } else {
+        printf("don't have sve2!\n");
+      }
+    }
+
+We can observe the following:
+
+    $ aarch64-linux-gnu-gcc test.c -static
+    $ ../qemu-aarch64 -cpu max ./a.out
+    have sve!
+    have sve2!
+    $ ../qemu-aarch64 -cpu max,sve=off ./a.out
+    don't have sve!
+    have sve2!
+
+I don't believe that there is a `-cpu ...,sve2=off` option, so I would expect that disabling SVE also prevents SVE2 from being advertised as available.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2309 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2309
new file mode 100644
index 00000000..d92a62cb
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2309
@@ -0,0 +1,31 @@
+qemu-aarch64 hangs running cargo test after libc6 upgrade to 2.36-9+deb12u6
+Description of problem:
+qemu-aarch64 seems to hang with 100% cpu usage without any indication.
+with -p 12345 for gdb debugging, gdb could not interrupt the remote with ctrl-c.
+Steps to reproduce:
+1. Ensure the test env has 2.36-9+deb12u6
+2. Install the latest rust toolchain.
+3. mkdir test_test && cargo init
+4. ensure src/main.rs has
+```
+fn main() {
+    println!("Hello, world!");
+}
+
+#[test]
+fn test() {
+    println!("hAAA!");
+}
+```
+5. create .cargo/config.toml 
+```
+[target.aarch64-unknown-linux-gnu]
+linker = "aarch64-linux-gnu-gcc"
+runner = "qemu-aarch64 -L /usr/aarch64-linux-gnu"
+rustflags = ["-C", "target-cpu=neoverse-n1"]
+```
+6. cargo test --target aarch64-unknown-linux-gnu
+Additional information:
+The issue does not seem to occur with libc6:2.36-9+deb12u4
+
+The same binary runs fine on a real arm64 target with the upgraded libc6 version 2.36-9+deb12u6.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2333 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2333
new file mode 100644
index 00000000..ffd0f371
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2333
@@ -0,0 +1,45 @@
+VDSO on armeb seems broken
+Description of problem:
+I'm seeing the VDSO method for `__clock_gettime64()` crashing under `qemu-armeb` (stack trace under Additional information, below).
+
+I rebuilt glibc with VDSO globally kludged off, and all was well.
+Steps to reproduce:
+```
+#include <time.h>
+#include <stdlib.h>
+#include <stdio.h>
+
+int main(int argc, char **argv) {
+  time_t ts;
+  printf("%ld\n", time(&ts));
+  exit(0);
+}
+```
+
+Results, first with VDSO active via a system snapshot, second with the patched glibc:
+```
+$ armeb-linux-gnueabihf-gcc -o /tmp/time /tmp/time.c
+$ qemu-armeb -L /.mirrorsnaps/.rootsnap.prev/usr/armeb-linux-gnueabihf /tmp/time
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+$ qemu-armeb -L /usr/armeb-linux-gnueabihf /tmp/time
+1715123280
+```
+Additional information:
+```
+Program received signal SIGSEGV, Segmentation fault.
+0x4082b462 in ?? ()
+(gdb) bt
+#0  0x4082b462 in ?? ()
+#1  0x40bf64a4 in __GI___clock_gettime64 (clock_id=clock_id@entry=5, tp=tp@entry=0x407fe9c0)
+    at ../sysdeps/unix/sysv/linux/clock_gettime.c:42
+#2  0x40be9f58 in __GI___time64 (timer=0x0) at ../sysdeps/unix/sysv/linux/time.c:60
+#3  __time (timer=0x407fea04) at ../sysdeps/unix/sysv/linux/time.c:73
+```
+
+`clock_gettime.c:42` is
+```
+      r = INTERNAL_VSYSCALL_CALL (vdso_time64, 2, clock_id, tp);
+```
+
+Interestingly, the problem doesn't occur on qemu-arm (little endian), all else equal.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2351 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2351
new file mode 100644
index 00000000..0a73da12
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2351
@@ -0,0 +1,15 @@
+Raspberry Pi: Unable to start raspios bookworm
+Description of problem:
+I am able to start RaspiOS bullseye (2023-05-03-raspios-bullseye-arm64-lite) in both, the rpi3 and rpi4 configurations, by first extracting the DTB and the kernel from the downloaded image (see the command lines).
+
+When I attempt to start RaspiOS bookworm (2024-03-15-raspios-bookworm-arm64-lite), I only get the following messages on the host's terminal:
+
+```
+usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa
+usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa
+usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa
+```
+
+[start-raspios.sh](/uploads/041fb113d1d0d920e52f3b11a9f51290/start-raspios.sh)
+Steps to reproduce:
+To reproduce, adapt the attached script, download the raspios images and run it.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2355 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2355
new file mode 100644
index 00000000..09b261e5
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2355
@@ -0,0 +1,79 @@
+buffer overflow in aspeed gpio
+Description of problem:
+The following log reveals it:
+
+```
+==2602930==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55a5da29e128 at pc 0x55a5d700dc62 bp 0x7fff096c4e90 sp 0x7fff096c4e88
+READ of size 2 at 0x55a5da29e128 thread T0
+    #0 0x55a5d700dc61 in aspeed_gpio_read /home/joey/repo/qemu/build/../hw/gpio/aspeed_gpio.c:564:14
+    #1 0x55a5d933f3ab in memory_region_read_accessor /home/joey/repo/qemu/build/../system/memory.c:445:11
+    #2 0x55a5d92fba40 in access_with_adjusted_size /home/joey/repo/qemu/build/../system/memory.c:573:18
+    #3 0x55a5d92f842c in memory_region_dispatch_read1 /home/joey/repo/qemu/build/../system/memory.c:1426:16
+    #4 0x55a5d92f7b68 in memory_region_dispatch_read /home/joey/repo/qemu/build/../system/memory.c:1459:9
+    #5 0x55a5d9376ad1 in flatview_read_continue_step /home/joey/repo/qemu/build/../system/physmem.c:2836:18
+    #6 0x55a5d9376399 in flatview_read_continue /home/joey/repo/qemu/build/../system/physmem.c:2877:19
+    #7 0x55a5d93775b8 in flatview_read /home/joey/repo/qemu/build/../system/physmem.c:2907:12
+    #8 0x55a5d9377078 in address_space_read_full /home/joey/repo/qemu/build/../system/physmem.c:2920:18
+    #9 0x55a5d8189aa2 in address_space_read /home/joey/repo/qemu/include/exec/memory.h:3100:18
+    #10 0x55a5d8189aa2 in qtest_process_command /home/joey/repo/qemu/build/../system/qtest.c:597:13
+    #11 0x55a5d818231d in qtest_process_inbuf /home/joey/repo/qemu/build/../system/qtest.c:811:9
+    #12 0x55a5d81915ae in qtest_read /home/joey/repo/qemu/build/../system/qtest.c:823:5
+    #13 0x55a5d9bc115d in qemu_chr_be_write_impl /home/joey/repo/qemu/build/../chardev/char.c:214:9
+    #14 0x55a5d9bc1219 in qemu_chr_be_write /home/joey/repo/qemu/build/../chardev/char.c:226:9
+    #15 0x55a5d9bccd25 in fd_chr_read /home/joey/repo/qemu/build/../chardev/char-fd.c:72:9
+    #16 0x55a5d95d958c in qio_channel_fd_source_dispatch /home/joey/repo/qemu/build/../io/channel-watch.c:84:12
+    #17 0x7f8909babc43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43)
+    #18 0x55a5d9f62319 in glib_pollfds_poll /home/joey/repo/qemu/build/../util/main-loop.c:287:9
+    #19 0x55a5d9f60c53 in os_host_main_loop_wait /home/joey/repo/qemu/build/../util/main-loop.c:310:5
+    #20 0x55a5d9f6081c in main_loop_wait /home/joey/repo/qemu/build/../util/main-loop.c:589:11
+    #21 0x55a5d8198807 in qemu_main_loop /home/joey/repo/qemu/build/../system/runstate.c:796:9
+    #22 0x55a5d9544c6c in qemu_default_main /home/joey/repo/qemu/build/../system/main.c:37:14
+    #23 0x55a5d9544cb7 in main /home/joey/repo/qemu/build/../system/main.c:48:12
+    #24 0x7f8909229d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
+    #25 0x7f8909229e3f in __libc_start_main csu/../csu/libc-start.c:392:3
+    #26 0x55a5d671ed34 in _start (/home/joey/repo/qemu/build/qemu-system-aarch64+0x2773d34)
+
+0x55a5da29e128 is located 24 bytes to the left of global variable '<string literal>' defined in '../hw/gpio/aspeed_gpio.c:1180:23' (0x55a5da29e140) of size 20
+  '<string literal>' is ascii string 'aspeed.gpio-ast2500'
+0x55a5da29e128 is located 22 bytes to the right of global variable '<string literal>' defined in '/home/joey/repo/qemu/include/hw/gpio/aspeed_gpio.h:17:1' (0x55a5da29e100) of size 18
+  '<string literal>' is ascii string 'ASPEED_GPIO_CLASS'
+SUMMARY: AddressSanitizer: global-buffer-overflow /home/joey/repo/qemu/build/../hw/gpio/aspeed_gpio.c:564:14 in aspeed_gpio_read
+Shadow bytes around the buggy address:
+  0x0ab53b44bbd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0ab53b44bbe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0ab53b44bbf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0ab53b44bc00: 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
+  0x0ab53b44bc10: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
+=>0x0ab53b44bc20: 00 00 02 f9 f9[f9]f9 f9 00 00 04 f9 f9 f9 f9 f9
+  0x0ab53b44bc30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0ab53b44bc40: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 00 00 04 f9
+  0x0ab53b44bc50: f9 f9 f9 f9 00 00 00 01 f9 f9 f9 f9 00 00 00 00
+  0x0ab53b44bc60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0ab53b44bc70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+Shadow byte legend (one shadow byte represents 8 application bytes):
+  Addressable:           00
+  Partially addressable: 01 02 03 04 05 06 07
+  Heap left redzone:       fa
+  Freed heap region:       fd
+  Stack left redzone:      f1
+  Stack mid redzone:       f2
+  Stack right redzone:     f3
+  Stack after return:      f5
+  Stack use after scope:   f8
+  Global redzone:          f9
+  Global init order:       f6
+  Poisoned by user:        f7
+  Container overflow:      fc
+  Array cookie:            ac
+  Intra object redzone:    bb
+  ASan internal:           fe
+  Left alloca redzone:     ca
+  Right alloca redzone:    cb
+```
+Steps to reproduce:
+```
+cat << EOF | qemu-system-aarch64 -display \
+none -machine accel=qtest, -m 512M -machine ast1030-evb -qtest stdio
+readq 0x7e780272
+EOF
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2356 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2356
new file mode 100644
index 00000000..d7358180
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2356
@@ -0,0 +1,15 @@
+assert in stm32l4x5_rcc
+Description of problem:
+The following log reveals it:
+
+```
+qemu-system-aarch64: ../hw/misc/stm32l4x5_rcc.c:546: void rcc_update_cfgr_register(Stm32l4x5RccState *): Assertion `val <= 0b100' failed.
+Aborted
+```
+Steps to reproduce:
+```
+cat << EOF | qemu-system-aarch64 -display \
+none -machine accel=qtest, -m 512M -machine b-l475e-iot01a -qtest stdio
+writeq 0x40021008 0xffffffff
+EOF
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2358 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2358
new file mode 100644
index 00000000..1b3dc770
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2358
@@ -0,0 +1,50 @@
+null-pointer-dereference in a9gtimer
+Description of problem:
+The following log reveals it:
+
+```
+../hw/timer/a9gtimer.c:51:22: runtime error: member access within null pointer of type 'CPUState' (aka 'struct CPUState')
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/timer/a9gtimer.c:51:22 in
+AddressSanitizer:DEADLYSIGNAL
+=================================================================
+==2624453==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000002d0 (pc 0x55df9673422f bp 0x7fff7310e930 sp 0x7fff7310e8a0 T0)
+==2624453==The signal is caused by a READ memory access.
+==2624453==Hint: address points to the zero page.
+    #0 0x55df9673422f in a9_gtimer_get_current_cpu /home/joey/repo/qemu/build/../hw/timer/a9gtimer.c:51:22
+    #1 0x55df9673408c in a9_gtimer_this_write /home/joey/repo/qemu/build/../hw/timer/a9gtimer.c:246:14
+    #2 0x55df97e00353 in memory_region_write_accessor /home/joey/repo/qemu/build/../system/memory.c:497:5
+    #3 0x55df97dffa40 in access_with_adjusted_size /home/joey/repo/qemu/build/../system/memory.c:573:18
+    #4 0x55df97dfd986 in memory_region_dispatch_write /home/joey/repo/qemu/build/../system/memory.c:1521:16
+    #5 0x55df97ea8973 in flatview_write_continue_step /home/joey/repo/qemu/build/../system/physmem.c:2755:18
+    #6 0x55df97ea81df in flatview_write_continue /home/joey/repo/qemu/build/../system/physmem.c:2785:19
+    #7 0x55df97e7be4b in flatview_write /home/joey/repo/qemu/build/../system/physmem.c:2816:12
+    #8 0x55df97e7b908 in address_space_write /home/joey/repo/qemu/build/../system/physmem.c:2936:18
+    #9 0x55df96c8b041 in qtest_process_command /home/joey/repo/qemu/build/../system/qtest.c:559:13
+    #10 0x55df96c8631d in qtest_process_inbuf /home/joey/repo/qemu/build/../system/qtest.c:811:9
+    #11 0x55df96c955ae in qtest_read /home/joey/repo/qemu/build/../system/qtest.c:823:5
+    #12 0x55df986c515d in qemu_chr_be_write_impl /home/joey/repo/qemu/build/../chardev/char.c:214:9
+    #13 0x55df986c5219 in qemu_chr_be_write /home/joey/repo/qemu/build/../chardev/char.c:226:9
+    #14 0x55df986d0d25 in fd_chr_read /home/joey/repo/qemu/build/../chardev/char-fd.c:72:9
+    #15 0x55df980dd58c in qio_channel_fd_source_dispatch /home/joey/repo/qemu/build/../io/channel-watch.c:84:12
+    #16 0x7f76346edc43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43)
+    #17 0x55df98a66319 in glib_pollfds_poll /home/joey/repo/qemu/build/../util/main-loop.c:287:9
+    #18 0x55df98a64c53 in os_host_main_loop_wait /home/joey/repo/qemu/build/../util/main-loop.c:310:5
+    #19 0x55df98a6481c in main_loop_wait /home/joey/repo/qemu/build/../util/main-loop.c:589:11
+    #20 0x55df96c9c807 in qemu_main_loop /home/joey/repo/qemu/build/../system/runstate.c:796:9
+    #21 0x55df98048c6c in qemu_default_main /home/joey/repo/qemu/build/../system/main.c:37:14
+    #22 0x55df98048cb7 in main /home/joey/repo/qemu/build/../system/main.c:48:12
+    #23 0x7f7633e29d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
+    #24 0x7f7633e29e3f in __libc_start_main csu/../csu/libc-start.c:392:3
+    #25 0x55df95222d34 in _start (/home/joey/repo/qemu/build/qemu-system-aarch64+0x2773d34)
+
+AddressSanitizer can not provide additional info.
+SUMMARY: AddressSanitizer: SEGV /home/joey/repo/qemu/build/../hw/timer/a9gtimer.c:51:22 in a9_gtimer_get_current_cpu
+==2624453==ABORTING
+```
+Steps to reproduce:
+```
+cat << EOF | /home/joey/repo/qemu/build/qemu-system-aarch64 -display \
+none -machine accel=qtest, -m 512M -machine npcm750-evb -qtest stdio
+writel 0xf03fe20c 0x26d7468c
+EOF
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/236 b/gitlab/issues_text/target_arm/host_missing/accel_missing/236
new file mode 100644
index 00000000..6b5d85f2
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/236
@@ -0,0 +1 @@
+CPU fetch from unpopulated ROM on reset
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2377 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2377
new file mode 100644
index 00000000..a16ae1f1
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2377
@@ -0,0 +1,25 @@
+Debootstrapping debian-bullseye arm64 segfaults with qemu >=8.1
+Steps to reproduce:
+1. Use qemu >= 8.1 (version <= 8.0.x work well)
+2. Install `debootstrap` package
+3. Run `sudo debootstrap --arch=arm64 bullseye root11-arm64`
+
+This fails to chroot into the system being debootstrapped:
+
+```
+$ sudo debootstrap --arch=arm64 bullseye root11-arm64
+...
+W: Failure trying to run: chroot "/home/3/root11" /sbin/ldconfig
+W: See /home/3/root11/debootstrap/debootstrap.log for details
+$ tail -n2 /home/3/root11/debootstrap/debootstrap.log
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+/usr/share/debootstrap/functions: line 1092:  3869 Segmentation fault      chroot "/home/3/root11" "$@"
+```
+Additional information:
+Failure happens only when debootstrapping "bullseye" with "arm64" architecture.
+Older (e.g. <= "buster") and newer (e.g. > "bookworm") distros are deboostrapped OK.
+Other (e.g. "armhf" and others) architectures are debootstrapped OK.
+
+Qemu version <8.1 (e.g. 8.0.5 I use in Gentoo or versions in Debian <= bookworm) don't have the bug.
+
+Originally faced the issue with Gentoo host. Recently rechecked with Debian Trixie host.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2382 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2382
new file mode 100644
index 00000000..5675ddef
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2382
@@ -0,0 +1,14 @@
+QEMU occurs an Error when testing my DIY UEFI aarch64 kernel:Synchronous Exception at 0x00000000E46CCEAC
+Description of problem:
+Shows Synchronous Exception at 0x00000000E46CCEAC and the program halts.
+Steps to reproduce:
+1.Download the UEFIPascalOS on github.
+2.run the bash buildaarch64.sh to build the kernel iso.
+3.Go through the installer guide and enter the kernel.
+4.Enter the account's name and password and press enter,now you can got an error that shows Synchronous Exception at 0x00000000E46CCEAC
+Additional information:
+(no logs,stack traces was shown for the error because logs and stack traces are not exists.)
+screenshots:
+![ScreenShot.png](/uploads/981efb0cfe6149872487b55b9beb504d/QQ截图20240605203550.png)
+If I create two accounts,it will halt on sentence "Welcome to TYDQ System!" and give me  Synchronous Exception at other numbers.
+If I change the memory in virt-machine,the Synchronous Exception showing number will be changed.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/239 b/gitlab/issues_text/target_arm/host_missing/accel_missing/239
new file mode 100644
index 00000000..9e5b942f
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/239
@@ -0,0 +1 @@
+Confusing error message when KVM can not start requested ARM CPU
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/247 b/gitlab/issues_text/target_arm/host_missing/accel_missing/247
new file mode 100644
index 00000000..2c02673c
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/247
@@ -0,0 +1 @@
+qemu-system-arm segmentation fault using pmemsave on the interrupt controller registers
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2473 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2473
new file mode 100644
index 00000000..1633eb58
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2473
@@ -0,0 +1,3 @@
+qemu-system-aarch64: Stop execution on unhandled exceptions
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2484 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2484
new file mode 100644
index 00000000..bb57f05f
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2484
@@ -0,0 +1 @@
+Confusing query-gic-capabilities output in --without-default-devices config
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2533 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2533
new file mode 100644
index 00000000..935c69d4
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2533
@@ -0,0 +1 @@
+Black screen while I'm trying to emulate Android using "-machine raspi4b"
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2536 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2536
new file mode 100644
index 00000000..ef331ea5
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2536
@@ -0,0 +1 @@
+Dynamic translation issue of arm instruction VFNMA and VFNMS
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2540 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2540
new file mode 100644
index 00000000..b4d72e1b
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2540
@@ -0,0 +1,17 @@
+Machine B-L475E-IOT01A USART devices not functional
+Description of problem:
+The B-L475E-IOT01A claims to support STM32L4x5 USARTs, UARTs and LPUART (Serial ports) but does not appear to actually function.
+
+I created a minimal bare metal binary that attempts to write to UART (via printf) but it does not succeed. While debugging it appears that all UART registers for USART1 are zero despite code that is writing to those registers and USART_ISR should have the default value of 0x020000C0 per STM documentation RM0351. The code ends up in an infinite loop waiting for the USART module to become ready but it never does.
+
+For comparison an almost identical program compiled for the netduino-plus-2 (also an STM32 Cortex-M4 CPU) is able to use USART succesfully.
+Steps to reproduce:
+1. Clone https://github.com/satur9nine/arm-cortex-qemu-demo/tree/STM_b-l475e-iot01a (note branch is STM_b-l475e-iot01a)
+2. Obtain arm-none-eabi-gcc version 13.3.rel1 or higher from ARM or linux package manager and install
+3. Go to `STM_b-l475e-iot01a_Build` and run `make all` to produce arm-cortex-qemu-demo.bin
+4. Run command provided above (optionally run with additional `-gdb tcp::1234,ipv4 -S` options and attach debugger), observe there is no UART output
+5. Repeat steps but with `STM_netduino-plus-2_Build` and observe UART output is produced for comparison
+Additional information:
+Notice memory located at 0x40013800 which is where USART1 is located shows all zeros.
+
+![iot01a_debug](/uploads/ae8eac57e162fe0ae45ec8e09114d038/iot01a_debug.png)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2546 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2546
new file mode 100644
index 00000000..f54a2dbb
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2546
@@ -0,0 +1 @@
+Troubleshooting Data Abort Error While Debugging U-Boot on mcimx6ul-evk in QEMU
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2547 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2547
new file mode 100644
index 00000000..4a03dad7
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2547
@@ -0,0 +1,3 @@
+Raspberry 4B Ethernet support
+Additional information:
+There is available WIP patch https://patchew.org/QEMU/20240226000259.2752893-1-sergey.kambalin@auriga.com/
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2549 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2549
new file mode 100644
index 00000000..882d5778
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2549
@@ -0,0 +1,3 @@
+qemu-system-arm, ast2400-a1, The ECC_TEST_CTRL register of aspeed_2400_sdmc_write is not implemented
+Additional information:
+The ast2400-a1 has a few more memory test modes compared to the ast2500-a2 (1xxb in 8:6 and 11b in 2:1), but I think it should be enough to always return a test pass result.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2554 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2554
new file mode 100644
index 00000000..e5721821
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2554
@@ -0,0 +1,11 @@
+qemu-system-arm: thumb2: vector table branch instruction not followed
+Description of problem:
+When an undefined instruction is hit and causes an exception that causes a jump to the undef vector at 0x04; translation of the branch instruction found there appears to fail since instead of branching to the handler it steps to the next instruction - the next entry in the vector table, translates that, and on stepping once again moves to the next entry in the vector table. Eventually it steps out of the table and (re)enters the _start subroutine pointed to by vector 0x0.
+Steps to reproduce:
+This is related to issue #2542 in as much as I am hunting down failures in the picolibc 1.8.6 test suite on Debian. After fixing issues such as the failure to enable the MMU and some others via incorporating upstream commits I'm left with 10 tests, all for exception handling, that result in meson (build system) TIMEOUT instead of EXPECTEDFAIL. All of these tests should fail instantly and cause Qemu to exit but it continues - apparently spinning in an endless loop as described above until meson kills it.
+
+Creating a small reproducer has proved challenging and nigh impossible (for me) - even identifying the crux as described here has taken 4 days. However with the help of `qemu-system-arm -d in_asm,op,out_asm ...` and `gdb-multiarch` I believe I may have produced a focused report that will help figure this out.
+
+#
+Additional information:
+Since this is hard to debug I can give remote ssh access via `tmate` to directly control the debug session if necessary.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2577 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2577
new file mode 100644
index 00000000..56930378
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2577
@@ -0,0 +1 @@
+buildx: Illegal instruction, exit code: 132
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2580 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2580
new file mode 100644
index 00000000..a7098504
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2580
@@ -0,0 +1,12 @@
+qemu-aarch64_be 9.1.0 fails to run any Linux programs due to unreachable in gdb_find_static_feature()
+Description of problem:
+```
+❯ cat empty.c
+void _start() {}
+❯ clang empty.c -target aarch64_be-linux -nostdlib -fuse-ld=lld
+❯ qemu-aarch64_be ./a.out
+**
+ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached
+Bail out! ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached
+fish: Job 1, 'qemu-aarch64_be ./a.out' terminated by signal SIGABRT (Abort)
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2588 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2588
new file mode 100644
index 00000000..1a2840dd
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2588
@@ -0,0 +1,43 @@
+qemu-system-arm regression: NonSecure World can change Secure World MMU mapping.
+Description of problem:
+A NonSecure execution context is able to override MMU L1 translation table
+flags set by Secure context on Secure World memory.
+
+This is not consistent with the same code running on real hardware and it's a
+regression over past qemu releases as 9.0.0 behaves correctly.
+Steps to reproduce:
+This has been tested with
+[GoTEE-example](https://github.com/usbarmory/GoTEE-example) as follows:
+
+```
+# building tamago
+wget https://github.com/usbarmory/tamago-go/archive/refs/tags/latest.zip
+unzip latest.zip
+cd tamago-go-latest/src && ./all.bash
+cd ../bin && export TAMAGO=`pwd`/go
+
+# building and running GoTEE-example
+wget https://github.com/usbarmory/GoTEE-example/archive/refs/heads/master.zip
+unzip master.zip
+cd GoTEE-example
+export TARGET=usbarmory && make clean && make nonsecure_os_go && make trusted_applet_go && make trusted_os && make qemu
+```
+
+#
+Additional information:
+The issue relates to the fact that the NonSecure World, at startup, configures
+the MMU with the NX bit for the entire address space not belonging to its
+firmware .text area.
+
+On real hardware this MMU configuration by NonSecure world does not affect the
+Secure World translation tables.
+
+On qemu 9.1.0, however it does and this is inconsistent with real hardware
+behavior. On qemu 9.0.0 the behaviour is correct so the issue has been
+introduced between these two releases.
+
+The switch between Secure and NonSecure is done
+[here](https://github.com/usbarmory/GoTEE/blob/7e62563c0628fed3ee0aebb4702e22be9bb636e3/monitor/exec_arm.s#L73).
+
+The MMU first level address table which sets the NX bit is done
+[here](https://github.com/usbarmory/tamago/blob/273d67cd811dfcb1782c0fe596ac14d43d0ce117/arm/mmu.go#L85).
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2591 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2591
new file mode 100644
index 00000000..783d23bc
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2591
@@ -0,0 +1 @@
+Black screen and DTB errors while trying to emulate the kernel of the RaspiOS (based on Debian Bookworm) using the parameter -machine raspi4b
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2595 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2595
new file mode 100644
index 00000000..f7baf033
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2595
@@ -0,0 +1,135 @@
+Incorrect behavior with 64-bit element SDOT and UDOT instructions on ARM SVE when sve-default-vector-length>=64
+Description of problem:
+The behavior of SDOT and UDOT instructions are incorrect when the Zresult.D register is used, which is the 64-bit svdot_lane\_{s,u}64 intrinsic in ACLE.
+
+I have tested the same code using [Arm Instruction Emulator](https://developer.arm.com/Tools%20and%20Software/Arm%20Instruction%20Emulator) (which is deprecated though) and gem5 which produced correct result, I believe that the SDOT and UDOT implementation in qemu is incorrect.
+Steps to reproduce:
+1. Get Arm Gnu toolchain from [Arm GNU Toolchain Downloads – Arm Developer](https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads), for x86 Linux hosts, download arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz and extract it. Alternatively, use any compiler that is able to cross compile for armv8.2-a+sve targets.
+2. Compile the following program with these compiler arguments
+
+   ```
+   arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc -O3 -march=armv8.2-a+sve dot_lane.c -o dot_lane
+   ```
+
+   ```c
+   #include <stdio.h>
+   #include <arm_sve.h>
+   
+   int64_t a[32] = { 0 };
+   int16_t b[128];
+   int16_t c[128];
+   int64_t r[32];
+   int64_t expected_r[32];
+   
+   #define IMM 0
+   
+   int main(void)
+   {
+       for (size_t i = 0; i < 128; i++) {
+           b[i] = 1;
+           c[i] = i / 4;
+       }
+   
+       svint64_t av = svld1(svptrue_b64(), a);
+       svint16_t bv = svld1(svptrue_b16(), b);
+       svint16_t cv = svld1(svptrue_b16(), c);
+   
+       svint64_t result = svdot_lane_s64(av, bv, cv, IMM);
+   
+       svst1(svptrue_b64(), r, result);
+   
+       for (size_t i = 0; i < svcntd(); i++) {
+           expected_r[i] = 
+               (int64_t)b[i * 4 + 0] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 0] +
+               (int64_t)b[i * 4 + 1] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 1] +
+               (int64_t)b[i * 4 + 2] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 2] +
+               (int64_t)b[i * 4 + 3] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 3] +
+               a[i];
+       }
+       
+       printf("%12s", "r: ");
+       for (size_t i = 0; i < svcntd(); i++) {
+           printf("%4ld", r[i]);
+       }
+       printf("\n");
+       printf("%12s", "expected_r: ");
+       for (size_t i = 0; i < svcntd(); i++) {
+           printf("%4ld", expected_r[i]);
+       }
+       printf("\n\t\t");
+       for (size_t i = 0; i < svcntd(); i++) {
+           if (r[i] != expected_r[i]) {
+               printf("%4c", '^');
+           } else {
+               printf("%4c", ' ');
+           }
+       }
+       printf("\n");
+       printf("idx:\t\t");
+       for (size_t i = 0; i < svcntd(); i++) {
+           if (r[i] != expected_r[i]) {
+               printf("%4d", i);
+           } else {
+               printf("%4c", ' ');
+           }
+       }
+       printf("\n");
+   
+       return 0;
+   }
+   ```
+3. Execute it with the following commands:
+
+   ```
+   qemu-aarch64 -cpu max,sve-default-vector-length=16 -L arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/../aarch64-none-linux-gnu/libc dot_lane
+   ```
+
+   Change the value of `sve-default-vector-length` to 32, 64, 128, 256 and observe the outputs, we should see that for `sve-default-vector-length` \>= 64, the result is incorrect.
+
+   `sve-default-vector-length=16`
+
+   ```
+            r:    0   0
+   expected_r:    0   0
+                           
+   idx:                
+   ```
+
+   `sve-default-vector-length=32`
+
+   ```
+            r:    0   0   8   8
+   expected_r:    0   0   8   8
+                                   
+   idx:                        
+   ```
+
+   `sve-default-vector-length=64`
+
+   ```
+            r:    0   0   8   8   8   8  24  24
+   expected_r:    0   0   8   8  16  16  24  24
+                                      ^   ^        
+   idx:                               4   5         
+   ```
+
+   `sve-default-vector-length=128`
+
+   ```
+            r:    0   0   8   8   8   8  24  24  24  24  40  40  40  40  56  56
+   expected_r:    0   0   8   8  16  16  24  24  32  32  40  40  48  48  56  56
+                                      ^   ^           ^   ^           ^   ^        
+   idx:                               4   5           8   9          12  13       
+   ```
+
+   `sve-default-vector-length=256`
+
+   ```
+            r:    0   0   8   8   8   8  24  24  24  24  40  40  40  40  56  56  56  56  72  72  72  72  88  88  88  88 104 104 104 104 120 120
+   expected_r:    0   0   8   8  16  16  24  24  32  32  40  40  48  48  56  56  64  64  72  72  80  80  88  88  96  96 104 104 112 112 120 120
+                                      ^   ^           ^   ^           ^   ^           ^   ^           ^   ^           ^   ^           ^   ^        
+   idx:                               4   5           8   9          12  13          16  17          20  21          24  25          28  29     
+   ```
+4. By passing `-S` to the compiler, we can see that sdot (or udot if using `svdot_lane_u64()`) is produced in assembly (`sdot z0.d, z1.h, z2.h[0]`), which is correct behavior according to [Intrinsics – Arm Developer](https://developer.arm.com/architectures/instruction-sets/intrinsics/svdot_lane%5B_s64%5D).
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2604 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2604
new file mode 100644
index 00000000..54593f0c
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2604
@@ -0,0 +1,44 @@
+qemu-user-static crash when executing generated  NEON code due to failure to detect invalidation
+Description of problem:
+`qemu-arm-static` crashes 100% of times when attempting to run NEON code. The same executable, when run in `system` emulation mode, works without issue.
+
+I experience this particular issue when attempting to test GStreamer's Orc library with NEON codegen with QEMU user emulation.
+Steps to reproduce:
+1. Clone https://gitlab.freedesktop.org/gstreamer/orc.git
+2. Build with `meson setup build -Ddefault_library=static; meson compile -C build`
+3. Run `qemu-arm-static ./build/tools/orc-bugreport`
+Additional information:
+The crash always happens inside the same JIT code. It is not a memory access, so there is no reason for QEMU to report SIGSEGV:
+
+```
+Program received signal SIGSEGV, Segmentation fault.
+0x409e503c in ?? ()
+(gdb) bt
+#0  0x409e503c in ?? ()
+#1  0x00408bc6 in orc_executor_run (ex=0x51cfc0) at ../orc/orcexecutor.c:51
+#2  0x00489692 in orc_test_compare_output_full_for_target (program=0x4bcd90, flags=0, 
+    target_name=0x0) at ../orc-test/orctest.c:800
+#3  0x00489004 in orc_test_compare_output_full (program=0x4bcd90, flags=0)
+    at ../orc-test/orctest.c:664
+#4  0x00404826 in test_opcode_src (opcode=0x4b098c <opcodes+2400>)
+    at ../tools/orc-bugreport.c:252
+#5  0x004045d8 in test_opcodes () at ../tools/orc-bugreport.c:188
+#6  0x004043f2 in main (argc=1, argv=0x40800704) at ../tools/orc-bugreport.c:118
+(gdb) disas 0x409e5030
+No function contains specified address.
+(gdb) disas 0x409e5030, +10
+Dump of assembler code from 0x409e5030 to 0x409e503a:
+   0x409e5030:  vld1.8  {d4-d5}, [r3]
+   0x409e5034:  vst1.8  {d4-d5}, [r2]
+   0x409e5038:  add     r2, r2, #16
+End of assembler dump.
+(gdb) disas 0x409e5030, +20
+Dump of assembler code from 0x409e5030 to 0x409e5044:
+   0x409e5030:  vld1.8  {d4-d5}, [r3]
+   0x409e5034:  vst1.8  {d4-d5}, [r2]
+   0x409e5038:  add     r2, r2, #16
+=> 0x409e503c:  add     r3, r3, #16
+   0x409e5040:  subs    r12, r12, #1
+End of assembler dump.
+(gdb) 
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2610 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2610
new file mode 100644
index 00000000..b2d0b602
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2610
@@ -0,0 +1 @@
+pl011: incorrect IBRD_MASK and FBRD_MASK
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2625 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2625
new file mode 100644
index 00000000..a87f5d17
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2625
@@ -0,0 +1,83 @@
+Adding TPM support for ARM SBSA-Ref machine
+Additional information:
+Here is a proposed change where a new memory region is added to the machine initialization routine:
+
+```diff
+diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
+index e3195d5449..84bc7d9adb 100644
+--- a/hw/arm/sbsa-ref.c
++++ b/hw/arm/sbsa-ref.c
+@@ -28,6 +28,8 @@
+ #include "sysemu/numa.h"
+ #include "sysemu/runstate.h"
+ #include "sysemu/sysemu.h"
++#include "sysemu/tpm.h"
++#include "sysemu/tpm_backend.h"
+ #include "exec/hwaddr.h"
+ #include "kvm_arm.h"
+ #include "hw/arm/boot.h"
+@@ -94,6 +96,7 @@ enum {
+     SBSA_SECURE_MEM,
+     SBSA_AHCI,
+     SBSA_XHCI,
++    SBSA_TPM,
+ };
+ 
+ struct SBSAMachineState {
+@@ -132,6 +135,7 @@ static const MemMapEntry sbsa_ref_memmap[] = {
+     /* Space here reserved for more SMMUs */
+     [SBSA_AHCI] =               { 0x60100000, 0x00010000 },
+     [SBSA_XHCI] =               { 0x60110000, 0x00010000 },
++    [SBSA_TPM] =                { 0x60120000, 0x00010000 },
+     /* Space here reserved for other devices */
+     [SBSA_PCIE_PIO] =           { 0x7fff0000, 0x00010000 },
+     /* 32-bit address PCIE MMIO space */
+@@ -629,6 +633,24 @@ static void create_smmu(const SBSAMachineState *sms, PCIBus *bus)
+     }
+ }
+ 
++static void create_tpm(SBSAMachineState *sbsa, PCIBus *bus)
++{
++    Error *errp = NULL;
++    DeviceState *dev;
++
++    TPMBackend *be = qemu_find_tpm_be("tpm0");
++    if (be == NULL) {
++        error_report("Couldn't find tmp0 backend");
++        return;
++    }
++
++    dev = qdev_new(TYPE_TPM_TIS_SYSBUS);
++    object_property_set_link(OBJECT(dev), "tpmdev", OBJECT(be), &errp);
++    object_property_set_str(OBJECT(dev), "tpmdev", be->id, &errp);
++    sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
++    sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, sbsa_ref_memmap[SBSA_TPM].base);
++}
++
+ static void create_pcie(SBSAMachineState *sms)
+ {
+     hwaddr base_ecam = sbsa_ref_memmap[SBSA_PCIE_ECAM].base;
+@@ -686,6 +708,8 @@ static void create_pcie(SBSAMachineState *sms)
+     pci_create_simple(pci->bus, -1, "bochs-display");
+ 
+     create_smmu(sms, pci->bus);
++
++    create_tpm(sms, pci->bus);
+ }
+ 
+ static void *sbsa_ref_dtb(const struct arm_boot_info *binfo, int *fdt_size)
+```
+
+With such, the tpm can get used when setting the TPM base address to be 0x60120000 with the following launching command:
+
+```bash
+qemu-system-aarch64 -machine sbsa-ref,gic-version=3,acpi=off \
+  -cpu host -m 4G \
+  -nographic -accel kvm \
+  -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \
+  -tpmdev emulator,id=tpm0,chardev=chrtpm \
+  -device virtio-blk-pci,drive=drv0 \
+  -drive format=qcow2,file=hda.qcow2,if=none,id=drv0 \
+  -drive if=pflash,format=raw,file=flash0.img,readonly=on \
+  -drive if=pflash,format=raw,file=flash1.img
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2636 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2636
new file mode 100644
index 00000000..1cbec4bc
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2636
@@ -0,0 +1 @@
+ast2600 fails to run u-boot
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2652 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2652
new file mode 100644
index 00000000..a1d6bc5a
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2652
@@ -0,0 +1 @@
+qemu-user please allow to emulate aarch64 cpu in 32bits mode
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2656 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2656
new file mode 100644
index 00000000..2a28ab90
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2656
@@ -0,0 +1 @@
+impossible to specify pauth-impdef=on when specifying multiple accelerators
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/268 b/gitlab/issues_text/target_arm/host_missing/accel_missing/268
new file mode 100644
index 00000000..328c1ca9
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/268
@@ -0,0 +1 @@
+arm gic: gic_acknowledge_irq doesn't clear line level for other cores for 1-n level-sensitive interrupts and gic_clear_pending uses GIC_DIST_TEST_MODEL (even on v2 where it always read 0 - "N-N")
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2689 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2689
new file mode 100644
index 00000000..47c0c583
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2689
@@ -0,0 +1 @@
+arm64be tuxrun test is sometimes failing with I/O errors
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2698 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2698
new file mode 100644
index 00000000..0b7f0a12
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2698
@@ -0,0 +1,9 @@
+virtualization not working with TCG mode on macOS
+Description of problem:
+TCG is supposed to work with virtualization=on option but it stops without priting anything.
+if I set it to off, I can get to the prompt.
+Steps to reproduce:
+1. Execute the qemu
+2. Hung.
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2702 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2702
new file mode 100644
index 00000000..42af8bd8
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2702
@@ -0,0 +1,53 @@
+qtest-arm/sse-timer-test sometimes fails on s390x host
+Description of problem:
+The sse-timer-test sometimes fails on the s390x runner in Travis, see:
+
+https://app.travis-ci.com/github/huth/qemu/jobs/628508770#L6337 :
+
+```
+>>> G_TEST_DBUS_DAEMON=/home/travis/build/huth/qemu/tests/dbus-vmstate-daemon.sh MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MESON_TEST_ITERATION=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 PYTHON=/home/travis/build/huth/qemu/build/pyvenv/bin/python3 MALLOC_PERTURB_=165 QTEST_QEMU_BINARY=./qemu-system-arm /home/travis/build/huth/qemu/build/tests/qtest/sse-timer-test --tap -k
+
+▶  70/287 ERROR:../tests/qtest/sse-timer-test.c:91:test_counter: assertion failed (readl(COUNTER_BASE + CNTCV_LO) == 100): (0 == 100) ERROR         
+
+ 70/287 qemu:qtest+qtest-arm / qtest-arm/sse-timer-test                       ERROR            0.71s   killed by signal 6 SIGABRT
+
+――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
+
+stderr:
+
+**
+
+ERROR:../tests/qtest/sse-timer-test.c:91:test_counter: assertion failed (readl(COUNTER_BASE + CNTCV_LO) == 100): (0 == 100)
+
+(test program exited with status code -6)
+
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+```
+
+https://app.travis-ci.com/github/huth/qemu/jobs/628373181#L6336 :
+
+```
+>>> G_TEST_DBUS_DAEMON=/home/travis/build/huth/qemu/tests/dbus-vmstate-daemon.sh PYTHON=/home/travis/build/huth/qemu/build/pyvenv/bin/python3 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 QTEST_QEMU_BINARY=./qemu-system-arm MALLOC_PERTURB_=250 MESON_TEST_ITERATION=1 /home/travis/build/huth/qemu/build/tests/qtest/sse-timer-test --tap -k
+
+▶  70/287 ERROR:../tests/qtest/sse-timer-test.c:91:test_counter: assertion failed (readl(COUNTER_BASE + CNTCV_LO) == 100): (0 == 100) ERROR         
+
+ 70/287 qemu:qtest+qtest-arm / qtest-arm/sse-timer-test                       ERROR            0.95s   killed by signal 6 SIGABRT
+
+――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
+
+stderr:
+
+**
+
+ERROR:../tests/qtest/sse-timer-test.c:91:test_counter: assertion failed (readl(COUNTER_BASE + CNTCV_LO) == 100): (0 == 100)
+
+(test program exited with status code -6)
+
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+```
+Steps to reproduce:
+1. Run the QEMU CI on Travis
+Additional information:
+It seems to be a new or intermittent problem, two weeks ago it was still working fine:
+
+https://app.travis-ci.com/github/huth/qemu/jobs/627999506#L6325
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2708 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2708
new file mode 100644
index 00000000..1df2c73a
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2708
@@ -0,0 +1 @@
+aarch64 register MDCCINT_EL1 exhibits bizzare behavior
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2715 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2715
new file mode 100644
index 00000000..fb05256c
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2715
@@ -0,0 +1 @@
+QEMU AARCH64 only supports canonical addresses running on x64.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2718 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2718
new file mode 100644
index 00000000..72c4019c
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2718
@@ -0,0 +1,102 @@
+9.2.0 build failure: FAILED: libcommon.a.p/hw_intc_arm_gicv3_its.c.o
+Description of problem:
+Unable to build 9.2.0 via our docker container based builder inside a ChromeOS M97 based Docker container (using glibc 2.32).
+Steps to reproduce:
+1. See build logs. (I thought this was a vte issue, but libvte is the current version, `0.78.2`.)
+Additional information:
+```
+FAILED: libcommon.a.p/hw_intc_arm_gicv3_its.c.o 
+cc -m64 -Ilibcommon.a.p -I../common-user/host/x86_64 -I../linux-user/include/host/x86_64 -I../linux-user/include -Isubprojects/dtc/libfdt -I../subprojects/dtc/libfdt -Isubprojects/libvduse -I../subprojects/libvduse -I/usr/local/include/p11-kit-1 -I/usr/local/include/pixman-1 -I/usr/local/include/libpng16 -I/usr/local/include/libusb-1.0 -I/usr/local/include/SDL2 -I/usr/local/include/libmount -I/usr/local/include/blkid -I/usr/local/include/glib-2.0 -I/usr/local/lib64/glib-2.0/include -I/usr/local/include/gio-unix-2.0 -I/usr/local/include/slirp -I/usr/local/include/ncursesw -I/usr/local/include/gtk-3.0 -I/usr/local/include/at-spi2-atk/2.0 -I/usr/local/include/at-spi-2.0 -I/usr/local/include/dbus-1.0 -I/usr/local/lib64/dbus-1.0/include -I/usr/local/include/pango-1.0 -I/usr/local/include/harfbuzz -I/usr/local/include/fribidi -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/freetype2 -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/webp -I/usr/local/include/vte-2.91 -I/usr/local/include/pipewire-0.3 -I/usr/local/include/spa-0.2 -flto=auto -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -fstack-protector-strong -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit-fallthrough=2 -Winit-self -Wmissing-format-attribute -Wmissing-prototypes -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wredundant-decls -Wshadow=local -Wstrict-prototypes -Wtype-limits -Wundef -Wvla -Wwrite-strings -Wno-missing-include-dirs -Wno-psabi -Wno-shift-negative-value -isystem /usr/local/tmp/crew/qemu.20241211185452.dir/linux-headers -isystem linux-headers -iquote . -iquote /usr/local/tmp/crew/qemu.20241211185452.dir -iquote /usr/local/tmp/crew/qemu.20241211185452.dir/include -iquote /usr/local/tmp/crew/qemu.20241211185452.dir/host/include/x86_64 -iquote /usr/local/tmp/crew/qemu.20241211185452.dir/host/include/generic -iquote /usr/local/tmp/crew/qemu.20241211185452.dir/tcg/i386 -pthread -mcx16 -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -ftrivial-auto-var-init=zero -fzero-call-used-regs=used-gpr -O3 -pipe -ffat-lto-objects -fPIC -fuse-ld=mold -flto=auto -fPIE -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNCURSES_WIDECHAR=1 -D_REENTRANT -DSTRUCT_IOVEC_DEFINED -MD -MQ libcommon.a.p/hw_intc_arm_gicv3_its.c.o -MF libcommon.a.p/hw_intc_arm_gicv3_its.c.o.d -o libcommon.a.p/hw_intc_arm_gicv3_its.c.o -c ../hw/intc/arm_gicv3_its.c
+In file included from ../hw/intc/trace.h:1,
+                 from ../hw/intc/arm_gicv3_its.c:16:
+In function ‘_nocheck__trace_gicv3_its_dte_read’,
+    inlined from ‘trace_gicv3_its_dte_read’ at trace/trace-hw_intc.h:6634:9,
+    inlined from ‘get_dte’ at ../hw/intc/arm_gicv3_its.c:312:9,
+    inlined from ‘process_vmapti’ at ../hw/intc/arm_gicv3_its.c:680:9:
+../hw/intc/trace-events:222:13: error: ‘dte.ittaddr’ may be used uninitialized [-Werror=maybe-uninitialized]
+  222 | gicv3_its_dte_read(uint32_t devid, int valid, uint32_t size, uint64_t ittaddr) "GICv3 ITS: Device Table read for DeviceID 0x%x: valid %d size 0x%x ITTaddr 0x%" PRIx64
+      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../hw/intc/arm_gicv3_its.c: In function ‘process_vmapti’:
+../hw/intc/arm_gicv3_its.c:654:13: note: ‘dte.ittaddr’ was declared here
+  654 |     DTEntry dte;
+      |             ^~~
+In function ‘_nocheck__trace_gicv3_its_dte_read’,
+    inlined from ‘trace_gicv3_its_dte_read’ at trace/trace-hw_intc.h:6634:9,
+    inlined from ‘get_dte’ at ../hw/intc/arm_gicv3_its.c:312:9,
+    inlined from ‘process_vmapti’ at ../hw/intc/arm_gicv3_its.c:680:9:
+../hw/intc/trace-events:222:13: error: ‘dte.size’ may be used uninitialized [-Werror=maybe-uninitialized]
+  222 | gicv3_its_dte_read(uint32_t devid, int valid, uint32_t size, uint64_t ittaddr) "GICv3 ITS: Device Table read for DeviceID 0x%x: valid %d size 0x%x ITTaddr 0x%" PRIx64
+      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../hw/intc/arm_gicv3_its.c: In function ‘process_vmapti’:
+../hw/intc/arm_gicv3_its.c:654:13: note: ‘dte.size’ was declared here
+  654 |     DTEntry dte;
+      |             ^~~
+In function ‘_nocheck__trace_gicv3_its_dte_read’,
+    inlined from ‘trace_gicv3_its_dte_read’ at trace/trace-hw_intc.h:6634:9,
+    inlined from ‘get_dte’ at ../hw/intc/arm_gicv3_its.c:312:9,
+    inlined from ‘process_mapti’ at ../hw/intc/arm_gicv3_its.c:608:9:
+../hw/intc/trace-events:222:13: error: ‘dte.ittaddr’ may be used uninitialized [-Werror=maybe-uninitialized]
+  222 | gicv3_its_dte_read(uint32_t devid, int valid, uint32_t size, uint64_t ittaddr) "GICv3 ITS: Device Table read for DeviceID 0x%x: valid %d size 0x%x ITTaddr 0x%" PRIx64
+      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../hw/intc/arm_gicv3_its.c: In function ‘process_mapti’:
+../hw/intc/arm_gicv3_its.c:586:13: note: ‘dte.ittaddr’ was declared here
+  586 |     DTEntry dte;
+      |             ^~~
+In function ‘_nocheck__trace_gicv3_its_dte_read’,
+    inlined from ‘trace_gicv3_its_dte_read’ at trace/trace-hw_intc.h:6634:9,
+    inlined from ‘get_dte’ at ../hw/intc/arm_gicv3_its.c:312:9,
+    inlined from ‘process_mapti’ at ../hw/intc/arm_gicv3_its.c:608:9:
+../hw/intc/trace-events:222:13: error: ‘dte.size’ may be used uninitialized [-Werror=maybe-uninitialized]
+  222 | gicv3_its_dte_read(uint32_t devid, int valid, uint32_t size, uint64_t ittaddr) "GICv3 ITS: Device Table read for DeviceID 0x%x: valid %d size 0x%x ITTaddr 0x%" PRIx64
+      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../hw/intc/arm_gicv3_its.c: In function ‘process_mapti’:
+../hw/intc/arm_gicv3_its.c:586:13: note: ‘dte.size’ was declared here
+  586 |     DTEntry dte;
+      |             ^~~
+In function ‘lookup_vte’,
+    inlined from ‘vmovp_callback’ at ../hw/intc/arm_gicv3_its.c:1036:14:
+../hw/intc/arm_gicv3_its.c:459:8: error: ‘vte.rdbase’ may be used uninitialized [-Werror=maybe-uninitialized]
+  459 |     if (vte->rdbase >= s->gicv3->num_cpu) {
+      |        ^
+../hw/intc/arm_gicv3_its.c: In function ‘vmovp_callback’:
+../hw/intc/arm_gicv3_its.c:1033:13: note: ‘vte.rdbase’ was declared here
+ 1033 |     VTEntry vte;
+      |             ^~~
+In function ‘_nocheck__trace_gicv3_its_vte_write’,
+    inlined from ‘trace_gicv3_its_vte_write’ at trace/trace-hw_intc.h:6789:9,
+    inlined from ‘update_vte’ at ../hw/intc/arm_gicv3_its.c:944:5,
+    inlined from ‘vmovp_callback’ at ../hw/intc/arm_gicv3_its.c:1051:10:
+../hw/intc/trace-events:227:13: error: ‘vte.vptaddr’ may be used uninitialized [-Werror=maybe-uninitialized]
+  227 | gicv3_its_vte_write(uint32_t vpeid, int valid, uint32_t vptsize, uint64_t vptaddr, uint32_t rdbase) "GICv3 ITS: vPE Table write for vPEID 0x%x: valid %d VPTsize 0x%x VPTaddr 0x%" PRIx64 " RDbase 0x%x"
+      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../hw/intc/arm_gicv3_its.c: In function ‘vmovp_callback’:
+../hw/intc/arm_gicv3_its.c:1033:13: note: ‘vte.vptaddr’ was declared here
+ 1033 |     VTEntry vte;
+      |             ^~~
+In function ‘_nocheck__trace_gicv3_its_vte_write’,
+    inlined from ‘trace_gicv3_its_vte_write’ at trace/trace-hw_intc.h:6789:9,
+    inlined from ‘update_vte’ at ../hw/intc/arm_gicv3_its.c:944:5,
+    inlined from ‘vmovp_callback’ at ../hw/intc/arm_gicv3_its.c:1051:10:
+../hw/intc/trace-events:227:13: error: ‘vte.vptsize’ may be used uninitialized [-Werror=maybe-uninitialized]
+  227 | gicv3_its_vte_write(uint32_t vpeid, int valid, uint32_t vptsize, uint64_t vptaddr, uint32_t rdbase) "GICv3 ITS: vPE Table write for vPEID 0x%x: valid %d VPTsize 0x%x VPTaddr 0x%" PRIx64 " RDbase 0x%x"
+      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../hw/intc/arm_gicv3_its.c: In function ‘vmovp_callback’:
+../hw/intc/arm_gicv3_its.c:1033:13: note: ‘vte.vptsize’ was declared here
+ 1033 |     VTEntry vte;
+      |             ^~~
+In function ‘lookup_vte’,
+    inlined from ‘vmovp_callback’ at ../hw/intc/arm_gicv3_its.c:1036:14:
+../hw/intc/arm_gicv3_its.c:453:13: error: ‘MEM <unsigned char> [(struct VTEntry *)&vte]’ may be used uninitialized [-Werror=maybe-uninitialized]
+  453 |     if (!vte->valid) {
+      |          ~~~^~~~~~~
+../hw/intc/arm_gicv3_its.c: In function ‘vmovp_callback’:
+../hw/intc/arm_gicv3_its.c:1033:13: note: ‘MEM <unsigned char> [(struct VTEntry *)&vte]’ was declared here
+ 1033 |     VTEntry vte;
+      |             ^~~
+cc1: all warnings being treated as errors
+
+```
+
+Full Build log:
+
+[qemu-build-log.zip](/uploads/db227e4a6bbbcfccd0e1e3ccaacf1aec/qemu-build-log.zip)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2721 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2721
new file mode 100644
index 00000000..99e8e301
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2721
@@ -0,0 +1 @@
+Failure with macOS 15.2 on ARM64: Property 'host-arm-cpu.sme' not found
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2725 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2725
new file mode 100644
index 00000000..3fe904ba
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2725
@@ -0,0 +1 @@
+multi-arch build at AMD64 for ARM64 fails without flag "F"
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2729 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2729
new file mode 100644
index 00000000..cebbfa18
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2729
@@ -0,0 +1,74 @@
+qemu-system-aarch64 -M raspi4b -- no valid DTB provided in x0 register
+Description of problem:
+When starting `qemu-system-aarch64 -M raspi4b`, no valid DTB is provided in x0.
+Steps to reproduce:
+Make a simple binary to loop forever
+
+```
+$ cat loop.c
+void _start(void)
+{
+	for(;;)
+		;
+}
+$ aarch64-linux-gnu-gcc loop.c -nostdlib
+$ aarch64-linux-gnu-objcopy -O binary a.out loop.bin
+```
+
+Start qemu for debugging and start gdb
+
+```
+$ qemu-system-aarch64 -S -s -M raspi4b -kernel loop.bin
+# in another terminal
+$ aarch64-linux-gnu-gdb
+(gdb) target remote :1234
+Remote debugging using :1234
+warning: No executable has been specified and target does not support
+determining executable automatically.  Try using the "file" command.
+0x0000000000000000 in ?? ()
+(gdb) watch *$x0
+Watchpoint 3: *$x0
+(gdb) watch $x0
+Watchpoint 4: $x0
+(gdb) x/2x$x0
+0x0:	0x580000c0	0xaa1f03e1
+(gdb) si
+
+Thread 1 hit Watchpoint 3: *$x0
+
+Old value = 1476395200
+New value = 5
+
+Thread 1 hit Watchpoint 4: $x0
+
+Old value = 0
+New value = 256
+0x0000000000000004 in ?? ()
+(gdb) x/2x$x0
+0x100:	0x00000005	0x54410001
+(gdb) si
+0x0000000000000008 in ?? ()
+(gdb) si
+0x000000000000000c in ?? ()
+(gdb) si
+0x000000000000000c in ?? ()
+(gdb) si
+0x0000000000000010 in ?? ()
+(gdb) si
+0x0000000000000014 in ?? ()
+(gdb) si
+0x0000000000080000 in ?? ()
+(gdb) si
+0x0000000000000200 in ?? ()
+(gdb) si
+0x0000000000000200 in ?? ()
+(gdb) si
+0x0000000000000200 in ?? ()
+(gdb) si
+0x0000000000000200 in ?? ()
+(gdb) x/2x$x0
+0x100:	0x00000005	0x54410001
+(gdb) 
+```
+
+Note that at no time is a valid DTB provided in x0. I expected to see the DTB magic 0xd00dfeed (or 0xedfe0dd0) at the memory pointed to by x0
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2733 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2733
new file mode 100644
index 00000000..e4bfaf96
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2733
@@ -0,0 +1,12 @@
+-machine raspi4b won't dump dtb
+Description of problem:
+the raspi4b machine won't dump tdb
+Steps to reproduce:
+```
+$ qemu-system-aarch64 -machine virt -machine dumpdtb=p.dmp
+qemu-system-aarch64: info: dtb dumped to p.dmp. Exiting.
+$ qemu-system-aarch64 -machine raspi4b -machine dumpdtb=p.dmp
+```
+notice no dtb is dumped for the raspi4b machine
+Additional information:
+see also https://gitlab.com/qemu-project/qemu/-/issues/2729
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2734 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2734
new file mode 100644
index 00000000..3ff97dc7
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2734
@@ -0,0 +1,24 @@
+many aarch64 machines exit with "fatal: Lockup: can't escalate 3 to HardFault"
+Description of problem:
+`-machine netduino2` and `-machine microbit` and many others dump core
+Steps to reproduce:
+```
+qemu-system-aarch64 -machine netduino2
+qemu-system-aarch64 -machine microbit
+...
+$ for x in microbit netduino2 b-l475e-iot01a emcraft-sf2 fby35-bmc lm3s6965evb lm3s811evb musca-a musca-b1 netduinoplus2 olimex-stm32-h405 stm32vldiscovery
+do qemu-system-aarch64 -machine $x
+done
+```
+and all the `mps2-*` machines all result in 
+```
+qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
+
+R00=00000000 R01=00000000 R02=00000000 R03=00000000
+R04=00000000 R05=00000000 R06=00000000 R07=00000000
+R08=00000000 R09=00000000 R10=00000000 R11=00000000
+R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000
+XPSR=40000003 -Z-- A handler
+FPSCR: 00000000
+Aborted (core dumped)
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2760 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2760
new file mode 100644
index 00000000..c352d97c
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2760
@@ -0,0 +1 @@
+Some Aarch64 system registers not available via the debugger
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2792 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2792
new file mode 100644
index 00000000..260321ab
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2792
@@ -0,0 +1,70 @@
+qemu-system-aarch64 segfault at startup with --enable-rust
+Description of problem:
+The following commit breaks type class initialization for `pl011_luminary`:
+
+```
+d9434f29ca83e114fe02ed24c8ad2ccfa7ac3fe9 is the first bad commit
+commit d9434f29ca83e114fe02ed24c8ad2ccfa7ac3fe9
+Author: Paolo Bonzini <pbonzini@redhat.com>
+Date:   Fri Nov 29 11:38:59 2024 +0100
+
+    rust: qom: move device_id to PL011 class side
+
+    There is no need to monkeypatch DeviceId::Luminary into the already-initialized
+    PL011State.  Instead, now that we can define a class hierarchy, we can define
+    PL011Class and make device_id a field in there.
+
+    There is also no need anymore to have "Arm" as zero, so change DeviceId into a
+    wrapper for the array; all it does is provide an Index<hwaddr> implementation
+    because arrays can only be indexed by usize.
+
+    Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
+    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+
+ rust/hw/char/pl011/src/device.rs | 59 +++++++++++++++++++---------------------
+ 1 file changed, 28 insertions(+), 31 deletions(-)
+bisect found first bad commit
+```
+
+It results in a segmentation fault during type initialization at startup:
+
+```
+$ ./build/qemu-system-aarch64 -machine help
+zsh: segmentation fault (core dumped)  ./build/qemu-system-aarch64 -machine help
+```
+
+Because the class is uninitialized on the `pl011_luminary` TypeInfo (I think):
+
+```
+$ gdb --args ./build/qemu-system-aarch64 -machine help
+...
+Thread 1 "qemu-system-aar" received signal SIGSEGV, Segmentation fault.
+0x0000555555fc0fcf in object_class_dynamic_cast (class=class@entry=0x5555575ca128, typename=typename@entry=0x5555562650cd "resettable") at ../qom/object.c:966
+966         if (type->class->interfaces &&
+(gdb) p type->class
+$1 = (ObjectClass *) 0x0
+(gdb) bt
+#0  0x0000555555fc0fcf in object_class_dynamic_cast (class=class@entry=0x5555575ca128, typename=typename@entry=0x5555562650cd "resettable") at ../qom/object.c:966
+#1  0x0000555555fc1473 in object_class_dynamic_cast_assert (class=class@entry=0x5555575ca128, typename=typename@entry=0x5555562650cd "resettable",
+    file=file@entry=0x5555562651a0 "/home/pdel/qemu/include/hw/resettable.h", line=line@entry=21, func=func@entry=0x55555643d2b0 <__func__.13> "RESETTABLE_CLASS") at ../qom/object.c:1016
+#2  0x0000555555fbc61b in RESETTABLE_CLASS (klass=0x5555575ca128) at /home/pdel/qemu/include/hw/resettable.h:21
+#3  device_class_set_legacy_reset (dc=0x5555575ca128, dev_reset=0x5555560dacb0 <qemu_api::qdev::rust_reset_fn>) at ../hw/core/qdev.c:790
+#4  0x00005555560dac03 in qemu_api::qdev::<impl qemu_api::qom::ClassInitImpl<qemu_api::bindings::DeviceClass> for T>::class_init (dc=0x5555575ca128)
+    at rust/qemu-api/libqemu_api.rlib.p/structured/qdev.rs:84
+#5  qemu_api::sysbus::<impl qemu_api::qom::ClassInitImpl<qemu_api::bindings::SysBusDeviceClass> for T>::class_init (sdc=0x5555575ca128) at rust/qemu-api/libqemu_api.rlib.p/structured/sysbus.rs:31
+#6  <pl011::device::PL011State as qemu_api::qom::ClassInitImpl<pl011::device::PL011Class>>::class_init (klass=0x5555575ca120) at ../rust/hw/char/pl011/src/device.rs:140
+#7  qemu_api::qom::rust_class_init (klass=0x5555575ca120, _data=<optimized out>) at rust/qemu-api/libqemu_api.rlib.p/structured/qom.rs:176
+#8  0x0000555555fc0930 in type_initialize (ti=0x555557555eb0) at ../qom/object.c:359
+#9  type_initialize (ti=ti@entry=0x555557556070) at ../qom/object.c:365
+#10 0x0000555555fc1190 in type_initialize (ti=0x555557556070) at ../qom/object.c:1122
+#11 object_class_foreach_tramp (key=<optimized out>, value=0x555557556070, opaque=0x7fffffffdd00) at ../qom/object.c:1110
+#12 0x00007ffff7528668 in g_hash_table_foreach () from /lib64/libglib-2.0.so.0
+#13 0x0000555555fc1931 in object_class_foreach (opaque=0x7fffffffdcf8, include_abstract=false, implements_type=<optimized out>, fn=0x555555fbf810 <object_class_get_list_tramp>) at ../qom/object.c:87
+#14 object_class_get_list (implements_type=implements_type@entry=0x5555562c5440 "machine", include_abstract=include_abstract@entry=false) at ../qom/object.c:1189
+#15 0x0000555555bf53ac in machine_help_func (qdict=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at ../system/vl.c:1559
+#16 qemu_init (argc=3, argv=<optimized out>) at ../system/vl.c:3319
+#17 0x00005555558f1a89 in main (argc=<optimized out>, argv=<optimized out>) at ../system/main.c:68
+```
+Steps to reproduce:
+1. Checkout cf86770c7aa31ebd6e56f4eeb25c34107f92c51e
+2. `./configure --target-list=aarch64-softmmu --enable-rust && ninja -C build && ./build/qemu-system-aarch64 -machine help`
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2797 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2797
new file mode 100644
index 00000000..c25aa1e1
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2797
@@ -0,0 +1,3 @@
+arm/raspi.c - incease memory limit
+Additional information:
+I can attempt to make a PR that increases this limit, but not sure if others would find it useful.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2861 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2861
new file mode 100644
index 00000000..f34d3e7b
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2861
@@ -0,0 +1,7 @@
+hw/pci-host/designware.c incorrect write to DESIGNWARE_PCIE_ATU_UPPER_TARGET register
+Description of problem:
+I think this is a obvious bug
+
+https://gitlab.com/qemu-project/qemu/-/blob/master/hw/pci-host/designware.c?ref_type=heads#L374
+
+Write to register DESIGNWARE_PCIE_ATU_UPPER_TARGET, val should be shifted left to update upper 32 bit part.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2870 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2870
new file mode 100644
index 00000000..9c2bcb73
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2870
@@ -0,0 +1 @@
+How to Create BE32-Type Instruction Emulation
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2886 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2886
new file mode 100644
index 00000000..3c58f990
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2886
@@ -0,0 +1,15 @@
+ACPI MADT advertises GITS even when disabled
+Description of problem:
+As per the command line given above, QEMU shall emulate a GICv4 without GIC Interrupt Translation Service (GITS).
+
+The following happens:
+- ACPI **incorrectly** lists a GITS (type 0xf) structure in the MADT with GITS MMIO Base = 0x8080000
+- The OS reads that structure and interprets it to mean a GITS is present at the given MMIO address
+- Subsequent access to GITS MMIO causes a data abort (0x25) because QEMU doesn't emulate a GITS (as requested)
+
+The bug is thus that QEMU wrongly advertises GITS as present (via the MADT) when it is in fact absent.
+Steps to reproduce:
+1. Disable GITS emulation by passing `its=off` on the QEMU command line
+2. Check if a GITS structure is listed in the ACPI MADT (must be present in ACPI MADT only if GITS is enabled and absent otherwise)
+Additional information:
+When booting with `its=on` (default), everything works as expected.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2896 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2896
new file mode 100644
index 00000000..4abb80cf
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2896
@@ -0,0 +1 @@
+How to enable MPU support on Cortex-R5F?
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2898 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2898
new file mode 100644
index 00000000..6f0618fb
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2898
@@ -0,0 +1,115 @@
+-M virt,dumpdtb is missing information from the device tree
+Description of problem:
+dumpdtb no longer produces a device tree with the full system described.
+
+
+```
+$ dtc -I dtb -O dts test.dtb
+<stdout>: Warning (unit_address_vs_reg): /soc/pci@30000000: node has a unit name, but no reg or ranges property
+<stdout>: Warning (simple_bus_reg): /soc/pci@30000000: missing or empty reg/ranges property
+/dts-v1/;
+
+/ {
+	#address-cells = <0x02>;
+	#size-cells = <0x02>;
+	compatible = "riscv-virtio";
+	model = "riscv-virtio,qemu";
+
+	pmu {
+		riscv,event-to-mhpmcounters = <0x01 0x01 0x7fff9 0x02 0x02 0x7fffc 0x10019 0x10019 0x7fff8 0x1001b 0x1001b 0x7fff8 0x10021 0x10021 0x7fff8>;
+		compatible = "riscv,pmu";
+	};
+
+	fw-cfg@10100000 {
+		dma-coherent;
+		reg = <0x00 0x10100000 0x00 0x18>;
+		compatible = "qemu,fw-cfg-mmio";
+	};
+
+	flash@20000000 {
+		bank-width = <0x04>;
+		reg = <0x00 0x20000000 0x00 0x2000000 0x00 0x22000000 0x00 0x2000000>;
+		compatible = "cfi-flash";
+	};
+
+	aliases {
+	};
+
+	chosen {
+		rng-seed = <0xd4266784 0xc7a7c66f 0xd5b7347d 0x862188f3 0x78065a8e 0xebdedae5 0xd77c47b0 0x34d31eff>;
+	};
+
+	soc {
+		#address-cells = <0x02>;
+		#size-cells = <0x02>;
+		compatible = "simple-bus";
+		ranges;
+
+		pci@30000000 {
+		};
+	};
+};
+```
+Steps to reproduce:
+1. qemu-system-riscv64 -machine virt,dumpdtb=test.dtb
+2. dtc -I dtb -O dts test.dtb
+Additional information:
+The regression was introduced in https://gitlab.com/qemu-project/qemu/-/commit/8fd2518ef2f8d. If this commit is reverted, the expected behavior returns.
+
+```
+dtc -I dtb -O dts test.dtb | grep "@"
+	platform-bus@4000000 {
+	memory@80000000 {
+		cpu@0 {
+	fw-cfg@10100000 {
+	flash@20000000 {
+		serial0 = "/soc/serial@10000000";
+		stdout-path = "/soc/serial@10000000";
+		rtc@101000 {
+		serial@10000000 {
+			clock-frequency = "", "8@";
+		test@100000 {
+		virtio_mmio@10008000 {
+		virtio_mmio@10007000 {
+		virtio_mmio@10006000 {
+		virtio_mmio@10005000 {
+		virtio_mmio@10004000 {
+		virtio_mmio@10003000 {
+		virtio_mmio@10002000 {
+		virtio_mmio@10001000 {
+		plic@c000000 {
+		clint@2000000 {
+		pci@30000000 {
+```
+
+Other machines are affected to a lesser degree. The arm virt machine:
+
+qemu-system-arm -machine virt,dumpdtb=test.dtb
+```
+@@ -8,28 +8,6 @@
+ 	#address-cells = <0x02>;
+ 	compatible = "linux,dummy-virt";
+
+-	psci {
+-		migrate = <0x84000005>;
+-		cpu_on = <0x84000003>;
+-		cpu_off = <0x84000002>;
+-		cpu_suspend = <0x84000001>;
+-		method = "hvc";
+-		compatible = "arm,psci-1.0", "arm,psci-0.2", "arm,psci";
+-	};
+-
+-	memory@40000000 {
+-		reg = <0x00 0x40000000 0x00 0x8000000>;
+-		device_type = "memory";
+-	};
+-
+-	platform-bus@c000000 {
+-		interrupt-parent = <0x8002>;
+-		ranges = <0x00 0x00 0xc000000 0x2000000>;
+-		#address-cells = <0x01>;
+-		#size-cells = <0x01>;
+-		compatible = "qemu,platform", "simple-bus";
+-	};
+-
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2910 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2910
new file mode 100644
index 00000000..8d8fa6da
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2910
@@ -0,0 +1,5 @@
+SME2 support for aarch64?
+Additional information:
+We've noticed that most `SME2` instructions work, despite `ARM_HWCAP2_A64_SME2` not being set.
+
+Cheers, Pedro
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2916 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2916
new file mode 100644
index 00000000..92a0df13
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2916
@@ -0,0 +1,26 @@
+qemu-system-arm hangs when attempting to enable MMU on Cortex-A7
+Description of problem:
+QEMU 9.x.x+ hangs when attempting to do enable the MMU from SCTLRL - M bit: https://developer.arm.com/documentation/ddi0601/2025-03/AArch32-Registers/SCTLR--System-Control-Register
+
+The instruction that hangs is the writing of the SCTLR register:
+
+```
+mrc     p15, 0, r0, c1, c0, 0
+orr     r0, r0, 1
+mcr     p15, 0, r0, c1, c0, 0
+```
+
+I am attempting to enable unaligned accesses and SCTLR-A bit doesn't seem to have any effect if the SCTLR-M is not enabled. Doing an unaligned access on cortex-a7 should be supported but it always trigger a Fault.
+Steps to reproduce:
+1. add the mrc/orr/mcr instruction sequence in the ResetHandler
+2. link the elf
+3. attempt to execute it
+Additional information:
+The unaligned access looked like it was working in QEMU 8.x.x but it might not have been emulated(?). I also am facing the same issues with MCR hanging and unaligned access not supported with latest 10.0.0-RC2.
+
+When it hangs, QEMU has to be killed and terminal reset.
+
+There might be two separate issues here:
+
+1. writing SCTLR register
+2. emulated cortex-a7 not supporting unaligned access (hardware supports it)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2917 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2917
new file mode 100644
index 00000000..be87e11a
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2917
@@ -0,0 +1,22 @@
+build failure because of warnings when -O3 is used
+Description of problem:
+qemu build fails when -O3 is enabled and the build is done either from a git cloned qemu or with -Werror enabled (qemu build enables -Werror automatically when it detects the .git folder)
+Steps to reproduce:
+1. git clone qemu && install appropriate dependencies for qemu build
+2. mkdir build
+3. ../configure --extra-cflags="-O3"
+4. make -j$(nbproc)
+
+```
+cc -m64 -Ilibcommon.a.p -I../common-user/host/x86_64 -I../linux-user/include/host/x86_64 -I../linux-user/include -Isubprojects/libvduse -I../subprojects/libvduse -I/usr/include/p11-kit-1 -I/usr/include/pixman-1 -I/usr/include/libpng16 -I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/libusb-1.0 -I/usr/include/SDL2 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/sysprof-6 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -I/usr/include/slirp -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/x86_64-linux-gnu -I/usr/include/webp -I/usr/include/atk-1.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/vte-2.91 -I/usr/include/virgl -I/usr/include/cacard -I/usr/include/nss -I/usr/include/nspr -I/usr/include/PCSC -I/usr/include/pipewire-0.3 -I/usr/include/spa-0.2 -I/usr/include/fuse3 -I/usr/include/uuid -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -fstack-protector-strong -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit-fallthrough=2 -Winit-self -Wmissing-format-attribute -Wmissing-prototypes -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wredundant-decls -Wshadow=local -Wstrict-prototypes -Wtype-limits -Wundef -Wvla -Wwrite-strings -Wno-missing-include-dirs -Wno-psabi -Wno-shift-negative-value -isystem /home/ubuntu/qemu/linux-headers -isystem linux-headers -iquote . -iquote /home/ubuntu/qemu -iquote /home/ubuntu/qemu/include -iquote /home/ubuntu/qemu/host/include/x86_64 -iquote /home/ubuntu/qemu/host/include/generic -iquote /home/ubuntu/qemu/tcg/i386 -pthread -mcx16 -msse2 -D_GNU_SOURCE -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -ftrivial-auto-var-init=zero -fzero-call-used-regs=used-gpr -O3 -fPIE -D_FILE_OFFSET_BITS=64 -D__USE_FILE_OFFSET64 -D__USE_LARGEFILE64 -DUSE_POSIX_ACLS=1 -isystem /usr/include/mit-krb5 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNCURSES_WIDECHAR=1 -D_REENTRANT -DSTRUCT_IOVEC_DEFINED -MD -MQ libcommon.a.p/hw_ssi_xilinx_spips.c.o -MF libcommon.a.p/hw_ssi_xilinx_spips.c.o.d -o libcommon.a.p/hw_ssi_xilinx_spips.c.o -c ../hw/ssi/xilinx_spips.c
+../hw/ssi/xilinx_spips.c: In function ‘xilinx_spips_flush_txfifo’:
+../hw/ssi/xilinx_spips.c:624:30: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
+  624 |                     tx_rx[i] = fifo8_pop(&s->tx_fifo);
+      |                     ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
+../hw/ssi/xilinx_spips.c:613:17: note: at offset 2 into destination object ‘tx_rx’ of size 2
+  613 |         uint8_t tx_rx[MAX_NUM_BUSSES] = { 0 };
+      |                 ^~~~~
+cc1: all warnings being treated as errors
+```
+Additional information:
+I fixed this warning locally on my build however it is only a start of several build warnings that happen down the road (\~6 warnings in total)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2921 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2921
new file mode 100644
index 00000000..b08ad225
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2921
@@ -0,0 +1,368 @@
+Aarch64 reverse debugging test is unreliable
+Description of problem:
+The reverse-debugging test for the aarch64 target is not working reliably, especially if the host system is under load, approx. 1 or 2 out of 10 test runs fail. The log looks like this:
+
+```
+2025-04-14 10:24:35,042 test             L0310 INFO | INIT 1-ReverseDebugging_AArch64.test_aarch64_virt
+2025-04-14 10:24:35,043 parameters       L0142 DEBUG| PARAMS (key=timeout, path=*, default=10) => 10
+2025-04-14 10:24:35,043 test             L0338 DEBUG| Test metadata:
+2025-04-14 10:24:35,043 test             L0340 DEBUG|   filename: /.../tmp/qemu-build/tests/avocado/reverse_debugging.py
+2025-04-14 10:24:35,044 test             L0346 DEBUG|   teststmpdir: /var/tmp/avocado_w5d2bkam
+2025-04-14 10:24:35,044 test             L0536 INFO | START 1-ReverseDebugging_AArch64.test_aarch64_virt
+2025-04-14 10:24:35,044 test             L0207 DEBUG| DATA (filename=output.expected) => NOT FOUND (data sources: variant, test, file)
+2025-04-14 10:24:35,045 parameters       L0142 DEBUG| PARAMS (key=arch, path=*, default=aarch64) => 'aarch64'
+2025-04-14 10:24:35,045 parameters       L0142 DEBUG| PARAMS (key=cpu, path=*, default=cortex-a53) => 'cortex-a53'
+2025-04-14 10:24:35,046 parameters       L0142 DEBUG| PARAMS (key=qemu_bin, path=*, default=./qemu-system-aarch64) => './qemu-system-aarch64'
+2025-04-14 10:24:35,272 parameters       L0142 DEBUG| PARAMS (key=machine, path=*, default=virt) => 'virt'
+2025-04-14 10:24:35,290 test             L0465 DEBUG| Test workdir initialized at: /var/tmp/.avocado-taskky_yb2qf/test-results/tmp_dir56wqq7g0/1-ReverseDebugging_AArch64.test_aarch64_virt
+2025-04-14 10:24:35,290 process          L0658 INFO | Running '/.../tmp/qemu-build/qemu-img create -f qcow2 /var/tmp/.avocado-taskky_yb2qf/test-results/tmp_dir56wqq7g0/1-ReverseDebugging_AArch64.test_aarch64_virt/disk.qcow2 128M'
+2025-04-14 10:24:35,347 process          L0470 DEBUG| [stdout] Formatting '/var/tmp/.avocado-taskky_yb2qf/test-results/tmp_dir56wqq7g0/1-ReverseDebugging_AArch64.test_aarch64_virt/disk.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=134217728 lazy_refcounts=off refcount_bits=16
+2025-04-14 10:24:35,393 process          L0739 INFO | Command '/.../tmp/qemu-build/qemu-img create -f qcow2 /var/tmp/.avocado-taskky_yb2qf/test-results/tmp_dir56wqq7g0/1-ReverseDebugging_AArch64.test_aarch64_virt/disk.qcow2 128M' finished with 0 after 0.100170269s
+2025-04-14 10:24:35,475 __init__         L0314 DEBUG| QEMUMachine "28fc0d7d-bd0a-44c0-afa8-f24a1800132f" created
+2025-04-14 10:24:35,475 __init__         L0315 DEBUG| QEMUMachine "28fc0d7d-bd0a-44c0-afa8-f24a1800132f" temp_dir: /var/tmp/.avocado-taskky_yb2qf/test-results/tmp_dir56wqq7g0/1-ReverseDebugging_AArch64.test_aarch64_virt/qemu-machine-052_8e_k
+2025-04-14 10:24:35,475 __init__         L0316 DEBUG| QEMUMachine "28fc0d7d-bd0a-44c0-afa8-f24a1800132f" log_dir: /var/tmp/.avocado-taskky_yb2qf/test-results/1-ReverseDebugging_AArch64.test_aarch64_virt
+2025-04-14 10:24:36,195 __init__         L0314 DEBUG| QEMUMachine "3f348d83-7aa3-4381-9919-389bc85ed85b" created
+2025-04-14 10:24:36,196 __init__         L0315 DEBUG| QEMUMachine "3f348d83-7aa3-4381-9919-389bc85ed85b" temp_dir: /var/tmp/.avocado-taskky_yb2qf/test-results/tmp_dir56wqq7g0/1-ReverseDebugging_AArch64.test_aarch64_virt/qemu-machine-vxlortdq
+2025-04-14 10:24:36,196 __init__         L0316 DEBUG| QEMUMachine "3f348d83-7aa3-4381-9919-389bc85ed85b" log_dir: /var/tmp/.avocado-taskky_yb2qf/test-results/1-ReverseDebugging_AArch64.test_aarch64_virt
+2025-04-14 10:24:37,623 stacktrace       L0039 ERROR| 
+2025-04-14 10:24:37,628 stacktrace       L0041 ERROR| Reproduced traceback from: /usr/lib/python3.13/site-packages/avocado/core/test.py:793
+2025-04-14 10:24:37,643 stacktrace       L0045 ERROR| Traceback (most recent call last):
+2025-04-14 10:24:37,643 stacktrace       L0045 ERROR|   File "/usr/lib/python3.13/site-packages/avocado/core/decorators.py", line 90, in wrapper
+2025-04-14 10:24:37,643 stacktrace       L0045 ERROR|     return function(obj, *args, **kwargs)
+2025-04-14 10:24:37,643 stacktrace       L0045 ERROR|   File "/.../tmp/qemu-build/tests/avocado/reverse_debugging.py", line 239, in test_aarch64_virt
+2025-04-14 10:24:37,644 stacktrace       L0045 ERROR|     self.reverse_debugging(
+2025-04-14 10:24:37,644 stacktrace       L0045 ERROR|     ~~~~~~~~~~~~~~~~~~~~~~^
+2025-04-14 10:24:37,644 stacktrace       L0045 ERROR|         args=('-kernel', kernel_path))
+2025-04-14 10:24:37,644 stacktrace       L0045 ERROR|         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,644 stacktrace       L0045 ERROR|   File "/.../tmp/qemu-build/tests/avocado/reverse_debugging.py", line 179, in reverse_debugging
+2025-04-14 10:24:37,644 stacktrace       L0045 ERROR|     if self.vm_get_icount(vm) == last_icount - 1:
+2025-04-14 10:24:37,644 stacktrace       L0045 ERROR|        ~~~~~~~~~~~~~~~~~~^^^^
+2025-04-14 10:24:37,644 stacktrace       L0045 ERROR|   File "/.../tmp/qemu-build/tests/avocado/reverse_debugging.py", line 100, in vm_get_icount
+2025-04-14 10:24:37,644 stacktrace       L0045 ERROR|     return vm.qmp('query-replay')['return']['icount']
+2025-04-14 10:24:37,644 stacktrace       L0045 ERROR|            ~~~~~~^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,645 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/machine/machine.py", line 711, in qmp
+2025-04-14 10:24:37,645 stacktrace       L0045 ERROR|     ret = self._qmp.cmd_raw(cmd, args=qmp_args)
+2025-04-14 10:24:37,645 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 208, in cmd_raw
+2025-04-14 10:24:37,645 stacktrace       L0045 ERROR|     return self.cmd_obj(qmp_cmd)
+2025-04-14 10:24:37,645 stacktrace       L0045 ERROR|            ~~~~~~~~~~~~^^^^^^^^^
+2025-04-14 10:24:37,645 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 186, in cmd_obj
+2025-04-14 10:24:37,645 stacktrace       L0045 ERROR|     self._sync(
+2025-04-14 10:24:37,645 stacktrace       L0045 ERROR|     ~~~~~~~~~~^
+2025-04-14 10:24:37,645 stacktrace       L0045 ERROR|         # pylint: disable=protected-access
+2025-04-14 10:24:37,645 stacktrace       L0045 ERROR|         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,646 stacktrace       L0045 ERROR|     ...<5 lines>...
+2025-04-14 10:24:37,646 stacktrace       L0045 ERROR|         self._timeout
+2025-04-14 10:24:37,646 stacktrace       L0045 ERROR|         ^^^^^^^^^^^^^
+2025-04-14 10:24:37,646 stacktrace       L0045 ERROR|     )
+2025-04-14 10:24:37,646 stacktrace       L0045 ERROR|     ^
+2025-04-14 10:24:37,646 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 102, in _sync
+2025-04-14 10:24:37,646 stacktrace       L0045 ERROR|     return self._aloop.run_until_complete(
+2025-04-14 10:24:37,647 stacktrace       L0045 ERROR|            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
+2025-04-14 10:24:37,647 stacktrace       L0045 ERROR|         asyncio.wait_for(future, timeout=timeout)
+2025-04-14 10:24:37,647 stacktrace       L0045 ERROR|         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,647 stacktrace       L0045 ERROR|     )
+2025-04-14 10:24:37,647 stacktrace       L0045 ERROR|     ^
+2025-04-14 10:24:37,647 stacktrace       L0045 ERROR|   File "/usr/lib64/python3.13/asyncio/base_events.py", line 725, in run_until_complete
+2025-04-14 10:24:37,647 stacktrace       L0045 ERROR|     return future.result()
+2025-04-14 10:24:37,647 stacktrace       L0045 ERROR|            ~~~~~~~~~~~~~^^
+2025-04-14 10:24:37,647 stacktrace       L0045 ERROR|   File "/usr/lib64/python3.13/asyncio/tasks.py", line 507, in wait_for
+2025-04-14 10:24:37,648 stacktrace       L0045 ERROR|     return await fut
+2025-04-14 10:24:37,648 stacktrace       L0045 ERROR|            ^^^^^^^^^
+2025-04-14 10:24:37,648 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 547, in _raw
+2025-04-14 10:24:37,648 stacktrace       L0045 ERROR|     return await self._execute(msg, assign_id=assign_id)
+2025-04-14 10:24:37,648 stacktrace       L0045 ERROR|            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,648 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 496, in _execute
+2025-04-14 10:24:37,648 stacktrace       L0045 ERROR|     return await self._reply(exec_id)
+2025-04-14 10:24:37,648 stacktrace       L0045 ERROR|            ^^^^^^^^^^^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,648 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 463, in _reply
+2025-04-14 10:24:37,648 stacktrace       L0045 ERROR|     raise result
+2025-04-14 10:24:37,648 stacktrace       L0045 ERROR| qemu.qmp.qmp_client.ExecInterruptedError: Disconnected
+2025-04-14 10:24:37,649 stacktrace       L0046 ERROR| 
+2025-04-14 10:24:37,649 test             L0798 DEBUG| Local variables:
+2025-04-14 10:24:37,671 test             L0801 DEBUG|  -> obj <class 'reverse_debugging.ReverseDebugging_AArch64'>: 1-ReverseDebugging_AArch64.test_aarch64_virt
+2025-04-14 10:24:37,671 test             L0801 DEBUG|  -> args <class 'tuple'>: ()
+2025-04-14 10:24:37,671 test             L0801 DEBUG|  -> kwargs <class 'dict'>: {}
+2025-04-14 10:24:37,671 test             L0801 DEBUG|  -> condition <class 'str'>: 1
+2025-04-14 10:24:37,671 test             L0801 DEBUG|  -> function <class 'function'>: <function ReverseDebugging_AArch64.test_aarch64_virt at 0x7fc6d4cc87c0>
+2025-04-14 10:24:37,672 test             L0801 DEBUG|  -> message <class 'str'>: Test is unstable on GitLab
+2025-04-14 10:24:37,672 test             L0801 DEBUG|  -> negate <class 'bool'>: True
+2025-04-14 10:24:37,673 stacktrace       L0039 ERROR| 
+2025-04-14 10:24:37,673 stacktrace       L0041 ERROR| Reproduced traceback from: /usr/lib/python3.13/site-packages/avocado/core/test.py:819
+2025-04-14 10:24:37,678 stacktrace       L0045 ERROR| Traceback (most recent call last):
+2025-04-14 10:24:37,679 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/machine/machine.py", line 580, in _soft_shutdown
+2025-04-14 10:24:37,679 stacktrace       L0045 ERROR|     self.qmp('quit')
+2025-04-14 10:24:37,679 stacktrace       L0045 ERROR|     ~~~~~~~~^^^^^^^^
+2025-04-14 10:24:37,679 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/machine/machine.py", line 711, in qmp
+2025-04-14 10:24:37,679 stacktrace       L0045 ERROR|     ret = self._qmp.cmd_raw(cmd, args=qmp_args)
+2025-04-14 10:24:37,679 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 208, in cmd_raw
+2025-04-14 10:24:37,679 stacktrace       L0045 ERROR|     return self.cmd_obj(qmp_cmd)
+2025-04-14 10:24:37,679 stacktrace       L0045 ERROR|            ~~~~~~~~~~~~^^^^^^^^^
+2025-04-14 10:24:37,679 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 192, in cmd_obj
+2025-04-14 10:24:37,680 stacktrace       L0045 ERROR|     self._qmp._raw(qmp_cmd, assign_id=False),
+2025-04-14 10:24:37,680 stacktrace       L0045 ERROR|     ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,680 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 155, in _wrapper
+2025-04-14 10:24:37,680 stacktrace       L0045 ERROR|     raise StateError(emsg, proto.runstate, required_state)
+2025-04-14 10:24:37,680 stacktrace       L0045 ERROR| qemu.qmp.protocol.StateError: QMPClient is disconnecting. Call disconnect() to return to IDLE state.
+2025-04-14 10:24:37,680 stacktrace       L0045 ERROR| 
+2025-04-14 10:24:37,680 stacktrace       L0045 ERROR| During handling of the above exception, another exception occurred:
+2025-04-14 10:24:37,680 stacktrace       L0045 ERROR| 
+2025-04-14 10:24:37,680 stacktrace       L0045 ERROR| Traceback (most recent call last):
+2025-04-14 10:24:37,680 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/machine/machine.py", line 611, in _do_shutdown
+2025-04-14 10:24:37,681 stacktrace       L0045 ERROR|     self._soft_shutdown(timeout)
+2025-04-14 10:24:37,681 stacktrace       L0045 ERROR|     ~~~~~~~~~~~~~~~~~~~^^^^^^^^^
+2025-04-14 10:24:37,681 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/machine/machine.py", line 583, in _soft_shutdown
+2025-04-14 10:24:37,681 stacktrace       L0045 ERROR|     self._close_qmp_connection()
+2025-04-14 10:24:37,681 stacktrace       L0045 ERROR|     ~~~~~~~~~~~~~~~~~~~~~~~~~~^^
+2025-04-14 10:24:37,681 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/machine/machine.py", line 501, in _close_qmp_connection
+2025-04-14 10:24:37,681 stacktrace       L0045 ERROR|     self._qmp.close()
+2025-04-14 10:24:37,681 stacktrace       L0045 ERROR|     ~~~~~~~~~~~~~~~^^
+2025-04-14 10:24:37,681 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 281, in close
+2025-04-14 10:24:37,681 stacktrace       L0045 ERROR|     self._sync(
+2025-04-14 10:24:37,681 stacktrace       L0045 ERROR|     ~~~~~~~~~~^
+2025-04-14 10:24:37,682 stacktrace       L0045 ERROR|         self._qmp.disconnect()
+2025-04-14 10:24:37,682 stacktrace       L0045 ERROR|         ^^^^^^^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,682 stacktrace       L0045 ERROR|     )
+2025-04-14 10:24:37,682 stacktrace       L0045 ERROR|     ^
+2025-04-14 10:24:37,682 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 102, in _sync
+2025-04-14 10:24:37,682 stacktrace       L0045 ERROR|     return self._aloop.run_until_complete(
+2025-04-14 10:24:37,682 stacktrace       L0045 ERROR|            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
+2025-04-14 10:24:37,682 stacktrace       L0045 ERROR|         asyncio.wait_for(future, timeout=timeout)
+2025-04-14 10:24:37,682 stacktrace       L0045 ERROR|         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,682 stacktrace       L0045 ERROR|     )
+2025-04-14 10:24:37,682 stacktrace       L0045 ERROR|     ^
+2025-04-14 10:24:37,683 stacktrace       L0045 ERROR|   File "/usr/lib64/python3.13/asyncio/base_events.py", line 725, in run_until_complete
+2025-04-14 10:24:37,683 stacktrace       L0045 ERROR|     return future.result()
+2025-04-14 10:24:37,683 stacktrace       L0045 ERROR|            ~~~~~~~~~~~~~^^
+2025-04-14 10:24:37,683 stacktrace       L0045 ERROR|   File "/usr/lib64/python3.13/asyncio/tasks.py", line 507, in wait_for
+2025-04-14 10:24:37,683 stacktrace       L0045 ERROR|     return await fut
+2025-04-14 10:24:37,683 stacktrace       L0045 ERROR|            ^^^^^^^^^
+2025-04-14 10:24:37,683 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 399, in disconnect
+2025-04-14 10:24:37,683 stacktrace       L0045 ERROR|     await self._wait_disconnect()
+2025-04-14 10:24:37,683 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 719, in _wait_disconnect
+2025-04-14 10:24:37,683 stacktrace       L0045 ERROR|     await all_defined_tasks  # Raise Exceptions from the bottom half.
+2025-04-14 10:24:37,684 stacktrace       L0045 ERROR|     ^^^^^^^^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,684 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 870, in _bh_loop_forever
+2025-04-14 10:24:37,684 stacktrace       L0045 ERROR|     await async_fn()
+2025-04-14 10:24:37,684 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 908, in _bh_recv_message
+2025-04-14 10:24:37,684 stacktrace       L0045 ERROR|     msg = await self._recv()
+2025-04-14 10:24:37,684 stacktrace       L0045 ERROR|           ^^^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,684 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 1009, in _recv
+2025-04-14 10:24:37,684 stacktrace       L0045 ERROR|     message = await self._do_recv()
+2025-04-14 10:24:37,684 stacktrace       L0045 ERROR|               ^^^^^^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,684 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 402, in _do_recv
+2025-04-14 10:24:37,684 stacktrace       L0045 ERROR|     msg_bytes = await self._readline()
+2025-04-14 10:24:37,685 stacktrace       L0045 ERROR|                 ^^^^^^^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,685 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 977, in _readline
+2025-04-14 10:24:37,685 stacktrace       L0045 ERROR|     raise EOFError
+2025-04-14 10:24:37,685 stacktrace       L0045 ERROR| EOFError
+2025-04-14 10:24:37,685 stacktrace       L0045 ERROR| 
+2025-04-14 10:24:37,685 stacktrace       L0045 ERROR| The above exception was the direct cause of the following exception:
+2025-04-14 10:24:37,685 stacktrace       L0045 ERROR| 
+2025-04-14 10:24:37,685 stacktrace       L0045 ERROR| Traceback (most recent call last):
+2025-04-14 10:24:37,685 stacktrace       L0045 ERROR|   File "/.../tmp/qemu-build/tests/avocado/avocado_qemu/__init__.py", line 372, in tearDown
+2025-04-14 10:24:37,685 stacktrace       L0045 ERROR|     vm.shutdown()
+2025-04-14 10:24:37,685 stacktrace       L0045 ERROR|     ~~~~~~~~~~~^^
+2025-04-14 10:24:37,686 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/machine/machine.py", line 648, in shutdown
+2025-04-14 10:24:37,686 stacktrace       L0045 ERROR|     self._do_shutdown(timeout)
+2025-04-14 10:24:37,686 stacktrace       L0045 ERROR|     ~~~~~~~~~~~~~~~~~^^^^^^^^^
+2025-04-14 10:24:37,686 stacktrace       L0045 ERROR|   File "/.../devel/qemu/python/qemu/machine/machine.py", line 618, in _do_shutdown
+2025-04-14 10:24:37,686 stacktrace       L0045 ERROR|     raise AbnormalShutdown("Could not perform graceful shutdown") \
+2025-04-14 10:24:37,686 stacktrace       L0045 ERROR|         from exc
+2025-04-14 10:24:37,686 stacktrace       L0045 ERROR| qemu.machine.machine.AbnormalShutdown: Could not perform graceful shutdown
+2025-04-14 10:24:37,686 stacktrace       L0046 ERROR| 
+2025-04-14 10:24:37,694 test             L0941 ERROR| Traceback (most recent call last):
+2025-04-14 10:24:37,694 test             L0941 ERROR|   File "/usr/lib/python3.13/site-packages/avocado/core/test.py", line 881, in _run_avocado
+    raise test_exception
+2025-04-14 10:24:37,694 test             L0941 ERROR|   File "/usr/lib/python3.13/site-packages/avocado/core/test.py", line 788, in _run_avocado
+    testMethod()
+    ~~~~~~~~~~^^
+2025-04-14 10:24:37,695 test             L0941 ERROR|   File "/usr/lib/python3.13/site-packages/avocado/core/decorators.py", line 90, in wrapper
+    return function(obj, *args, **kwargs)
+2025-04-14 10:24:37,695 test             L0941 ERROR|   File "/.../tmp/qemu-build/tests/avocado/reverse_debugging.py", line 239, in test_aarch64_virt
+    self.reverse_debugging(
+    ~~~~~~~~~~~~~~~~~~~~~~^
+        args=('-kernel', kernel_path))
+        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,695 test             L0941 ERROR|   File "/.../tmp/qemu-build/tests/avocado/reverse_debugging.py", line 179, in reverse_debugging
+    if self.vm_get_icount(vm) == last_icount - 1:
+       ~~~~~~~~~~~~~~~~~~^^^^
+2025-04-14 10:24:37,695 test             L0941 ERROR|   File "/.../tmp/qemu-build/tests/avocado/reverse_debugging.py", line 100, in vm_get_icount
+    return vm.qmp('query-replay')['return']['icount']
+           ~~~~~~^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,695 test             L0941 ERROR|   File "/.../devel/qemu/python/qemu/machine/machine.py", line 711, in qmp
+    ret = self._qmp.cmd_raw(cmd, args=qmp_args)
+2025-04-14 10:24:37,695 test             L0941 ERROR|   File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 208, in cmd_raw
+    return self.cmd_obj(qmp_cmd)
+           ~~~~~~~~~~~~^^^^^^^^^
+2025-04-14 10:24:37,695 test             L0941 ERROR|   File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 186, in cmd_obj
+    self._sync(
+    ~~~~~~~~~~^
+        # pylint: disable=protected-access
+        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    ...<5 lines>...
+        self._timeout
+        ^^^^^^^^^^^^^
+    )
+    ^
+2025-04-14 10:24:37,695 test             L0941 ERROR|   File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 102, in _sync
+    return self._aloop.run_until_complete(
+           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
+        asyncio.wait_for(future, timeout=timeout)
+        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    )
+    ^
+2025-04-14 10:24:37,695 test             L0941 ERROR|   File "/usr/lib64/python3.13/asyncio/base_events.py", line 725, in run_until_complete
+    return future.result()
+           ~~~~~~~~~~~~~^^
+2025-04-14 10:24:37,695 test             L0941 ERROR|   File "/usr/lib64/python3.13/asyncio/tasks.py", line 507, in wait_for
+    return await fut
+           ^^^^^^^^^
+2025-04-14 10:24:37,696 test             L0941 ERROR|   File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 547, in _raw
+    return await self._execute(msg, assign_id=assign_id)
+           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,696 test             L0941 ERROR|   File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 496, in _execute
+    return await self._reply(exec_id)
+           ^^^^^^^^^^^^^^^^^^^^^^^^^^
+2025-04-14 10:24:37,696 test             L0941 ERROR|   File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 463, in _reply
+    raise result
+2025-04-14 10:24:37,696 test             L0941 ERROR| qemu.qmp.qmp_client.ExecInterruptedError: Disconnected
+2025-04-14 10:24:37,696 test             L0956 ERROR| ERROR 1-ReverseDebugging_AArch64.test_aarch64_virt -> ExecInterruptedError: Disconnected
+2025-04-14 10:24:37,696 test             L0948 INFO | 
+```
+Steps to reproduce:
+1. ``make check-venv``
+2. Run something in the background that keeps all CPUs busy
+3. ``for ((x=0;x<20;x++)); do QEMU_TEST_FLAKY_TESTS=1 pyvenv/bin/avocado run tests/avocado/reverse_debugging.py:ReverseDebugging_AArch64.test_aarch64_virt  ; done``
+Additional information:
+The problem can be reproduced with the test converted to the functional framework, too (that's where I noticed it first). In that case the stack trace looked like this:
+
+```
+$ QEMU_TEST_ALLOW_SLOW=1 QEMU_TEST_ALLOW_UNTRUSTED_CODE=1 QEMU_TEST_FLAKY_TESTS=1 QEMU_TEST_ALLOW_LARGE_STORAGE=1 ~/devel/qemu/tests/functional/test_aarch64_reverse_debug.py 
+TAP version 13
+Traceback (most recent call last):
+  File "/.../devel/qemu/tests/functional/test_aarch64_reverse_debug.py", line 33, in test_aarch64_virt
+    self.reverse_debugging(args=('-kernel', kernel_path))
+    ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/.../devel/qemu/tests/functional/reverse_debugging.py", line 147, in reverse_debugging
+    pc = self.get_pc(g)
+  File "/.../devel/qemu/tests/functional/reverse_debugging.py", line 82, in get_pc
+    return self.get_reg(g, self.REG_PC)
+           ~~~~~~~~~~~~^^^^^^^^^^^^^^^^
+  File "/.../devel/qemu/tests/functional/reverse_debugging.py", line 77, in get_reg
+    return self.get_reg_le(g, reg)
+           ~~~~~~~~~~~~~~~^^^^^^^^
+  File "/.../devel/qemu/tests/functional/reverse_debugging.py", line 63, in get_reg_le
+    res = g.cmd(b'p%x' % reg)
+  File "/usr/lib/python3.13/site-packages/avocado/utils/gdb.py", line 783, in cmd
+    response_payload = self.decode(result)
+  File "/usr/lib/python3.13/site-packages/avocado/utils/gdb.py", line 738, in decode
+    raise InvalidPacketError
+avocado.utils.gdb.InvalidPacketError
+
+not ok 1 test_aarch64_reverse_debug.ReverseDebugging_AArch64.test_aarch64_virt
+Traceback (most recent call last):
+  File "/.../devel/qemu/python/qemu/machine/machine.py", line 580, in _soft_shutdown
+    self.qmp('quit')
+    ~~~~~~~~^^^^^^^^
+  File "/.../devel/qemu/python/qemu/machine/machine.py", line 711, in qmp
+    ret = self._qmp.cmd_raw(cmd, args=qmp_args)
+  File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 208, in cmd_raw
+    return self.cmd_obj(qmp_cmd)
+           ~~~~~~~~~~~~^^^^^^^^^
+  File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 186, in cmd_obj
+    self._sync(
+    ~~~~~~~~~~^
+        # pylint: disable=protected-access
+        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    ...<5 lines>...
+        self._timeout
+        ^^^^^^^^^^^^^
+    )
+    ^
+  File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 102, in _sync
+    return self._aloop.run_until_complete(
+           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
+        asyncio.wait_for(future, timeout=timeout)
+        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    )
+    ^
+  File "/usr/lib64/python3.13/asyncio/base_events.py", line 725, in run_until_complete
+    return future.result()
+           ~~~~~~~~~~~~~^^
+  File "/usr/lib64/python3.13/asyncio/tasks.py", line 507, in wait_for
+    return await fut
+           ^^^^^^^^^
+  File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 547, in _raw
+    return await self._execute(msg, assign_id=assign_id)
+           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 496, in _execute
+    return await self._reply(exec_id)
+           ^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 463, in _reply
+    raise result
+qemu.qmp.qmp_client.ExecInterruptedError: Disconnected
+
+During handling of the above exception, another exception occurred:
+
+Traceback (most recent call last):
+  File "/.../devel/qemu/python/qemu/machine/machine.py", line 611, in _do_shutdown
+    self._soft_shutdown(timeout)
+    ~~~~~~~~~~~~~~~~~~~^^^^^^^^^
+  File "/.../devel/qemu/python/qemu/machine/machine.py", line 583, in _soft_shutdown
+    self._close_qmp_connection()
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~^^
+  File "/.../devel/qemu/python/qemu/machine/machine.py", line 501, in _close_qmp_connection
+    self._qmp.close()
+    ~~~~~~~~~~~~~~~^^
+  File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 281, in close
+    self._sync(
+    ~~~~~~~~~~^
+        self._qmp.disconnect()
+        ^^^^^^^^^^^^^^^^^^^^^^
+    )
+    ^
+  File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 102, in _sync
+    return self._aloop.run_until_complete(
+           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
+        asyncio.wait_for(future, timeout=timeout)
+        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    )
+    ^
+  File "/usr/lib64/python3.13/asyncio/base_events.py", line 725, in run_until_complete
+    return future.result()
+           ~~~~~~~~~~~~~^^
+  File "/usr/lib64/python3.13/asyncio/tasks.py", line 507, in wait_for
+    return await fut
+           ^^^^^^^^^
+  File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 399, in disconnect
+    await self._wait_disconnect()
+  File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 719, in _wait_disconnect
+    await all_defined_tasks  # Raise Exceptions from the bottom half.
+    ^^^^^^^^^^^^^^^^^^^^^^^
+  File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 834, in _bh_close_stream
+    await wait_closed(self._writer)
+  File "/.../devel/qemu/python/qemu/qmp/util.py", line 130, in wait_closed
+    await writer.wait_closed()
+  File "/usr/lib64/python3.13/asyncio/streams.py", line 358, in wait_closed
+    await self._protocol._get_close_waiter(self)
+  File "/usr/lib64/python3.13/asyncio/selector_events.py", line 1067, in write
+    n = self._sock.send(data)
+BrokenPipeError: [Errno 32] Broken pipe
+
+The above exception was the direct cause of the following exception:
+
+Traceback (most recent call last):
+  File "/.../devel/qemu/tests/functional/qemu_test/testcase.py", line 398, in tearDown
+    vm.shutdown()
+    ~~~~~~~~~~~^^
+  File "/.../devel/qemu/python/qemu/machine/machine.py", line 648, in shutdown
+    self._do_shutdown(timeout)
+    ~~~~~~~~~~~~~~~~~^^^^^^^^^
+  File "/.../devel/qemu/python/qemu/machine/machine.py", line 618, in _do_shutdown
+    raise AbnormalShutdown("Could not perform graceful shutdown") \
+        from exc
+qemu.machine.machine.AbnormalShutdown: Could not perform graceful shutdown
+
+not ok 1 test_aarch64_reverse_debug.ReverseDebugging_AArch64.test_aarch64_virt
+1..1
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/2944 b/gitlab/issues_text/target_arm/host_missing/accel_missing/2944
new file mode 100644
index 00000000..69334651
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/2944
@@ -0,0 +1,21 @@
+Commit 59754f85 introduces regression with U-Boot on Cortex-A9 platforms
+Description of problem:
+In U-Boot CI, we started to update from v8.2.0 to v9.2.3 and found that the vexpress_ca9x4 platform was now failing one of the CI tests. I have reconfirmed the problem on top of tree QEMU, and bisected the failure to commit [59754f85("target/arm: Do memory type alignment check when translation disabled
+")](https://gitlab.com/qemu-project/qemu/-/commit/59754f85ed35cbd5f4bf2663ca2136c78d5b2413). I have also re-verified the test is fine on a physical platform with a Cortex-A9 that is as follows (per the RM):
+```
+Table 12-2. Cortex-A9 revision
+Core MP004-BU-50000-r2p10-0rel0
+NEON AT397-BU-50001- r2p0-00rel0
+PL310 PL310-BU-00000-r3p2-50rel0
+```
+Steps to reproduce:
+1. git clone https://source.denx.de/u-boot/u-boot.git; cd u-boot
+2. make O=/tmp/vexpress_ca9x4 CROSS_COMPILE=arm-linux-gnueabi- vexpress_ca9x4_config
+3. make O=/tmp/vexpress_ca9x4 CROSS_COMPILE=arm-linux-gnueabi- -sj$(nproc)
+4. qemu-system-arm -nographic -m 1G -audio none -net user,tftp=/tmp/vexpress_ca9x4 -net nic -M vexpress-a9 -kernel /tmp/vexpress_ca9x4/u-boot
+5. Stop autoboot with any key
+6. setenv autoload no
+7. dhcp
+8. tftpboot 60200000 lib/efi_loader/helloworld.efi
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/340 b/gitlab/issues_text/target_arm/host_missing/accel_missing/340
new file mode 100644
index 00000000..38ec006c
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/340
@@ -0,0 +1 @@
+qemu: uncaught target signal 6 (Aborted) - core dumped on Apple Silicon M1 arm64
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/373 b/gitlab/issues_text/target_arm/host_missing/accel_missing/373
new file mode 100644
index 00000000..cc7310c4
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/373
@@ -0,0 +1 @@
+Indentation should be done with spaces, not with TABs, in the ARM subsystem
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/386 b/gitlab/issues_text/target_arm/host_missing/accel_missing/386
new file mode 100644
index 00000000..2add7691
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/386
@@ -0,0 +1 @@
+raspi0 machine has incorrect memory mapping for devices
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/410 b/gitlab/issues_text/target_arm/host_missing/accel_missing/410
new file mode 100644
index 00000000..bf9c3239
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/410
@@ -0,0 +1 @@
+Abort in audio_bug triggered in sb16/pl041
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/411 b/gitlab/issues_text/target_arm/host_missing/accel_missing/411
new file mode 100644
index 00000000..185c6722
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/411
@@ -0,0 +1 @@
+Abort when runs into unsupported AUXCommand in xlnx_dp_aux_set_command
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/447 b/gitlab/issues_text/target_arm/host_missing/accel_missing/447
new file mode 100644
index 00000000..0e21ab56
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/447
@@ -0,0 +1 @@
+qemu-arm: Unable to reserve 0xffff0000 bytes of virtual address space at 0x1000 (Success) for use as guest address space (check yourvirtual memory ulimit setting, min_mmap_addr or reserve less using -R option)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/448 b/gitlab/issues_text/target_arm/host_missing/accel_missing/448
new file mode 100644
index 00000000..de9f7f6c
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/448
@@ -0,0 +1 @@
+raspi0 machine leads to kernel panic of latest raspberry pi os kernel
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/45 b/gitlab/issues_text/target_arm/host_missing/accel_missing/45
new file mode 100644
index 00000000..1f804094
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/45
@@ -0,0 +1 @@
+qemu-system-aarch64: no function defined to set boot device list for this architecture
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/452 b/gitlab/issues_text/target_arm/host_missing/accel_missing/452
new file mode 100644
index 00000000..5ff54aea
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/452
@@ -0,0 +1,56 @@
+Akita (and probably all Spitz-like / PXA270) platform does not load BIOS binary
+Description of problem:
+QEMU does not appear to load a binary file passed with the "-bios" argument for the "akita" target. This probably extends to other spitz-type systems.
+
+Exptected behavior: qemu loads the binary into address 0x0000.
+Actual behavior: address space at 0x0000 contains only zeros.
+Steps to reproduce:
+Terminal 1:
+```
+qemu-system-arm -M akita -bios c750.rom -s -S
+```
+
+Terminal 2: 
+```
+gdb-multiarch
+target remote localhost:1234
+x/64i $pc
+```
+
+Result:
+```
+=> 0x0: andeq   r0, r0, r0
+   0x4: andeq   r0, r0, r0
+   0x8: andeq   r0, r0, r0
+   0xc: andeq   r0, r0, r0
+   0x10:        andeq   r0, r0, r0
+```
+
+Correct behavior (can demonstrate with virt machine):
+Same as before, but start Terminal 1 with:
+```
+qemu-system-arm -M akita -bios c750.rom -s -S
+```
+
+Result:
+```
+=> 0x0: b       0x34
+   0x4: ldr     pc, [pc, #156]  ; 0xa8
+   0x8: ldr     pc, [pc, #156]  ; 0xac
+   0xc: ldr     pc, [pc, #156]  ; 0xb0
+   0x10:        ldr     pc, [pc, #156]  ; 0xb4
+   0x14:        nop                     ; (mov r0, r0)
+   0x18:        ldr     pc, [pc, #152]  ; 0xb8
+   0x1c:        ldr     pc, [pc, #152]  ; 0xbc
+   0x20:        mov     r0, #128        ; 0x80
+   0x24:        b       0x2c
+   0x28:        mov     r0, #129        ; 0x81
+   0x2c:        ldr     r1, [pc, #140]  ; 0xc0
+   0x30:        str     r0, [r1]
+   0x34:        mrs     lr, CPSR
+   0x38:        bic     lr, lr, #31
+   0x3c:        orr     lr, lr, #211    ; 0xd3
+   0x40:        msr     CPSR_fc, lr
+```
+Additional information:
+File with very tiny boot ROM: [c750-tiny.rom](/uploads/045852c8b353174bf0b7a4193d0d1be0/c750-tiny.rom)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/454 b/gitlab/issues_text/target_arm/host_missing/accel_missing/454
new file mode 100644
index 00000000..041f2b30
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/454
@@ -0,0 +1,3 @@
+edk2-aarch64-code.fd prints a lot of debug output
+Additional information:
+Currently running a QEMU version built from source with the last commit to pc-bios being 7a3d37a3f2335e18539e821d0c72abe0b22480bd (and I don't see any changes to edk2-aarch64-code since)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/459 b/gitlab/issues_text/target_arm/host_missing/accel_missing/459
new file mode 100644
index 00000000..ab940ce3
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/459
@@ -0,0 +1,35 @@
+bcm2835_aux (raspi3) fails when the receive FIFO fills up
+Description of problem:
+When a bare-metal application on the `raspi3` board reads the `AUX_MU_STAT_REG` MMIO register while the device's buffer is at full receive FIFO capacity (i.e. `s->read_count == BCM2835_AUX_RX_FIFO_LEN`) the assertion `assert(s->read_count < BCM2835_AUX_RX_FIFO_LEN)` fails.
+
+The assertion in question is currently in line 141 of `hw/char/bcm2835_aux.c`: https://gitlab.com/qemu-project/qemu/-/blob/9c2647f75004c4f7d64c9c0ec55f8c6f0739a8b1/hw/char/bcm2835_aux.c#L141
+but in my current QEMU version, it seems that it was in line 140, but I don't think that has any implication on this error. If the below steps to reproduce are followed, the full output of a normal QEMU (no debugging output or anything) is simply:
+
+```text
+$ echo abcdefgh | qemu-system-aarch64 -M raspi3 -kernel kernel8.elf -serial null -serial stdio
+qemu-system-aarch64: /build/qemu-71DV4m/qemu-4.2/hw/char/bcm2835_aux.c:140: bcm2835_aux_read: Assertion `s->read_count < BCM2835_AUX_RX_FIFO_LEN' failed.
+Aborted (core dumped)
+```
+
+Notice, that there is nothing really wrong with the implementation, if for instance an application that uses the `AUX_MU_LSR_REG` instead to check whether input is available, everything works as expected. It really seems that just this assertion is wrong. Also notice that the [BCM2835 manual](https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf) (page 18) explicitly allows values inclusive 8.
+Steps to reproduce:
+1. write a minimal bare-metal application for aarch64 using below main file
+2. compile it with a decent aarch64 compiler, linker script and entry assembly as `kernel8.elf`
+3. `echo abcdefgh | qemu-system-aarch64 -M raspi3 -kernel kernel8.elf -serial null -serial stdio`
+4. QEMU crashes with the above state assertion error
+Additional information:
+Minimal bare-metal application (`main.c`):
+
+```c
+#define MMIO_BASE       0x3F000000
+#define AUX_MU_STAT     ((volatile unsigned int*)(MMIO_BASE+0x00215064))
+
+void main() {
+    while (1) {
+        // Just read STAT register to trigger the assertion error
+        *AUX_MU_STAT;
+    }
+}
+```
+
+Also see [kernel8.elf.zip](/uploads/b12ae2750d2df1bb8db2701f3145f653/kernel8.elf.zip) for a precompiled version of the above application.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/461 b/gitlab/issues_text/target_arm/host_missing/accel_missing/461
new file mode 100644
index 00000000..4454222f
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/461
@@ -0,0 +1 @@
+What's your plan of Raspberry 3/3B/4B
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/467 b/gitlab/issues_text/target_arm/host_missing/accel_missing/467
new file mode 100644
index 00000000..8c5fafa3
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/467
@@ -0,0 +1 @@
+savevm/loadvm/migration broken for 32-bit arm guests that use TrustZone
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/468 b/gitlab/issues_text/target_arm/host_missing/accel_missing/468
new file mode 100644
index 00000000..58ebd566
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/468
@@ -0,0 +1 @@
+Zynq7000 UART clock reset initialization
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/470 b/gitlab/issues_text/target_arm/host_missing/accel_missing/470
new file mode 100644
index 00000000..d9d59a0e
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/470
@@ -0,0 +1 @@
+qemu linux-user requires read permissions on memory passed to syscalls that should only need write access
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/472 b/gitlab/issues_text/target_arm/host_missing/accel_missing/472
new file mode 100644
index 00000000..fab3bb00
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/472
@@ -0,0 +1 @@
+Device trees should specify `clock-frequency` property for `/cpus/cpu*` nodes
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/481 b/gitlab/issues_text/target_arm/host_missing/accel_missing/481
new file mode 100644
index 00000000..49f1aa15
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/481
@@ -0,0 +1 @@
+Implement I2C for BCM2835 (raspi)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/482 b/gitlab/issues_text/target_arm/host_missing/accel_missing/482
new file mode 100644
index 00000000..6192b7b3
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/482
@@ -0,0 +1 @@
+Unable to set SVE VL to 1024 bits or above since 7b6a2198
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/518 b/gitlab/issues_text/target_arm/host_missing/accel_missing/518
new file mode 100644
index 00000000..8b40e942
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/518
@@ -0,0 +1 @@
+Android for arm guest
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/528 b/gitlab/issues_text/target_arm/host_missing/accel_missing/528
new file mode 100644
index 00000000..c84f406b
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/528
@@ -0,0 +1 @@
+arm: trying to use KVM with an EL3-enabled CPU hits an assertion failure
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/54 b/gitlab/issues_text/target_arm/host_missing/accel_missing/54
new file mode 100644
index 00000000..eccc61b7
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/54
@@ -0,0 +1 @@
+Attaching SD-Card to specific SD-Bus Sabrelite (ARM)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/549 b/gitlab/issues_text/target_arm/host_missing/accel_missing/549
new file mode 100644
index 00000000..69ba2f5a
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/549
@@ -0,0 +1 @@
+FPE in npcm7xx_clk_update_pll
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/550 b/gitlab/issues_text/target_arm/host_missing/accel_missing/550
new file mode 100644
index 00000000..3ad9b9d7
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/550
@@ -0,0 +1 @@
+FPE in npcm7xx_adc_convert
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/555 b/gitlab/issues_text/target_arm/host_missing/accel_missing/555
new file mode 100644
index 00000000..a811b7b7
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/555
@@ -0,0 +1 @@
+qemu user aarch64 crashes when giving the dynamic loader as argument
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/61 b/gitlab/issues_text/target_arm/host_missing/accel_missing/61
new file mode 100644
index 00000000..91c26884
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/61
@@ -0,0 +1 @@
+qemu-system-arm segfaults while servicing SYS_HEAPINFO
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/613 b/gitlab/issues_text/target_arm/host_missing/accel_missing/613
new file mode 100644
index 00000000..4f58eb69
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/613
@@ -0,0 +1 @@
+ARM cortex-m55 LOB instructions make QEMU crash
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/620 b/gitlab/issues_text/target_arm/host_missing/accel_missing/620
new file mode 100644
index 00000000..bbcd808a
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/620
@@ -0,0 +1 @@
+QEMU gdbstub should add memtag support for aarch64 MTE
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/633 b/gitlab/issues_text/target_arm/host_missing/accel_missing/633
new file mode 100644
index 00000000..91be580e
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/633
@@ -0,0 +1,32 @@
+i686-arm-user-static - Allocating guest commpage: Operation not permitted
+Steps to reproduce:
+1. Run the test case linked earlier.
+2. You'll see `apt update` failing:
+
+```
+Get:1 http://archive.raspberrypi.org/debian buster InRelease [32.6 kB]
+Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
+Err:1 http://archive.raspberrypi.org/debian buster InRelease
+  At least one invalid signature was encountered.
+Err:2 http://raspbian.raspberrypi.org/raspbian buster InRelease
+  At least one invalid signature was encountered.
+Reading package lists... Done
+W: GPG error: http://archive.raspberrypi.org/debian buster InRelease: At least one invalid signature was encountered.
+E: The repository 'http://archive.raspberrypi.org/debian buster InRelease' is not signed.
+N: Updating from such a repository can't be done securely, and is therefore disabled by default.
+N: See apt-secure(8) manpage for repository creation and user configuration details.
+W: GPG error: http://raspbian.raspberrypi.org/raspbian buster InRelease: At least one invalid signature was encountered.
+E: The repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' is not signed.
+N: Updating from such a repository can't be done securely, and is therefore disabled by default.
+N: See apt-secure(8) manpage for repository creation and user configuration details.
+```
+Additional information:
+Setting `sysctl vm.mmap_min_addr=53248` makes it work (as opposed to the system default of 65536).
+
+Bisecting the bug linked earlier also breaks this in a slightly different way. Everything works at 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1. After that, apt update appears to work, but the package lists end up empty, so nothing can be installed. Then after 975ac4559c4c00010e05f7a3e782eeb9497837ea, the output is as provided above.
+
+apt launches /usr/lib/apt/methods/gpgv and passes it some commands through stdin. gpgv launches /usr/bin/apt-key, which fails with `Allocating guest commpage: Operation not permitted`. Running gpgv directly and sending the same commands works without any issues. The problem only occurs when gpgv is run through apt. (I don't meant the normal system gpgv binary, but the transport method binary that comes with apt)
+
+Getting any output is tricky because by the time apt-key is launched, gpgv redirects stdout and stderr to /dev/null and communication takes place through fd 3. https://salsa.debian.org/apt-team/apt/-/blob/2.2.4/apt-pkg/contrib/gpgv.cc#L355 https://salsa.debian.org/apt-team/apt/-/blob/main/methods/gpgv.cc#L186
+
+I had to do some ugly things with different versions of qemu and wrapper scripts to see the commpage error, but hopefully there's enough information provided here that it won't be necessary.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/636 b/gitlab/issues_text/target_arm/host_missing/accel_missing/636
new file mode 100644
index 00000000..73a12814
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/636
@@ -0,0 +1,356 @@
+tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_initrd can not perform graceful shutdown
+Description of problem:
+Roughly once every 20 times, the [`halt`](https://gitlab.com/qemu-project/qemu/-/blob/73257aa02376829f724357094e252fc3e5dd1363/tests/acceptance/boot_linux_console.py#L522) command will not produce the desired effect, and [wait()ing](https://gitlab.com/qemu-project/qemu/-/blob/73257aa02376829f724357094e252fc3e5dd1363/tests/acceptance/boot_linux_console.py#L524) on the QEMU process to gracefully shutdown will fail.
+
+I was not able to see any other failure in what the test covers, except the `halt` command and the `wait()`ing.  That is, the booting of the kernel and initrd, and the execution of commands to inspect the system all run without problems.
+Steps to reproduce:
+1. make check-venv
+2. ./tests/venv/bin/avocado run tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_initrd
+Additional information:
+```
+13:48:01 DEBUG| PARAMS (key=arch, path=*, default=arm) => 'arm'
+13:48:01 DEBUG| PARAMS (key=cpu, path=*, default=None) => None
+13:48:01 DEBUG| PARAMS (key=machine, path=*, default=raspi2b) => 'raspi2b'
+13:48:01 DEBUG| PARAMS (key=qemu_bin, path=*, default=./qemu-system-arm) => './qemu-system-arm'
+13:48:01 DEBUG| Test workdir initialized at: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd
+13:48:08 DEBUG| QEMUMachine "default" created
+13:48:08 DEBUG| QEMUMachine "default" temp_dir: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/qemu-machine-5pavn9gy
+13:48:08 DEBUG| QEMUMachine "default" log_dir: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd
+13:48:08 DEBUG| VM launch command: './qemu-system-arm -display none -vga none -chardev socket,id=mon,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-monitor.sock -mon chardev=mon,mode=control -machine raspi2b -chardev socket,id=console,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-console.sock,server=on,wait=off -serial chardev:console -kernel /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/kernel7.img -dtb /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/bcm2709-rpi-2-b.dtb -initrd /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/rootfs.cpio -append printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0 -no-reboot'
+13:48:08 DEBUG| >>> {'execute': 'qmp_capabilities'}
+13:48:08 DEBUG| <<< {'return': {}}
+13:48:08 DEBUG| [    0.000000] Booting Linux on physical CPU 0xf00
+13:48:08 DEBUG| [    0.000000] Linux version 4.14.98-v7+ (dom@dom-XPS-13-9370) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1200 SMP Tue Feb 12 20:27:48 GMT 2019
+13:48:08 DEBUG| [    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
+13:48:08 DEBUG| [    0.000000] CPU: div instructions available: patching division code
+13:48:08 DEBUG| [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
+13:48:08 DEBUG| [    0.000000] OF: fdt: Machine model: Raspberry Pi 2 Model B
+13:48:08 DEBUG| [    0.000000] earlycon: pl11 at MMIO 0x3f201000 (options '')
+13:48:08 DEBUG| [    0.000000] bootconsole [pl11] enabled
+13:48:08 DEBUG| [    0.000000] Memory policy: Data cache writealloc
+13:48:08 DEBUG| [    0.000000] cma: Reserved 8 MiB at 0x3b800000
+13:48:08 DEBUG| [    0.000000] percpu: Embedded 17 pages/cpu @baf2e000 s38720 r8192 d22720 u69632
+13:48:08 DEBUG| [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 243600
+13:48:08 DEBUG| [    0.000000] Kernel command line: printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0
+13:48:08 DEBUG| PID hash table entries: 4096 (order: 2, 16384 bytes)
+13:48:08 DEBUG| Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
+13:48:08 DEBUG| Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
+13:48:08 DEBUG| Memory: 949120K/983040K available (7168K kernel code, 577K rwdata, 2080K rodata, 1024K init, 698K bss, 25728K reserved, 8192K cma-reserved)
+13:48:08 DEBUG| Virtual kernel memory layout:
+13:48:08 DEBUG| vector  : 0xffff0000 - 0xffff1000   (   4 kB)
+13:48:08 DEBUG| fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
+13:48:08 DEBUG| vmalloc : 0xbc800000 - 0xff800000   (1072 MB)
+13:48:08 DEBUG| lowmem  : 0x80000000 - 0xbc000000   ( 960 MB)
+13:48:08 DEBUG| modules : 0x7f000000 - 0x80000000   (  16 MB)
+13:48:08 DEBUG| .text : 0x80008000 - 0x80800000   (8160 kB)
+13:48:08 DEBUG| .init : 0x80b00000 - 0x80c00000   (1024 kB)
+13:48:08 DEBUG| .data : 0x80c00000 - 0x80c906d4   ( 578 kB)
+13:48:08 DEBUG| .bss : 0x80c97ef8 - 0x80d468f0   ( 699 kB)
+13:48:08 DEBUG| SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
+13:48:08 DEBUG| ftrace: allocating 25298 entries in 75 pages
+13:48:09 DEBUG| Hierarchical RCU implementation.
+13:48:09 DEBUG| NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
+13:48:09 DEBUG| arch_timer: cp15 timer(s) running at 62.50MHz (virt).
+13:48:09 DEBUG| clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
+13:48:09 DEBUG| sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
+13:48:09 DEBUG| Switching to timer-based delay loop, resolution 16ns
+13:48:09 DEBUG| Console: colour dummy device 80x30
+13:48:09 DEBUG| Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=625000)
+13:48:09 DEBUG| pid_max: default: 32768 minimum: 301
+13:48:09 DEBUG| Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
+13:48:09 DEBUG| Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
+13:48:09 DEBUG| Disabling memory control group subsystem
+13:48:09 DEBUG| CPU: Testing write buffer coherency: ok
+13:48:09 DEBUG| CPU0: update cpu_capacity 1024
+13:48:09 DEBUG| CPU0: thread -1, cpu 0, socket 15, mpidr 80000f00
+13:48:09 DEBUG| Setting up static identity map for 0x100000 - 0x10003c
+13:48:09 DEBUG| Hierarchical SRCU implementation.
+13:48:09 DEBUG| smp: Bringing up secondary CPUs ...
+13:48:09 DEBUG| CPU1: update cpu_capacity 1024
+13:48:09 DEBUG| CPU1: thread -1, cpu 1, socket 15, mpidr 80000f01
+13:48:09 DEBUG| CPU2: update cpu_capacity 1024
+13:48:09 DEBUG| CPU2: thread -1, cpu 2, socket 15, mpidr 80000f02
+13:48:09 DEBUG| CPU3: update cpu_capacity 1024
+13:48:09 DEBUG| CPU3: thread -1, cpu 3, socket 15, mpidr 80000f03
+13:48:09 DEBUG| smp: Brought up 1 node, 4 CPUs
+13:48:09 DEBUG| SMP: Total of 4 processors activated (500.00 BogoMIPS).
+13:48:09 DEBUG| CPU: All CPU(s) started in SVC mode.
+13:48:09 DEBUG| devtmpfs: initialized
+13:48:09 DEBUG| random: get_random_u32 called from bucket_table_alloc+0xfc/0x24c with crng_init=0
+13:48:09 DEBUG| VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
+13:48:09 DEBUG| clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+13:48:09 DEBUG| futex hash table entries: 1024 (order: 4, 65536 bytes)
+13:48:09 DEBUG| pinctrl core: initialized pinctrl subsystem
+13:48:09 DEBUG| NET: Registered protocol family 16
+13:48:09 DEBUG| DMA: preallocated 1024 KiB pool for atomic coherent allocations
+13:48:09 DEBUG| hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
+13:48:09 DEBUG| hw-breakpoint: maximum watchpoint size is 8 bytes.
+13:48:09 DEBUG| Serial: AMBA PL011 UART driver
+13:48:09 DEBUG| bcm2835-mbox 3f00b880.mailbox: mailbox enabled
+13:48:09 DEBUG| bcm2835-dma 3f007000.dma: DMA legacy API manager at bc813000, dmachans=0x1
+13:48:09 DEBUG| SCSI subsystem initialized
+13:48:09 DEBUG| usbcore: registered new interface driver usbfs
+13:48:09 DEBUG| usbcore: registered new interface driver hub
+13:48:09 DEBUG| usbcore: registered new device driver usb
+13:48:09 DEBUG| raspberrypi-firmware soc:firmware: Attached to firmware from 1970-01-05 00:12
+13:48:09 DEBUG| clocksource: Switched to clocksource arch_sys_counter
+13:48:09 DEBUG| VFS: Disk quotas dquot_6.6.0
+13:48:09 DEBUG| VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
+13:48:09 DEBUG| FS-Cache: Loaded
+13:48:09 DEBUG| CacheFiles: Loaded
+13:48:09 DEBUG| NET: Registered protocol family 2
+13:48:09 DEBUG| TCP established hash table entries: 8192 (order: 3, 32768 bytes)
+13:48:09 DEBUG| TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
+13:48:09 DEBUG| TCP: Hash tables configured (established 8192 bind 8192)
+13:48:09 DEBUG| UDP hash table entries: 512 (order: 2, 16384 bytes)
+13:48:09 DEBUG| UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
+13:48:09 DEBUG| NET: Registered protocol family 1
+13:48:09 DEBUG| RPC: Registered named UNIX socket transport module.
+13:48:09 DEBUG| RPC: Registered udp transport module.
+13:48:09 DEBUG| RPC: Registered tcp transport module.
+13:48:09 DEBUG| RPC: Registered tcp NFSv4.1 backchannel transport module.
+13:48:09 DEBUG| Trying to unpack rootfs image as initramfs...
+13:48:09 DEBUG| Freeing initrd memory: 3256K
+13:48:09 DEBUG| hw perfevents: enabled with armv7_cortex_a7 PMU driver, 5 counters available
+13:48:09 DEBUG| workingset: timestamp_bits=14 max_order=18 bucket_order=4
+13:48:09 DEBUG| FS-Cache: Netfs 'nfs' registered for caching
+13:48:09 DEBUG| NFS: Registering the id_resolver key type
+13:48:09 DEBUG| Key type id_resolver registered
+13:48:09 DEBUG| Key type id_legacy registered
+13:48:09 DEBUG| nfs4filelayout_init: NFSv4 File Layout Driver Registering...
+13:48:09 DEBUG| Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
+13:48:09 DEBUG| io scheduler noop registered
+13:48:09 DEBUG| io scheduler deadline registered
+13:48:09 DEBUG| io scheduler cfq registered (default)
+13:48:09 DEBUG| io scheduler mq-deadline registered
+13:48:09 DEBUG| io scheduler kyber registered
+13:48:09 DEBUG| BCM2708FB: allocated DMA memory fb900000
+13:48:09 DEBUG| BCM2708FB: allocated DMA channel 0 @ bc813000
+13:48:09 DEBUG| Console: switching to colour frame buffer device 100x30
+13:48:09 DEBUG| bcm2835-rng 3f104000.rng: hwrng registered
+13:48:09 DEBUG| vc-mem: phys_addr:0x00000000 mem_base=0x00000000 mem_size:0x00000000(0 MiB)
+13:48:09 DEBUG| vc-sm: Videocore shared memory driver
+13:48:09 DEBUG| gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
+13:48:09 DEBUG| brd: module loaded
+13:48:09 DEBUG| loop: module loaded
+13:48:09 DEBUG| Loading iSCSI transport class v2.0-870.
+13:48:09 DEBUG| libphy: Fixed MDIO Bus: probed
+13:48:09 DEBUG| usbcore: registered new interface driver lan78xx
+13:48:09 DEBUG| usbcore: registered new interface driver smsc95xx
+13:48:09 DEBUG| dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
+13:48:09 DEBUG| dwc_otg 3f980000.usb: base=0xf0980000
+13:48:10 DEBUG| Core Release: 2.94a
+13:48:10 DEBUG| Setting default values for core params
+13:48:10 DEBUG| Finished setting default values for core params
+13:48:10 DEBUG| Using Buffer DMA mode
+13:48:10 DEBUG| Periodic Transfer Interrupt Enhancement - disabled
+13:48:10 DEBUG| Multiprocessor Interrupt Enhancement - disabled
+13:48:10 DEBUG| OTG VER PARAM: 0, OTG VER FLAG: 0
+13:48:10 DEBUG| Shared Tx FIFO mode
+13:48:10 DEBUG| WARN::dwc_otg_hcd_init:1046: FIQ DMA bounce buffers: virt = 0xbb914000 dma = 0xfb914000 len=9024
+13:48:10 DEBUG| WARN::hcd_init_fiq:459: FIQ on core 1 at 0x805edb88
+13:48:10 DEBUG| WARN::hcd_init_fiq:460: FIQ ASM at 0x805edcb4 length 36
+13:48:10 DEBUG| WARN::hcd_init_fiq:486: MPHI regs_base at 0xf0006000
+13:48:10 DEBUG| dwc_otg 3f980000.usb: DWC OTG Controller
+13:48:10 DEBUG| dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
+13:48:10 DEBUG| dwc_otg 3f980000.usb: irq 62, io mem 0x00000000
+13:48:10 DEBUG| Init: Port Power? op_state=1
+13:48:10 DEBUG| Init: Power Port (1)
+13:48:10 DEBUG| usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
+13:48:10 DEBUG| usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
+13:48:10 DEBUG| usb usb1: Product: DWC OTG Controller
+13:48:10 DEBUG| usb usb1: Manufacturer: Linux 4.14.98-v7+ dwc_otg_hcd
+13:48:10 DEBUG| usb usb1: SerialNumber: 3f980000.usb
+13:48:10 DEBUG| hub 1-0:1.0: USB hub found
+13:48:10 DEBUG| hub 1-0:1.0: 1 port detected
+13:48:10 DEBUG| usbcore: registered new interface driver usb-storage
+13:48:10 DEBUG| mousedev: PS/2 mouse device common for all mice
+13:48:10 DEBUG| IR NEC protocol handler initialized
+13:48:10 DEBUG| IR RC5(x/sz) protocol handler initialized
+13:48:10 DEBUG| IR RC6 protocol handler initialized
+13:48:10 DEBUG| IR JVC protocol handler initialized
+13:48:10 DEBUG| IR Sony protocol handler initialized
+13:48:10 DEBUG| IR SANYO protocol handler initialized
+13:48:10 DEBUG| IR Sharp protocol handler initialized
+13:48:10 DEBUG| IR MCE Keyboard/mouse protocol handler initialized
+13:48:10 DEBUG| IR XMP protocol handler initialized
+13:48:10 DEBUG| bcm2835-wdt 3f100000.watchdog: Broadcom BCM2835 watchdog timer
+13:48:10 DEBUG| bcm2835-cpufreq: min=700000 max=700000
+13:48:10 DEBUG| sdhci: Secure Digital Host Controller Interface driver
+13:48:10 DEBUG| sdhci: Copyright(c) Pierre Ossman
+13:48:10 DEBUG| sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe
+13:48:10 DEBUG| sdhci-pltfm: SDHCI platform and OF driver helper
+13:48:10 DEBUG| ledtrig-cpu: registered to indicate activity on CPUs
+13:48:10 DEBUG| hidraw: raw HID events driver (C) Jiri Kosina
+13:48:10 DEBUG| usbcore: registered new interface driver usbhid
+13:48:10 DEBUG| usbhid: USB HID core driver
+13:48:10 DEBUG| vchiq: vchiq_init_state: slot_zero = bb980000, is_master = 0
+13:48:10 DEBUG| bcm2835_vchiq 3f00b840.vchiq: failed to set channelbase
+13:48:10 DEBUG| vchiq: could not load vchiq
+13:48:10 DEBUG| Initializing XFRM netlink socket
+13:48:10 DEBUG| NET: Registered protocol family 17
+13:48:10 DEBUG| Key type dns_resolver registered
+13:48:10 DEBUG| Registering SWP/SWPB emulation handler
+13:48:10 DEBUG| registered taskstats version 1
+13:48:10 DEBUG| uart-pl011 3f201000.serial: cts_event_workaround enabled
+13:48:10 DEBUG| 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud = 0) is a PL011 rev2
+13:48:10 DEBUG| console [ttyAMA0] enabled
+13:48:10 DEBUG| console [ttyAMA0] enabled
+13:48:10 DEBUG| bootconsole [pl11] disabled
+13:48:10 DEBUG| bootconsole [pl11] disabled
+13:48:10 DEBUG| bcm2835_thermal 3f212000.thermal: Not able to read trip_temp: -33
+13:48:10 DEBUG| bcm2835-clk 3f101000.cprman: tsens: couldn't lock PLL
+13:48:10 DEBUG| bcm2835_thermal: probe of 3f212000.thermal failed with error -33
+13:48:10 DEBUG| sdhost: log_buf @ bb913000 (fb913000)
+13:48:10 DEBUG| mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
+13:48:10 DEBUG| of_cfs_init
+13:48:10 DEBUG| of_cfs_init: OK
+13:48:10 DEBUG| uart-pl011 3f201000.serial: no DMA platform data
+13:48:10 DEBUG| Freeing unused kernel memory: 1024K
+13:48:11 DEBUG| mount: mounting devtmpfs on /dev failed: Device or resource busy
+13:48:11 DEBUG| Starting logging: OK
+13:48:11 DEBUG| Initializing random number generator... random: dd: uninitialized urandom read (512 bytes read)
+13:48:11 DEBUG| done.
+13:48:12 DEBUG| Starting network: OK
+13:48:12 DEBUG| Found console ttyAMA0
+13:48:12 DEBUG| Linux version 4.14.98-v7+ (dom@dom-XPS-13-9370) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1200 SMP Tue Feb 12 20:27:48 GMT 2019
+13:48:12 DEBUG| Boot successful.
+13:48:12 DEBUG| cat /proc/cpuinfo
+13:48:12 DEBUG| / # cat /proc/cpuinfo
+13:48:12 DEBUG| processor	: 0
+13:48:12 DEBUG| model name	: ARMv7 Processor rev 5 (v7l)
+13:48:12 DEBUG| BogoMIPS	: 125.00
+13:48:12 DEBUG| Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
+13:48:12 DEBUG| CPU implementer	: 0x41
+13:48:12 DEBUG| CPU architecture: 7
+13:48:12 DEBUG| CPU variant	: 0x0
+13:48:12 DEBUG| CPU part	: 0xc07
+13:48:12 DEBUG| CPU revision	: 5
+13:48:12 DEBUG| processor	: 1
+13:48:12 DEBUG| model name	: ARMv7 Processor rev 5 (v7l)
+13:48:12 DEBUG| BogoMIPS	: 125.00
+13:48:12 DEBUG| Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
+13:48:12 DEBUG| CPU implementer	: 0x41
+13:48:12 DEBUG| CPU architecture: 7
+13:48:12 DEBUG| CPU variant	: 0x0
+13:48:12 DEBUG| CPU part	: 0xc07
+13:48:12 DEBUG| CPU revision	: 5
+13:48:12 DEBUG| processor	: 2
+13:48:12 DEBUG| model name	: ARMv7 Processor rev 5 (v7l)
+13:48:12 DEBUG| BogoMIPS	: 125.00
+13:48:12 DEBUG| Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
+13:48:12 DEBUG| CPU implementer	: 0x41
+13:48:12 DEBUG| CPU architecture: 7
+13:48:12 DEBUG| CPU variant	: 0x0
+13:48:12 DEBUG| CPU part	: 0xc07
+13:48:12 DEBUG| CPU revision	: 5
+13:48:12 DEBUG| processor	: 3
+13:48:12 DEBUG| model name	: ARMv7 Processor rev 5 (v7l)
+13:48:12 DEBUG| BogoMIPS	: 125.00
+13:48:12 DEBUG| Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
+13:48:12 DEBUG| CPU implementer	: 0x41
+13:48:12 DEBUG| CPU architecture: 7
+13:48:12 DEBUG| CPU variant	: 0x0
+13:48:12 DEBUG| CPU part	: 0xc07
+13:48:12 DEBUG| CPU revision	: 5
+13:48:12 DEBUG| Hardware	: BCM2835
+13:48:12 DEBUG| Revision	: 0000
+13:48:12 DEBUG| Serial		: 0000000000000000
+13:48:12 DEBUG| cat /proc/iomem
+13:48:12 DEBUG| / # cat /proc/iomem
+13:48:12 DEBUG| 00000000-3bffffff : System RAM
+13:48:12 DEBUG| 00008000-00afffff : Kernel code
+13:48:12 DEBUG| 00c00000-00d468ef : Kernel data
+13:48:12 DEBUG| 3f006000-3f006fff : dwc_otg
+13:48:12 DEBUG| 3f007000-3f007eff : /soc/dma@7e007000
+13:48:12 DEBUG| 3f00b880-3f00b8bf : /soc/mailbox@7e00b880
+13:48:12 DEBUG| 3f100000-3f100027 : /soc/watchdog@7e100000
+13:48:12 DEBUG| 3f101000-3f102fff : /soc/cprman@7e101000
+13:48:12 DEBUG| 3f200000-3f2000b3 : /soc/gpio@7e200000
+13:53:12 WARNI| qemu received signal 9; command: "./qemu-system-arm -display none -vga none -chardev socket,id=mon,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-monitor.sock -mon chardev=mon,mode=control -machine raspi2b -chardev socket,id=console,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-console.sock,server=on,wait=off -serial chardev:console -kernel /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/kernel7.img -dtb /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/bcm2709-rpi-2-b.dtb -initrd /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/rootfs.cpio -append printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0 -no-reboot"
+13:53:12 ERROR| 
+13:53:12 ERROR| Reproduced traceback from: /var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.9/site-packages/avocado/core/test.py:794
+13:53:12 ERROR| Traceback (most recent call last):
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 514, in _do_shutdown
+13:53:12 ERROR|     self._soft_shutdown(timeout, has_quit)
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 497, in _soft_shutdown
+13:53:12 ERROR|     self._subp.wait(timeout=timeout)
+13:53:12 ERROR|   File "/usr/lib64/python3.9/subprocess.py", line 1189, in wait
+13:53:12 ERROR|     return self._wait(timeout=timeout)
+13:53:12 ERROR|   File "/usr/lib64/python3.9/subprocess.py", line 1909, in _wait
+13:53:12 ERROR|     raise TimeoutExpired(self.args, timeout)
+13:53:12 ERROR| subprocess.TimeoutExpired: Command '('./qemu-system-arm', '-display', 'none', '-vga', 'none', '-chardev', 'socket,id=mon,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-monitor.sock', '-mon', 'chardev=mon,mode=control', '-machine', 'raspi2b', '-chardev', 'socket,id=console,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-console.sock,server=on,wait=off', '-serial', 'chardev:console', '-kernel', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/kernel7.img', '-dtb', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/bcm2709-rpi-2-b.dtb', '-initrd', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/rootfs.cpio', '-append', 'printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0', '-no-reboot')' timed out after 300 seconds
+13:53:12 ERROR| 
+13:53:12 ERROR| The above exception was the direct cause of the following exception:
+13:53:12 ERROR| 
+13:53:12 ERROR| Traceback (most recent call last):
+13:53:12 ERROR|   File "/var/lib/users/cleber/build/qemu/tests/acceptance/boot_linux_console.py", line 502, in test_arm_raspi2_initrd
+13:53:12 ERROR|     self.vm.wait(300)
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 561, in wait
+13:53:12 ERROR|     self.shutdown(has_quit=True, timeout=timeout)
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 544, in shutdown
+13:53:12 ERROR|     self._do_shutdown(timeout, has_quit)
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 517, in _do_shutdown
+13:53:12 ERROR|     raise AbnormalShutdown("Could not perform graceful shutdown") \
+13:53:12 ERROR| qemu.machine.machine.AbnormalShutdown: Could not perform graceful shutdown
+13:53:12 ERROR| 
+13:53:12 DEBUG| Local variables:
+13:53:12 DEBUG|  -> self <class 'boot_linux_console.BootLinuxConsole'>: 01-tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_initrd
+13:53:12 DEBUG|  -> deb_url <class 'str'>: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel_1.20190215-1_armhf.deb
+13:53:12 DEBUG|  -> deb_hash <class 'str'>: cd284220b32128c5084037553db3c482426f3972
+13:53:12 DEBUG|  -> deb_path <class 'str'>: /home/cleber/avocado/data/cache/by_location/c813ab2b9e4f63b2aa876075ad70d638a31a25b7/raspberrypi-kernel_1.20190215-1_armhf.deb
+13:53:12 DEBUG|  -> kernel_path <class 'str'>: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/kernel7.img
+13:53:12 DEBUG|  -> dtb_path <class 'str'>: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/bcm2709-rpi-2-b.dtb
+13:53:12 DEBUG|  -> initrd_url <class 'str'>: https://github.com/groeck/linux-build-test/raw/2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/arm/rootfs-armv7a.cpio.gz
+13:53:12 DEBUG|  -> initrd_hash <class 'str'>: 604b2e45cdf35045846b8bbfbf2129b1891bdc9c
+13:53:12 DEBUG|  -> initrd_path_gz <class 'str'>: /home/cleber/avocado/data/cache/by_location/d100d022b257e2c8f0c0c97434576ed642f9afe5/rootfs-armv7a.cpio.gz
+13:53:12 DEBUG|  -> initrd_path <class 'str'>: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/rootfs.cpio
+13:53:12 DEBUG|  -> kernel_command_line <class 'str'>: printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0
+13:53:12 DEBUG| DATA (filename=output.expected) => NOT FOUND (data sources: variant, test, file)
+13:53:12 DEBUG| DATA (filename=stdout.expected) => NOT FOUND (data sources: variant, test, file)
+13:53:12 DEBUG| DATA (filename=stderr.expected) => NOT FOUND (data sources: variant, test, file)
+13:53:12 ERROR| Traceback (most recent call last):
+
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 514, in _do_shutdown
+    self._soft_shutdown(timeout, has_quit)
+
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 497, in _soft_shutdown
+    self._subp.wait(timeout=timeout)
+
+13:53:12 ERROR|   File "/usr/lib64/python3.9/subprocess.py", line 1189, in wait
+    return self._wait(timeout=timeout)
+
+13:53:12 ERROR|   File "/usr/lib64/python3.9/subprocess.py", line 1909, in _wait
+    raise TimeoutExpired(self.args, timeout)
+
+13:53:12 ERROR| subprocess.TimeoutExpired: Command '('./qemu-system-arm', '-display', 'none', '-vga', 'none', '-chardev', 'socket,id=mon,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-monitor.sock', '-mon', 'chardev=mon,mode=control', '-machine', 'raspi2b', '-chardev', 'socket,id=console,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-console.sock,server=on,wait=off', '-serial', 'chardev:console', '-kernel', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/kernel7.img', '-dtb', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/bcm2709-rpi-2-b.dtb', '-initrd', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/rootfs.cpio', '-append', 'printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0', '-no-reboot')' timed out after 300 seconds
+
+13:53:12 ERROR| 
+The above exception was the direct cause of the following exception:
+
+
+13:53:12 ERROR| Traceback (most recent call last):
+
+13:53:12 ERROR|   File "/var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.9/site-packages/avocado/core/test.py", line 882, in _run_avocado
+    raise test_exception
+
+13:53:12 ERROR|   File "/var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.9/site-packages/avocado/core/test.py", line 789, in _run_avocado
+    testMethod()
+
+13:53:12 ERROR|   File "/var/lib/users/cleber/build/qemu/tests/acceptance/boot_linux_console.py", line 502, in test_arm_raspi2_initrd
+    self.vm.wait(300)
+
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 561, in wait
+    self.shutdown(has_quit=True, timeout=timeout)
+
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 544, in shutdown
+    self._do_shutdown(timeout, has_quit)
+
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 517, in _do_shutdown
+    raise AbnormalShutdown("Could not perform graceful shutdown") \
+
+13:53:12 ERROR| qemu.machine.machine.AbnormalShutdown: Could not perform graceful shutdown
+
+13:53:12 ERROR| ERROR 01-tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_initrd -> AbnormalShutdown: Could not perform graceful shutdown
+13:53:12 INFO | 
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/638 b/gitlab/issues_text/target_arm/host_missing/accel_missing/638
new file mode 100644
index 00000000..9080a4e3
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/638
@@ -0,0 +1,13 @@
+exynos4210_uart.c: SIGSEGV when loadvm
+Description of problem:
+Line 619 of hw/char/exynos4210_uart.c cast the object incorrectly.
+
+The function will be called with Exynos4210UartFIFO as opaque because it is set as `vmstate_exynos4210_uart_fifo.post_load`
+
+#
+Steps to reproduce:
+1. Create a VM with exynos4210_uart
+2. savevm 
+3. loadvm
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/64 b/gitlab/issues_text/target_arm/host_missing/accel_missing/64
new file mode 100644
index 00000000..e42ddbe5
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/64
@@ -0,0 +1 @@
+raspi3 machine can not shutdown
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/656 b/gitlab/issues_text/target_arm/host_missing/accel_missing/656
new file mode 100644
index 00000000..2a8fcd40
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/656
@@ -0,0 +1,7 @@
+qemu-system-arm sabrelite does not use sd card
+Description of problem:
+I have build qemu from source. Furthermore I build Uboot from source following [this Link](https://qemu.readthedocs.io/en/latest/system/arm/sabrelite.html). With the provided command lines I am able to create and image and start the sabrelite board and see Uboot console Output. The problem I am facing is, that I am not able to interact with the provided tmp.img. 
+
+I was also using the -driver option instead of the -blockdev option, but did not get any different results with that.
+Additional information:
+I provide the console output in the attached file. [console.out](/uploads/996b8c07310ec3b008477e3e70a2e629/console.out)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/690 b/gitlab/issues_text/target_arm/host_missing/accel_missing/690
new file mode 100644
index 00000000..8bf9c3be
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/690
@@ -0,0 +1,19 @@
+32bit qemu-arm can't run GCC due to failure to allocate memory range for guest (Allocating guest commpage error)
+Description of problem:
+I'm running ARM binaries using 32 bit qemu-arm-static on x86_64 host. Since version 5.1 (include latest 6.1), QEMU cannot run GCC and some other things with an error `Allocating guest commpage: Operation not permitted`. The problem is NOT reproducible on QEMU 5.0, so probably the problem was caused by a [rework of init_guest_space or the following commits](https://gitlab.com/qemu-project/qemu/-/commit/ee94743034bfb443cf246eda4971bdc15d8ee066) a year ago.
+
+Also the problem is not reproducible for all users. It is known that it is reproduced on all Arch Linux host machines and some Debian, and probably depends on some kernel build parameters.
+
+The sysctl `vm.mmap_min_addr` parameter also affects the problem. The error varies depending on its value:
+```
+[0 ... 53248] - No error at all
+[53249 ... 61440] - Cannot allocate memory
+[61441 ... 65536 and higher] - Operation not permitted
+```
+Steps to reproduce:
+1. Download and extract attached tarball: [qemu-test-gcc.tgz](/uploads/0031fdf6705183626f646b78a281dd2a/qemu-test-gcc.tgz)
+2. `$ make # will build the docker container`
+3. `$ make run # will enter the container`
+4. Once in the container, run: `# /qemu-arm-static-50 /bin/bash /runme.sh`
+Additional information:
+A detailed description of the problem and feedback from other users is here: https://bugs.launchpad.net/qemu/+bug/1891748
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/714 b/gitlab/issues_text/target_arm/host_missing/accel_missing/714
new file mode 100644
index 00000000..eb5290a5
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/714
@@ -0,0 +1,43 @@
+Command line arguments are not passed correctly with user-space semihosting
+Description of problem:
+The emulated process always receives a value of 1 for `argc`, with `argv[0]` returning seemingly random characters (in Ubuntu packaged qemu 5.2), but correlating with command-line input (output below from master built qemu 6.1):
+```
+$ qemu-arm -cpu cortex-m7 ./a.out 123 test
+argc: 1
+argv: 
+ - @@@
+
+$ qemu-arm -cpu cortex-m7 ./a.out 
+argc: 1
+argv:
+ [0] @
+```
+Steps to reproduce:
+1. Compile the following program with [ARM embedded toolchain](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads):
+```cpp
+#include <iostream>
+
+int main(int argc, char* argv[]) {
+	std::cout << "argc: " << argc << "\n";
+	std::cout << "argv: \n";
+
+	for (int i = 0; i < argc; i++)
+		std::cout << " [" << i << "] " << argv[i] << "\n";
+	return 0;
+}
+```
+
+```
+$ $CXX --version
+arm-none-eabi-g++ (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release)
+Copyright (C) 2020 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+$ $CXX main.cpp --specs=rdimon.specs -mcpu=cortex-m7
+```
+
+2. Run in user-space (semihosted):
+```
+$ qemu-arm -cpu cortex-m7 ./a.out 
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/717 b/gitlab/issues_text/target_arm/host_missing/accel_missing/717
new file mode 100644
index 00000000..e56c66b3
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/717
@@ -0,0 +1,3 @@
+using the "scsi-cd" option on arm64 platform
+Description of problem:
+When using OpenStack to create a virtual machine instance, I need to configure the password of the root user through cloud-init. I use the ConfigDriver method, in which OpenStack will mount a virtual disk in iso9660 format to the virtual machine instance. The command line generated by OpenStack is shown above. You can see that this ConfigDrive virtual disk is mounted via "--device scsi-cd". But when I entered the virtual machine instance and used lsblk, blkid and searched in /dev/disk/by-label, I did not find the virtual disk that should be mounted. In addition, I don't have more debugging messages or error messages. I want to know if the "scsi-cd" is not fully adapted to arm64 platform.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/725 b/gitlab/issues_text/target_arm/host_missing/accel_missing/725
new file mode 100644
index 00000000..6d7b10de
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/725
@@ -0,0 +1,14 @@
+GICv3 ITS CTLR[Enabled] bit can not be cleared
+Description of problem:
+ITS CTLR[Enabled] can not be cleared, 
+
+    `s->ctlr |= (value & ~(s->ctlr));`
+
+Link:
+https://gitlab.com/qemu-project/qemu/-/blob/master/hw/intc/arm_gicv3_its.c#L899
+Steps to reproduce:
+1. 
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/729 b/gitlab/issues_text/target_arm/host_missing/accel_missing/729
new file mode 100644
index 00000000..bf2aac17
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/729
@@ -0,0 +1,34 @@
+Environment variables are not passed with user-space semihosting
+Description of problem:
+Environment variables are not passed to the emulated process, either inherited (as I might expect it to work in user-space?) or by specifying the values through the QEMU command-line. Note that setting the environment variable from within the app before calling `getenv` does work, so it isn't just a case of some system no-ops for the platform.
+Steps to reproduce:
+1. Compile the following program with [ARM embedded toolchain](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads):
+```cpp
+#include <iostream>
+#include <cstdlib>
+
+int main(int argc, char* argv[]) {
+	char* env = std::getenv("TEST");
+	if (env)
+		std::cout << "Env TEST: " << env << "\n";
+	else
+		std::cout << "Env TEST not set.\n";
+	return 0;
+}
+```
+
+```
+$ $CXX --version
+arm-none-eabi-g++ (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release)
+Copyright (C) 2020 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+$ $CXX main.cpp --specs=rdimon.specs -mcpu=cortex-m7
+```
+
+2. Run in user-space (semihosted):
+```
+$ qemu-arm -cpu cortex-m7 -E TEST=val123 ./a.out 
+Env TEST not set.
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/736 b/gitlab/issues_text/target_arm/host_missing/accel_missing/736
new file mode 100644
index 00000000..3e1f0eac
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/736
@@ -0,0 +1,47 @@
+qemu-system-arm crash (hardware error: tsc210x_txrx: FIXME: bad SPI word width 24)
+Description of problem:
+The `tests/avocado/machine_arm_n8x0.py:N8x0Machine.test_n800` will sometimes trigger situation where the test does not progress and ends up interrupted.  One example is [here](https://gitlab.com/qemu-project/qemu/-/jobs/1796742618#L242):
+
+```
+(075/171) tests/avocado/machine_arm_n8x0.py:N8x0Machine.test_n800:  INTERRUPTED: Test interrupted by SIGTERM\nRunner error occurred: Timeout reached\nOriginal status: ERROR\n{'name': '075-tests/avocado/machine_arm_n8x0.py:N8x0Machine.test_n800', 'logdir': '/builds/qem
+```
+Steps to reproduce:
+1. ./tests/venv/bin/avocado assets fetch tests/avocado/machine_arm_n8x0.py
+2. nc -l -U /var/tmp/qemu-monitor.sock
+3. ./qemu-system-arm -display none -vga none -chardev socket,id=mon,path=/var/tmp/qemu-monitor.sock -mon chardev=mon,mode=control -machine n800 -serial null -chardev socket,id=console,path=/var/tmp/qemu-51887-console.sock,server=on,wait=off -serial chardev:console -kernel $HOME/avocado/data/cache/by_location/07af9de13713c2905e8c6a88d6600eb1bc885c5c/meego-arm-n8x0-1.0.80.20100712.1431-vmlinuz-2.6.35~rc4-129.1-n8x0 -append 'printk.time=0 console=ttyS1'
+Additional information:
+```
+#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
+#1  0x00007ffff4d498c3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
+#2  0x00007ffff4cfc6b6 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
+#3  0x00007ffff4ce67d3 in __GI_abort () at abort.c:79
+#4  0x0000555555e544b3 in hw_error (fmt=0x555556264da8 "%s: FIXME: bad SPI word width %i\n") at ../../src/qemu/softmmu/cpus.c:126
+#5  0x0000555555a8f4b8 in tsc210x_txrx (opaque=0x5555579e9820, value=6468416, len=24) at ../../src/qemu/hw/input/tsc210x.c:913
+#6  0x0000555555bf49c1 in omap_mcspi_transfer_run (s=0x555557757d10, chnum=0) at ../../src/qemu/hw/ssi/omap_spi.c:93
+#7  0x0000555555bf536b in omap_mcspi_write (opaque=0x555557757d10, addr=56, value=6468416, size=4) at ../../src/qemu/hw/ssi/omap_spi.c:335
+#8  0x0000555555e68f05 in memory_region_write_accessor
+    (mr=0x555557757d10, addr=56, value=0x7fffe7034cc8, size=4, shift=0, mask=4294967295, attrs=...) at ../../src/qemu/softmmu/memory.c:492
+#9  0x0000555555e6914b in access_with_adjusted_size (addr=56, value=0x7fffe7034cc8, size=4, access_size_min=1, access_size_max=4, access_fn=
+    0x555555e68e0f <memory_region_write_accessor>, mr=0x555557757d10, attrs=...) at ../../src/qemu/softmmu/memory.c:554
+#10 0x0000555555e6c1e4 in memory_region_dispatch_write (mr=0x555557757d10, addr=56, data=6468416, op=MO_32, attrs=...)
+    at ../../src/qemu/softmmu/memory.c:1504
+#11 0x0000555555fa9936 in io_writex
+    (env=0x555556e419f0, iotlbentry=0x7fff581ad800, mmu_idx=10, val=6468416, addr=4194926648, retaddr=140734913962650, op=MO_32)
+    at ../../src/qemu/accel/tcg/cputlb.c:1420
+#12 0x0000555555fac1b1 in store_helper (env=0x555556e419f0, addr=4194926648, val=6468416, oi=42, retaddr=140734913962650, op=MO_32)
+    at ../../src/qemu/accel/tcg/cputlb.c:2355
+#13 0x0000555555fac571 in full_le_stl_mmu (env=0x555556e419f0, addr=4194926648, val=6468416, oi=42, retaddr=140734913962650)
+    at ../../src/qemu/accel/tcg/cputlb.c:2443
+#14 0x0000555555fac5a9 in helper_le_stl_mmu (env=0x555556e419f0, addr=4194926648, val=6468416, oi=42, retaddr=140734913962650)
+    at ../../src/qemu/accel/tcg/cputlb.c:2449
+#15 0x00007fff668de29a in code_gen_buffer ()
+#16 0x0000555555f95c5d in cpu_tb_exec (cpu=0x555556e37c60, itb=0x7fffa3aae140, tb_exit=0x7fffe703540c) at ../../src/qemu/accel/tcg/cpu-exec.c:357
+#17 0x0000555555f96afe in cpu_loop_exec_tb (cpu=0x555556e37c60, tb=0x7fffa3aae140, last_tb=0x7fffe7035420, tb_exit=0x7fffe703540c)
+    at ../../src/qemu/accel/tcg/cpu-exec.c:833
+#18 0x0000555555f96ed7 in cpu_exec (cpu=0x555556e37c60) at ../../src/qemu/accel/tcg/cpu-exec.c:992
+#19 0x0000555555fb9682 in tcg_cpus_exec (cpu=0x555556e37c60) at ../../src/qemu/accel/tcg/tcg-accel-ops.c:67
+#20 0x0000555555fb9a13 in mttcg_cpu_thread_fn (arg=0x555556e37c60) at ../../src/qemu/accel/tcg/tcg-accel-ops-mttcg.c:95
+#21 0x0000555556179831 in qemu_thread_start (args=0x55555700dbc0) at ../../src/qemu/util/qemu-thread-posix.c:556
+#22 0x00007ffff4d47b17 in start_thread (arg=<optimized out>) at pthread_create.c:435
+#23 0x00007ffff4dcc6c0 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/789 b/gitlab/issues_text/target_arm/host_missing/accel_missing/789
new file mode 100644
index 00000000..51fc2dca
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/789
@@ -0,0 +1,12 @@
+QEMU arm (not arm64) crashes on apple silicon when run via docker desktop
+Description of problem:
+docker build of the simple Dockerfile here causes QEMU to crash in arm
+emulation. It is perfectly reproducible.
+
+FROM balenalib/rpi-raspbian:bullseye-20210925
+
+USER root
+
+RUN apt-get update -y && apt-get upgrade -y
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/803 b/gitlab/issues_text/target_arm/host_missing/accel_missing/803
new file mode 100644
index 00000000..aca99ef7
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/803
@@ -0,0 +1,20 @@
+v6.2.0 armv7m: savevm fails assertion
+Description of problem:
+Trying to take a snapshot on some arm machines just fails an assertion, while some work fine.  
+e.g. mps2-an385 and stm32vldiscovery don't work, while e.g. raspi0 does.
+```
+$ build/qemu-system-arm -machine mps2-an385 -monitor stdio -drive file=dummy.qcow2 -S 
+QEMU 6.1.50 monitor - type 'help' for more information
+(qemu) VNC server running on ::1:5900
+savevm test
+qemu-system-arm: ../migration/vmstate.c:363: vmstate_save_state_v: Assertion `first_elem || !n_elems || !size' failed.
+[1]    631940 IOT instruction (core dumped)  build/qemu-system-arm -machine mps2-an385 -monitor stdio -drive  -S
+```
+This happens with or without a kernel (so -S is optional, if a kernel is present).
+Steps to reproduce:
+1. Create some image for snapshots (once): ``qemu-img create -f qcow2 dummy.qcow2 32M``
+2. ``qemu-system-arm -machine mps2-an385 -monitor stdio -drive file=dummy.qcow2 -S``
+3. In monitor: ``savevm something``
+Additional information:
+Bisect indicates the Problem first presented itself in commit d5093d961585f02126191951ded9b90dbc52883b by @pm215.  
+This led me to test stm32vldiscovery, which also includes armv7m.h and fails, while some others don't.
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/838 b/gitlab/issues_text/target_arm/host_missing/accel_missing/838
new file mode 100644
index 00000000..97d7b42e
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/838
@@ -0,0 +1 @@
+qemu-system-arm, ast2600-evb, the address mapping of ASPEED_DEV_SPI2 is different from datasheet
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/903 b/gitlab/issues_text/target_arm/host_missing/accel_missing/903
new file mode 100644
index 00000000..fc880ec9
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/903
@@ -0,0 +1,355 @@
+m1 MacOS panic testing lima with qemu HEAD/7.0.0
+Description of problem:
+I'm trying to help the `lima` project test the latest version of lima on m1 with the latest qemu https://github.com/lima-vm/lima/issues/713 and I got a panic and was told to report back in the qemu issue tracker.
+
+I created a VM with 8GiB memory, and got a panic.
+
+
+lima version:
+```
+⎈ |rancher-desktop:default) ~ ❯❯❯ limactl --version                                                                                                                                                                                                                                                                                            ✘ 1 
+limactl version HEAD-1164273
+```
+
+qemu version:
+```
+(⎈ |rancher-desktop:default) ~ ❯❯❯ qemu-system-aarch64 --version
+QEMU emulator version 6.2.50 (v6.2.0-2380-g1416688c53)
+Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
+```
+
+MacOS panic:
+
+```
+panic(cpu 3 caller 0xfffffe001db6ea58): vm_fault() KERN_FAILURE from guest fault on state 0xfffffe6032c98000 @sleh.c:3091
+Debugger message: panic
+Memory ID: 0x6
+OS release type: User
+OS version: 21A559
+Kernel version: Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000
+Fileset Kernelcache UUID: 3B2CA3833A09A383D66FB36667ED9CBF
+Kernel UUID: 67BCB41B-BAA4-3634-8E51-B0210457E324
+iBoot version: iBoot-7429.41.5
+secure boot?: YES
+Paniclog version: 13
+KernelCache slide: 0x00000000160d8000
+KernelCache base:  0xfffffe001d0dc000
+Kernel slide:      0x0000000016900000
+Kernel text base:  0xfffffe001d904000
+Kernel text exec slide: 0x00000000169e8000
+Kernel text exec base:  0xfffffe001d9ec000
+mach_absolute_time: 0x1661a3f15fc
+Epoch Time:        sec       usec
+  Boot    : 0x622a7219 0x00029f9b
+  Sleep   : 0x622ba92c 0x00061dca
+  Wake    : 0x622ba9d3 0x000ae46d
+  Calendar: 0x622bc0fb 0x000caf67
+
+Zone info:
+Foreign   : 0xfffffe0025c14000 - 0xfffffe0025c28000
+Native    : 0xfffffe10003bc000 - 0xfffffe30003bc000
+Readonly  : 0 - 0
+Metadata  : 0xfffffe64105d0000 - 0xfffffe641c53c000
+Bitmaps   : 0xfffffe641c53c000 - 0xfffffe6433f6c000
+CORE 0 PVH locks held: None
+CORE 1 PVH locks held: None
+CORE 2 PVH locks held: None
+CORE 3 PVH locks held: None
+CORE 4 PVH locks held: None
+CORE 5 PVH locks held: None
+CORE 6 PVH locks held: None
+CORE 7 PVH locks held: None
+CORE 8 PVH locks held: None
+CORE 9 PVH locks held: None
+CORE 0: PC=0xfffffe001da72c6c, LR=0xfffffe001da72c6c, FP=0xfffffe6110abbef0
+CORE 1: PC=0xfffffe001f2cdbe0, LR=0xfffffe001f2ceb54, FP=0xfffffe611027b600
+CORE 2: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe603778bef0
+CORE 3 is the one that panicked. Check the full backtrace for details.
+CORE 4: PC=0xfffffe001da72c6c, LR=0xfffffe001da72c6c, FP=0xfffffe61166fbef0
+CORE 5: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe6110a6bef0
+CORE 6: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe61121cbef0
+CORE 7: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe60b4be3ef0
+CORE 8: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe6032af3ef0
+CORE 9: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe6090a4bef0
+Panicked task 0xfffffe150e4ccd50: 17757 pages, 10 threads: pid 21141: qemu-system-aarc
+Panicked thread: 0xfffffe1515ae87d8, backtrace: 0xfffffe60d51e3300, tid: 979402
+		  lr: 0xfffffe001da3e488  fp: 0xfffffe60d51e3370
+		  lr: 0xfffffe001da3e158  fp: 0xfffffe60d51e33e0
+		  lr: 0xfffffe001db7a558  fp: 0xfffffe60d51e3400
+		  lr: 0xfffffe001db6d2d4  fp: 0xfffffe60d51e3480
+		  lr: 0xfffffe001db6ac9c  fp: 0xfffffe60d51e3540
+		  lr: 0xfffffe001d9f37f8  fp: 0xfffffe60d51e3550
+		  lr: 0xfffffe001da3ddcc  fp: 0xfffffe60d51e38f0
+		  lr: 0xfffffe001da3ddcc  fp: 0xfffffe60d51e3960
+		  lr: 0xfffffe001e23c748  fp: 0xfffffe60d51e3980
+		  lr: 0xfffffe001db6ea58  fp: 0xfffffe60d51e39e0
+		  lr: 0xfffffe001db6e5dc  fp: 0xfffffe60d51e3a50
+		  lr: 0xfffffe001d9fe828  fp: 0xfffffe60d51e3a60
+		  lr: 0xfffffe001db823f4  fp: 0xfffffe60d51e3e50
+		  lr: 0xfffffe001db6b140  fp: 0xfffffe60d51e3f10
+		  lr: 0xfffffe001d9f37f8  fp: 0xfffffe60d51e3f20
+
+last started kext at 1368960011: com.apple.filesystems.smbfs	4.0 (addr 0xfffffe001d8ea490, size 64483)
+loaded kexts:
+com.apple.filesystems.smbfs	4.0
+com.apple.filesystems.autofs	3.0
+com.apple.fileutil	20.036.15
+com.apple.UVCService	1
+com.apple.driver.AppleUSBTopCaseDriver	5010.1
+com.apple.iokit.SCSITaskUserClient	452.30.4
+com.apple.driver.AppleIntelI210Ethernet	2.3.1
+com.apple.driver.AppleBiometricServices	1
+com.apple.driver.CoreKDL	1
+com.apple.driver.AppleTopCaseHIDEventDriver	5010.1
+com.apple.driver.SEPHibernation	1
+com.apple.driver.BCMWLANFirmware4387.Hashstore	1
+com.apple.driver.DiskImages.ReadWriteDiskImage	493.0.0
+com.apple.driver.DiskImages.UDIFDiskImage	493.0.0
+com.apple.driver.DiskImages.RAMBackingStore	493.0.0
+com.apple.driver.DiskImages.FileBackingStore	493.0.0
+com.apple.filesystems.apfs	1933.41.2
+com.apple.driver.AppleUSBDeviceNCM	5.0.0
+com.apple.driver.AppleThunderboltIP	4.0.3
+com.apple.driver.AppleFileSystemDriver	3.0.1
+com.apple.nke.l2tp	1.9
+com.apple.filesystems.tmpfs	1
+com.apple.filesystems.lifs	1
+com.apple.IOTextEncryptionFamily	1.0.0
+com.apple.filesystems.hfs.kext	582.40.4
+com.apple.security.BootPolicy	1
+com.apple.BootCache	40
+com.apple.AppleFSCompression.AppleFSCompressionTypeZlib	1.0.0
+com.apple.AppleFSCompression.AppleFSCompressionTypeDataless	1.0.0d1
+com.apple.driver.AppleCS42L84Audio	502.6
+com.apple.driver.ApplePMP	1
+com.apple.driver.AppleSmartIO2	1
+com.apple.driver.AppleSN012776Amp	502.6
+com.apple.AppleEmbeddedSimpleSPINORFlasher	1
+com.apple.driver.AppleT6000SOCTuner	1
+com.apple.driver.AppleT6000CLPCv3	1
+com.apple.driver.AppleSmartBatteryManager	161.0.0
+com.apple.driver.AppleALSColorSensor	1.0.0d1
+com.apple.driver.AppleAOPVoiceTrigger	100.1
+com.apple.driver.ApplePMPFirmware	1
+com.apple.driver.AppleMCDP29XXUpdateSupport	1
+com.apple.driver.AppleM68Buttons	1.0.0d1
+com.apple.driver.AppleSamsungSerial	1.0.0d1
+com.apple.driver.AppleSerialShim	1
+com.apple.driver.usb.AppleSynopsysUSB40XHCI	1
+com.apple.driver.AppleSDXC	3.1.1
+com.apple.driver.AppleSPMIPMU	1.0.1
+com.apple.AGXG13X	187.57
+com.apple.driver.AppleAVD	415
+com.apple.driver.AppleAVE2	501.6.9
+com.apple.driver.AppleJPEGDriver	4.7.8
+com.apple.driver.AppleProResHW	126.2.0
+com.apple.driver.AppleMobileDispT600X-DCP	140.0
+com.apple.driver.AppleDPDisplayTCON	1
+com.apple.driver.AppleEventLogHandler	1
+com.apple.driver.AppleS5L8960XNCO	1
+com.apple.driver.AppleT6001PMGR	1
+com.apple.driver.AppleS8000AES	1
+com.apple.driver.AppleS8000DWI	1.0.0d1
+com.apple.driver.AppleInterruptControllerV2	1.0.0d1
+com.apple.driver.AppleT8110DART	1
+com.apple.driver.AppleBluetoothModule	1
+com.apple.driver.AppleBCMWLANBusInterfacePCIe	1
+com.apple.driver.AppleS5L8920XPWM	1.0.0d1
+com.apple.driver.AudioDMAController-T600x	100.51
+com.apple.driver.AppleT6000DART	1
+com.apple.driver.AppleSPIMC	1
+com.apple.driver.AppleS5L8940XI2C	1.0.0d2
+com.apple.driver.AppleT6000	1
+com.apple.iokit.IOUserEthernet	1.0.1
+com.apple.driver.usb.AppleUSBUserHCI	1
+com.apple.iokit.IOKitRegistryCompatibility	1
+com.apple.iokit.EndpointSecurity	1
+com.apple.driver.AppleDiskImages2	126.40.1
+com.apple.AppleSystemPolicy	2.0.0
+com.apple.nke.applicationfirewall	402
+com.apple.kec.InvalidateHmac	1
+com.apple.kec.AppleEncryptedArchive	1
+com.apple.driver.driverkit.serial	6.0.0
+com.apple.kext.triggers	1.0
+com.apple.driver.AppleUSBMergeNub	900.4.2
+com.apple.driver.usb.cdc.ecm	5.0.0
+com.apple.driver.usb.cdc.acm	5.0.0
+com.apple.driver.usb.serial	6.0.0
+com.apple.driver.usb.cdc.ncm	5.0.0
+com.apple.iokit.IOAVBFamily	1010.2
+com.apple.plugin.IOgPTPPlugin	1000.11
+com.apple.driver.usb.IOUSBHostHIDDevice	1.2
+com.apple.driver.usb.cdc	5.0.0
+com.apple.driver.AppleUSBAudio	412.8
+com.apple.iokit.IOAudioFamily	300.10
+com.apple.vecLib.kext	1.2.0
+com.apple.iokit.IOEthernetAVBController	1.1.0
+com.apple.driver.usb.AppleUSBXHCIPCI	1.2
+com.apple.driver.AppleMesaSEPDriver	100.99
+com.apple.iokit.IOBiometricFamily	1
+com.apple.driver.AppleHIDKeyboard	228
+com.apple.driver.AppleHSBluetoothDriver	5010.1
+com.apple.driver.IOBluetoothHIDDriver	9.0.0
+com.apple.driver.AppleActuatorDriver	5400.25
+com.apple.driver.AppleMultitouchDriver	5400.25
+com.apple.driver.AppleThunderboltPCIUpAdapter	4.1.1
+com.apple.driver.AppleThunderboltDPOutAdapter	8.5.0
+com.apple.driver.AppleSEPHDCPManager	1.0.1
+com.apple.driver.AppleTrustedAccessory	1
+com.apple.iokit.AppleSEPGenericTransfer	1
+com.apple.driver.DiskImages.KernelBacked	493.0.0
+com.apple.driver.AppleXsanScheme	3
+com.apple.driver.usb.networking	5.0.0
+com.apple.driver.AppleThunderboltUSBDownAdapter	1.0.4
+com.apple.driver.AppleThunderboltPCIDownAdapter	4.1.1
+com.apple.driver.AppleThunderboltDPInAdapter	8.5.0
+com.apple.driver.AppleThunderboltDPAdapterFamily	8.5.0
+com.apple.nke.ppp	1.9
+com.apple.driver.AppleHIDTransportSPI	5400.30
+com.apple.driver.AppleHIDTransport	5400.30
+com.apple.driver.AppleInputDeviceSupport	5400.30
+com.apple.driver.AppleBSDKextStarter	3
+com.apple.filesystems.hfs.encodings.kext	1
+com.apple.driver.AppleConvergedIPCOLYBTControl	1
+com.apple.driver.AppleConvergedPCI	1
+com.apple.driver.AppleBluetoothDebug	1
+com.apple.driver.AppleBTM	1.0.1
+com.apple.driver.AppleDiagnosticDataAccessReadOnly	1.0.0
+com.apple.driver.AppleCSEmbeddedAudio	502.6
+com.apple.driver.AppleDCPDPTXProxy	1.0.0
+com.apple.driver.DCPDPFamilyProxy	1
+com.apple.driver.ApplePassthroughPPM	3.0
+com.apple.driver.AppleAOPAudio	102.2
+com.apple.driver.AppleEmbeddedAudio	502.6
+com.apple.iokit.AppleARMIISAudio	100.1
+com.apple.driver.AppleSPU	1
+com.apple.iokit.IONVMeFamily	2.1.0
+com.apple.driver.AppleNANDConfigAccess	1.0.0
+com.apple.AGXFirmwareKextG13XRTBuddy	187.57
+com.apple.AGXFirmwareKextRTBuddy64	187.57
+com.apple.driver.AppleHPM	3.4.4
+com.apple.driver.DCPAVFamilyProxy	1
+com.apple.driver.AppleStockholmControl	1.0.0
+com.apple.driver.AppleT6000TypeCPhy	1
+com.apple.driver.AppleT8103TypeCPhy	1
+com.apple.driver.AppleUSBXDCIARM	1.0
+com.apple.driver.AppleUSBXDCI	1.0
+com.apple.iokit.IOUSBDeviceFamily	2.0.0
+com.apple.driver.usb.AppleSynopsysUSBXHCI	1
+com.apple.driver.usb.AppleUSBXHCI	1.2
+com.apple.driver.AppleEmbeddedUSBHost	1
+com.apple.driver.usb.AppleUSBHub	1.2
+com.apple.driver.usb.AppleUSBHostCompositeDevice	1.2
+com.apple.driver.AppleDialogPMU	1.0.1
+com.apple.driver.AppleSPMI	1.0.1
+com.apple.driver.usb.AppleUSBHostPacketFilter	1.0
+com.apple.iokit.IOGPUFamily	35.11
+com.apple.iokit.IOMobileGraphicsFamily-DCP	343.0.0
+com.apple.driver.AppleDCP	1
+com.apple.driver.AppleFirmwareKit	1
+com.apple.iokit.IOMobileGraphicsFamily	343.0.0
+com.apple.driver.AppleSART	1
+com.apple.driver.ApplePMGR	1
+com.apple.driver.AppleARMWatchdogTimer	1
+com.apple.driver.AppleDisplayCrossbar	1.0.0
+com.apple.iokit.IODisplayPortFamily	1.0.0
+com.apple.driver.AppleTypeCPhy	1
+com.apple.driver.AppleThunderboltNHI	7.2.8
+com.apple.driver.AppleT6000PCIeC	1
+com.apple.iokit.IOThunderboltFamily	9.3.2
+com.apple.driver.ApplePIODMA	1
+com.apple.driver.AppleT600xPCIe	1
+com.apple.driver.AppleMultiFunctionManager	1
+com.apple.driver.AppleBluetoothDebugService	1
+com.apple.driver.AppleBCMWLANCore	1.0.0
+com.apple.iokit.IO80211Family	1200.12.2b1
+com.apple.driver.IOImageLoader	1.0.0
+com.apple.driver.AppleOLYHAL	1
+com.apple.driver.corecapture	1.0.4
+com.apple.driver.AppleEmbeddedPCIE	1
+com.apple.driver.AppleMCA2-T600x	600.95
+com.apple.driver.AppleEmbeddedAudioLibs	100.9.1
+com.apple.driver.AppleFirmwareUpdateKext	1
+com.apple.driver.AppleH13CameraInterface	4.79.0
+com.apple.driver.AppleH10PearlCameraInterface	17.0.3
+com.apple.driver.AppleGPIOICController	1.0.2
+com.apple.driver.AppleFireStormErrorHandler	1
+com.apple.driver.AppleMobileApNonce	1
+com.apple.iokit.IOTimeSyncFamily	1000.11
+com.apple.driver.DiskImages	493.0.0
+com.apple.iokit.IOGraphicsFamily	593
+com.apple.iokit.IOBluetoothSerialManager	9.0.0
+com.apple.iokit.IOBluetoothHostControllerUSBTransport	9.0.0
+com.apple.iokit.IOBluetoothHostControllerUARTTransport	9.0.0
+com.apple.iokit.IOBluetoothHostControllerTransport	9.0.0
+com.apple.driver.IOBluetoothHostControllerPCIeTransport	9.0.0
+com.apple.iokit.IOBluetoothFamily	9.0.0
+com.apple.driver.FairPlayIOKit	68.13.0
+com.apple.iokit.CoreAnalyticsFamily	1
+com.apple.iokit.CSRBluetoothHostControllerUSBTransport	9.0.0
+com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport	9.0.0
+com.apple.driver.AppleSSE	1.0
+com.apple.driver.AppleSEPKeyStore	2
+com.apple.driver.AppleUSBTDM	532.40.7
+com.apple.iokit.IOUSBMassStorageDriver	209.40.6
+com.apple.iokit.IOPCIFamily	2.9
+com.apple.iokit.IOSCSIBlockCommandsDevice	452.30.4
+com.apple.iokit.IOSCSIArchitectureModelFamily	452.30.4
+com.apple.driver.AppleIPAppender	1.0
+com.apple.driver.AppleFDEKeyStore	28.30
+com.apple.driver.AppleEffaceableStorage	1.0
+com.apple.driver.AppleCredentialManager	1.0
+com.apple.driver.KernelRelayHost	1
+com.apple.iokit.IOUSBHostFamily	1.2
+com.apple.driver.AppleUSBHostMergeProperties	1.2
+com.apple.driver.usb.AppleUSBCommon	1.0
+com.apple.driver.AppleSMC	3.1.9
+com.apple.driver.RTBuddy	1.0.0
+com.apple.driver.AppleEmbeddedTempSensor	1.0.0
+com.apple.driver.AppleARMPMU	1.0
+com.apple.iokit.IOAccessoryManager	1.0.0
+com.apple.driver.AppleOnboardSerial	1.0
+com.apple.iokit.IOSkywalkFamily	1.0
+com.apple.driver.mDNSOffloadUserClient	1.0.1b8
+com.apple.iokit.IONetworkingFamily	3.4
+com.apple.iokit.IOSerialFamily	11
+com.apple.driver.AppleSEPManager	1.0.1
+com.apple.driver.AppleA7IOP	1.0.2
+com.apple.driver.IOSlaveProcessor	1
+com.apple.driver.AppleBiometricSensor	2
+com.apple.iokit.IOHIDFamily	2.0.0
+com.apple.driver.AppleANELoadBalancer	5.33.2
+com.apple.driver.AppleH11ANEInterface	5.33.0
+com.apple.AUC	1.0
+com.apple.iokit.IOAVFamily	1.0.0
+com.apple.iokit.IOHDCPFamily	1.0.0
+com.apple.iokit.IOCECFamily	1
+com.apple.iokit.IOAudio2Family	1.0
+com.apple.driver.AppleIISController	100.1
+com.apple.driver.AppleAudioClockLibs	100.9.1
+com.apple.driver.AppleM2ScalerCSCDriver	265.0.0
+com.apple.iokit.IOSurface	302.9
+com.apple.driver.IODARTFamily	1
+com.apple.security.quarantine	4
+com.apple.security.sandbox	300.0
+com.apple.kext.AppleMatch	1.0.0d1
+com.apple.driver.AppleMobileFileIntegrity	1.0.5
+com.apple.security.AppleImage4	4.1.0
+com.apple.kext.CoreTrust	1
+com.apple.iokit.IOCryptoAcceleratorFamily	1.0.1
+com.apple.driver.AppleARMPlatform	1.0.2
+com.apple.iokit.IOStorageFamily	2.1
+com.apple.iokit.IOSlowAdaptiveClockingFamily	1.0.0
+com.apple.iokit.IOReportFamily	47
+com.apple.kec.pthread	1
+com.apple.kec.Libm	1
+com.apple.kec.corecrypto	12.0
+
+
+
+** Stackshot Succeeded ** Bytes Traced 478480 (Uncompressed 1208976) **
+```
+Steps to reproduce:
+1. See https://github.com/lima-vm/lima/issues/713
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/914 b/gitlab/issues_text/target_arm/host_missing/accel_missing/914
new file mode 100644
index 00000000..b19793dc
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/914
@@ -0,0 +1 @@
+Raspi4 emulation
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/920 b/gitlab/issues_text/target_arm/host_missing/accel_missing/920
new file mode 100644
index 00000000..de409ec5
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/920
@@ -0,0 +1,12 @@
+Aarch64 QEMU+KVM+OVMF RAM Bug
+Description of problem:
+OVMF EDK2 does not recognize any amount of RAM.  It always detects as 0 MB and causes operating systems to crash.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+There was a problem with the Redmi Note 10S device via Termux.
+ ![Screenshot_2022-03-19-13-50-58-126_com.realvnc.viewer.android](/uploads/dc4a1b75dde84ea14625aee45bb4684c/Screenshot_2022-03-19-13-50-58-126_com.realvnc.viewer.android.jpg)
+
+ ovmf
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/922 b/gitlab/issues_text/target_arm/host_missing/accel_missing/922
new file mode 100644
index 00000000..6f3e7dc8
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/922
@@ -0,0 +1,20 @@
+QEMU 7.0.0-rc0: Random segfaults when running grep using qemu-arm-static
+Description of problem:
+I'm running ARM binaries using 32 bit qemu-arm-static on x86_64 host. Sometimes when running grep via qemu, I get a random segmentation fault. Sometimes it happens faster, sometimes it takes several thousand iterations, but sooner or later it happens and really annoying.
+
+This problem is also reproduced on 6.2, 5.2 and 5.1 releases, and NOT reproduced on 5.0
+
+I wrote small test to demonstrate this bug.
+Steps to reproduce:
+1. Download the test environment: [qemu-test-segfault.tar.bz2](/uploads/8f52617d46ba1e5bf29fc273cd07131d/qemu-test-segfault.tar.bz2)
+2. `$ make # To build the docker container`
+3. `$ make shell # To run ARM bash`
+4. Inside a container, run `while true; do /qemu /bin/grep -E f text > /dev/null; [ $? -ne 0 ] && break; done`. After a while you will get segfault:
+```
+[root@0d81b08f032b /]# /qemu --version
+qemu-arm version 6.2.90
+Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
+[root@0d81b08f032b /]# while true; do /qemu /bin/grep -E f text > /dev/null; [ $? -ne 0 ] && break; done
+Segmentation fault (core dumped)
+[root@0d81b08f032b /]#
+```
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/923 b/gitlab/issues_text/target_arm/host_missing/accel_missing/923
new file mode 100644
index 00000000..85ada262
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/923
@@ -0,0 +1 @@
+Kernel OOPS on SBSA-ref due to missing watchdog register
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/924 b/gitlab/issues_text/target_arm/host_missing/accel_missing/924
new file mode 100644
index 00000000..928d0d97
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/924
@@ -0,0 +1 @@
+AHCI IRQ lost running Fedora on SBSA-ref
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/95 b/gitlab/issues_text/target_arm/host_missing/accel_missing/95
new file mode 100644
index 00000000..5f205264
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/95
@@ -0,0 +1 @@
+linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils configure check code)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/952 b/gitlab/issues_text/target_arm/host_missing/accel_missing/952
new file mode 100644
index 00000000..82ad1b5c
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/952
@@ -0,0 +1,97 @@
+qemu: uncaught target signal 5 (Trace/breakpoint trap)
+Description of problem:
+I'm getting core dumped when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue.
+
+And I found that QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signal.
+
+0xa602 <_start>         movs    r0, #22   
+                                                                                                                           0xa604 <_start+2>       addw    r1, pc, #186    ; 0xba                                                                                                                                           
+0xa608 <_start+6>       bkpt    0x00ab       
+
+$readelf -h hello
+
+ELF Header:
+  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00  
+  Class:                             ELF32  
+  Data:                              2's complement, little endian  
+  Version:                           1 (current)    
+  OS/ABI:                            UNIX - System V  
+  ABI Version:                       0  
+  Type:                              EXEC (Executable file)  
+  Machine:                           ARM  
+  Version:                           0x1  
+  Entry point address:               0xa603  
+  Start of program headers:          52 (bytes into file)  
+  Start of section headers:          144128 (bytes into file)  
+  Flags:                             0x5000200, Version5 EABI, soft-float ABI  
+  Size of this header:               52 (bytes)  
+  Size of program headers:           32 (bytes)  
+  Number of program headers:         5  
+  Size of section headers:           40 (bytes)  
+  Number of section headers:         16  
+  Section header string table index: 14  
+
+And I have check that the bug(https://bugs.launchpad.net/qemu/+bug/1873898) is fixed.
+
+But it's coredump.
+
+I found that bkpt instruction is not recognized, the bkpt is in 0x0000a608.
+
+host：
+```
+$qemu-arm -g 12345 hello  
+```
+service:
+```
+$gdb-multiarch hello  
+(gdb) target remote localhost:12345  
+Remote debugging using localhost:12345  
+0x0000a602 in _start ()  
+(gdb) ni  
+0x0000a604 in _start ()
+(gdb)  
+0x0000a608 in _start ()
+(gdb)  
+0x0000a608 in _start ()
+```
+Another way to check:
+```
+$gdb qemu-arm
+(gdb) run hello
+(gdb) bt
+#0  0x00007ffff79474ba in __GI___sigsuspend (set=set@entry=0x7fffffffd9d8) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26
+#1  0x000055555573bfff in dump_core_and_abort (target_sig=target_sig@entry=5) at ../linux-user/signal.c:772
+#2  0x000055555573c3c8 in handle_pending_signal (cpu_env=cpu_env@entry=0x555555da5940, sig=sig@entry=5, k=k@entry=0x555555e60e00) at ../linux-user/signal.c:1099
+#3  0x000055555573de8c in process_pending_signals (cpu_env=cpu_env@entry=0x555555da5940) at ../linux-user/signal.c:1175
+#4  0x0000555555622070 in cpu_loop (env=0x555555da5940) at ../linux-user/arm/cpu_loop.c:472
+#5  0x0000555555603cf4 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../linux-user/main.c:883
+(gdb) up
+#1  0x000055555573bfff in dump_core_and_abort (target_sig=target_sig@entry=5) at ../linux-user/signal.c:772
+772         sigsuspend(&act.sa_mask);
+(gdb)
+#2  0x000055555573c3c8 in handle_pending_signal (cpu_env=cpu_env@entry=0x555555da5940, sig=sig@entry=5, k=k@entry=0x555555e60e00) at ../linux-user/signal.c:1099
+1099            dump_core_and_abort(sig);
+(gdb)
+#3  0x000055555573de8c in process_pending_signals (cpu_env=cpu_env@entry=0x555555da5940) at ../linux-user/signal.c:1175
+1175                handle_pending_signal(cpu_env, sig, &ts->sync_signal);
+(gdb)
+#4  0x0000555555622070 in cpu_loop (env=0x555555da5940) at ../linux-user/arm/cpu_loop.c:472
+472             process_pending_signals(env);
+(gdb) l
+467             default:
+468             error:
+469                 EXCP_DUMP(env, "qemu: unhandled CPU exception 0x%x - aborting\n", trapnr);
+470                 abort();
+471             }
+472             process_pending_signals(env);
+473         }
+474     }
+475
+476     void target_cpu_copy_regs(CPUArchState *env, struct target_pt_regs *regs)
+(gdb) p cpu_exec(cs)
+$2 = 7
+```
+Here process_pending_signals(env) gives SIGTRAP??
+
+Here is my binary:
+[hello](/uploads/7225e1f1c5a61ace40f90d5d2401a758/hello)
diff --git a/gitlab/issues_text/target_arm/host_missing/accel_missing/970 b/gitlab/issues_text/target_arm/host_missing/accel_missing/970
new file mode 100644
index 00000000..c6890f82
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_missing/accel_missing/970
@@ -0,0 +1,33 @@
+ARM SCTLR allows writes to "write ignore" bits
+Description of problem:
+The firmware I have executed in qemu sets up pagetables and then enables the MMU.
+A few instructions later, a prefetch abort was occurring. After debugging it turned out the problem was because get_phys_addr_v5 was being used to walk the pagetable instead of get_phys_addr_v6.
+qemu has this code:
+```c
+regime_sctlr(env, mmu_idx) & SCTLR_XP
+// where SCTLR_XP is commented as
+#define SCTLR_XP      (1U << 23) /* up to v6; v7 onward RAO */
+```
+Somewhat interestingly, A5 has a lot of bits marked as `/WI`: https://developer.arm.com/documentation/ddi0433/c/system-control/register-descriptions/system-control-register
+
+A9 has less, but still a few which qemu is not handling: https://developer.arm.com/documentation/ddi0388/e/the-system-control-coprocessors/summary-of-system-control-coprocessor-registers/system-control-register
+I've made this hacky patch to fix it for myself:
+```diff
+diff --git a/qemu/target/arm/helper.c b/qemu/target/arm/helper.c
+index 60c9db9e..d8fd5a7d 100644
+--- a/qemu/target/arm/helper.c
++++ b/qemu/target/arm/helper.c
+@@ -4306,6 +4306,11 @@ static void sctlr_write(CPUARMState *env, const ARMCPRegInfo *ri,
+ {
+     ARMCPU *cpu = env_archcpu(env);
+
++    // for cortex-a5 specifically
++    value |= (0b11 << 22) | (1 << 18) | (1 << 16) | (0b1111 << 3);
++    value &= ~((1 << 31) | (0b11 << 26) | (1 << 24) | (0b111 << 19) |
++        (1 << 17) | (0b11 << 14) | (0b111 << 7));
++
+     if (raw_read(env, ri) == value) {
+         /* Skip the TLB flush if nothing actually changed; Linux likes
+          * to do a lot of pointless SCTLR writes.
+```
+I think the real fix would allow expressing the ones/zeros mask as part of `ARMCPU` per-arch.
diff --git a/gitlab/issues_text/target_arm/host_ppc/accel_missing/1528 b/gitlab/issues_text/target_arm/host_ppc/accel_missing/1528
new file mode 100644
index 00000000..f8816a1b
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_ppc/accel_missing/1528
@@ -0,0 +1,9 @@
+ppc64le: qemu-arm: basic hello world fails with "user-exec.c:492: page_set_flags: Assertion `start < end' failed."
+Description of problem:
+Trying to utilize a RH8 enterprise POWER9 based server to build OpenBMC which utilizes qemu under the covers to validate cross compiles. After some debug, I found that a basic hello-world cross compiled application does not work on POWER9 hardware.
+Steps to reproduce:
+1. Create basic hello world .c file, cross compile it for arm (arm-linux-gnueabi-gcc hello.c -o hello)
+2. Build latest qemu-arm from master
+3. Run qemu-arm against hello world binary
+Additional information:
+
diff --git a/gitlab/issues_text/target_arm/host_s390/accel_TCG/1751 b/gitlab/issues_text/target_arm/host_s390/accel_TCG/1751
new file mode 100644
index 00000000..71736300
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_s390/accel_TCG/1751
@@ -0,0 +1 @@
+s390 host: helper_st16_mmu: Assertion `(get_memop(oi) & MO_SIZE) == MO_128' failed
diff --git a/gitlab/issues_text/target_arm/host_s390/accel_TCG/187 b/gitlab/issues_text/target_arm/host_s390/accel_TCG/187
new file mode 100644
index 00000000..43e46a2d
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_s390/accel_TCG/187
@@ -0,0 +1 @@
+Cannot boot arm kernel images on s390x
diff --git a/gitlab/issues_text/target_arm/host_s390/accel_missing/1333 b/gitlab/issues_text/target_arm/host_s390/accel_missing/1333
new file mode 100644
index 00000000..b3b83454
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_s390/accel_missing/1333
@@ -0,0 +1,11 @@
+vhost-user-test qos-test fails on s390x host
+Description of problem:
+The qos-test is now definitely failing in the ubuntu-20.04-s390x-all CI job. See https://gitlab.com/qemu-project/qemu/-/jobs/3363173491 , then click on "Complete Raw" to see the full log. Quoting:
+
+```
+ERROR:../tests/qtest/vhost-user-test.c:248:wait_for_fds: assertion failed: (s->fds_num)
+**
+ERROR:../tests/qtest/qos-test.c:191:subprocess_run_one_test: child process (/arm/virt/virtio-mmio/virtio-bus/vhost-user-gpio-device/vhost-user-gpio/vhost-user-gpio-tests/read-guest-mem/memfile/subprocess [274051]) failed unexpectedly
+
+(test program exited with status code -6)
+```
diff --git a/gitlab/issues_text/target_arm/host_s390/accel_missing/2973 b/gitlab/issues_text/target_arm/host_s390/accel_missing/2973
new file mode 100644
index 00000000..29a62878
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_s390/accel_missing/2973
@@ -0,0 +1,63 @@
+ast2700a0-evb machine hangs in U-Boot when trying to determine the RAM size
+Description of problem:
+On a BE host, the ast2700a0-evb machine hangs in U-Boot when trying to determine the RAM size if the RAM size is set to a value other than 8 GB.
+Steps to reproduce:
+1. ./qemu-system-aarch64 -machine ast2700a0-evb  -m 1g 
+2.
+3.
+Additional information:
+On a BE host, if I run an ast2700a0-evb machine :
+   ```
+   $ qemu-system-aarch64 -machine ast2700a0-evb  ...
+   ...
+   U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
+
+   SOC: AST2700-A0
+   Model: AST2700 EVB
+   DRAM:  8 GiB (effective 0 Bytes)
+   ```
+
+QEMU hangs.
+
+If the RAM size is defined to 8g
+   ```
+   $ qemu-system-aarch64 -machine ast2700a0-evb -m 8g  ...
+   ...
+   U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
+
+   SOC: AST2700-A0
+   Model: AST2700 EVB
+   DRAM:  8 GiB
+   aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp. version(0)
+   Core:  125 devices, 27 uclasses, devicetree: separate
+   ```
+
+machine boots.
+
+Whereas, with an ast2700a1-evb machine :
+   ```
+   $ qemu-system-aarch64 -machine ast2700a1-evb  ...
+   ...
+   U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
+
+   SOC: AST2700-A1
+   Model: AST2700 EVB
+   DRAM:  1 GiB
+   aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp. version(0)
+   Core:  125 devices, 27 uclasses, devicetree: separate
+   ```
+
+machine boots.
+   ```
+   $ qemu-system-aarch64 -machine ast2700a1-evb -m 8g  ...
+   ...
+   U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
+
+   SOC: AST2700-A1
+   Model: AST2700 EVB
+   DRAM:  8 GiB
+   aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp. version(0)
+   Core:  125 devices, 27 uclasses, devicetree: separate
+   ```
+
+machine boots.
diff --git a/gitlab/issues_text/target_arm/host_x86/accel_TCG/1581 b/gitlab/issues_text/target_arm/host_x86/accel_TCG/1581
new file mode 100644
index 00000000..7088d477
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_x86/accel_TCG/1581
@@ -0,0 +1,14 @@
+QEMU TCG crashes when running on windows
+Description of problem:
+QEMU crashes immediately after startup and shows an assertion failure：
+
+ERROR:C:/msys64/home/xxx/qemu/tcg/i386/tcg-target.c.inc:1085:tcg_out_addi_ptr: assertion failed: (64 == 32)
+
+Bail out! ERROR:C:/msys64/home/xxx/qemu/tcg/i386/tcg-target.c.inc:1085:tcg_out_addi_ptr: assertion failed: (64 ==
+ 32)
+Steps to reproduce:
+NA
+Additional information:
+1. This problem only occurs when the host system is windows, and the same QEMU configuration does not have this problem when the host system is Linux.
+2. This problem is related to the -smp parameter of QEMU. If the smp parameter is 1, this problem will not occur.
+3. This problem does not exist in the QEMU version 7.2.
diff --git a/gitlab/issues_text/target_arm/host_x86/accel_TCG/1592 b/gitlab/issues_text/target_arm/host_x86/accel_TCG/1592
new file mode 100644
index 00000000..c3578907
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_x86/accel_TCG/1592
@@ -0,0 +1,16 @@
+QEMU v8.0.0 crashes when running in TCG mode on windows OS
+Description of problem:
+This bug is a follow-up to issue #1581. 
+After the patch 7d9e1ee424b06a43708be02474e6714962cfee92 is merged, QEMU segfaults at startup.
+And the location where the segfault occurs here(from coredump):
+```
+atomic_common.c.inc:60
+CMPXCHG_HELPER(cmpxchgo_le, Int128)
+```
+Steps to reproduce:
+NA
+Additional information:
+1. This problem only occurs when the host system is windows, and the same QEMU configuration does not have this problem when the host system is Linux.
+2. This problem is related to the -smp parameter of QEMU. If the smp parameter is 1, this problem will not occur.
+3. This problem does not exist in the QEMU version 7.2.
+4. What is even more confusing is that if you use gdb to load qemu and run it, this issue cannot be reproduced.
diff --git a/gitlab/issues_text/target_arm/host_x86/accel_TCG/1642 b/gitlab/issues_text/target_arm/host_x86/accel_TCG/1642
new file mode 100644
index 00000000..57ab5633
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_x86/accel_TCG/1642
@@ -0,0 +1,22 @@
+Qemu aarch64 tcg crashes when emulating an STXP instruction but only on a Windows host
+Description of problem:
+Qemu segfaults when trying to emulate an STXP instruction, but only when running natively on a windows host (msys2 build). This is not the same as https://gitlab.com/qemu-project/qemu/-/issues/1581.
+
+I've managed to git-bisect it to this change: https://github.com/qemu/qemu/commit/546789c7df8866c55cae8d3195e8e58328a35d51
+Sadly i cannot investigate it further and contribute a fix, but it seems like a problem with one of the I128 arguments to `helper_atomic_cmpxchgo_le `
+
+UPD: Issue is also in master (as of `caa9cbd566877b34e9abcc04d936116fc5e0ab28`)
+Steps to reproduce:
+N/A
+Additional information:
+```
+Thread 9 received signal SIGSEGV, Segmentation fault.
+0x00007ff67efc32dc in helper_atomic_cmpxchgo_le (env=0x24796b08c10, addr=18446684150325987376, oldv=46236672343829145701101521005152, newv=2595395441251766838621186119693696, oi=3650) at ../accel/tcg/atomic_common.c.inc:60
+60      CMPXCHG_HELPER(cmpxchgo_le, Int128)
+(gdb) bt
+#0  0x00007ff67efc32dc in helper_atomic_cmpxchgo_le (env=0x24796b08c10,
+    addr=18446684150325987376, oldv=46236672343829145701101521005152,
+    newv=2595395441251766838621186119693696, oi=3650) at ../accel/tcg/atomic_common.c.inc:60
+#1  0x00000247a124f73d in ?? ()
+
+```
diff --git a/gitlab/issues_text/target_arm/host_x86/accel_missing/1325 b/gitlab/issues_text/target_arm/host_x86/accel_missing/1325
new file mode 100644
index 00000000..780ebebe
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_x86/accel_missing/1325
@@ -0,0 +1,81 @@
+c++: internal compiler error: Segmentation fault signal terminated program cc1plus when running in qemu-aarch64-static chroot on x86_64
+Description of problem:
+After a moment of compiling the `src/emoji/Provider.cpp` file, `cc1plus` (I assume the compiler program itself) throws a segfault when running in the emulated chroot environment. The error is shown below.
+```
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+c++: internal compiler error: Segmentation fault signal terminated program cc1plus
+Please submit a full bug report, with preprocessed source (by using -freport-bug).
+See <https://github.com/archlinuxarm/PKGBUILDs/issues> for instructions.
+```
+
+This does not happen if you enter the chroot environment on a real ARM device (like a Raspberry PI 3 or 4 or PinePhone). The ARM device does not need to have `qemu-user-static`, nor `qemu-user-static-binfmt` installed because it does not need to emulate an aarch64 CPU.
+Steps to reproduce:
+There are two ways to replicate this. Either use (1) my preconfigured ARM chroot or (2) setup the chroot environment yourself. These instructions assume you are running on Arch Linux (x86_64).
+1. You can use my aarch64 chroot environment provided. (This is the easy way)
+  - 1) Clone the repo I provided and then change into that directory. 
+```bash
+git clone https://github.com/i3Craig/Temp-aarch64-chroot-for-nheko-compile-issues-in-qemu.git
+cd Temp-aarch64-chroot-for-nheko-compile-issues-in-qemu
+```
+  - 2) On your PC, install `qemu-user-static` and `qemu-user-static-binfmt` and `arch-install-scripts`. This will allow us to `chroot` into the Arch Linux ARM image (technically `chroot` will work since we don't need to use `pacman` for anything with this method, so you could skip `arch-install-scripts` if you prefer). `sudo pacman -S qemu-user-static qemu-user-static-binfmt arch-install-scripts`.
+  - 3) I put the chroot environment in a state where you can simply run the following command to build the one file that fails. Run the following command.
+   ```bash
+sudo chroot chroot/  /usr/bin/c++ -DFMT_SHARED -DGSTREAMER_AVAILABLE -DNHEKO_DBUS_SYS -DQAPPLICATION_CLASS=QApplication -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_QUICKCONTROLS2_LIB -DQT_QUICKWIDGETS_LIB -DQT_QUICK_LIB -DQT_SVG_LIB -DQT_WIDGETS_LIB -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DSPDLOG_SHARED_LIB -DXCB_AVAILABLE -Dnheko_EXPORTS -I/home/builder/packages/nheko/src/build -I/home/builder/packages/nheko/src/nheko-0.10.2 -I/home/builder/packages/nheko/src/build/nheko_autogen/include -I/home/builder/packages/nheko/src/nheko-0.10.2/src -I/home/builder/packages/nheko/src/nheko-0.10.2/includes -I/home/builder/packages/nheko/src/nheko-0.10.2/third_party/blurhash -I/home/builder/packages/nheko/src/nheko-0.10.2/third_party/cpp-httplib-0.5.12 -I/home/builder/packages/nheko/src/nheko-0.10.2/third_party/SingleApplication-3.3.2 -isystem /usr/include/qt -isystem /usr/include/qt/QtDBus -isystem /usr/include/qt/QtCore -isystem /usr/lib/qt/mkspecs/linux-g++ -isystem /usr/include/qt/QtWidgets -isystem /usr/include/qt/QtGui -isystem /usr/include/qt/QtSvg -isystem /usr/include/qt/QtConcurrent -isystem /usr/include/qt/QtMultimedia -isystem /usr/include/qt/QtNetwork -isystem /usr/include/qt/QtQml -isystem /usr/include/qt/QtQuickControls2 -isystem /usr/include/qt/QtQuick -isystem /usr/include/qt/QtQmlModels -isystem /usr/include/qt/QtQuickWidgets -isystem /usr/include/gstreamer-1.0 -isystem /usr/include/glib-2.0 -isystem /usr/lib/glib-2.0/include -isystem /usr/include/sysprof-4 -isystem /usr/include/orc-0.4 -isystem /usr/include/libmount -isystem /usr/include/blkid -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -Wp,-D_GLIBCXX_ASSERTIONS -Wall -Wextra -pedantic -fsized-deallocation -fdiagnostics-color=always -Wunreachable-code -Wno-attributes -fPIE -fPIC -DSPDLOG_SHARED_LIB -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -pthread -std=gnu++17 -Winvalid-pch -include /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/cmake_pch.hxx -MD -MT /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/src/emoji/Provider.cpp.o -MF /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/src/emoji/Provider.cpp.o.d -o /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/src/emoji/Provider.cpp.o -c /home/builder/packages/nheko/src/nheko-0.10.2/src/emoji/Provider.cpp
+   ```
+- 4) The above command will fail with a segfault error. If you copy your `chroot` over to a real ARM device (like an Raspberry PI 3 or 4 or PinePhone) and run the compile command from step (3), it will be successful. This suggests that everything is setup correctly, but there is a bug in QEMU that causes the c++ compiler to fail.
+
+2. You can download an Arch Linux ARM image from archlinuxarm.org and chroot into that. Then attempt to build the `nheko` AUR package. (This way requires extra work, but you can use this if you don't trust my chroot archive).
+  - 1) Download Arch Linux ARM to your X86_64 PC. The Raspberry PI 3/4 image should work. `http://os.archlinuxarm.org/os/ArchLinuxARM-rpi-aarch64-latest.tar.gz`. Signatures are available on archlinuxarm.org.
+  - 2) Extract the tar archive: `mkdir chroot; sudo tar -xf ArchLinuxARM-rpi-aarch64-latest.tar.gz -C chroot` (this will extract to the `chroot` folder in your current working directory.
+  - 3) On your PC, install `qemu-user-static` and `qemu-user-static-binfmt` and `arch-install-scripts`. This will allow us to `chroot` into the Arch Linux ARM image (using the `arch-chroot` because we will need to install packages with pacman in the chroot environment). `sudo pacman -S qemu-user-static qemu-user-static-binfmt arch-install-scripts`.
+  - 4) Now, we can bindmount the `chroot` directory to itself so `arch-chroot` is happy. `sudo mount --bind chroot/ chroot/`
+  - 5) Enter the chroot: `sudo arch-chroot chroot/`
+  - 6) At this point, we need to get our build environment setup. Let's start by installing `git`, `base-devel`, `screen` and `vim`. `pacman -S git base-devel screen vim`. I use screen to have one terminal for the root user to install stuff and one for the `builder` user that we will create for building packages as `makepkg` does not particularly like to run as root.
+  - 7) Add the builder user and create its home folder: `useradd builder; mkdir /home/builder; chown builder:builder /home/builder`.
+  - 8) You could maybe use an AUR helper to build the following packages, but they don't have the 'aarch64' flag, so they will throw an error when you try to compile them. Thus, I use `makepkg` manually with the `--ignorearch` flag to ignore the architecture of the chroot environment (they are fully compatible with aarch64, just not marked as such). Thus, run `su -l builder` to switch to the builder user, `mkdir packages` to create the packages folder, and then clone the following AUR packages into this folder and build them: `coeurl  lmdbxx  mtxclient  nheko  tweeny`. These are dependencies for `nheko`. The process is `git clone https://aur.archlinux.org/<PACKAGENAME>.git`, then `cd PACKAGENAME`, then `makepkg --ignorearch`, then (as the root user in the chroot environment - can use sudo if you set it up) `pacman -U PACKAGENAME.PACKAGEVERSION.pkg.tar.xz` (you can type the package name and then use tab to autocomplete the exact package name). They will all compile just fine and install correctly.
+  - 9) Now, do the same for the AUR package `nheko`. Notice that it will start to compile, but the error shown above will be printed on the screen after a while. If you copy your `chroot` over to a real ARM device (like an Raspberry PI 3 or 4 or PinePhone) and `arch-chroot` into it and attempt the compile again, it will be successful. This suggests that everything is setup correctly, but there is a bug in qemu that causes the c++ compiler to fail. This is known to break in nheko version `0.10.2-1`. You can get to this by running `git checkout d83124fbffe86d7f875bf8e56834ae98cc21160c` after you clone the `nheko` AUR build script. This is the current latest version as of writing this, but this may change in the future and the bug may no longer show up. If it doesn't, run that `git checkout` command.
+Additional information:
+After using the `-strace` option in `qemu-aarch64-static` (which has to be copied from the host system to the chroot for this to work: `sudo cp /usr/bin/qemu-aarch64-static chroot/usr/bin/qemu-aarch64-static`), I determined that `c++` was running `/usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/cc1plus`, which segfaulted. Note: have to run `sudo arch-chroot chroot/ /usr/bin/qemu-aarch64-static -strace <PUT LONG C++ COMPILE COMMAND HERE>`.
+After manually running the `cc1plus` command with the `-strace` option outlined above, I get the following strace, which doesn't seem particularly interesting.
+```
+1 brk(0x000000000320a000) = 0x000000000320a000
+1 brk(0x000000000324a000) = 0x000000000324a000
+1 brk(0x00000000032ca000) = 0x00000000032ca000
+1 brk(0x00000000033ca000) = 0x00000000033ca000
+1 brk(0x00000000035ca000) = 0x00000000035ca000
+1 brk(0x00000000031ca000) = 0x00000000031ca000
+1 mmap(NULL,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000005520bc3000
+1 brk(0x000000000320a000) = 0x000000000320a000
+1 brk(0x000000000324a000) = 0x000000000324a000
+1 brk(0x00000000032ca000) = 0x00000000032ca000
+1 brk(0x00000000033ca000) = 0x00000000033ca000
+1 brk(0x00000000035ca000) = 0x00000000035ca000
+1 mmap(NULL,4198400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000005520be3000
+1 brk(0x00000000031ca000) = 0x00000000031ca000
+1 munmap(0x0000005520be3000,4198400) = 0
+1 brk(0x000000000320a000) = 0x000000000320a000
+1 brk(0x000000000324a000) = 0x000000000324a000
+1 brk(0x00000000032ca000) = 0x00000000032ca000
+1 brk(0x00000000033ca000) = 0x00000000033ca000
+1 brk(0x00000000035ca000) = 0x00000000035ca000
+1 brk(0x00000000039ca000) = 0x00000000039ca000
+1 brk(0x00000000031ca000) = 0x00000000031ca000
+1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000005520fe4000
+1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055211e4000
+1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055213e4000
+1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055215e4000
+1 brk(0x00000000031eb000) = 0x00000000031eb000
+1 mmap(NULL,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055217e4000
+1 brk(0x0000000003214000) = 0x0000000003214000
+1 brk(0x0000000003274000) = 0x0000000003274000
+1 brk(0x0000000003295000) = 0x0000000003295000
+1 brk(0x0000000003318000) = 0x0000000003318000
+1 brk(0x0000000003339000) = 0x0000000003339000
+1 brk(0x000000000335a000) = 0x000000000335a000
+--- SIGSEGV {si_signo=SIGSEGV, si_code=2, si_addr=0x0000005500000ff0} ---
+--- SIGSEGV {si_signo=SIGSEGV, si_code=2, si_addr=0x0000005500000ff0} ---
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+```
+
+
+I haven't encountered this bug when compiling any other programs, which is good. However, it mea
diff --git a/gitlab/issues_text/target_arm/host_x86/accel_missing/1858 b/gitlab/issues_text/target_arm/host_x86/accel_missing/1858
new file mode 100644
index 00000000..103f9dac
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_x86/accel_missing/1858
@@ -0,0 +1,10 @@
+Block device read operation misses one byte(8 bit) per chip per SPI transaction
+Description of problem:
+Block device Micron m25qu02gcbb (hw/block/m25p80.c) is emulated by the two -drive files. For block device read operation, device driver from Windriver vxWorks issues SPI commands. For read SPI command( 0x6b ) from device driver, there is a data length to be read is specified. For each SPI command call, m25p80_transfer8(SSISlave *ss, uint32_t tx) from hw/block/m25p80.c is called and read byte is returned to guest OS. It is observed that for more than one sequential SPI read commmands, first byte from the next read block is not returned back to guest OS. Traces within m25p80.c shows that all the data bytes are read however, first byte from the next read block is missing at guest OS.
+ 
+drive file content: 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8
+SPI read command is set to read 4 bytes in one transaction, two transactions are needed from guest OS to read the entire  data.
+trace_m25p80_read_byte() shows that all bytes are read at m25p80_transfer8() call.
+At guest OS following is received: 0x0 0x1 0x2 0x3 0x5 0x6 0x7 0x8 (Missing first byte of the second transaction, 0x4)
+Additional information:
+Windriver is a proprietary OS so I can't attach the .bin files. However, any other guest OS should be able to demostrate this behavior. guest OS device driver is reading without errors on an actual Micron QSPI device.
diff --git a/gitlab/issues_text/target_arm/host_x86/accel_missing/1890 b/gitlab/issues_text/target_arm/host_x86/accel_missing/1890
new file mode 100644
index 00000000..97240831
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_x86/accel_missing/1890
@@ -0,0 +1,25 @@
+qemu-arm 8.1.0 Error mapping file: Operation not permitted
+Description of problem:
+failed to execute the cortex-m binary hello_world, and says:
+qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted
+Steps to reproduce:
+1.
+```
+cat > hello_new.c <<EOF
+#include <stdio.h>
+int main()
+{printf("hello world"); return 0;}
+EOF
+```
+2.
+```
+arm-none-eabi-gcc -mcpu=cortex-m55 -g hello_world.c -o hello_world -specs=rdimon.specs
+```
+3.
+```
+qemu-arm -cpu cortex-m55 hello_world
+qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted
+```
+Additional information:
+1, version 8.0.4 version is okay\
+2, arm-none-eabi-gcc version is 10.3.1 20210824 (release)
diff --git a/gitlab/issues_text/target_arm/host_x86/accel_missing/2146 b/gitlab/issues_text/target_arm/host_x86/accel_missing/2146
new file mode 100644
index 00000000..0a435335
--- /dev/null
+++ b/gitlab/issues_text/target_arm/host_x86/accel_missing/2146
@@ -0,0 +1,114 @@
+qemu-system-aarch64 Segfaults
+Description of problem:
+Never finishes the script below always segfaults after a few hours
+in seemingly random functions.
+Steps to reproduce:
+This is what i did with qemu version 8.2.1
+inside test directory:
+1. wget https://download.qemu.org/qemu-8.2.1.tar.xz
+2. tar xvJf qemu-8.2.1.tar.xz
+3. cd qemu-8.2.1
+4. ./configure --target-list="aarch64-linux-user, aarch64-softmmu" --enable-slirp (crashes with and without --enable-debug)
+5. make -j$(nproc)
+6. ln -sf "$PWD/build/qemu-system-aarch64" "../qemu-system-aarch64"
+7. cd ..
+
+Now the VM
+1. wget -O installer-linux https://deb.debian.org/debian/dists/bookworm/main/installer-arm64/current/images/netboot/debian-installer/arm64/linux
+2. wget -O installer-initrd.gz https://deb.debian.org/debian/dists/bookworm/main/installer-arm64/current/images/netboot/debian-installer/arm64/initrd.gz
+3. qemu-img create -f qcow2 hda.qcow2 15G
+4. ./qemu-system-aarch64 -M virt -m 6G -cpu cortex-a72 \
+      -kernel installer-linux \
+      -initrd installer-initrd.gz \
+      -drive if=none,file=hda.qcow2,format=qcow2,id=hd \
+      -device virtio-blk-pci,drive=hd \
+      -netdev user,id=mynet \
+      -device virtio-net-pci,netdev=mynet \
+      -nographic -no-reboot \
+      -accel tcg,thread=multi \
+      -smp 8
+5. Install minimal debian inside the VM
+6. sudo virt-copy-out -a hda.qcow2 /boot/vmlinuz-6.1.0-17-arm64 /boot/initrd.img-6.1.0-17-arm64 .
+7. ./qemu-system-aarch64 -M virt -m 6G -cpu cortex-a72 \
+      -kernel vmlinuz-6.1.0-17-arm64 \
+      -initrd initrd.img-6.1.0-17-arm64 \
+      -append 'root=/dev/vda2' \
+      -drive if=none,file=hda.qcow2,format=qcow2,id=hd \
+      -device virtio-blk-pci,drive=hd \
+      -netdev user,id=mynet,hostfwd=tcp::10022-:22 \
+      -device virtio-net-pci,netdev=mynet \
+      -nographic \
+      -accel tcg,thread=multi \
+      -smp 8
+8. Now run this script inside some directory inside the VM(you might need to install gcc first)
+
+#!/bin/bash
+
+wget --no-clobber https://sourceware.org/pub/binutils/releases/binutils-2.41.tar.xz   
+wget --no-clobber https://ftp.gnu.org/gnu/mpfr/mpfr-4.2.0.tar.xz   
+wget --no-clobber https://ftp.gnu.org/gnu/gmp/gmp-6.3.0.tar.xz    
+wget --no-clobber https://ftp.gnu.org/gnu/mpc/mpc-1.3.1.tar.gz    
+wget --no-clobber https://ftp.gnu.org/gnu/gcc/gcc-13.2.0/gcc-13.2.0.tar.xz   
+
+BUG_TARGET="$(uname -m)-bug-linux-gnu"
+
+tar -xf binutils-2.41.tar.xz   
+cd binutils-2.41   
+mkdir -vp build   
+cd build   
+../configure --prefix=$PWD        \
+             --with-sysroot=$PWD  \
+             --target=$BUG_TARGET \
+             --disable-nls        \
+             --enable-gprofng=no  \
+             --disable-werror     \
+             --disable-gdb
+make --jobs $(nproc)   
+cd ../..   
+rm -rf binutils   
+
+tar -xf gcc-13.2.0.tar.xz   
+cd gcc-13.2.0   
+tar -xf ../mpfr-4.2.0.tar.xz   
+tar -xf ../gmp-6.3.0.tar.xz   
+tar -xf ../mpc-1.3.1.tar.gz   
+mv mpfr-4.2.0 mpfr   
+mv gmp-6.3.0 gmp   
+mv mpc-1.3.1 mpc   
+mkdir -vp build   
+cd build   
+../configure --prefix=$PWD             \
+             --with-sysroot=$PWD       \
+             --target=$BUG_TARGET      \
+             --with-glibc-version=2.38 \
+             --with-newlib             \
+             --without-headers         \
+             --enable-default-pie      \
+             --enable-default-ssp      \
+             --disable-nls             \
+             --disable-shared          \
+             --disable-multilib        \
+             --disable-threads         \
+             --disable-libatomic       \
+             --disable-libgomp         \
+             --disable-libquadmath     \
+             --disable-libssp          \
+             --disable-libvtv          \
+             --disable-libstdcxx       \
+             --enable-languages=c,c++
+make --jobs $(nproc)   
+cd ../..   
+rm -rf gcc
+Additional information:
+I tried all the versions listed above, 6.2 usually segfaults in binutils while the other two run further.
+
+Example:
+```
+Program terminated with signal SIGSEGV, Segmentation fault.
+#0  0x000055555615dd37 in tlb_index (cpu=<Cannot access memory at address 0x7fffefffe1c8>,
+    mmu_idx=<Cannot access memory at address 0x7fffefffe1c0>,
+    addr=<Cannot access memory at address 0x7fffefffe1b8>)
+    at qemu-8.2.1/include/exec/cpu_ldst.h:367
+367	    uintptr_t size_mask = cpu->neg.tlb.f[mmu_idx].mask >> CPU_TLB_ENTRY_BITS;
+[Current thread is 1 (LWP 857562)]
+```
diff --git a/gitlab/issues_text/target_avr/host_missing/accel_TCG/1118 b/gitlab/issues_text/target_avr/host_missing/accel_TCG/1118
new file mode 100644
index 00000000..23893ca3
--- /dev/null
+++ b/gitlab/issues_text/target_avr/host_missing/accel_TCG/1118
@@ -0,0 +1,75 @@
+[AVR] Interrupt skips to incorrect handler when raised after skipping instruction
+Description of problem:
+If interrupt is raised after instruction that can skip following instruction (for example `CPSE`), and skip condition is active, instead of correct vector, one after it is executed. 
+
+This can happen only if CPSE instruction is at the end of translation block. Usually it is somewhere inside block and very rare arrangement of code is required to get into that error.
+Steps to reproduce:
+Real world scenario is waiting in busy loop for `std::atomic<bool>` set by interrupt, in bigger application, with optimized code and rare chance of code arrangement. Effect usually is landing in `__bad_interrupt` and reset, but can also be executing other interrupt handler.
+
+Synthetic example is:
+
+1. There must be instruction that can skip following instruction (for example `CPSE`), with always-active condition for skip
+2. It must be placed in way, that it will be at the end of translation block.
+
+	Example (addresses matter):
+```
+     ff8:	81 e0       	ldi	r24, 0x01	; 1
+     ffa:	88 13       	cpse	r24, r24
+     ffc:	01 c0       	rjmp	.+2      	; 0x1000
+     ffe:	80 e0       	ldi	r24, 0x00	; 0
+    1000:	00 00       	nop
+```
+
+3. It should be busy-looped to raise chances of encountering that code
+4. Any external interrupt should be generated
+	- the simplest is UART RX on stdin raised by key presses
+
+Fully working example attached, with ELF file, annotated C code, ASM dump, and Makefile that allows compiling and running this scenario (but I don't guarantee that self-compiling would always generate this error - it can move code a bit). 
+
+(please adjust paths to GCC and QEMU in Makefile before using)
+
+[avr-irq-fail.zip](/uploads/b702104098a31754d544d6ae6e60e074/avr-irq-fail.zip)
+
+Running by command:
+
+    ./qemu-system-avr -machine arduino-uno -nographic -monitor null -serial stdio -bios fail.elf
+
+And then press any key until error happens.
+
+It is largely machine independent, I originally encountered that on custom Atmega644 machine.
+Additional information:
+Annotated execution log output of `in_asm`, real-world example:
+
+```
+----------------
+IN: _ZNKSt6atomicIbEcvbEv
+0x00000ff4:  MOVW      r31:r30, r25:r24
+0x00000ff6:  LDDZ      r25, Z+0
+0x00000ff8:  LDI       r24, 1
+0x00000ffa:  CPSE      r25, r1            // <-------------------- it must looks like that, with CPSE at the end
+
+----------------
+IN: _ZNKSt6atomicIbEcvbEv
+0x00000ffc:  RJMP      .+2
+
+----------------
+IN: _ZNKSt6atomicIbEcvbEv
+0x00001000:  RET
+...
+```
+and then:
+```
+// <-------------------- INT 20 raised
+...
+----------------
+IN:
+0x00000050:  JMP       0x1002  // <-- correct vector loaded...
+
+----------------
+IN:
+0x00000054:  JMP       0x1012  // <-- ...but skipping to one after that...
+
+----------------
+IN: __vector_21     // <-- ...and executing incorrect handler
+...
+```
diff --git a/gitlab/issues_text/target_avr/host_missing/accel_TCG/489 b/gitlab/issues_text/target_avr/host_missing/accel_TCG/489
new file mode 100644
index 00000000..3a3df92c
--- /dev/null
+++ b/gitlab/issues_text/target_avr/host_missing/accel_TCG/489
@@ -0,0 +1,37 @@
+Assertion raised when hitting gdb break point in qemu-system-avr
+Description of problem:
+An assertion is triggered when inserting a break point via gdb and continuing from gdb until hitting the break point:
+```
+./qemu-system-avr -nographic -machine uno -s -S -bios simpletest.bin 
+Starting up...
+qemu-system-avr: ../accel/tcg/translate-all.c:1476: tb_gen_code: Assertion `tb->size != 0' failed.
+Aborted (core dumped)
+```
+The matching gdb session:
+```
+~/gdb/gdb-10.1-OK/gdb/avr-gdb 
+GNU gdb (GDB) 10.1
+[snipped copyright notice ]
+(gdb) tar rem :1234
+Remote debugging using :1234
+warning: Target-supplied registers are not supported by the current architecture
+warning: No executable has been specified and target does not support
+determining executable automatically.  Try using the "file" command.
+0x00000000 in ?? ()
+(gdb) b *0xb2
+Breakpoint 1 at 0xb2
+(gdb) c
+Continuing.
+Remote connection closed
+(gdb) 
+```
+Steps to reproduce:
+1. Start qemu with command line given in description above
+2. Connect to qemu session using avr-gdb, also given in description.
+3. From avr-gdb, place a break point somewhere in code, then continue
+4. When qemu reaches break point, an assertion is raised
+Additional information:
+1. When running without a break point there is no assertion
+2. Problem appears to be triggered only when inserted break point is hit.
+3. Stepping in gdb works
+4. This problem isn't evident in qemu 6.0.0
diff --git a/gitlab/issues_text/target_avr/host_missing/accel_TCG/869 b/gitlab/issues_text/target_avr/host_missing/accel_TCG/869
new file mode 100644
index 00000000..6f3a17c7
--- /dev/null
+++ b/gitlab/issues_text/target_avr/host_missing/accel_TCG/869
@@ -0,0 +1,21 @@
+Qemu-system-avr working example
+Description of problem:
+I'm trying to get an Arduino board emulated with QEMU. Unfortunately, I can't get it to work.
+I tried the commands, given in [https://qemu.readthedocs.io/en/latest/system/target-avr.html](https://qemu.readthedocs.io/en/latest/system/target-avr.html) and also downloaded and used the example elf file.
+
+
+I then tried some more basic commands and used`qemu-system-avr -machine uno`. This should
+run without any problems or? I also tried `2009` and `mega2560`.
+
+I also searched on the internet about working examples as well as further usage information, but I couldn't really find much.
+Therefore, I hope someone can help me out or point me to additional material.
+Steps to reproduce:
+1. run `qemu-system-avr -machine uno`
+2. wait around 5-10 seconds
+3. on the terminal the following message appears with the qemu window crashing
+```
+$ qemu-system-avr -machine uno
+  qemu-system-avr: execution left flash memory
+```
+Additional information:
+I'm fairly new to this, so please excuse me if I forgot something to post or made a mistake while posting.
diff --git a/gitlab/issues_text/target_avr/host_missing/accel_missing/1525 b/gitlab/issues_text/target_avr/host_missing/accel_missing/1525
new file mode 100644
index 00000000..aec01b59
--- /dev/null
+++ b/gitlab/issues_text/target_avr/host_missing/accel_missing/1525
@@ -0,0 +1,78 @@
+Wrong initial value of stack pointer on AVR devices
+Description of problem:
+The initial value of stack pointer of AVR MCUs should be RAMEND (address of the end of their RAM), but QEMU initialize them to 0.
+
+`qemu-system-avr -machine help` lists 4 flavors of MCUs which are ATmega168, ATmega2560, ATmega1280, ATmega328P. According to their datasheets, the stack pointer should be initialized as follows on reset.
+
+- [ATmega168](https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-9365-Automotive-Microcontrollers-ATmega88-ATmega168_Datasheet.pdf#page=12): RAMEND (which is 0x04FF)
+- [ATmega2560 and ATmega1280](https://ww1.microchip.com/downloads/en/devicedoc/atmel-2549-8-bit-avr-microcontroller-atmega640-1280-1281-2560-2561_datasheet.pdf#page=15): RAMEND (which is 0x21FF)
+- [ATmega328P](https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061B.pdf#page=22): RAMEND (which is 0x08FF)
+Steps to reproduce:
+1. Assemble the assembly code below: `avrasm2 -fI test.asm`
+
+    ```asm
+    ;; test.asm
+    .INCLUDE "m328Pdef.inc"
+
+    .EQU F_CPU = 16000000
+    .EQU BAUD_RATE = 9600
+    .EQU PRESCALE = (F_CPU / (16 * BAUD_RATE)) - 1
+
+    .CSEG
+    start:
+    	;; initialize USART (serial port)
+    	LDI R16, LOW(PRESCALE)
+    	LDI R17, HIGH(PRESCALE)
+    	STS UBRR0L, R16
+    	STS UBRR0H, R17
+    	LDI R16, (1 << RXEN0) | (1 << TXEN0)
+    	STS UCSR0B, R16
+
+    	;; Get stack pointer low byte and print it in ASCII
+    	IN R16, SPL
+    	LDI R17, 0x30
+    	ADD R16, R17
+    print1:
+    	LDS r17, UCSR0A
+    	SBRS r17, UDRE0
+    	RJMP print1
+    	STS UDR0, r16
+
+    	;; Get stack pointer high byte and print it in ASCII
+    	IN R16, SPH
+    	LDI R17, 0x30
+    	ADD R16, R17
+    print2:
+    	LDS r17, UCSR0A
+    	SBRS r17, UDRE0
+    	RJMP print2
+    	STS UDR0, r16
+
+    end:
+    	RJMP end
+    ```
+
+2. Convert it to bin file: `avr-objcopy --input-target=ihex --output-target=binary test.hex test.bin`
+
+3. Run it with QEMU: `qemu-system-avr -machine uno -bios test.bin -serial stdio`
+
+This should print 00 which means that the stack pointer is initialized to 0.
+Additional information:
+I examined the source code and I think that editing the function `avr_cpu_reset_hold` in `/target/avr/cpu.c` might fix this issue. This is my first time seeing QEMU source code, so I might be wrong, though.
+
+```c
+// in /target/avr/cpu.c line 70
+static void avr_cpu_reset_hold(Object *obj)
+{
+    // ...
+
+    env->rampD = 0;
+    env->rampX = 0;
+    env->rampY = 0;
+    env->rampZ = 0;
+    env->eind = 0;
+    env->sp = 0;    // <-- change this value in accordance with board type?
+
+    //...
+}
+```
diff --git a/gitlab/issues_text/target_hexagon/host_missing/accel_missing/2696 b/gitlab/issues_text/target_hexagon/host_missing/accel_missing/2696
new file mode 100644
index 00000000..5e71d974
--- /dev/null
+++ b/gitlab/issues_text/target_hexagon/host_missing/accel_missing/2696
@@ -0,0 +1,12 @@
+qemu-hexagon 9.2.0-rc1 hits unreachable assertion in decode_insns() on invalid instruction
+Description of problem:
+```
+❯ cat start.s
+.globl _start
+_start: .word 0
+❯ clang start.s -target hexagon-linux -nostdlib -fuse-ld=lld
+❯ qemu-hexagon ./a.out
+**
+ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached
+Bail out! ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached
+```
diff --git a/gitlab/issues_text/target_hexagon/host_missing/accel_missing/805 b/gitlab/issues_text/target_hexagon/host_missing/accel_missing/805
new file mode 100644
index 00000000..c0180e5c
--- /dev/null
+++ b/gitlab/issues_text/target_hexagon/host_missing/accel_missing/805
@@ -0,0 +1,14 @@
+qemu-hexagon: [binary]: Error mapping file: Invalid argument
+Description of problem:
+Running a (32bit) hexagon binary on a 64bit/32bit system gives the following error:
+`qemu-hexagon: hexagon-hello-world: Error mapping file: Invalid argument`
+Steps to reproduce:
+```
+./qemu-hexagon <hexagon-binary>
+qemu-hexagon: hexagon-hello-world: Error mapping file: Invalid argument
+```
+Additional information:
+A similar problem has been reported on the mailing list:
+https://www.mail-archive.com/qemu-devel@nongnu.org/msg836466.html
+
+Unfortunately without a solution.
diff --git a/gitlab/issues_text/target_hexagon/host_missing/accel_missing/831 b/gitlab/issues_text/target_hexagon/host_missing/accel_missing/831
new file mode 100644
index 00000000..67afae3b
--- /dev/null
+++ b/gitlab/issues_text/target_hexagon/host_missing/accel_missing/831
@@ -0,0 +1 @@
+clang compile error because of unused variable
diff --git a/gitlab/issues_text/target_hppa/host_missing/accel_TCG/299 b/gitlab/issues_text/target_hppa/host_missing/accel_TCG/299
new file mode 100644
index 00000000..77e50049
--- /dev/null
+++ b/gitlab/issues_text/target_hppa/host_missing/accel_TCG/299
@@ -0,0 +1 @@
+Tulip NIC not working on OpenBSD/hppa (and more)
diff --git a/gitlab/issues_text/target_hppa/host_missing/accel_TCG/635 b/gitlab/issues_text/target_hppa/host_missing/accel_TCG/635
new file mode 100644
index 00000000..8655b8f5
--- /dev/null
+++ b/gitlab/issues_text/target_hppa/host_missing/accel_TCG/635
@@ -0,0 +1,28 @@
+HPPA Error on Raspberry PI - deposit64: Assertion `start >= 0 && length > 0 && length <= 64 - start' failed
+Description of problem:
+The emulator starts normally but during the Guest OS installation (HP-UX 10.20) it crash with below error:
+(qemu) qemu-system-hppa: /root/qemu/include/qemu/bitops.h:496: deposit64: Assertion `start >= 0 && length > 0 && length <= 64 - start' failed.
+Steps to reproduce:
+1. Run qemu-system-hppa with the command listed above
+2. Start HP-UX 10.20 installation and finish the install wizard
+Additional information:
+It crashes after the installation step bolow:
+
+Executing user specified script:
+=========================================
+
+  [[ ! -a /dev/lan0 ]] && mknod /dev/lan0 c 52 0x000000
+
+=========================================
+       * Will use the cold-install media for swinstall as well.
+       * Starting swinstall:
+WARNING: The software specified contains a kernel fileset.  It will be
+         necessary to reconfigure and reboot the system to make the
+         kernel software functional.
+
+       * Beginning Analysis Phase.
+       * Source:           localhost:/SD_CDROM
+       * Target:           loopback:/
+       * Target logfile:   loopback:/var/adm/sw/swagent.log
+       * Reading source for product information.
+       * Reading source for file information.
diff --git a/gitlab/issues_text/target_hppa/host_missing/accel_missing/1991 b/gitlab/issues_text/target_hppa/host_missing/accel_missing/1991
new file mode 100644
index 00000000..3dc19d69
--- /dev/null
+++ b/gitlab/issues_text/target_hppa/host_missing/accel_missing/1991
@@ -0,0 +1,64 @@
+error "hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached" in qemu-system-hppa
+Description of problem:
+The installation phase terminates with a failed assertion in qemu:
+```
+...
+Rebooting the system
+reboot: Restarting system
+SeaBIOS wants SYSTEM RESET.
+***************************
+**
+ERROR:../hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached
+Bail out! ERROR:../hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached
+Aborted (core dumped)
+```
+Steps to reproduce:
+```
+PATH=$HOME/inst-qemu/8.2.0-rc0/bin:$PATH
+```
+
+Create empty disk:
+```
+qemu-img create -f qcow2 t2sde.qcow2 10G
+```
+
+Pull kernel and initrd out of the installation CD:
+```
+sudo mount -r -t iso9660 -o loop t2-23.6-hppa-minimal-desktop-gcc-glibc.iso /mnt
+mkdir boot-for-install
+cp -p /mnt/boot/* boot-for-install/
+sudo umount /mnt
+```
+
+Run installer:
+```
+machine_args="-M C3700 -m 256"
+disk_args="-drive file=t2sde.qcow2,format=qcow2,id=hd0"
+net_args=""
+#display_args="-monitor stdio -display gtk"
+display_args="-nographic"
+common_args="$machine_args $disk_args $net_args $display_args"
+qemu-system-hppa $common_args \
+  -kernel boot-for-install/vmlinux-6.3.7-t2 -initrd boot-for-install/initrd-6.3.7-t2 \
+  -drive file=t2-23.6-hppa-minimal-desktop-gcc-glibc.iso,if=scsi,bus=0,unit=2,media=cdrom
+```
+
+```
+Serial terminal: <Enter> or console
+# install
+Partition:
+  fdisk
+  n p 1 <Enter> <Enter>
+  w
+On /dev/sda1: Create filesystem of type ext3 with mount point /
+Install the system
+Full install (all packages).
+Keyboard: us
+Root password: t2
+Time zone: Europe/Berlin
+Locale: --
+Finally: <Back>
+Then: <Exit>
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_hppa/host_missing/accel_missing/2918 b/gitlab/issues_text/target_hppa/host_missing/accel_missing/2918
new file mode 100644
index 00000000..b7c50a5f
--- /dev/null
+++ b/gitlab/issues_text/target_hppa/host_missing/accel_missing/2918
@@ -0,0 +1 @@
+qemu-system-hppa hangs on 64bit installations (machine -C3700)
diff --git a/gitlab/issues_text/target_hppa/host_missing/accel_missing/625 b/gitlab/issues_text/target_hppa/host_missing/accel_missing/625
new file mode 100644
index 00000000..0cf5f76a
--- /dev/null
+++ b/gitlab/issues_text/target_hppa/host_missing/accel_missing/625
@@ -0,0 +1,23 @@
+qemu-hppa floating point POWER function is incorrect
+Description of problem:
+The floating point power function produces incorrect values, and possibly stack misshapes as well.
+Steps to reproduce:
+1. $ hppa1.1-unknown-linux-gnu-gcc pow.c -o pow -lm -static
+2. $ qemu-hppa pow
+3. the expected result is 10.0 ^ 6.0 = 6000000.0, instead of 403.45
+Additional information:
+Example C source to reproduce, pow.c:
+```
+#include <stdio.h>
+#include <math.h>
+int main()
+{
+    double base, expo, res;
+    base=10.0;
+    expo=6.0;
+    // res sould be 1e+6
+    res = pow(base, expo);
+    printf("%.1lf^%.1lf = %.2lf\n", base, expo, res);
+    return 0;
+}
+```
diff --git a/gitlab/issues_text/target_hppa/host_x86/accel_TCG/2044 b/gitlab/issues_text/target_hppa/host_x86/accel_TCG/2044
new file mode 100644
index 00000000..40923240
--- /dev/null
+++ b/gitlab/issues_text/target_hppa/host_x86/accel_TCG/2044
@@ -0,0 +1,5 @@
+HP-UX 10.20 doesn't boot on QEMU 8.2.0-rc4
+Description of problem:
+After update QEMU for v8.2.0-rc4 existing HP-UX 10.20 installation doesn't work anymore. I also tried to boot the installation media and SeaBIOS stays in loop.
+Additional information:
+#
diff --git a/gitlab/issues_text/target_i386/host_arm/accel_TCG/1659 b/gitlab/issues_text/target_i386/host_arm/accel_TCG/1659
new file mode 100644
index 00000000..e182cc15
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_arm/accel_TCG/1659
@@ -0,0 +1,27 @@
+x86 vm fails to stop on Darwin aarch64 when qemu compiled with -O1/-O2
+Description of problem:
+When compiled with `-O2` or `-O1` qemu process hangs on full VM stopping on macOS aarch64 host if `shutdown -P now` initiated from guest system.
+Steps to reproduce:
+1. Compile latest qemu version with -O2 (default value) or -O1 passed 
+2. Run qemu-system-x86_64 with ubuntu image, e.g. https://cloud-images.ubuntu.com/focal/20230215/focal-server-cloudimg-amd64.img and custom cloud-init (for user/password authentication)
+3. Wait until image is loaded, connect via vnc or provide login/password in stdio
+4. Initiate shutdown with `sudo shutdown -P now`
+5. See that VM indefinitely shutdowns
+6. Kill VM from host system with kill -9 <qemu-system-x86_64-process-pid>
+7. Recompile qemu with -O0
+8. Repeat steps 2-4
+9. See that vm successfully stopped, and qemu process exited with code 0
+Additional information:
+I've created thread dump from activity monitor with threads which qemu hanging on, attached below
+[sample-qemu-system-x86_64.txt](/uploads/119b89b7f55f4374acb9ae1f9dc2e517/sample-qemu-system-x86_64.txt)
+
+Probably there is some compiler optimisation which prevents qemu threads from receive shutdown signal or appropriate notification from another threads.
+
+The compiler version with which qemu is built:
+```bash
+% cc --version
+Apple clang version 14.0.3 (clang-1403.0.22.14.1)
+Target: arm64-apple-darwin22.4.0
+Thread model: posix
+InstalledDir: /Library/Developer/CommandLineTools/usr/bin
+```
diff --git a/gitlab/issues_text/target_i386/host_arm/accel_TCG/2101 b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2101
new file mode 100644
index 00000000..e92dfe93
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2101
@@ -0,0 +1,17 @@
+[qemu-user/qemu-x86_64] run x86_64 'ls /' on aarch64 platform get wrong result
+Description of problem:
+```
+    qemu-x86_64 -L /tmp/ls-x86_64/root-x86_64-ls  /tmp/ls-x86_64/root-x86_64-ls/bin/ls  -l  /
+    ```
+get wrong result
+Steps to reproduce:
+1. copy /usr/bin/ls and the so library files it depends on from x86_64 platform to aarch64 platform
+2. qemu-x86_64 -L /path/to/x86_64/lib/root/dir  /path/to/ls  /  -l
+Additional information:
+Actual test script:
+```
+# host
+curl -Ls https://github.com/tcler/kiss-vm-ns/raw/master/utils/archive-ld-program.sh | sudo bash /dev/stdin ls
+scp  ls.x86_64.ash  root@jiyin-fedora-39_aarch64:
+ssh root@jiyin-fedora-39_aarch64 ./ls.x86_64.ash -l /
+```
diff --git a/gitlab/issues_text/target_i386/host_arm/accel_TCG/2168 b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2168
new file mode 100644
index 00000000..cd2af620
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2168
@@ -0,0 +1,32 @@
+qemu-x86_64: segfault when running grep on arm64 host
+Description of problem:
+An internal segmentation fault occurs when attempting to run `grep` in a Gentoo stage3 chroot
+Steps to reproduce:
+1. Unpack an x86_64 chroot environment (easiest way is using one of Gentoo's stage3s from https://get.gentoo.org)
+2. Run `qemu-x86_64 -L /path/to/x86_64/chroot /path/to/x86_64/chroot/bin/grep`
+Additional information:
+It seems this only occurs in 8.x.x, 7.x.x does not have this segfault.
+
+Output:
+```
+# qemu-x86_64 -L /bugs/grep-sandbox /bugs/grep-sandbox/bin/grep
+qemu-x86_64: QEMU internal SIGSEGV {code=MAPERR, addr=0x20}
+Segmentation fault
+```
+
+GDB bt:
+```
+(gdb) bt
+#0  open_self_maps_2 (opaque=0xffffffffd0b0, guest_start=18446744073699065856, guest_end=<optimized out>, flags=12) at ../linux-user/syscall.c:8089
+#1  0x000000000048539c in walk_memory_regions (priv=priv@entry=0xffffffffd0b0, fn=fn@entry=0x4a13e4 <open_self_maps_2>) at ../accel/tcg/user-exec.c:176
+#2  0x00000000004a20bc in open_self_maps_1 (smaps=false, fd=3, env=<optimized out>) at ../linux-user/syscall.c:8112
+#3  open_self_maps (cpu_env=<optimized out>, fd=3) at ../linux-user/syscall.c:8122
+#4  0x00000000004aaa00 in do_guest_openat (cpu_env=cpu_env@entry=0x862050, dirfd=dirfd@entry=-100, fname=fname@entry=0x5555555776f1 "/proc/self/maps", flags=0, mode=mode@entry=0, safe=safe@entry=true)
+    at ../linux-user/syscall.c:8381
+#5  0x00000000004b0cc4 in do_syscall1 (cpu_env=cpu_env@entry=0x862050, num=num@entry=257, arg1=arg1@entry=4294967196, arg2=arg2@entry=93824992376561, arg3=arg3@entry=0, arg4=arg4@entry=0,
+    arg5=arg5@entry=93824992373306, arg6=arg6@entry=0, arg8=0, arg7=0) at ../linux-user/syscall.c:9075
+#6  0x00000000004b2770 in do_syscall (cpu_env=cpu_env@entry=0x862050, num=257, arg1=4294967196, arg2=93824992376561, arg3=0, arg4=0, arg5=93824992373306, arg6=0, arg7=arg7@entry=0, arg8=arg8@entry=0)
+    at ../linux-user/syscall.c:13658
+#7  0x0000000000404fdc in cpu_loop (env=env@entry=0x862050) at ../linux-user/x86_64/../i386/cpu_loop.c:242
+#8  0x0000000000400d7c in main (argc=4, argv=0xffffffffed48, envp=<optimized out>) at ../linux-user/main.c:1014
+```
diff --git a/gitlab/issues_text/target_i386/host_arm/accel_TCG/2271 b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2271
new file mode 100644
index 00000000..d192cea1
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2271
@@ -0,0 +1,16 @@
+pci passthrough fails from aarch64 to amd64 guest
+Description of problem:
+**PCIe device Pass-thru from aarch64 host to amd64 guest fails with the below**
+
+qemu-system-amd64: -device vfio-pci,host=0003:06:00.0: VFIO_MAP_DMA failed: Invalid argument
+qemu-system-amd64: -device vfio-pci,host=0003:06:00.0: vfio 0003:06:00.0: failed to setup container for group 25: memory listener initialization failed: Region pc.ram: vfio_dma_map(0xba4058207210, 0x100000, 0xbff00000, 0xeba70a300000) = -22 (Invalid argument)
+
+pass-thru with same command line syntax works correctly if the guest is aarch64 (qemu-system-aarch64).
+
+AMD64 guest VM otherwise works correctly if -device vfio-pci is not used.
+
+libvirt / virtmanager fail for aarch64 host -> amd64 guest as well.
+Steps to reproduce:
+1. Unbind pass-thru device from host.
+2. Attach pass-thru device to vfio-pci
+3. Execute qemu-system-amd64 as above.
diff --git a/gitlab/issues_text/target_i386/host_arm/accel_TCG/2560 b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2560
new file mode 100644
index 00000000..bf6bca7f
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2560
@@ -0,0 +1,105 @@
+Go garbage collector crashes when using qemu-x86_64 on an aarch64 host
+Description of problem:
+Apps compiled for Go and the Go compiler/tool itself crash when they are run with `qemu-x86_64` on an AARCH64 host system. This was not a problem on QEMU 8.2.x (I bisected, see further down). I also seem to recall that Go 1.21 is fine on QEMU 9.x, so maybe some recent change in Go 1.22 + recent changes in QEMU broke something?
+
+The crash from Go seems to be in the garbage collector, I cannot reproduce the issue when I disable the GC with `GOGC=off`.
+
+Output from Go when it crashes:
+
+```
+$ sudo chroot . go build main.go
+runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0
+fatal error: lfstack.push
+
+runtime stack:
+runtime.throw({0xa95b29?, 0x797b1e2a383c?})
+        runtime/panic.go:1023 +0x5c fp=0xc000515f08 sp=0xc000515ed8 pc=0x43c27c
+runtime.(*lfstack).push(0x0?, 0xc0005041c0?)
+        runtime/lfstack.go:29 +0x125 fp=0xc000515f48 sp=0xc000515f08 pc=0x40fd45
+runtime.(*spanSetBlockAlloc).free(...)
+        runtime/mspanset.go:322
+runtime.(*spanSet).reset(0xf46980)
+        runtime/mspanset.go:264 +0x79 fp=0xc000515f78 sp=0xc000515f48 pc=0x437219
+runtime.finishsweep_m()
+        runtime/mgcsweep.go:258 +0x8d fp=0xc000515fb8 sp=0xc000515f78 pc=0x42a6cd
+runtime.gcStart.func2()
+        runtime/mgc.go:685 +0xf fp=0xc000515fc8 sp=0xc000515fb8 pc=0x46e40f
+runtime.systemstack(0x0)
+        runtime/asm_amd64.s:509 +0x4a fp=0xc000515fd8 sp=0xc000515fc8 pc=0x47442a
+````
+Steps to reproduce:
+0. Use an aarch64 host system!
+
+1. Set up binfmt to use qemu-x86_64:
+
+```
+$ cat /proc/sys/fs/binfmt_misc/qemu-x86_64
+enabled
+interpreter /usr/bin/qemu-x86_64
+flags: OCF
+offset 0
+magic 7f454c4602010100000000000000000002003e00
+mask fffffffffffefe00fffffffffffffffffeffffff
+```
+
+2. Download/extract x86_64 rootfs:
+
+```
+$ curl -O https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/alpine-minirootfs-3.20.2-x86_64.tar.gz	
+```
+
+3. Create example app in the x86_64 rootfs:
+
+```
+package main
+
+func main() {
+}
+```
+
+4. Build using chroot:
+
+```
+$ sudo chroot /path/to/x86_64/rootfs apk add go
+$ sudo chroot /path/to/x86_64/rootfs go build main.go
+runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0
+fatal error: lfstack.push
+...
+```
+
+5. As noted previously, if the Go garbage collector is disabled, then it works, presumably because it avoids the bug(?) in QEMU:
+
+```
+$ sudo chroot . env GOGC=off go build main.go
+# might have to mount /dev to build successfully, but Go doesn't panic!
+```
+Additional information:
+I've bisected this exact crash/failure to:
+
+```
+commit 2952b642a555207748dd961fcbfdc48f198eebb6
+Author: Richard Henderson <richard.henderson@linaro.org>
+Date:   Tue Feb 13 10:20:27 2024 -1000
+
+    linux-user: Split out do_munmap
+
+    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
+    Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
+```
+
+Though a different crash starts happening at the commit before that one:
+
+```
+commit ad87d26e6bb13257409f412224c862fc54025e8b
+Author: Richard Henderson <richard.henderson@linaro.org>
+Date:   Tue Jan 2 12:57:55 2024 +1100
+
+    linux-user: Do early mmap placement only for reserved_va
+
+    For reserved_va, place all non-fixed maps then proceed
+    as for MAP_FIXED.
+
+    Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
+```
+
+FYI @rth7680
diff --git a/gitlab/issues_text/target_i386/host_arm/accel_missing/2027 b/gitlab/issues_text/target_i386/host_arm/accel_missing/2027
new file mode 100644
index 00000000..16fd0870
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_arm/accel_missing/2027
@@ -0,0 +1,233 @@
+Go runtime panic with qemu-x86_64-static on aarch64 (bisected)
+Description of problem:
+I have run into some crashes with certain x86 Go binaries running on arm64 (Asahi Linux) using qemu-user-static. The issue is also reproducible on current master (9c74490bff6c8886a922008d0c9ce6cae70dd17e). I have bisected the issue to commit 2d708164e0475064e0e2167bd73e8570e22df1e0:
+
+```
+first bad commit: [2d708164e0475064e0e2167bd73e8570e22df1e0] linux-user: Define TASK_UNMAPPED_BASE in $guest/target_mman.h
+```
+Steps to reproduce:
+1. Build example Go program `GOARCH=amd64 go build -o crashing .`
+2. Run it with `qemu-x86_64-static ./crashing`
+
+<details><summary>Go program to reproduce</summary>
+
+```go
+package main
+
+import "crypto/x509"
+
+func main() {
+  x509.SystemCertPool()
+}
+```
+
+</details>
+Additional information:
+<details><summary>Go program stacktrace</summary>
+
+```
+runtime: lfstack.push invalid packing: node=0xffff3c3a9780 cnt=0x1 packed=0xffff3c3a97800001 -> node=0xffffffff3c3a9780
+fatal error: lfstack.push
+
+runtime stack:
+runtime.throw({0x52cb61?, 0x2ce5?})
+	/usr/lib/golang/src/runtime/panic.go:1077 +0x5c fp=0xc000613f08 sp=0xc000613ed8 pc=0x433d5c
+runtime.(*lfstack).push(0xa0000000002?, 0xffffffffffffefe8?)
+	/usr/lib/golang/src/runtime/lfstack.go:29 +0x125 fp=0xc000613f48 sp=0xc000613f08 pc=0x40ac25
+runtime.(*spanSetBlockAlloc).free(...)
+	/usr/lib/golang/src/runtime/mspanset.go:322
+runtime.(*spanSet).reset(0x64d220)
+	/usr/lib/golang/src/runtime/mspanset.go:264 +0x79 fp=0xc000613f78 sp=0xc000613f48 pc=0x42ef79
+runtime.finishsweep_m()
+	/usr/lib/golang/src/runtime/mgcsweep.go:260 +0x95 fp=0xc000613fb8 sp=0xc000613f78 pc=0x423455
+runtime.gcStart.func2()
+	/usr/lib/golang/src/runtime/mgc.go:687 +0xf fp=0xc000613fc8 sp=0xc000613fb8 pc=0x45bd8f
+traceback: unexpected SPWRITE function runtime.systemstack
+runtime.systemstack()
+	/usr/lib/golang/src/runtime/asm_amd64.s:509 +0x4a fp=0xc000613fd8 sp=0xc000613fc8 pc=0x46016a
+
+goroutine 1 [running]:
+runtime.systemstack_switch()
+	/usr/lib/golang/src/runtime/asm_amd64.s:474 +0x8 fp=0xc0001bb9f0 sp=0xc0001bb9e0 pc=0x460108
+runtime.gcStart({0xc000600000?, 0x98370?, 0x307800?})
+	/usr/lib/golang/src/runtime/mgc.go:686 +0x2e5 fp=0xc0001bba88 sp=0xc0001bb9f0 pc=0x418e05
+runtime.mallocgc(0x98370, 0x50bb80, 0x1)
+	/usr/lib/golang/src/runtime/malloc.go:1242 +0x76f fp=0xc0001bbaf0 sp=0xc0001bba88 pc=0x40caaf
+runtime.makeslice(0xc0001840a8?, 0x26?, 0x0?)
+	/usr/lib/golang/src/runtime/slice.go:103 +0x49 fp=0xc0001bbb18 sp=0xc0001bbaf0 pc=0x449729
+os.ReadFile({0xc00035a0f0?, 0x52dcd6?})
+	/usr/lib/golang/src/os/file.go:738 +0xe5 fp=0xc0001bbbf0 sp=0xc0001bbb18 pc=0x49ed25
+crypto/x509.loadSystemRoots()
+	/usr/lib/golang/src/crypto/x509/root_unix.go:70 +0x3d4 fp=0xc0001bbcd8 sp=0xc0001bbbf0 pc=0x4fdef4
+crypto/x509.initSystemRoots()
+	/usr/lib/golang/src/crypto/x509/root.go:30 +0x5c fp=0xc0001bbd10 sp=0xc0001bbcd8 pc=0x4fd9fc
+sync.(*Once).doSlow(0x1?, 0xb30000c00018ada0?)
+	/usr/lib/golang/src/sync/once.go:74 +0xbf fp=0xc0001bbd70 sp=0xc0001bbd10 pc=0x467bff
+sync.(*Once).Do(...)
+	/usr/lib/golang/src/sync/once.go:65
+crypto/x509.systemRootsPool()
+	/usr/lib/golang/src/crypto/x509/root.go:21 +0x45 fp=0xc0001bbdc0 sp=0xc0001bbd70 pc=0x4fd8a5
+crypto/x509.SystemCertPool()
+	/usr/lib/golang/src/crypto/x509/cert_pool.go:112 +0x25 fp=0xc0001bbf30 sp=0xc0001bbdc0 pc=0x4f6705
+main.main()
+	/home/cyrill/dev/goruntime-crash/main.go:6 +0xf fp=0xc0001bbf40 sp=0xc0001bbf30 pc=0x4ff18f
+runtime.main()
+	/usr/lib/golang/src/runtime/proc.go:267 +0x2bb fp=0xc0001bbfe0 sp=0xc0001bbf40 pc=0x43673b
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc0001bbfe8 sp=0xc0001bbfe0 pc=0x461f61
+
+goroutine 2 [force gc (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004efa8 sp=0xc00004ef88 pc=0x436b8e
+runtime.goparkunlock(...)
+	/usr/lib/golang/src/runtime/proc.go:404
+runtime.forcegchelper()
+	/usr/lib/golang/src/runtime/proc.go:322 +0xb3 fp=0xc00004efe0 sp=0xc00004efa8 pc=0x436a13
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004efe8 sp=0xc00004efe0 pc=0x461f61
+created by runtime.init.6 in goroutine 1
+	/usr/lib/golang/src/runtime/proc.go:310 +0x1a
+
+goroutine 3 [GC sweep wait]:
+runtime.gopark(0x1?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004f778 sp=0xc00004f758 pc=0x436b8e
+runtime.goparkunlock(...)
+	/usr/lib/golang/src/runtime/proc.go:404
+runtime.bgsweep(0x0?)
+	/usr/lib/golang/src/runtime/mgcsweep.go:321 +0xdf fp=0xc00004f7c8 sp=0xc00004f778 pc=0x4235bf
+runtime.gcenable.func1()
+	/usr/lib/golang/src/runtime/mgc.go:200 +0x25 fp=0xc00004f7e0 sp=0xc00004f7c8 pc=0x418945
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004f7e8 sp=0xc00004f7e0 pc=0x461f61
+created by runtime.gcenable in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:200 +0x66
+
+goroutine 4 [GC scavenge wait]:
+runtime.gopark(0xc00006c000?, 0x570658?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004ff70 sp=0xc00004ff50 pc=0x436b8e
+runtime.goparkunlock(...)
+	/usr/lib/golang/src/runtime/proc.go:404
+runtime.(*scavengerState).park(0x625680)
+	/usr/lib/golang/src/runtime/mgcscavenge.go:425 +0x49 fp=0xc00004ffa0 sp=0xc00004ff70 pc=0x420e49
+runtime.bgscavenge(0x0?)
+	/usr/lib/golang/src/runtime/mgcscavenge.go:658 +0x59 fp=0xc00004ffc8 sp=0xc00004ffa0 pc=0x4213f9
+runtime.gcenable.func2()
+	/usr/lib/golang/src/runtime/mgc.go:201 +0x25 fp=0xc00004ffe0 sp=0xc00004ffc8 pc=0x4188e5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004ffe8 sp=0xc00004ffe0 pc=0x461f61
+created by runtime.gcenable in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:201 +0xa5
+
+goroutine 17 [finalizer wait]:
+runtime.gopark(0x400000?, 0x10004e670?, 0x0?, 0x0?, 0x654640?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004e628 sp=0xc00004e608 pc=0x436b8e
+runtime.runfinq()
+	/usr/lib/golang/src/runtime/mfinal.go:193 +0x107 fp=0xc00004e7e0 sp=0xc00004e628 pc=0x4179c7
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004e7e8 sp=0xc00004e7e0 pc=0x461f61
+created by runtime.createfing in goroutine 1
+	/usr/lib/golang/src/runtime/mfinal.go:163 +0x3d
+
+goroutine 18 [GC worker (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004a750 sp=0xc00004a730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004a7e0 sp=0xc00004a750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004a7e8 sp=0xc00004a7e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 19 [GC worker (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004af50 sp=0xc00004af30 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004afe0 sp=0xc00004af50 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004afe8 sp=0xc00004afe0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 33 [GC worker (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc000090750 sp=0xc000090730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc0000907e0 sp=0xc000090750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc0000907e8 sp=0xc0000907e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 20 [GC worker (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004b750 sp=0xc00004b730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004b7e0 sp=0xc00004b750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004b7e8 sp=0xc00004b7e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 49 [GC worker (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00008c750 sp=0xc00008c730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00008c7e0 sp=0xc00008c750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00008c7e8 sp=0xc00008c7e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 21 [GC worker (idle)]:
+runtime.gopark(0xa740c76b8ab?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004bf50 sp=0xc00004bf30 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004bfe0 sp=0xc00004bf50 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004bfe8 sp=0xc00004bfe0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 22 [GC worker (idle)]:
+runtime.gopark(0xa740cc9dc5e?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004c750 sp=0xc00004c730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004c7e0 sp=0xc00004c750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004c7e8 sp=0xc00004c7e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 23 [GC worker (idle)]:
+runtime.gopark(0x654640?, 0x1?, 0xba?, 0x5f?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004cf50 sp=0xc00004cf30 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004cfe0 sp=0xc00004cf50 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004cfe8 sp=0xc00004cfe0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 24 [GC worker (idle)]:
+runtime.gopark(0xa740c58ec16?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004d750 sp=0xc00004d730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004d7e0 sp=0xc00004d750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004d7e8 sp=0xc00004d7e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 34 [GC worker (idle)]:
+runtime.gopark(0x654640?, 0x1?, 0x7a?, 0xa3?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc000090f50 sp=0xc000090f30 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc000090fe0 sp=0xc000090f50 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc000090fe8 sp=0xc000090fe0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+exit status 2
+```
+
+</details>
diff --git a/gitlab/issues_text/target_i386/host_arm/accel_missing/2531 b/gitlab/issues_text/target_i386/host_arm/accel_missing/2531
new file mode 100644
index 00000000..b80654da
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_arm/accel_missing/2531
@@ -0,0 +1,60 @@
+QEMU internal SIGSEGV when creating an x86_64 Debian chroot from an aarch64 host.
+Description of problem:
+When I try to create a x86_64 Debian chroot using debootstrap from an aarch64 host system, QEMU segfaults causing the process to fail.
+Steps to reproduce:
+1. Run `sudo apt install debootstrap qemu-user-static binfmt-support`
+2. Run `sudo debootstrap --arch amd64 bookworm debian_chroot http://deb.debian.org/debian/`
+Additional information:
+End of deboostrap output:
+```
+I: Configuring dash...
+I: Configuring libpam-modules:amd64...
+I: Configuring grep...
+I: Configuring perl-base...
+I: Configuring gzip...
+I: Configuring passwd...
+I: Configuring login...
+I: Configuring apt...
+I: Configuring adduser...
+I: Configuring libc-bin...
+W: Failure while configuring required packages.
+W: See /home/allen/debian_chroot/debootstrap/debootstrap.log for details (possibly the package passwd is at fault)
+```
+
+End of debootstrap log:
+```
+$ tail /home/allen/debian_chroot/debootstrap/debootstrap.log -n30
+Setting up grep (3.8-5) ...
+Setting up perl-base (5.36.0-7+deb12u1) ...
+Setting up gzip (1.12-1) ...
+Setting up passwd (1:4.13+dfsg1-1+b1) ...
+x86_64-binfmt-P: QEMU internal SIGSEGV {code=MAPERR, addr=0x20}
+Segmentation fault
+groupadd: group 'shadow' already exists
+Group ID 42 has been allocated for the shadow group.  You have either
+used 42 yourself or created a shadow group with a different ID.
+Please correct this problem and reconfigure with dpkg --configure passwd''.
+
+Note that both user and group IDs in the range 0-99 are globally
+allocated by the Debian project and must be the same on every Debian
+system.
+dpkg: error processing package passwd (--configure):
+ installed passwd package post-installation script subprocess returned error exit status 1
+Setting up libpam-runtime (1.5.2-6+deb12u1) ...
+Setting up login (1:4.13+dfsg1-1+b1) ...
+dpkg: apt: dependency problems, but configuring anyway as you requested:
+ apt depends on adduser.
+
+Setting up apt (2.6.1) ...
+dpkg: adduser: dependency problems, but configuring anyway as you requested:
+ adduser depends on passwd; however:
+  Package passwd is not configured yet.
+
+Setting up adduser (3.134) ...
+Processing triggers for libc-bin (2.36-9+deb12u7) ...
+Errors were encountered while processing:
+ passwd
+```
+
+Full debootstrap log:
+[debootstrap.log](/uploads/4eb24abd98a647e08bd03deea897b9dd/debootstrap.log)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HAX/325 b/gitlab/issues_text/target_i386/host_missing/accel_HAX/325
new file mode 100644
index 00000000..fd9365c5
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_HAX/325
@@ -0,0 +1 @@
+Latest QEMU crashes when switching color depth of ReactOS
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/1067 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/1067
new file mode 100644
index 00000000..fd91c3be
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_HVF/1067
@@ -0,0 +1,84 @@
+SSH QEMU ISSUE by using with MacOs
+Description of problem:
+ssh connection between Qemu Image and Guest Host (MacOS) broken down after few minutes
+Steps to reproduce:
+1. Take the Qemu window and external ssh connection to backround, \
+   wait until few minutes and the connection are frozen. \
+   If we clicking to qemu window again, the ssh connection are available
+Additional information:
+The ssh connection settings by Macos: \
+Host * \
+AddKeysToAgent yes \
+IdentityFile ~/.ssh/id_rsa \
+IdentitiesOnly yes \
+ServerAliveInterval 3600 \
+TCPKeepAlive yes \
+ServerAliveCountMax 2 \
+\
+\
+SSH connection settings by Ubuntu Server:
+
+Include /etc/ssh/sshd_config.d/*.conf \
+\
+#Port 22 \
+#AddressFamily any \
+#ListenAddress 0.0.0.0 \
+#ListenAddress :: \
+#HostKey /etc/ssh/ssh_host_rsa_key \
+#HostKey /etc/ssh/ssh_host_ecdsa_key \
+#HostKey /etc/ssh/ssh_host_ed25519_key \
+#RekeyLimit default none \
+#SyslogFacility AUTH \
+#LogLevel INFO \
+#LoginGraceTime 2m \
+#PermitRootLogin prohibit-password \
+#StrictModes yes \
+#MaxAuthTries 6 \
+#MaxSessions 10 \
+#PubkeyAuthentication yes \
+#Expect .ssh/authorized_keys2 to be disregarded by default in future. \
+#AuthorizedKeysFile	.ssh/authorized_keys .ssh/authorized_keys2 \
+#AuthorizedPrincipalsFile none \
+#AuthorizedKeysCommand none \
+#AuthorizedKeysCommandUser nobody \
+#HostbasedAuthentication no \
+#IgnoreUserKnownHosts no \
+#IgnoreRhosts yes \
+#PasswordAuthentication yes \
+#PermitEmptyPasswords no \
+ChallengeResponseAuthentication no \
+#KerberosAuthentication no \
+#KerberosOrLocalPasswd yes \
+#KerberosTicketCleanup yes \
+#KerberosGetAFSToken no \
+#GSSAPIAuthentication no \
+#GSSAPICleanupCredentials yes \
+#GSSAPIStrictAcceptorCheck yes \
+#GSSAPIKeyExchange no \
+UsePAM yes \
+#AllowAgentForwarding yes \
+#AllowTcpForwarding yes \
+#GatewayPorts no \
+X11Forwarding yes \
+#X11DisplayOffset 10 \
+#X11UseLocalhost yes \
+#PermitTTY yes \
+PrintMotd no \
+#PrintLastLog yes \
+#TCPKeepAlive yes \
+#PermitUserEnvironment no \
+#Compression delayed \
+#ClientAliveInterval 0 \
+#ClientAliveCountMax 3 \
+#UseDNS no \
+#PidFile /var/run/sshd.pid \
+#MaxStartups 10:30:100 \
+#PermitTunnel no \
+#ChrootDirectory none \
+#VersionAddendum none \
+#Banner none \
+AcceptEnv LANG LC_* \
+PasswordAuthentication yes \
+ClientAliveInterval 600 \
+TCPKeepAlive yes \
+ClientAliveCountMax 10 \
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/150 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/150
new file mode 100644
index 00000000..dbbe0826
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_HVF/150
@@ -0,0 +1 @@
+Illegal Instruction with HVF when encountering SSE instructions in the emulator
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/155 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/155
new file mode 100644
index 00000000..8471bf98
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_HVF/155
@@ -0,0 +1 @@
+MMX emulation is missing on HVF Acceleration
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/1603 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/1603
new file mode 100644
index 00000000..be641041
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_HVF/1603
@@ -0,0 +1,73 @@
+Regression in v8.0.0-rc1: `Abort trap: 6` during `hvf/x86_emu.c:exec_mov()` (`-cpu host` + UEFI)
+Description of problem:
+`qemu-system-x86_64 -accel hvf -cpu host -drive <UEFI>` crashes.
+Steps to reproduce:
+```console
+$ qemu-system-x86_64 -accel hvf -cpu host -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/qemu/edk2-x86_64-code.fd 
+vmx_read_mem: mmu_gva_to_gpa ffc00000 failed
+Abort trap: 6
+```
+Additional information:
+This is a regression in v8.0.0-rc1.
+
+- v8.0.0-rc0: works
+- v8.0.0-rc1: crashes
+- ...
+- v8.0.0-rc4: crashes
+
+
+Backtrace:
+```console
+$ lldb /usr/local/bin/qemu-system-x86_64 
+(lldb) target create "/usr/local/bin/qemu-system-x86_64"
+Current executable set to '/usr/local/bin/qemu-system-x86_64' (x86_64).
+(lldb) process handle SIGUSR2 -s false -p true
+NAME         PASS     STOP     NOTIFY
+===========  =======  =======  =======
+SIGUSR2      true     false    not set
+(lldb) run  -accel hvf -cpu host -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/qemu/edk2-x86_64-code.fd
+Process 17627 launched: '/usr/local/bin/qemu-system-x86_64' (x86_64)
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2
+2023-04-14 17:16:22.879194+0900 qemu-system-x86_64[17627:1529741] [Window] Warning: Window NSWindow 0x10391def0 ordered front from a non-active application and may order beneath the active application's windows.
+vmx_read_mem: mmu_gva_to_gpa ffc00000 failed
+Process 17627 stopped
+* thread #4, stop reason = signal SIGABRT
+    frame #0: 0x00007ff8121331f2 libsystem_kernel.dylib`__pthread_kill + 10
+libsystem_kernel.dylib`:
+->  0x7ff8121331f2 <+10>: jae    0x7ff8121331fc            ; <+20>
+    0x7ff8121331f4 <+12>: movq   %rax, %rdi
+    0x7ff8121331f7 <+15>: jmp    0x7ff81212ccdb            ; cerror_nocancel
+    0x7ff8121331fc <+20>: retq   
+Target 0: (qemu-system-x86_64) stopped.
+(lldb) bt
+* thread #4, stop reason = signal SIGABRT
+  * frame #0: 0x00007ff8121331f2 libsystem_kernel.dylib`__pthread_kill + 10
+    frame #1: 0x00007ff81216aee6 libsystem_pthread.dylib`pthread_kill + 263
+    frame #2: 0x00007ff812091b45 libsystem_c.dylib`abort + 123
+    frame #3: 0x0000000100223608 qemu-system-x86_64`vmx_read_mem + 201
+    frame #4: 0x000000010021fa5b qemu-system-x86_64`read_val_ext + 65
+    frame #5: 0x000000010021fc02 qemu-system-x86_64`fetch_operands + 197
+    frame #6: 0x0000000100220f8b qemu-system-x86_64`exec_mov + 31
+    frame #7: 0x0000000100220f01 qemu-system-x86_64`exec_instruction + 48
+    frame #8: 0x000000010021c81f qemu-system-x86_64`hvf_vcpu_exec + 4144
+    frame #9: 0x000000010033fa53 qemu-system-x86_64`hvf_cpu_thread_fn + 270
+    frame #10: 0x0000000100492e49 qemu-system-x86_64`qemu_thread_start + 130
+    frame #11: 0x00007ff81216b1d3 libsystem_pthread.dylib`_pthread_start + 125
+    frame #12: 0x00007ff812166bd3 libsystem_pthread.dylib`thread_start + 15
+(lldb) 
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/2938 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/2938
new file mode 100644
index 00000000..0ffa4769
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_HVF/2938
@@ -0,0 +1,11 @@
+10.0.0 HVF x86_64 regression: can't boot NetBSD 10.1 with -smp 2
+Description of problem:
+Under 9.2.3, a NetBSD/amd64 10.1 guest with `-smp 2` booted and ran fine.
+
+Under 10.0.0, the same guest never finishes loading the kernel. It looks like it's retrying many times per second, possibly even reloading the NetBSD boot loader each time, though it's redrawing so fast I can't tell for sure. (I'll attempt to link to an asciinema capture shortly.) `-smp 1` lets the machine come up.
+
+For comparison, a NetBSD/aarch64 10.1 with `-smp 4` runs with `-accel hvf` under macOS/aarch64 15.4.1 just as well with 10.0.0 as it did with 9.2.3.
+Steps to reproduce:
+1. With x86 macOS host and NetBSD guest (possibly a wider range than the exact versions I'm currently using), attempt to boot NetBSD with `-smp 2`
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/664 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/664
new file mode 100644
index 00000000..5f8de9c2
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_HVF/664
@@ -0,0 +1,14 @@
+hvf-accelerated x86_64 incorrectly reports virtual address bit width via CPUID
+Description of problem:
+When running qemu-system-x86_64 with hvf acceleration enabled the maximum extended cpuid function (available via EAX=0x80000000) is reported to be 0x80000001, which means that physical address and virtual address bit width (which is supposed to be reported via EAX=0x80000008) is not available. As per the intel IA32/64 manual: `Processors that do not support CPUID function 80000008H, support a linear-address width of 32.`, while in actuality qemu-system-x86_64 with hvf acceleration supports virtual addresses of up to 48 bit in width, like most modern x86_64 processors.
+Steps to reproduce:
+This can be observed when running SerenityOS on x86_64 qemu with hvf acceleration based on the following dmesg lines:
+```
+[Kernel]: CPU[0]: Physical address bit width: 36
+[Kernel]: CPU[0]: Virtual address bit width: 32
+```
+But can also be reproduced by running the CPUID instruction with EAX set to 0x80000000 and observing that the returned value is 0x80000001.
+Additional information:
+The best way to resolve this as far as I can tell is to expose the 0x80000008 CPUID function and report the real values.
+
+NOTE: This is a report of the underlying bug that was found during the investigation of an issue raised in the SerenityOS repository, see https://github.com/SerenityOS/serenity/issues/10382 for more information.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/886 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/886
new file mode 100644
index 00000000..a5fc2840
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_HVF/886
@@ -0,0 +1,16 @@
+OpenIndiana panics when using -accel hvf
+Description of problem:
+OpenIndiana panics on boot.
+
+```
+Loading unix...
+Loading /platform/i86pc/amd64/boot_archive...
+Loading /platform/i86pc/amd64/boot_archive.hash...
+Booting...
+OpenIndiana Hipster 2021.10 Version illumos-79a6379db8 64-bit
+
+panic[cpu0]/thread=fffffffffbc49060:
+```
+Steps to reproduce:
+1. Run given command
+2. Wait
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1004 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1004
new file mode 100644
index 00000000..ce7f2089
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1004
@@ -0,0 +1,9 @@
+qemu-system-i386 peggs 100% host CPU
+Description of problem:
+Before the guest OS even starts up, the host CPU eggs at 100%.
+Steps to reproduce:
+1. Start any VM using qemu-system-i386
+2. On Ubuntu use Virt Manager or command line.
+3. On macOS use UTM.
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1008 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1008
new file mode 100644
index 00000000..1bf26795
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1008
@@ -0,0 +1,20 @@
+nested virtualisation with old host kernel, qemu 7.0.0 broken
+Description of problem:
+```
+$ qemu-system-x86_64 -enable-kvm -nographic
+qemu-system-x86_64: error: failed to set MSR 0xc0000104 to 0x100000000
+qemu-system-x86_64: ../target/i386/kvm/kvm.c:2996: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.
+Aborted (core dumped)
+
+$
+```
+Steps to reproduce:
+1. (hardware) Host 1 running kernel 5.10 with nested kvm enabled
+2. (virtual) Host 2, with qemu 7.0.0 installed
+3. In the inner/virtual host, run: `qemu-system-x86 -enable-kvm -nographic`
+Additional information:
+It is fixed by using either a more up-to-date kernel version on the hardware/outer host (5.17.x for example), or by reverting to qemu 6.2.0 in the virtual/inner host.
+
+I have also reproduced this with latest qemu master, commit 731340813fdb4cb8339edb8630e3f923b7d987ec.
+
+**Reverting commit 3e4546d5bd38a1e98d4bd2de48631abf0398a3a2 also fixes the issue.**
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1021 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1021
new file mode 100644
index 00000000..9410805b
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1021
@@ -0,0 +1,9 @@
+nVMX: QEMU does not clear nVMX state through KVM(L0) when guest(L2) trigger a reboot event through I/O-Port(0xCF9)
+Description of problem:
+#
+Steps to reproduce:
+Guest(L2) write 0xCF9 to trigger a platform reboot.
+
+#
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1045 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1045
new file mode 100644
index 00000000..cfb4524a
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1045
@@ -0,0 +1,26 @@
+When a break point is set, nested virtualization sees "kvm_queue_exception: Assertion `!env->exception_has_payload' failed."
+Description of problem:
+I am debugging XMHF and LHV using QEMU + KVM. I found that if I set a break point using GDB, QEMU will crash when LHV is booting. The message is
+```
+qemu-system-i386: ../../../target/i386/kvm/kvm.c:678: kvm_queue_exception: Assertion `!env->exception_has_payload' failed.
+```
+
+The address of the break point is arbitrary. The break point does not need to hit. So I chose 0 as the address in this bug report.
+Steps to reproduce:
+1. Start QEMU using `qemu-system-i386 -m 512M -gdb tcp::1234 -smp 2 -cpu Haswell,vmx=yes -enable-kvm -serial stdio -drive media=disk,file=1.img,index=1 -drive media=disk,file=2.img,index=2 -S`
+2. In another shell, start GDB using `gdb --ex 'target remote :::1234' --ex 'hb *0' --ex c`
+3. See many serial output lines. The tail of the output is
+    ```
+    CPU #0: vcpu_vaddr_ptr=0x01e06080, esp=0x01e11000
+    CPU #1: vcpu_vaddr_ptr=0x01e06540, esp=0x01e15000
+    BSP(0x00): Rallying APs...
+    BSP(0x00): APs ready, doing DRTM...
+    LAPIC base and status=0xfee00900
+    Sending INIT IPI to all APs...
+    ```
+4. See assertion error in QEMU
+    ```
+    qemu-system-i386: ../target/i386/kvm/kvm.c:645: kvm_queue_exception: Assertion `!env->exception_has_payload' failed.
+    ```
+Additional information:
+This bug was first incorrectly filed in KVM's bug tracker at <https://bugzilla.kernel.org/show_bug.cgi?id=216002>.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1068 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1068
new file mode 100644
index 00000000..6a6af675
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1068
@@ -0,0 +1,11 @@
+VMs stuck loading Kernel "Freeing unused Kernel image (initmem) memory" with host running Vanilla Kernel >= 5.18.0
+Description of problem:
+The VMs are stuck after "Freeing unused Kernel image (initmem) memory"  
+See attached screen recording.  
+Rebooting the host with Kernel 5.17.13 solves the problem.
+Steps to reproduce:
+1. Boot host with Kernel >= 5.18.0
+2. Start VM
+Additional information:
+[bug.log](/uploads/faa14ac0bf84a21beb2ffeeb650df4b9/bug.log)
+[qemu-libvirt-host-kernel-5.18.2.mkv](/uploads/87a064f171833e9fb3d46fd3ece32152/qemu-libvirt-host-kernel-5.18.2.mkv)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1069 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1069
new file mode 100644
index 00000000..0634db6c
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1069
@@ -0,0 +1,13 @@
+Qemu triggers the split lock detection of the Linux kernel
+Description of problem:
+Windows displays a "blue screen of death" and the Linux kernel logs this error message:
+
+```
+[  180.886150] x86/split lock detection: #AC: qemu-system-x86/10167 took a split_lock trap at address: 0x3ff2624d
+[  180.946151] x86/split lock detection: #AC: qemu-system-x86/10168 took a split_lock trap at address: 0x3ff2624d
+```
+Steps to reproduce:
+1. Start the guest OS
+2. Do some stuff in the Windows guest (for instance OS updates)
+Additional information:
+Is this a bug in Windows or in Qemu ?
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1133 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1133
new file mode 100644
index 00000000..8fe0446b
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1133
@@ -0,0 +1,10 @@
+unused memory filled with 0x00 instead of 0xFF
+Description of problem:
+Qemu, ever since it was made (so, since 2003), has this problem in DOS (either PC-DOS or MS-DOS and partly Windows 9x) not recognizing the memory available when the memory is filled with 0x00 but when it is filled with 0xFF it gets recognized properly, where should I patch qemu to solve this memory problem?
+
+Refer to
+https://bugs.launchpad.net/qemu/+bug/1180923
+Steps to reproduce:
+1.
+2.
+3.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1198 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1198
new file mode 100644
index 00000000..bb52ed61
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1198
@@ -0,0 +1,53 @@
+Windows 11 Guest keeps crashing with abort in cpu_asidx_from_attrs
+Steps to reproduce:
+1. Create Windows 11 guest, SWTPM, SECBOOT (haven't tested without since this is not an option for installing Windows 11)
+2. Use OS
+3. Will eventually crash. Have tried across multiple kernels 5.17, 5.18, 5.19
+Additional information:
+```
+
+               Stack trace of thread 76223:
+                #0  0x00007f24072d44dc n/a (libc.so.6 + 0x884dc)
+                #1  0x00007f2407284998 raise (libc.so.6 + 0x38998)
+                #2  0x00007f240726e53d abort (libc.so.6 + 0x2253d)
+                #3  0x00007f240726e45c n/a (libc.so.6 + 0x2245c)
+                #4  0x00007f240727d4c6 __assert_fail (libc.so.6 + 0x314c6)
+                #5  0x0000555681a35101 cpu_asidx_from_attrs (qemu-system-x86_64 + 0x572101)
+                #6  0x0000555681c6531e cpu_memory_rw_debug (qemu-system-x86_64 + 0x7a231e)
+                #7  0x0000555681bfb54a x86_cpu_dump_state (qemu-system-x86_64 + 0x73854a)
+                #8  0x0000555681d84a65 kvm_cpu_exec (qemu-system-x86_64 + 0x8c1a65)
+                #9  0x0000555681d85e48 kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x8c2e48)
+                #10 0x0000555681fed0a8 qemu_thread_start (qemu-system-x86_64 + 0xb2a0a8)
+                #11 0x00007f24072d278d n/a (libc.so.6 + 0x8678d)
+                #12 0x00007f24073538e4 __clone (libc.so.6 + 0x1078e4)
+```
+
+
+```
+KVM: entry failed, hardware error 0x80000021
+
+If you're running a guest on an Intel machine without unrestricted mode
+support, the failure can be most likely due to the guest entering an invalid
+state for Intel VT. For example, the guest maybe running in big real mode
+which is not supported on less recent Intel processors.
+
+EAX=00000000 EBX=00000000 ECX=00000000 EDX=04c6d3e0
+ESI=12af7eb0 EDI=9e55d420 EBP=821b5aa0 ESP=10db0fb0
+EIP=00008000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=1 HLT=0
+ES =0000 00000000 ffffffff 00809300
+CS =b500 7ffb5000 ffffffff 00809300
+SS =0000 00000000 ffffffff 00809300
+DS =0000 00000000 ffffffff 00809300
+FS =0000 00000000 ffffffff 00809300
+GS =0000 00000000 ffffffff 00809300
+LDT=0000 00000000 000fffff 00000000
+TR =0040 10d97000 00000067 00008b00
+GDT=     10d98fb0 00000057
+IDT=     00000000 00000000
+CR0=00050032 CR2=f80ff80c CR3=e47e7000 CR4=00000000
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000000
+Code=qemu-system-x86_64: ../qemu-7.0.0/hw/core/cpu-sysemu.c:77: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed.
+2022-09-06 14:48:15.392+0000: shutting down, reason=crashed
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1217 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1217
new file mode 100644
index 00000000..961b0299
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1217
@@ -0,0 +1,130 @@
+QEMU  6.2.0: Random segfaults when access register eax using qemu-system-x86_64
+Description of problem:
+coredump info:
+```
+(gdb) bt
+#0  0x0000152016187387 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55
+#1  0x0000152016188a78 in __GI_abort () at abort.c:90
+#2  0x00001520159f2439 in os::abort (dump_core=<optimized out>)
+    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:1572
+#3  0x0000152015c0e64a in VMError::report_and_die (this=this@entry=0x151fe009c4d0)
+    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/share/vm/utilities/vmError.cpp:1112
+#4  0x00001520159fc5e5 in JVM_handle_linux_signal (sig=11, info=0x151fe009c770, ucVoid=0x151fe009c640,
+    abort_if_unrecognized=<optimized out>)
+    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:541
+#5  0x00001520159ef5f8 in signalHandler (sig=11, info=0x151fe009c770, uc=0x151fe009c640)
+    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:4591
+#6  <signal handler called>
+#7  do_clone (pd=pd@entry=0x151fc7cfe700, attr=attr@entry=0x151fe009d410, stackaddr=<optimized out>,
+    stopped=<optimized out>, fct=0x152016b4fde0 <start_thread>, clone_flags=4001536)
+    at ../nptl/sysdeps/pthread/createthread.c:77
+#8  0x0000152016b5056a in create_thread (stackaddr=<optimized out>, attr=0x151fe009d410, pd=0x151fc7cfe700)
+    at ../nptl/sysdeps/pthread/createthread.c:244
+#9  __pthread_create_2_1 (newthread=<optimized out>, attr=<optimized out>, start_routine=<optimized out>,
+    arg=<optimized out>) at pthread_create.c:553
+#10 0x00001520159fb9b8 in os::create_thread (thread=0x561592f7f000, thr_type=<optimized out>,
+---Type <return> to continue, or q <return> to quit---f 7
+    stack_size=<optimized out>)
+    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:921
+#11 0x00001520157eea78 in JVM_StartThread (env=<optimized out>, jthread=0x151fe009d4d0)
+    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/share/vm/prims/jvm.cpp:3128
+#12 0x0000152001ef0c26 in ?? ()
+#13 0x00000006e100f538 in ?? ()
+#14 0x00000000de00bfff in ?? ()
+#15 0x0000151fe009d530 in ?? ()
+#16 0x0000152001915328 in ?? ()
+#17 0x00000006e100f538 in ?? ()
+#18 0x0000152010062550 in ?? ()
+#19 0x00000006f1450200 in ?? ()
+#20 0x00001520de280104 in ?? ()
+#21 0x0000000000000000 in ?? ()
+(gdb) f 7
+#7  do_clone (pd=pd@entry=0x151fc7cfe700, attr=attr@entry=0x151fe009d410, stackaddr=<optimized out>,
+    stopped=<optimized out>, fct=0x152016b4fde0 <start_thread>, clone_flags=4001536)
+    at ../nptl/sysdeps/pthread/createthread.c:77
+77        if (__builtin_expect (rc == -1, 0))
+(gdb) disas
+Dump of assembler code for function do_clone:
+   0x0000152016b4f010 <+0>:     push   %r12
+   0x0000152016b4f012 <+2>:     xor    %r12d,%r12d
+   0x0000152016b4f015 <+5>:     mov    %rdx,%r10
+   0x0000152016b4f018 <+8>:     push   %rbp
+   0x0000152016b4f019 <+9>:     mov    %rsi,%rbp
+   0x0000152016b4f01c <+12>:    push   %rbx
+   0x0000152016b4f01d <+13>:    mov    %rdi,%rbx
+   0x0000152016b4f020 <+16>:    sub    $0x10,%rsp
+   0x0000152016b4f024 <+20>:    test   %ecx,%ecx
+   0x0000152016b4f026 <+22>:    setne  %r12b
+   0x0000152016b4f02a <+26>:    jne    0x152016b4f07f <do_clone+111>
+   0x0000152016b4f02c <+28>:    lock incl 0x21022d(%rip)        # 0x152016d5f260 <__nptl_nthreads>
+   0x0000152016b4f033 <+35>:    lea    0x2d0(%rbx),%r8
+   0x0000152016b4f03a <+42>:    lea    0xd9f(%rip),%rdi        # 0x152016b4fde0 <start_thread>
+   0x0000152016b4f041 <+49>:    xor    %eax,%eax
+   0x0000152016b4f043 <+51>:    mov    %rbx,%r9
+   0x0000152016b4f046 <+54>:    mov    %rbx,%rcx
+   0x0000152016b4f049 <+57>:    mov    $0x3d0f00,%edx
+   0x0000152016b4f04e <+62>:    mov    %r8,(%rsp)
+   0x0000152016b4f052 <+66>:    mov    %r10,%rsi
+   0x0000152016b4f055 <+69>:    callq  0x152016b4d470 <__clone@plt>
+=> 0x0000152016b4f05a <+74>:    cmp    $0xffffffff,%eax
+   0x0000152016b4f05d <+77>:    je     0x152016b4f118 <do_clone+264>
+---Type <return> to continue, or q <return> to quit---q
+Quit
+(gdb) p rc
+$1 = 223935
+(gdb) i r rax
+rax            0x36abf  223935
+(gdb) i r eax
+eax            0x0      0
+(gdb) l
+72        atomic_increment (&__nptl_nthreads);
+73
+74        int rc = ARCH_CLONE (fct, STACK_VARIABLES_ARGS, clone_flags,
+75                             pd, &pd->tid, TLS_VALUE, &pd->tid);
+76
+77        if (__builtin_expect (rc == -1, 0))
+78          {
+79            atomic_decrement (&__nptl_nthreads); /* Oops, we lied for a second.  */
+80
+81            /* Perhaps a thread wants to change the IDs and if waiting
+(gdb)
+```
+Additional information:
+```
+# cat test.c
+#include <stdlib.h>
+
+int main() {
+   int rc = test1();
+   if(__builtin_expect (rc == -1, 0)) {
+        return rc;
+   }
+
+  return 0;
+}
+# cat test_asm.s
+global test1
+section .text
+test1:
+      mov rax, 223935
+      ret
+
+(gdb) disas main
+Dump of assembler code for function main:
+   0x00000000004004f6 <+0>:     sub    $0x8,%rsp
+   0x00000000004004fa <+4>:     mov    $0x0,%eax
+   0x00000000004004ff <+9>:     callq  0x4004f0 <test1>
+   0x0000000000400504 <+14>:    cmp    $0xffffffff,%eax
+   0x0000000000400507 <+17>:    sete   %al
+   0x000000000040050a <+20>:    movzbl %al,%eax
+   0x000000000040050d <+23>:    neg    %eax
+   0x000000000040050f <+25>:    add    $0x8,%rsp
+   0x0000000000400513 <+29>:    retq
+End of assembler dump.
+...
+# set breakpoint at 0x0000000000400504 
+(gdb) i r eax
+eax            0x36abf  223935
+(gdb) i r rax
+rax            0x36abf  223935
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1306 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1306
new file mode 100644
index 00000000..2bcf220a
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1306
@@ -0,0 +1,159 @@
+OpenIndiana fails with "BAD TRAP" & "Page fault" in guest with SATA optical drive
+Additional information:
+I am not experienced in QEMU, and have not been able to isolate with a simple command line. However, I will attempt any test cases provided by the community.
+
+The problem in the domain reproduced below resolves by removing the SATA optical drive (even if the SATA controller remains).
+
+The working case may be derived through the following patch:
+
+```
+1c1
+< <domain type='kvm' id='83'>
+---
+> <domain type='kvm' id='82'>
+18a19
+>     <boot dev='hd'/>
+42c43
+<       <source file='/srv/store/epl/img/OI-hipster-minimal-20211031.iso' index='2'/>
+---
+>       <source file='/srv/store/epl/img/OI-hipster-minimal-20211031.iso' index='1'/>
+46d46
+<       <boot order='1'/>
+48,54d47
+<       <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+<     </disk>
+<     <disk type='file' device='cdrom'>
+<       <driver name='qemu'/>
+<       <target dev='sda' bus='sata'/>
+<       <readonly/>
+<       <alias name='sata0-0-0'/>
+```
+
+For consistency, the boot media is installed on an IDE optical drive, which appears not to cause problems. The problem was originally discovered attempting to boot from a SATA optical drive, following the intended layout of the guest system.
+
+---
+
+```
+<domain type='kvm' id='84'>
+  <name>openindiana-clone</name>
+  <uuid>7a0550ec-ff03-4894-80b8-affe0dfd8177</uuid>
+  <metadata>
+    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
+      <libosinfo:os id="http://oracle.com/solaris/11"/>
+    </libosinfo:libosinfo>
+  </metadata>
+  <memory unit='KiB'>2097152</memory>
+  <currentMemory unit='KiB'>2097152</currentMemory>
+  <vcpu placement='static'>4</vcpu>
+  <resource>
+    <partition>/machine</partition>
+  </resource>
+  <os>
+    <type arch='x86_64' machine='pc-i440fx-jammy'>hvm</type>
+    <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE_4M.fd</loader>
+    <nvram template='/usr/share/OVMF/OVMF_VARS_4M.fd'>/var/lib/libvirt/qemu/nvram/openindiana-clone_VARS.fd</nvram>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+    <vmport state='off'/>
+  </features>
+  <cpu mode='host-passthrough' check='none' migratable='on'/>
+  <clock offset='utc'>
+    <timer name='rtc' tickpolicy='catchup'/>
+    <timer name='pit' tickpolicy='delay'/>
+    <timer name='hpet' present='no'/>
+  </clock>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>destroy</on_crash>
+  <pm>
+    <suspend-to-mem enabled='no'/>
+    <suspend-to-disk enabled='no'/>
+  </pm>
+  <devices>
+    <emulator>/usr/bin/qemu-system-x86_64</emulator>
+    <disk type='file' device='cdrom'>
+      <driver name='qemu' type='raw'/>
+      <source file='/srv/img/OI-hipster-minimal-20211031.iso' index='2'/>
+      <backingStore/>
+      <target dev='hda' bus='ide'/>
+      <readonly/>
+      <boot order='1'/>
+      <alias name='ide0-0-0'/>
+      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+    </disk>
+    <disk type='file' device='cdrom'>
+      <driver name='qemu'/>
+      <target dev='sda' bus='sata'/>
+      <readonly/>
+      <alias name='sata0-0-0'/>
+      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+    </disk>
+    <controller type='usb' index='0' model='ich9-ehci1'>
+      <alias name='usb'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-uhci1'>
+      <alias name='usb'/>
+      <master startport='0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-uhci2'>
+      <alias name='usb'/>
+      <master startport='2'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-uhci3'>
+      <alias name='usb'/>
+      <master startport='4'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
+    </controller>
+    <controller type='pci' index='0' model='pci-root'>
+      <alias name='pci.0'/>
+    </controller>
+    <controller type='ide' index='0'>
+      <alias name='ide'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
+    </controller>
+    <controller type='sata' index='0'>
+      <alias name='sata0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+    </controller>
+    <input type='mouse' bus='ps2'>
+      <alias name='input0'/>
+    </input>
+    <input type='keyboard' bus='ps2'>
+      <alias name='input1'/>
+    </input>
+    <graphics type='spice'>
+      <listen type='none'/>
+      <image compression='off'/>
+      <gl enable='no'/>
+    </graphics>
+    <audio id='1' type='spice'/>
+    <video>
+      <model type='vga' vram='16384' heads='1' primary='yes'/>
+      <alias name='video0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+    </video>
+    <memballoon model='virtio'>
+      <alias name='balloon0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
+    </memballoon>
+  </devices>
+  <seclabel type='dynamic' model='apparmor' relabel='yes'>
+    <label>libvirt-7a0550ec-ff03-4894-80b8-affe0dfd8177</label>
+    <imagelabel>libvirt-7a0550ec-ff03-4894-80b8-affe0dfd8177</imagelabel>
+  </seclabel>
+  <seclabel type='dynamic' model='dac' relabel='yes'>
+    <label>+64055:+130</label>
+    <imagelabel>+64055:+130</imagelabel>
+  </seclabel>
+</domain>
+```
+
+
+---
+
+![Screenshot_openindiana-clone_2022-11-07_11_24_06](/uploads/2f4a22d0fe3d5e2eb689bbaeb6dce346/Screenshot_openindiana-clone_2022-11-07_11_24_06.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/131 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/131
new file mode 100644
index 00000000..65128e9d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/131
@@ -0,0 +1 @@
+QEMU's default msrs handling causes Windows 10 64 bit to crash
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1484 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1484
new file mode 100644
index 00000000..7e7c078c
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1484
@@ -0,0 +1,29 @@
+cachy linux iso not booting in linux, host machine freezes
+Description of problem:
+- cachyos-gnome-linux-230121.iso
+  - boots native (core-i7 haswell) via ventoy-boot 
+  - boots on windows (Win10 22H2 19045.2546) using  
+    ```
+    qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -smp "sockets=1,cores=8,threads=1" -bios E:\vstorage\win_m01_edk2-x8_64.fd -boot d -cdrom E:/transcend/cachyos-gnome-linux-230121.iso  -display gtk -vga virtio -rtc base=utc -netdev user,id=vmnic1,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15,hostfwd=tcp::9551-:22 -device virtio-net,netdev=vmnic1 -device virtio-serial -chardev socket,path=C:/tmpq/Downloads/qga.sock,server=on,wait=off,id=qga0 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=ch1,name=vdagent,clipboard=on  -device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0  -qmp "tcp:127.0.0.1:5955,server,nowait"
+    ```
+  - does not boot on Linux. Infact it crashes the host, which is a much bigger problem
+    ```
+    qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot d  -drive "index=0,if=pflash,format=raw,readonly=on,file=/usr/share/edk2/ovmf/OVMF_CODE.fd" -drive "index=1,if=pflash,format=raw,file=/vol/15KJ_Images/vstorage/m20_OVMF_VARS.fd" -cdrom /vol/15KJ_Images/transcend/cachyos-gnome-linux-230121.iso  -device virtio-vga-gl  -display "spice-app,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -device virtio-serial -chardev socket,path=/tmp/qga.sock,server=on,wait=off,id=qga0 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=ch1,name=vdagent,clipboard=on  -device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0  -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" -qmp tcp:0:5955,server,nowait
+    ```  
+    when qemu windows pops up graphics inside the popped up virtviewer spice VM-window is garbled, seemingly of the grub2 bootscreen.  
+    Initially, after window popup the mouse pointer can move for a few more seconds.  
+    Then host machine GUI freezes  
+    Then caps lock toggle/LED works for a while  
+    Then host machine itself freezes. Even Ctrl-Alt-Fx to linux-console does not work.  
+    Then forced to long-press power button and reboot  
+
+Its one thing for the qemu to not be able to boot VM/iso, Its a whole different level bug to freeze the host-machine.   
+Fault inside VM should not affect outside. Plus, I think, I ran qemu-system-x86-64 as ordinary user and not as root.
+
+The self-built qemu-7.2.0 from handcrafted srpm has worked well with my other images.
+
+It may have something to do with virtio-vga-gl in linux but will need to test on next reboot to linux.
+Steps to reproduce:
+1. just run qemu command on linux
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/180 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/180
new file mode 100644
index 00000000..df5d576b
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/180
@@ -0,0 +1 @@
+hardware-based time keeping
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/1966 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1966
new file mode 100644
index 00000000..380c5892
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/1966
@@ -0,0 +1,8 @@
+windows xp - some VM's hangs some working (regression?)
+Description of problem:
+Some of my XP instances behaves strange - seems that explorer.exe is unresponsive for about half an hour after start then works +- normally. 
+what is worse - there are instance which behaves normally - ie. after launch everything works as expected.
+Steps to reproduce:
+I want to know.
+Additional information:
+under qemu 8.0.4 all vms works.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2003 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2003
new file mode 100644
index 00000000..f5d08fed
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2003
@@ -0,0 +1,15 @@
+Windows guest boot happens blue screen and crash by using "-cpu Skylake-Server,+la57,phys-bits=52"
+Description of problem:
+We are verifying 5-level paging enabling on Windows guest. After creating Windows guest, the system boot caused blue screen and no screen interface response.
+
+Same QEMU parameter without **+la57,phys-bits=52** (i.e., `./qemu-system-x86_64 -accel kvm -smp 4 -m 4096 -machine q35 -drive file=Winvm5l_host5l_ept5_1698034398,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0,bootindex=0 -cpu Skylake-Server -monitor pty -daemonize -vnc :40541 -device virtio-net-pci,netdev=nic0,mac=00:5b:0b:59:0d:26 -netdev tap,id=nic0,br=virbr0,helper=/usr/local/libexec/qemu-bridge-helper,vhost=on`), the same Windows image can be booted successfully. Initially suspected this new QEMU release does not support 5-level paging related features.
+Steps to reproduce:
+1. Create guest by using the command
+
+```
+./qemu-system-x86_64 -accel kvm -smp 4 -m 4096 -machine q35 -drive file=Winvm5l_host5l_ept5_1698034398,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0,bootindex=0 -cpu Skylake-Server,+la57,phys-bits=52 -monitor pty -daemonize -vnc :40541 -device virtio-net-pci,netdev=nic0,mac=00:5b:0b:59:0d:26 -netdev tap,id=nic0,br=virbr0,helper=/usr/local/libexec/qemu-bridge-helper,vhost=on
+```
+Additional information:
+Suspected to be a QEMU regression issue, the first bad commit id: 14f5a7bae4cb5ca45a03e16b5bb0c5d766fd51b7.
+
+Latest successful version commit id: cea3ea670fe265421131aad90c36fbb87bc4d206
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2007 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2007
new file mode 100644
index 00000000..69e70cf4
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2007
@@ -0,0 +1,29 @@
+Unable to update APIC_TPR when x2APIC is enabled and -global kvm-pit.lost_tick_policy=discard parameter provided
+Description of problem:
+I am developing a custom OS and I wanted to implement x2APIC support. I was able to enable x2APIC, read and write some registers, like APIC_VER and APIC_SIVR. Everything looks good, except that I cannot update APIC_TPR register. Reading it always returns 0. The code I wrote works properly on bare metal. Below some observations:
+
+Scenario 1:
+1. Enable x2APIC
+2. Write to CR8 - success
+3. Read from CR8 - gives correct value
+4. Read from APIC_TPR - gives correct value
+
+Scenario 2:
+1. Enable x2APIC
+2. Read from APIC_TPR - gives 0
+3. Write to APIC_TPR
+4. Read from APIC_TPR - gives 0 again
+
+Scenario 3:
+1. Initialize APIC (LAPIC or xAPIC)
+2. Write to APIC_TPR
+3. Read from APIC_TPR - gives correct value
+4. Switch to x2APIC
+5. Read from APIC_TPR - gives correct value stored in pt. 2
+6. Write to APIC_TPR
+7. Read from APIC_TPR - gives values stored in pt.2, not in point 6!
+
+Looks like APIC_TPR is stuck at value stored there before switching to x2APIC and it cannot be updated with MSR. Only update CR8 works.
+I have checked parameters I passed to qemu. After removing `-global kvm-pit.lost_tick_policy=discard` problem is gone and APIC_TPR is updated correctly.
+Additional information:
+Please let me know if you need additional information.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2037 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2037
new file mode 100644
index 00000000..09edffc4
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2037
@@ -0,0 +1,15 @@
+CPUID.07H:EBX.intel-pt not supported warning info shown in terminal when start guest with -cpu qemu64,+intel-pt
+Description of problem:
+When launch guest with qemu-system-x86_64 with parameter -cpu host,+intel-pt, it will show warning info in terminal :
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25] 'intel_pt' can not be found  in guest's CPU flag. 
+While host already support intel_pt.
+Steps to reproduce:
+1. Run the above QEMU command.
+Additional information:
+This issue was observed with kernel 5.13
+
+qemu-system-x86_64 -accel kvm -m 4096 -smp 4 -cpu host,+intel-pt,min-level=0x14
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/217 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/217
new file mode 100644
index 00000000..89efe120
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/217
@@ -0,0 +1 @@
+Qemu does not force SSE data alignment
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2325 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2325
new file mode 100644
index 00000000..6b7bd158
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2325
@@ -0,0 +1,11 @@
+[Performance Regression] Constant freezes on Alder lake and Raptor lake CPUs.
+Description of problem:
+Strangely, no logs are recorded. The guest just freezes. It can however be rescued by a simple pause and unpause.
+
+This issue only happens when using the KVM hypervisor. Other hypervisors are fine.
+
+This issue does NOT happen when I tested my Intel Core i7 8700K.
+Steps to reproduce:
+1. Create a basic virtual machine for Windows 11 (Or 10).
+2. Run it for about 5 - 30 minutes (Sometimes it happens in 20 seconds or even less).
+3. The problem should occur.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2361 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2361
new file mode 100644
index 00000000..f4490e91
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2361
@@ -0,0 +1,13 @@
+-cpu host or -cpu max breaks GRUB on AMD
+Description of problem:
+I'm running the on an AMD Ryzen CPU host.  I am emulating a Debian Bookworm image stored in a raw disk.  It uses GRUB to load a large (400MB) initrd.  When ran with the flag -cpu host or -cpu max, GRUB throws an out of memory error while loading the initrd.  This doesn't occur when using -cpu kvm64 or excluding the -cpu flag.
+
+If I direct boot the initrd and kernel via -initrd and -kernel, it works fine.  The image also works with -cpu host on an Intel CPU host machine.  The image also works with -cpu EPYC.
+Steps to reproduce:
+1. Create a raw disk with a large initrd and GRUB boot loader
+2. Start a qemu machine on an AMD host 
+3. Receive an error: out of memory
+Additional information:
+I could try selectively enabling CPU features, but I was wondering if the maintainers knew of any feature that might be causing this or how to list the features -cpu host enables.
+
+I also am not 100% that this is a QEMU bug, but it seems the only way to fix it is changing the QEMU config.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2394 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2394
new file mode 100644
index 00000000..6e19dbb7
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2394
@@ -0,0 +1,29 @@
+kvm-unit-tests vmx failed
+Description of problem:
+On the Sierra Forest platform, the vmx test in kvm-unit-tests failed. But this issue cannot be replicated on Emerald Rapids platform.
+
+The first bad commit is ba6780905943696d790cc880c8e5684b51f027fe.
+Steps to reproduce:
+1.git clone https://gitlab.com/kvm-unit-tests/kvm-unit-tests.git
+
+2.cd kvm-unit-tests; ./configure
+
+3.make standalone
+
+4.rmmod kvm_intel
+
+5.modprobe kvm_intel nested=Y allow_smaller_maxphyaddr=Y
+
+6.cd tests; ./vmx
+Additional information:
+...
+FAIL: HOST_CR3 2000000001007000: vmlaunch fails
+
+FAIL: HOST_CR3 4000000001007000: vmlaunch fails
+...
+
+SUMMARY: 430013 tests, 2 unexpected failures, 2 expected failures, 5 skipped
+
+FAIL vmx (430013 tests, 2 unexpected failures, 2 expected failures, 5 skipped)
+
+[error.log](/uploads/02456b40f2736c0bf34d3f4b3a0c872a/error.log)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2429 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2429
new file mode 100644
index 00000000..0cb4d410
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2429
@@ -0,0 +1,29 @@
+Enabling SVM in guest forcefully enables hypervisor flag and doesn't respect hv-vendor-id
+Description of problem:
+When the SVM cpu feature is enabled in a guest; despite both the hypervisor feature being disabled and hv-vendor-id being set to AuthenticAMD, the guest hypervisor is detected as "Microsoft Hv" and the hypervisor flag is present. Whereas when the SVM cpu feature is disabled but everything else is still the same, the vendor-id is detected as "AuthenticAMD" and the hypervisor flag isn't present, which is exactly as it was intended by the parameters. Therefore, from what I can tell, enabling the SVM cpu feature (which is necessary for nested-virtualization on AMD CPUs) renders hypervisor=off and hv-vendor-id useless by forcefully enabling the hypervisor flag and setting the hypervisor's vendor-id to the default "Microsoft Hv", which normally shouldn't happen.
+Steps to reproduce:
+1. Run a Windows 11 virtual machine with the given CLI arguments including svm=on
+2. I'm not sure how to check the hypervisor vendor from Command Prompt or PowerShell in Windows, so I used [Paranoid Fish](https://github.com/a0rtega/pafish) to check the hypervisor vendor, it's a utility for checking various different VM detection flags in a guest.
+3. You should see "Hypervisor: Microsoft Hv"
+Additional information:
+Screenshot of Paranoid Fish with SVM enabled:
+
+![svm_enabled.png](/uploads/1ea311d526c4d761cc734cc0daf9614e/svm_enabled.png){width="291" height="86"} ("Hypervisor:" is visible, meaning "-hypervisor" was ignored)
+
+![svm_enabled_hypervisor.png](/uploads/61262cfb6f6c2867b9c20c663fa704d3/svm_enabled_hypervisor.png){width="369" height="13"} (traced means the hypervisor bit is present, meaning `hypervisor=off` was ignored)
+
+And with SVM disabled:
+
+![image.png](/uploads/4a7b7812193c4303e930543a036bfa8f/image.png) ("Hypervisor:" isn't visible, as intended)
+
+![svm_disabled_hypervisor.png](/uploads/94fadbef1e168ace8f32923b3ca92ea9/svm_disabled_hypervisor.png){width="339" height="12"} (OK means the hypervisor bit isn't present, as intended)
+
+# Solution
+
+I finally found a solution to this. And it looks like the problem might not even have been on QEMU's side from the beginning. First disabling Virtualization Based Security (Memory Integrity) from settings and then running the following command: `bcdedit /set hypervisorlaunchtype off` in an admin PowerShell fixes the issue and now with SVM enabled, regardless of whether Hyper-V is enabled or not, I see the following CPU information in Paranoid Fish (identical to when SVM was disabled and everything is as intended, and I can still see that virtualization is enabled in task manager):
+
+![image.png](/uploads/f7cc24c201ad2a6c1ff5a98623e3235b/image.png)
+
+![image.png](/uploads/f3257f420d72fcd3a95ee45b1d9e24a0/image.png)
+
+It looks like for some odd reason Windows enables the hypervisor bit on the CPU and sets the hypervisor's vendor-id to "Microsoft Hv" when SVM is enabled in the VM. No clue as to why it does that, but disabling Virtualization Based Security (Memory Integrity) and running the command I mentioned earlier in an admin PowerShell fixes the problem regardless.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2502 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2502
new file mode 100644
index 00000000..53341377
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2502
@@ -0,0 +1,13 @@
+Old amd64 Ubuntu won't start
+Description of problem:
+While taking a trip down memory lane, I noticed that old Ubuntu amd64 live CDs won't boot in qemu-system-x86_64, while i386 ones work fine. I can confirm this for 6.06 and prior releases, while 8.04 and forward are OK (I don't have interim releases isos).
+Steps to reproduce:
+1. Launch qemu-system-x86_64 with Ubuntu 6.06.1 amd64 live CD
+2. Press "Start or install Ubuntu"
+3. PANIC: early exception rip (etc, please see screenshot below)
+Additional information:
+![Schermata_da_2024-08-13_22-07-14](/uploads/b25474a5bc984e330c1cec32677db2bb/Schermata_da_2024-08-13_22-07-14.png)
+
+I tried a few versions of QEMU and I can tell you that everything worked fine in 7.0.0 and it first broke in 7.1.0. I don't have a more precise bisect, sorry. I also tried in Fedora 40 with QEMU 8.2.2 and I have the same issue, so I don't think it's distro related.
+
+On the other hand, on a completely different PC with an Intel Core i3-330M I have no issue at all, even with QEMU 8.2.3, so it might be AMD/Ryzen related.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2571 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2571
new file mode 100644
index 00000000..ac17a0e1
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2571
@@ -0,0 +1,66 @@
+9.1.0 spurious guest journal errors -> linux guest on AMD host
+Description of problem:
+Since upgrading to 9.1.0 I'm seeing new error messages (see below) inside the guest when booting linux guests on an AMD host. Bisection points to:
+```
+2ba8b7ee63589d4063c3b8dff3b70dbf9e224fc6 is the first bad commit
+commit 2ba8b7ee63589d4063c3b8dff3b70dbf9e224fc6
+Author: John Allen <john.allen@amd.com>
+Date:   Mon Jun 3 19:36:21 2024 +0000
+
+    i386: Add support for SUCCOR feature
+    
+    Add cpuid bit definition for the SUCCOR feature. This cpuid bit is required to
+    be exposed to guests to allow them to handle machine check exceptions on AMD
+    hosts.
+```
+Everything still seems to work so possibly not a bug. But the errors are still very disconcerting. Any thoughts?
+Steps to reproduce:
+1. e.g. Boot linux with `-cpu host` on an AMD host
+Additional information:
+```
+Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
+Sep 14 12:02:53 kernel: unchecked MSR access error: RDMSR from 0x852 at rIP: 0xffffffffb548ffa7 (native_read_msr+0x7/0x40)
+Sep 14 12:02:53 kernel: Call Trace:
+Sep 14 12:02:53 kernel:  <TASK>
+Sep 14 12:02:53 kernel:  ? ex_handler_msr.isra.0.cold+0x28/0x60
+Sep 14 12:02:53 kernel:  ? fixup_exception+0x157/0x380
+Sep 14 12:02:53 kernel:  ? gp_try_fixup_and_notify+0x1e/0xb0
+Sep 14 12:02:53 kernel:  ? exc_general_protection+0x104/0x400
+Sep 14 12:02:53 kernel:  ? asm_exc_general_protection+0x26/0x30
+Sep 14 12:02:53 kernel:  ? native_read_msr+0x7/0x40
+Sep 14 12:02:53 kernel:  native_apic_msr_read+0x20/0x30
+Sep 14 12:02:53 kernel:  setup_APIC_eilvt+0x47/0x110
+Sep 14 12:02:53 kernel:  mce_amd_feature_init+0x485/0x4e0
+Sep 14 12:02:53 kernel:  mcheck_cpu_init+0x1bb/0x470
+Sep 14 12:02:53 kernel:  identify_cpu+0x396/0x5e0
+Sep 14 12:02:53 kernel:  arch_cpu_finalize_init+0x20/0x140
+Sep 14 12:02:53 kernel:  start_kernel+0x931/0x9c0
+Sep 14 12:02:53 kernel:  x86_64_start_reservations+0x24/0x30
+Sep 14 12:02:53 kernel:  x86_64_start_kernel+0x95/0xa0
+Sep 14 12:02:53 kernel:  common_startup_64+0x13e/0x141
+Sep 14 12:02:53 kernel:  </TASK>
+Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 0, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
+0 on this cpu
+Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
+Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 2, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
+0 on this cpu
+Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
+Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 4, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
+0 on this cpu
+Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
+Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 6, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
+0 on this cpu
+Sep 14 12:02:53 kernel:  #1 #3 #5 #7
+Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
+Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 1, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
+0 on this cpu
+Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
+Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 3, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
+0 on this cpu
+Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
+Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 5, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
+0 on this cpu
+Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly.
+Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 7, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x
+0 on this cpu
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2572 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2572
new file mode 100644
index 00000000..20ad0c1e
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2572
@@ -0,0 +1,30 @@
+Guest os=Windows , qemu. Shutdown very slow. Memory allocation issue.
+Description of problem:
+simplifiying - libvirt config:
+```
+<memory unit='KiB'>33554432</memory>
+  <currentMemory unit='KiB'>131072</currentMemory>
+```
+when use `<currentMemory>` less than `<memory>` - at/after shutdown of guest os cpu hangs on 100% and lasts long- approximately 3-5 minutes
+if change to
+```
+<memory unit='KiB'>33554432</memory>
+  <currentMemory unit='KiB'>33554432</currentMemory>
+```
+then shutdown takes less some seconds
+
+problem occurs not (shutdown of VM takes some seconds) in cases when not used balloon device:
+1 `<currentMemory>` equal to `<memory>`
+2 memballoon driver disabled in windows
+3 memballoon disabled on libvirt with "model=none" (and therefore not passed to qemu command line)
+Additional information:
+on the guest :
+ * used drivers from virtio-win-0.1.262.iso - membaloon ver 100.95.104.26200 
+ * possible combination of all or some components 
+
+monitored next: 
+`virsh dommemstat VMName` at shutdown time there grows "rss" till MaxMem, but very slowly.
+aLso on `virsh setmem VMName --live --size 32G` 
+rss grows slow - but takes 2 times less than at simple shutdown time ( = at shutdown seems occurs memory allocation and deallocation at the same time)
+
+so something with some or all libvirt/qemu/balloon parts not so nice
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2582 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2582
new file mode 100644
index 00000000..11ec718a
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2582
@@ -0,0 +1,23 @@
+CR4.VMX leaks from L1 into L2 on Intel VMX
+Description of problem:
+In a nested virtualization setting, `savevm` can cause CR4 bits from leaking from L1 into L2. This causes general-protection faults in certain guests.
+
+The L2 guest executes this code:
+
+```
+mov rax, cr4  ; Get CR4​
+mov rcx, rax  ; Remember the old value​
+btc rax, 7    ; Toggle CR4.PGE​
+mov cr4, rax  ; #GP! <- Shouldn't happen!​
+mov cr4, rcx  ; Restore old value
+```
+
+If the guest code is interrupted at the right time (e.g. via `savevm`), Qemu marks CR4 dirty while the guest executes L2 code. Due to really complicated KVM semantics, this will result in L1 CR4 bits (VMXE) leaking into the L2 guest and the L2 will die with a GP:
+
+Instead of the expected CR4 value, the L2 guest reads a value with VMXE set. When it tries to write this back into CR4, this triggers the general protection fault.
+Steps to reproduce:
+This is only an issue on **Intel** systems.
+
+#
+Additional information:
+See also this discussion where we discussed a (flawed) approach to fixing this in KVM: https://lore.kernel.org/lkml/Zh6WlOB8CS-By3DQ@google.com/t/
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2612 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2612
new file mode 100644
index 00000000..0da5edd2
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2612
@@ -0,0 +1,82 @@
+In-guest ROCm tests fail with multiple AMD GPUs passed through (bisected to SeaBIOS update)
+Description of problem:
+We got a report of a VM setup with 8 passed-through AMD GPUs that works well with QEMU 8.1.5, but has issues with QEMU 8.2.2 (see below for details). A QEMU bisect points to commit [14f5a7ba](https://gitlab.com/qemu-project/qemu/-/commit/14f5a7bae4cb5ca45a03e16b5bb0c5d766fd51b7) which updated the seabios snapshot.
+Even though Proxmox VE comes with its own packaged QEMU versions, for bisecting we used the [upstream repository](https://gitlab.com/qemu-project/qemu).
+
+Bisecting seabios between rel-1.16.2 and rel-1.16.3 brought the following 2 commits to attention:
+
+[bcfed7e2](https://gitlab.com/qemu-project/seabios/-/commit/bcfed7e270776ab5595cafc6f1794bea0cae1c6c) move 64bit pci window to end of address space
+
+[96a8d130](https://gitlab.com/qemu-project/seabios/-/commit/96a8d130a8c2e908e357ce62cd713f2cc0b0a2eb) be less conservative with the 64bit pci io window
+
+
+
+Since bcfed7e2 resulted in KVM errors when trying to start the guest, we could not narrow it down to a single commit. With 96a8d130 the issues in the guest began.
+
+The issues in the guest were reproduced by running some ROCm tests in the guest using all 8 GPUs. We had no insight into the tests in question, they, as well as the test setup, were provided by one of our customers. The failing test was a DeepSpeed test using all 8 GPUs.
+
+We're not sure if it's a driver issue in the guest (AMDGPU and ROCm 6.1.x and 6.2.1 tested), a hardware issue or a seabios issue. Since we narrowed it down to these commits (QEMU, seabios) we wanted to open an issue here first. 
+
+The in-guest kernel warning received seems to indicate an issue with the driver::
+```
+kernel: ------------[ cut here ]------------
+kernel: WARNING: CPU: 2 PID: 149 at /tmp/amd.eT2ZshuE/ttm/ttm_bo.c:687 amdttm_bo_unpin+0x72/0x90 [amdttm]
+kernel: Modules linked in: veth tls xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat n>
+kernel:  libahci video wmi i2c_algo_bit hid_generic usbhid hid aesni_intel crypto_simd cryptd
+kernel: CPU: 2 PID: 149 Comm: kworker/2:1 Tainted: G           OE      6.8.0-45-generic #45-Ubuntu
+kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
+kernel: Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu]
+kernel: RIP: 0010:amdttm_bo_unpin+0x72/0x90 [amdttm]
+kernel: Code: 89 de e8 01 56 00 00 48 8b bb 60 01 00 00 48 81 c7 40 08 00 00 e8 6e 72 89 d2 48 8b 5d f8 c9 31 c0 31 f6 31 ff e9 79 54 b5 d2 <0f> 0b 48 8b 5d f8 c9 31 c0 31 f6 31 ff e9 67 54 b5>
+kernel: RSP: 0018:ffffa03380687ca0 EFLAGS: 00010246
+kernel: RAX: 0000000000000000 RBX: ffff8ed6191b6848 RCX: 0000000000000000
+kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8ed6191b6848
+kernel: RBP: ffffa03380687ca8 R08: 0000000000000000 R09: 0000000000000000
+kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffff8ed62268ef38
+kernel: R13: ffff8ed6014fc800 R14: ffff8ed6015f0400 R15: ffff8ed60109b000
+kernel: FS:  0000000000000000(0000) GS:ffff8ef4ff700000(0000) knlGS:0000000000000000
+kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+kernel: CR2: 00007f923c000020 CR3: 00000106f083c006 CR4: 0000000000770ef0
+kernel: PKRU: 55555554
+kernel: Call Trace:
+kernel:  <TASK>
+kernel:  ? show_regs+0x6d/0x80
+kernel:  ? __warn+0x89/0x160
+kernel:  ? amdttm_bo_unpin+0x72/0x90 [amdttm]
+kernel:  ? report_bug+0x17e/0x1b0
+kernel:  ? handle_bug+0x51/0xa0
+kernel:  ? exc_invalid_op+0x18/0x80
+kernel:  ? asm_exc_invalid_op+0x1b/0x20
+kernel:  ? amdttm_bo_unpin+0x72/0x90 [amdttm]
+kernel:  amdgpu_bo_unpin+0x1f/0xb0 [amdgpu]
+kernel:  amdgpu_amdkfd_gpuvm_unpin_bo+0x35/0xd0 [amdgpu]
+kernel:  amdgpu_amdkfd_gpuvm_free_memory_of_gpu+0x3ea/0x460 [amdgpu]
+kernel:  kfd_process_device_free_bos+0xb7/0x150 [amdgpu]
+kernel:  kfd_process_wq_release+0x2db/0x410 [amdgpu]
+kernel:  process_one_work+0x16f/0x350
+kernel:  worker_thread+0x306/0x440
+kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
+kernel:  ? _raw_spin_unlock_irqrestore+0x11/0x60
+kernel:  ? __pfx_worker_thread+0x10/0x10
+kernel:  kthread+0xf2/0x120
+kernel:  ? __pfx_kthread+0x10/0x10
+kernel:  ret_from_fork+0x47/0x70
+kernel:  ? __pfx_kthread+0x10/0x10
+kernel:  ret_from_fork_asm+0x1b/0x30
+kernel:  </TASK>
+kernel: ---[ end trace 0000000000000000 ]---
+```
+
+Does anyone have an idea how to troubleshoot this further? If any more information or logs are required, we can try to provide them.
+Steps to reproduce:
+Sadly we can't provide steps since we only had the customer's setup that included a proprietary docker image.
+Additional information:
+We used the options `-chardev pipe,path=qemudebugpipe,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios` specified in [0] to gather some debug logs from seabios:
+
+The non-working one is from commit `96a8d130` while the working one is from an earlier version.
+
+[seabios.log](/uploads/4d7f43213c631fb5cf6aea519bfd79ad/seabios.log)
+[seabios_working.log](/uploads/978e6c56ff8784bb5639963c9fb0c93f/seabios_working.log)
+
+
+[0] https://gitlab.com/qemu-project/seabios/-/blob/master/docs/Debugging.md?ref_type=heads
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2622 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2622
new file mode 100644
index 00000000..e1d4828c
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2622
@@ -0,0 +1,267 @@
+qemu abort in qemu_aio_coroutine_enter
+Description of problem:
+Start the virtual machine using NFS disk, run sysbench to test myql inside the virtual machine,
+ and execute command "virsh domblkinfo domid vda" in host. After running for a period of time, qemu crashes.
+ This issue is not a necessary problem and requires long-term operation for more than ten hours. 
+It maybe related to NFS disk and not appear with other types of storage.
+the qemu log is 
+
+qemu_aio_coroutine_enter Co-routine was already scheduled in aio_co_schedule
+
+```
+Core was generated by `/usr/libexec/qemu-kvm -name guest=default_vm-csv66,debug-threads=on -S -object'.
+Program terminated with signal SIGABRT, Aborted.
+#0  0x00007f9702f5a54c in __pthread_kill_implementation () from /lib64/libc.so.6
+[Current thread is 1 (Thread 0x7f9701f7bf40 (LWP 98))]
+Missing separate debuginfos, use: dnf debuginfo-install capstone-4.0.2-10.cl9.x86_64 cyrus-sasl-lib-2.1.27-20.cl9.x86_64 daxctl-libs-71.1-7.cl9.x86_64 glib2-2.68.4-5.cl9.x86_64 glibc-2.34-40.cl9_1.2.x86_64 gnutls-3.7.6-18.cl9_1.x86_64 kmod-libs-28-7.cl9.x86_64 krb5-libs-1.19.1-24.cl9_1.x86_64 libaio-0.3.111-13.cl9.x86_64 libblkid-2.37.4-9.cl9.x86_64 libcom_err-1.46.5-3.cl9.x86_64 libfdt-1.6.0-7.cl9.x86_64 libffi-3--Type <RET> for more, q to quit, c to continue without paging--
+.4.2-7.cl9.x86_64 libgcc-11.3.1-2.1.cl9.x86_64 libibverbs-42.0-1.cl9.x86_64 libidn2-2.3.0-7.cl9.x86_64 libmount-2.37.4-9.cl9.x86_64 libnfs-5.0.3-2.cl9.x86_64 libnl3-3.7.0-1.cl9.x86_64 libpmem-1.12.1-1.cl9.x86_64 libpng-1.6.37-12.cl9.x86_64 librdmacm-42.0-1.cl9.x86_64 libseccomp-2.5.2-2.cl9.x86_64 libselinux-3.4-3.cl9.x86_64 libslirp-4.4.0-7.cl9.x86_64 libstdc++-11.3.1-2.1.cl9.x86_64 libtasn1-4.16.0-8.cl9_1.x86_64 libunistring-0.9.10-16.cl9.x86_64 liburing-0.7-7.cl9.x86_64 libuuid-2.37.4-9.cl9.x86_64 libxcrypt-4.4.18-3.cl9.x86_64 libzstd-1.5.1-2.cl9.x86_64 lzo-2.10-7.cl9.x86_64 nettle-3.8-3.cl9_0.x86_64 numactl-libs-2.0.14-8.cl9.x86_64 openssl-libs-3.0.1-49.cl9_1.x86_64 p11-kit-0.24.1-2.cl9.x86_64 pcre-8.44-3.cl9.3.x86_64 pcre2-10.40-2.cl9.x86_64 pixman-0.40.0-5.cl9.x86_64 snappy-1.1.8-8.cl9.x86_64 systemd-libs-250-12.cl9_1.3.x86_64 zlib-1.2.11-34.cl9.x86_64
+(gdb) bt
+#0  0x00007f9702f5a54c in __pthread_kill_implementation () from /lib64/libc.so.6
+#1  0x00007f9702f0dce6 in raise () from /lib64/libc.so.6
+#2  0x00007f9702ee17f3 in abort () from /lib64/libc.so.6
+#3  0x00005631681ceed2 in qemu_aio_coroutine_enter (ctx=0x563169dd9550, co=<optimized out>) at ../util/qemu-coroutine.c:277
+#4  0x00005631680a99e9 in bdrv_poll_co (s=0x7ffe072eea80)
+    at /usr/src/debug/qemu-kvm-8.2.0-1.cl9.gcc.git908b11716.x86_64/block/block-gen.h:42
+#5  bdrv_get_info (bs=bs@entry=0x563169fc1680, bdi=bdi@entry=0x7ffe072eeaf0) at block/block-gen.c:600
+#6  0x00005631680efc3d in bdrv_do_query_node_info (bs=bs@entry=0x563169fc1680, info=info@entry=0x56316a0f6650,
+    errp=errp@entry=0x7ffe072eed48) at ../block/qapi.c:255
+#7  0x00005631680efe1a in bdrv_query_image_info (bs=0x563169fc1680, p_info=0x56316a53c0d8, flat=<optimized out>,
+    skip_implicit_filters=<optimized out>, errp=0x7ffe072eed48) at ../block/qapi.c:337
+#8  0x00005631680f026f in bdrv_block_device_info (blk=blk@entry=0x0, bs=bs@entry=0x563169fc1680, flat=flat@entry=true,
+    errp=errp@entry=0x7ffe072eed48) at ../block/qapi.c:155
+#9  0x00005631680b31e3 in bdrv_named_nodes_list (flat=<optimized out>, errp=errp@entry=0x7ffe072eed48) at ../block.c:6207
+#10 0x00005631680a4162 in qmp_query_named_block_nodes (has_flat=<optimized out>, flat=<optimized out>, errp=errp@entry=0x7ffe072eed48)
+    at ../blockdev.c:2785
+#11 0x00005631681593eb in qmp_marshal_query_named_block_nodes (args=0x7f96e80093d0, ret=0x7f9701777eb8, errp=0x7f9701777eb0)
+    at qapi/qapi-commands-block-core.c:553
+#12 0x00005631681ade8d in do_qmp_dispatch_bh (opaque=0x7f9701777ec0) at ../qapi/qmp-dispatch.c:128
+#13 0x00005631681cd155 in aio_bh_poll (ctx=ctx@entry=0x563169da6e70) at ../util/async.c:216
+#14 0x00005631681b7a42 in aio_dispatch (ctx=0x563169da6e70) at ../util/aio-posix.c:423
+#15 0x00005631681ccee2 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>)
+    at ../util/async.c:358
+#16 0x00007f9703356d6f in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
+#17 0x00005631681ce710 in glib_pollfds_poll () at ../util/main-loop.c:290
+#18 os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:313
+#19 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:592
+#20 0x0000563167edc9b7 in qemu_main_loop () at ../system/runstate.c:782
+#21 0x0000563167daa3ab in qemu_default_main () at ../system/main.c:37
+#22 0x00007f9702ef8eb0 in __libc_start_call_main () from /lib64/libc.so.6
+#23 0x00007f9702ef8f60 in __libc_start_main_impl () from /lib64/libc.so.6
+#24 0x0000563167daa2d5 in _start ()
+(gdb) list ../util/qemu-coroutine.c:277
+272              * been deleted */
+273             if (scheduled) {
+**274                 fprintf(stderr,
+275                         "%s: Co-routine was already scheduled in '%s'\n",
+276                         __func__, scheduled);
+277                 abort();**
+278             }
+279
+280             if (to->caller) {
+281                 fprintf(stderr, "Co-routine re-entered recursively\n");
+
+(gdb) p *(AioContext *)0x563169dd9550
+$3 = {source = {callback_data = 0x0, callback_funcs = 0x0, source_funcs = 0x563168f029c0 <aio_source_funcs>, ref_count = 2,
+    context = 0x563169dd16b0, priority = 0, flags = 33, source_id = 1, poll_fds = 0x563169d34e70, prev = 0x0, next = 0x563169da6e70,
+    name = 0x563169ddd400 "aio-context", priv = 0x563169da7230}, lock = {m = {lock = {__data = {__lock = 0, __count = 0, __owner = 0,
+          __nusers = 0, __kind = 1, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}},
+        __size = '\000' <repeats 16 times>, "\001", '\000' <repeats 22 times>, __align = 0}, initialized = true}},
+  bdrv_graph = 0x563169dc7350, aio_handlers = {lh_first = 0x563169ddd020}, deleted_aio_handlers = {lh_first = 0x0}, notify_me = 0,
+  list_lock = {count = 0}, bh_list = {slh_first = 0x563169dad160}, bh_slice_list = {sqh_first = 0x0, sqh_last = 0x563169dd9608},
+  notified = true, notifier = {rfd = 8, wfd = 8, initialized = true}, scheduled_coroutines = {slh_first = 0x563169fbff70},
+  co_schedule_bh = 0x563169dad160, thread_pool_min = 0, thread_pool_max = 64, thread_pool = 0x0, linux_aio = 0x0, linux_io_uring = 0x0,
+  fdmon_io_uring = {sq = {khead = 0x7f9701675000, ktail = 0x7f9701675040, kring_mask = 0x7f9701675100, kring_entries = 0x7f9701675108,
+      kflags = 0x7f9701675114, kdropped = 0x7f9701675110, array = 0x7f9701676140, sqes = 0x7f9701673000, sqe_head = 0, sqe_tail = 0,
+      ring_sz = 4928, ring_ptr = 0x7f9701675000}, cq = {khead = 0x7f9701675080, ktail = 0x7f97016750c0, kring_mask = 0x7f9701675104,
+      kring_entries = 0x7f970167510c, kflags = 0x7f9701675118, koverflow = 0x7f970167511c, cqes = 0x7f9701675140, ring_sz = 4928,
+      ring_ptr = 0x7f9701675000}, flags = 0, ring_fd = 7}, submit_list = {slh_first = 0x0}, tlg = {tl = {0x563169ddd390, 0x563169dd1a50,
+      0x563169dd1ac0, 0x563169dd1b30}}, poll_disable_cnt = 0, poll_ns = 0, poll_max_ns = 0, poll_grow = 0, poll_shrink = 0,
+  aio_max_batch = 0, poll_aio_handlers = {lh_first = 0x563169ddd020}, poll_started = false, epollfd = -1,
+  fdmon_ops = 0x563168dfabe0 <fdmon_poll_ops>}
+(gdb) list bdrv_poll_co
+file: "/usr/src/debug/qemu-kvm-8.2.0-1.cl9.gcc.git908b11716.x86_64/block/block-gen.h", line number: 38, symbol: "bdrv_poll_co"
+33          AioContext *ctx;
+34          bool in_progress;
+35          Coroutine *co; /* Keep pointer here for debugging */
+36      } BdrvPollCo;
+37
+38      static inline void bdrv_poll_co(BdrvPollCo *s)
+39      {
+40          assert(!qemu_in_coroutine());
+41
+42          aio_co_enter(s->ctx, s->co);
+file: "/usr/src/debug/qemu-kvm-8.2.0-1.cl9.gcc.git908b11716.x86_64/block/block-gen.h", line number: 40, symbol: "bdrv_poll_co"
+35          Coroutine *co; /* Keep pointer here for debugging */
+36      } BdrvPollCo;
+37
+38      static inline void bdrv_poll_co(BdrvPollCo *s)
+39      {
+40          assert(!qemu_in_coroutine());
+41
+42          aio_co_enter(s->ctx, s->co);
+43          AIO_WAIT_WHILE(s->ctx, s->in_progress);
+44      }
+(gdb) p *(BdrvPollCo*)0x7ffe072eea80
+$4 = {ctx = 0x563169dd9550, in_progress = true, co = 0x563169fbff70}
+
+(gdb) p *(Coroutine*)0x563169fbff70
+$6 = {entry = 0x5631680a7bc0 <bdrv_co_get_info_entry>, entry_arg = 0x7ffe072eea80, caller = 0x0, caller_sp = 0x7ffe072eea28, pool_next = {
+    sle_next = 0x0}, locks_held = 0, ctx = 0x563169dd9550, scheduled = 0x5631683596c0 <__func__.3> "aio_co_schedule", co_queue_next = {
+    sqe_next = 0x0}, co_queue_wakeup = {sqh_first = 0x0, sqh_last = 0x563169fbffb8}, co_scheduled_next = {sle_next = 0x0}}
+(gdb)
+```
+Steps to reproduce:
+1. start vm 
+
+the virtual machine xml is
+[libnfs-vm-xml](/uploads/f664fe2002a032064f3d574f3cc0b13f/libnfs-vm-xml)
+
+2. run sysbench test for mysql
+the command line:
+
+![0880c4c80710b5db8422](/uploads/e3431029de2d66a075bb34d3866ac92d/0880c4c80710b5db8422.png)
+3. run command line: virsh domlbkinfo domid vda
+Additional information:
+```
+the all theads stack:
+
+Thread 12 (Thread 0x7f59b1a71640 (LWP 102)):
+#0  0x00007f59ba2ed71f in poll () from /lib64/libc.so.6
+#1  0x00007f59ba69e0bc in split_replacement.constprop () from /lib64/libglib-2.0.so.0
+#2  0xddd73fd20744af00 in ?? ()
+#3  0x00080f8a5afdd040 in ?? ()
+#4  0x0000563110266fd8 in ?? ()
+#5  0x0000563110266fd0 in ?? ()
+#6  0x0000563110239680 in ?? ()
+#7  0x000056311023ad20 in ?? ()
+#8  0x00007f59ba24a530 in ?? () from /lib64/libc.so.6
+#9  0x0000000000000000 in ?? ()
+
+Thread 11 (Thread 0x7f579cbbf640 (LWP 107)):
+#0  0x00007f59ba24739a in __futex_abstimed_wait_common () from /lib64/libc.so.6
+#1  0x00007f59ba249ba0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libc.so.6
+#2  0x000056310e2edced in qemu_cond_wait_impl (cond=<optimized out>, mutex=0x56311160aea8, file=0x56310e392334 "../ui/vnc-jobs.c", line=248) at ../util/qemu-thread-posix.c:225
+#3  0x000056310df03c47 in vnc_worker_thread_loop (queue=queue@entry=0x56311160ae70) at ../ui/vnc-jobs.c:248
+#4  0x000056310df045c0 in vnc_worker_thread (arg=0x56311160ae70) at ../ui/vnc-jobs.c:362
+#5  0x000056310e2ed7f3 in qemu_thread_start (args=0x563110dbab70) at ../util/qemu-thread-posix.c:541
+#6  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
+#7  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
+
+Thread 10 (Thread 0x7f59b896b640 (LWP 98)):
+#0  0x00007f59ba2ed81e in ppoll () from /lib64/libc.so.6
+#1  0x000056310e303d05 in ppoll (__ss=0x0, __timeout=0x7f59b896a540, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/bits/poll2.h:64
+#2  qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../util/qemu-timer.c:351
+#3  0x000056310e2eb2d9 in fdmon_poll_wait (ctx=0x56311043f190, ready_list=0x7f59b896a5d0, timeout=93350478717) at ../util/fdmon-poll.c:79
+#4  0x000056310e2eaadd in aio_poll (ctx=0x56311043f190, blocking=blocking@entry=true) at ../util/aio-posix.c:670
+#5  0x000056310e1d8fba in iothread_run (opaque=0x563110239ce0) at ../iothread.c:63
+#6  0x000056310e2ed7f3 in qemu_thread_start (args=0x56311043f6f0) at ../util/qemu-thread-posix.c:541
+#7  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
+#8  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
+
+Thread 9 (Thread 0x7f579fffe640 (LWP 105)):
+#0  0x00007f59ba1e9c6b in ioctl () from /lib64/libc.so.6
+--Type <RET> for more, q to quit, c to continue without paging--
+#1  0x000056310e19f0cd in kvm_vcpu_ioctl (cpu=cpu@entry=0x563110535c10, type=type@entry=44672) at ../accel/kvm/kvm-all.c:3078
+#2  0x000056310e19f47a in kvm_cpu_exec (cpu=cpu@entry=0x563110535c10) at ../accel/kvm/kvm-all.c:2890
+#3  0x000056310e1a09cd in kvm_vcpu_thread_fn (arg=0x563110535c10) at ../accel/kvm/kvm-accel-ops.c:51
+#4  0x000056310e2ed7f3 in qemu_thread_start (args=0x56311053ea10) at ../util/qemu-thread-posix.c:541
+#5  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
+#6  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
+
+Thread 8 (Thread 0x7f59b1270640 (LWP 103)):
+#0  0x00007f59ba1e9c6b in ioctl () from /lib64/libc.so.6
+#1  0x000056310e19f0cd in kvm_vcpu_ioctl (cpu=cpu@entry=0x5631104fd5e0, type=type@entry=44672) at ../accel/kvm/kvm-all.c:3078
+#2  0x000056310e19f47a in kvm_cpu_exec (cpu=cpu@entry=0x5631104fd5e0) at ../accel/kvm/kvm-all.c:2890
+#3  0x000056310e1a09cd in kvm_vcpu_thread_fn (arg=0x5631104fd5e0) at ../accel/kvm/kvm-accel-ops.c:51
+#4  0x000056310e2ed7f3 in qemu_thread_start (args=0x5631104ac540) at ../util/qemu-thread-posix.c:541
+#5  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
+#6  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
+
+Thread 7 (Thread 0x7f59b926d640 (LWP 97)):
+#0  0x00007f59ba1e9e5d in syscall () from /lib64/libc.so.6
+#1  0x000056310e2ee262 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /usr/src/debug/qemu-kvm-8.2.0-1.cl9.gcc.gita8dcbf606.x86_64/include/qemu/futex.h:29
+#2  qemu_event_wait (ev=ev@entry=0x56310f060688 <rcu_call_ready_event>) at ../util/qemu-thread-posix.c:464
+#3  0x000056310e2f8a52 in call_rcu_thread (opaque=<optimized out>) at ../util/rcu.c:278
+#4  0x000056310e2ed7f3 in qemu_thread_start (args=0x5631101d9df0) at ../util/qemu-thread-posix.c:541
+#5  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
+#6  0x00007f59ba1ea450 in clone3 () from /lib64/libc.so.6
+
+Thread 6 (Thread 0x7f59b37fe640 (LWP 100)):
+#0  0x00007f59ba2ed81e in ppoll () from /lib64/libc.so.6
+#1  0x000056310e303d5d in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/bits/poll2.h:64
+#2  0x000056310e2eb2d9 in fdmon_poll_wait (ctx=0x56311043fea0, ready_list=0x7f59b37fd5d0, timeout=-1) at ../util/fdmon-poll.c:79
+#3  0x000056310e2eaadd in aio_poll (ctx=0x56311043fea0, blocking=blocking@entry=true) at ../util/aio-posix.c:670
+#4  0x000056310e1d8fba in iothread_run (opaque=0x56311043f8f0) at ../iothread.c:63
+#5  0x000056310e2ed7f3 in qemu_thread_start (args=0x5631104404c0) at ../util/qemu-thread-posix.c:541
+#6  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
+#7  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
+
+Thread 5 (Thread 0x7f59b2ffd640 (LWP 101)):
+#0  0x00007f59ba2ed81e in ppoll () from /lib64/libc.so.6
+--Type <RET> for more, q to quit, c to continue without paging--
+#1  0x000056310e303d5d in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/bits/poll2.h:64
+#2  0x000056310e2eb2d9 in fdmon_poll_wait (ctx=0x5631104407f0, ready_list=0x7f59b2ffc5d0, timeout=-1) at ../util/fdmon-poll.c:79
+#3  0x000056310e2eaadd in aio_poll (ctx=0x5631104407f0, blocking=blocking@entry=true) at ../util/aio-posix.c:670
+#4  0x000056310e1d8fba in iothread_run (opaque=0x56311043fc20) at ../iothread.c:63
+#5  0x000056310e2ed7f3 in qemu_thread_start (args=0x5631104437a0) at ../util/qemu-thread-posix.c:541
+#6  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
+#7  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
+
+Thread 4 (Thread 0x7f59b0a6f640 (LWP 104)):
+#0  0x00007f59ba1e9c6b in ioctl () from /lib64/libc.so.6
+#1  0x000056310e19f0cd in kvm_vcpu_ioctl (cpu=cpu@entry=0x56311052bd80, type=type@entry=44672) at ../accel/kvm/kvm-all.c:3078
+#2  0x000056310e19f47a in kvm_cpu_exec (cpu=cpu@entry=0x56311052bd80) at ../accel/kvm/kvm-all.c:2890
+#3  0x000056310e1a09cd in kvm_vcpu_thread_fn (arg=0x56311052bd80) at ../accel/kvm/kvm-accel-ops.c:51
+#4  0x000056310e2ed7f3 in qemu_thread_start (args=0x563110535330) at ../util/qemu-thread-posix.c:541
+#5  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
+#6  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
+
+Thread 3 (Thread 0x7f59b3fff640 (LWP 99)):
+#0  0x00007f59ba2ed81e in ppoll () from /lib64/libc.so.6
+#1  0x000056310e303d5d in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/bits/poll2.h:64
+#2  0x000056310e2eb2d9 in fdmon_poll_wait (ctx=0x563110441e00, ready_list=0x7f59b3ffe5d0, timeout=-1) at ../util/fdmon-poll.c:79
+#3  0x000056310e2eaadd in aio_poll (ctx=0x563110441e00, blocking=blocking@entry=true) at ../util/aio-posix.c:670
+#4  0x000056310e1d8fba in iothread_run (opaque=0x56311043fa40) at ../iothread.c:63
+#5  0x000056310e2ed7f3 in qemu_thread_start (args=0x5631104423b0) at ../util/qemu-thread-posix.c:541
+#6  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
+#7  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
+
+Thread 2 (Thread 0x7f579f7fd640 (LWP 106)):
+#0  0x00007f59ba1e9c6b in ioctl () from /lib64/libc.so.6
+#1  0x000056310e19f0cd in kvm_vcpu_ioctl (cpu=cpu@entry=0x56311053f2f0, type=type@entry=44672) at ../accel/kvm/kvm-all.c:3078
+#2  0x000056310e19f47a in kvm_cpu_exec (cpu=cpu@entry=0x56311053f2f0) at ../accel/kvm/kvm-all.c:2890
+#3  0x000056310e1a09cd in kvm_vcpu_thread_fn (arg=0x56311053f2f0) at ../accel/kvm/kvm-accel-ops.c:51
+#4  0x000056310e2ed7f3 in qemu_thread_start (args=0x563110548280) at ../util/qemu-thread-posix.c:541
+#5  0x00007f59ba24a802 in start_thread () from /lib64/libc.so.6
+#6  0x00007f59ba1ea314 in clone () from /lib64/libc.so.6
+
+Thread 1 (Thread 0x7f59b9270f40 (LWP 95)):
+#0  0x00007f59ba24c54c in __pthread_kill_implementation () from /lib64/libc.so.6
+--Type <RET> for more, q to quit, c to continue without paging--
+#1  0x00007f59ba1ffce6 in raise () from /lib64/libc.so.6
+#2  0x00007f59ba1d37f3 in abort () from /lib64/libc.so.6
+#3  0x000056310e301e02 in qemu_aio_coroutine_enter (ctx=0x563110266550, co=<optimized out>) at ../util/qemu-coroutine.c:277
+#4  0x000056310e1dc919 in bdrv_poll_co (s=0x7ffd1c9ec8d0) at /usr/src/debug/qemu-kvm-8.2.0-1.cl9.gcc.gita8dcbf606.x86_64/block/block-gen.h:42
+#5  bdrv_get_info (bs=bs@entry=0x563110481e10, bdi=bdi@entry=0x7ffd1c9ec940) at block/block-gen.c:600
+#6  0x000056310e222b6d in bdrv_do_query_node_info (bs=bs@entry=0x563110481e10, info=info@entry=0x563110480130, errp=errp@entry=0x7ffd1c9ecb98) at ../block/qapi.c:255
+#7  0x000056310e222d4a in bdrv_query_image_info (bs=0x563110481e10, p_info=0x56311121cc18, flat=<optimized out>, skip_implicit_filters=<optimized out>, errp=0x7ffd1c9ecb98) at ../block/qapi.c:337
+#8  0x000056310e22319f in bdrv_block_device_info (blk=blk@entry=0x0, bs=bs@entry=0x563110481e10, flat=flat@entry=true, errp=errp@entry=0x7ffd1c9ecb98) at ../block/qapi.c:155
+#9  0x000056310e1e6113 in bdrv_named_nodes_list (flat=<optimized out>, errp=errp@entry=0x7ffd1c9ecb98) at ../block.c:6207
+#10 0x000056310e1d7092 in qmp_query_named_block_nodes (has_flat=<optimized out>, flat=<optimized out>, errp=errp@entry=0x7ffd1c9ecb98) at ../blockdev.c:2785
+#11 0x000056310e28c31b in qmp_marshal_query_named_block_nodes (args=0x7f579800bbc0, ret=0x7f59b8a6ceb8, errp=0x7f59b8a6ceb0) at qapi/qapi-commands-block-core.c:553
+#12 0x000056310e2e0dbd in do_qmp_dispatch_bh (opaque=0x7f59b8a6cec0) at ../qapi/qmp-dispatch.c:128
+#13 0x000056310e300085 in aio_bh_poll (ctx=ctx@entry=0x563110233e70) at ../util/async.c:216
+#14 0x000056310e2ea972 in aio_dispatch (ctx=0x563110233e70) at ../util/aio-posix.c:423
+#15 0x000056310e2ffe12 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:358
+#16 0x00007f59ba648d6f in g_main_context_find_source_by_user_data () from /lib64/libglib-2.0.so.0
+#17 0x000056310f060908 in iohandler_ctx ()
+#18 0x00007ffd1c9ecd40 in ?? ()
+#19 0x000056310e301640 in glib_pollfds_poll () at ../util/main-loop.c:290
+#20 os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:313
+#21 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:592
+#22 0x000056310e00f9b7 in qemu_main_loop () at ../system/runstate.c:782
+#23 0x000056310dedd3ab in qemu_default_main () at ../system/main.c:37
+#24 0x00007f59ba1eaeb0 in __libc_start_call_main () from /lib64/libc.so.6
+#25 0x00007f59ba1eaf60 in __libc_start_main_impl () from /lib64/libc.so.6
+#26 0x000056310dedd2d5 in _start ()
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2669 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2669
new file mode 100644
index 00000000..026572f8
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2669
@@ -0,0 +1,18 @@
+CPU Hotplug (Host Model) Causes the Windows VM to BSOD
+Description of problem:
+The QEMU runs on a host with the Intel(R) Xeon(R) CPU E3-1230 v6 CPU which supports Software Guard Extension (SGX). I start a VM with Windows Server 2019 inside and with `-cpu host,...`. When I attempts to hotplug additional CPU (when the VM is running), the OS issues a bug check 0x3e (`MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED`). The problem is that the newly hotplugged CPU is not evaluated as "equivalent enough" compared to the already present CPUs. I did some more digging and reverse engineering and it looks like the CPU being hotplugged has SGX turned off. This seems to be fixed when the VM reboots.
+
+I tried to disable SGX through `-cpu host,-sgx` which helps (the VM successfully accepts the hotplugged CPU), however, `+sgx` does not help (seems to have no effect on the CPU being hotplugged).
+
+My goal is to be able to hotplug CPUs even when the host CPU supports SGX.
+
+I tested with QEMU 8.0.0, 9.1.0, 9.1.1 and 9.1.50 (current master) but with no luck.
+Steps to reproduce:
+1. Create a simple Windows VM,
+2. start the VM,
+3. use `qpm-shell` to hotplug a CPU (https://www.qemu.org/docs/master/system/cpu-hotplug.html).
+
+I can provide you the VM as well but its image (QCOW2) has around 10G in size.
+
+Best regards
+Martin Dráb
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2731 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2731
new file mode 100644
index 00000000..556a9560
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2731
@@ -0,0 +1,344 @@
+test_kvm_xen_guest_novector_noapic sometimes fails
+Description of problem:
+The test_kvm_xen_guest_novector_noapic test of tests/avocado/kvm_xen_guest.py (soon to be moved to tests/functional/test_x86_64_kvm_xen.py ) is sometimes (maybe 1 time out of 50) failing to boot to the shell prompt. The messages on the serial console are:
+
+```
+Linux version 6.3.0-rc3-00031-g1e760fa3596e (alex@zen) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #21 SMP PREEMPT_DYNAMIC Fri Mar 24 15:04:37 GMT 2023
+Command line: printk.time=0 root=/dev/xvda console=ttyS0 xen_emul_unplug=ide-disks xen_no_vector_callback noapic
+x86/fpu: x87 FPU will use FXSAVE
+signal: max sigframe size: 1440
+BIOS-provided physical RAM map:
+BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
+BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
+BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
+BIOS-e820: [mem 0x0000000000100000-0x0000000007fdffff] usable
+BIOS-e820: [mem 0x0000000007fe0000-0x0000000007ffffff] reserved
+BIOS-e820: [mem 0x00000000feff8000-0x00000000feffffff] reserved
+BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
+NX (Execute Disable) protection: active
+SMBIOS 2.8 present.
+DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
+Hypervisor detected: Xen HVM
+Xen version 4.10.
+last_pfn = 0x7fe0 max_arch_pfn = 0x400000000
+x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
+found SMP MP-table at [mem 0x000f5470-0x000f547f]
+ACPI: Early table checksum verification disabled
+ACPI: RSDP 0x00000000000F5290 000014 (v00 BOCHS )
+ACPI: RSDT 0x0000000007FE237F 000034 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+ACPI: FACP 0x0000000007FE222B 000074 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+ACPI: DSDT 0x0000000007FE0040 0021EB (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+ACPI: FACS 0x0000000007FE0000 000040
+ACPI: APIC 0x0000000007FE229F 000080 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
+ACPI: HPET 0x0000000007FE231F 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+ACPI: WAET 0x0000000007FE2357 000028 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+ACPI: Reserving FACP table memory at [mem 0x7fe222b-0x7fe229e]
+ACPI: Reserving DSDT table memory at [mem 0x7fe0040-0x7fe222a]
+ACPI: Reserving FACS table memory at [mem 0x7fe0000-0x7fe003f]
+ACPI: Reserving APIC table memory at [mem 0x7fe229f-0x7fe231e]
+ACPI: Reserving HPET table memory at [mem 0x7fe231f-0x7fe2356]
+ACPI: Reserving WAET table memory at [mem 0x7fe2357-0x7fe237e]
+Zone ranges:
+  DMA      [mem 0x0000000000001000-0x0000000000ffffff]
+  DMA32    [mem 0x0000000001000000-0x0000000007fdffff]
+  Normal   empty
+  Device   empty
+Movable zone start for each node
+Early memory node ranges
+  node   0: [mem 0x0000000000001000-0x000000000009efff]
+  node   0: [mem 0x0000000000100000-0x0000000007fdffff]
+Initmem setup node 0 [mem 0x0000000000001000-0x0000000007fdffff]
+On node 0, zone DMA: 1 pages in unavailable ranges
+On node 0, zone DMA: 97 pages in unavailable ranges
+On node 0, zone DMA32: 32 pages in unavailable ranges
+ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
+ACPI: Skipping IOAPIC probe due to 'noapic' option.
+ACPI: Using ACPI for processor (LAPIC) configuration information
+ACPI: HPET id: 0x8086a201 base: 0xfed00000
+Intel MultiProcessor Specification v1.4
+MPTABLE: OEM ID: BOCHSCPU
+MPTABLE: Product ID: 0.1         
+MPTABLE: APIC at: 0xFEE00000
+IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
+Processors: 2
+smpboot: Allowing 2 CPUs, 0 hotplug CPUs
+[mem 0x08000000-0xfeff7fff] available for PCI devices
+Booting paravirtualized kernel on Xen HVM
+clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
+setup_percpu: NR_CPUS:64 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1
+percpu: Embedded 44 pages/cpu s149304 r0 d30920 u1048576
+Built 1 zonelists, mobility grouping on.  Total pages: 31968
+Kernel command line: printk.time=0 root=/dev/xvda console=ttyS0 xen_emul_unplug=ide-disks xen_no_vector_callback noapic
+Dentry cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
+Inode-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
+mem auto-init: stack:off, heap alloc:off, heap free:off
+Memory: 102364K/130552K available (12288K kernel code, 1699K rwdata, 3004K rodata, 1040K init, 2632K bss, 27928K reserved, 0K cma-reserved)
+SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
+Dynamic Preempt: full
+rcu: Preemptible hierarchical RCU implementation.
+rcu: 	RCU event tracing is enabled.
+rcu: 	RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=2.
+rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
+rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
+NR_IRQS: 4352, nr_irqs: 440, preallocated irqs: 16
+xen:events: Using 2-level ABI
+rcu: srcu_init: Setting srcu_struct sizes based on contention.
+Console: colour *CGA 80x25
+Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
+printk: console [ttyS0] enabled
+ACPI: Core revision 20221020
+ACPI: setting ELCR to 0200 (from 0c00)
+clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
+APIC: Switch to symmetric I/O mode setup
+Not enabling interrupt remapping due to skipped IO-APIC setup
+tsc: Unable to calibrate against PIT
+tsc: using HPET reference calibration
+tsc: Detected 2496.010 MHz processor
+clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x23fa80a809f, max_idle_ns: 440795273818 ns
+Calibrating delay loop (skipped), value calculated using timer frequency.. 4992.02 BogoMIPS (lpj=2496010)
+pid_max: default: 32768 minimum: 301
+LSM: initializing lsm=capability,yama,integrity,selinux
+Yama: becoming mindful.
+SELinux:  Initializing.
+Mount-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
+Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
+Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
+Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
+Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
+Spectre V2 : Kernel not compiled with retpoline; no mitigation available!
+Spectre V2 : Vulnerable
+Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
+Speculative Store Bypass: Vulnerable
+MDS: Vulnerable: Clear CPU buffers attempted, no microcode
+MMIO Stale Data: Unknown: No mitigations
+Freeing SMP alternatives memory: 24K
+APIC timer disabled due to verification failure
+smpboot: CPU0: Intel QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1)
+Performance Events: unsupported Netburst CPU model 107 no PMU driver, software events only.
+rcu: Hierarchical SRCU implementation.
+rcu: 	Max phase no-delay instances is 400.
+NMI watchdog: Perf NMI watchdog permanently disabled
+smp: Bringing up secondary CPUs ...
+x86: Booting SMP configuration:
+.... node  #0, CPUs:      #1
+smp: Brought up 1 node, 2 CPUs
+smpboot: Max logical packages: 1
+smpboot: Total of 2 processors activated (9984.04 BogoMIPS)
+devtmpfs: initialized
+x86/mm: Memory block size: 128MB
+clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
+futex hash table entries: 512 (order: 3, 32768 bytes, linear)
+PM: RTC time: 12:02:16, date: 2024-12-19
+NET: Registered PF_NETLINK/PF_ROUTE protocol family
+audit: initializing netlink subsys (disabled)
+audit: type=2000 audit(1734609736.239:1): state=initialized audit_enabled=0 res=1
+thermal_sys: Registered thermal governor 'step_wise'
+thermal_sys: Registered thermal governor 'user_space'
+cpuidle: using governor ladder
+cpuidle: using governor menu
+PCI: Using configuration type 1 for base access
+HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
+HugeTLB: 28 KiB vmemmap can be freed for a 2.00 MiB page
+cryptd: max_cpu_qlen set to 1000
+ACPI: Added _OSI(Module Device)
+ACPI: Added _OSI(Processor Device)
+ACPI: Added _OSI(3.0 _SCP Extensions)
+ACPI: Added _OSI(Processor Aggregator Device)
+ACPI: 1 ACPI AML tables successfully acquired and loaded
+ACPI: Interpreter enabled
+ACPI: PM: (supports S0 S3 S5)
+ACPI: Using PIC for interrupt routing
+PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
+PCI: Using E820 reservations for host bridge windows
+ACPI: Enabled 2 GPEs in block 00 to 0F
+ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
+acpi PNP0A03:00: _OSC: OS supports [ASPM ClockPM Segments MSI HPX-Type3]
+acpi PNP0A03:00: PCIe port services disabled; not requesting _OSC control
+acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended configuration space under this bridge
+PCI host bridge to bus 0000:00
+pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
+pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
+pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
+pci_bus 0000:00: root bus resource [mem 0x08000000-0xfebfffff window]
+pci_bus 0000:00: root bus resource [mem 0x100000000-0x17fffffff window]
+pci_bus 0000:00: root bus resource [bus 00-ff]
+pci 0000:00:00.0: [8086:1237] type 00 class 0x060000
+pci 0000:00:01.0: [8086:7000] type 00 class 0x060100
+pci 0000:00:01.1: [8086:7010] type 00 class 0x010180
+pci 0000:00:01.1: reg 0x20: [io  0xc120-0xc12f]
+pci 0000:00:01.1: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
+pci 0000:00:01.1: legacy IDE quirk: reg 0x14: [io  0x03f6]
+pci 0000:00:01.1: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
+pci 0000:00:01.1: legacy IDE quirk: reg 0x1c: [io  0x0376]
+pci 0000:00:01.3: [8086:7113] type 00 class 0x068000
+pci 0000:00:01.3: quirk: [io  0x0600-0x063f] claimed by PIIX4 ACPI
+pci 0000:00:01.3: quirk: [io  0x0700-0x070f] claimed by PIIX4 SMB
+pci 0000:00:02.0: [5853:0001] type 00 class 0xff8000
+pci 0000:00:02.0: reg 0x10: [io  0xc000-0xc0ff]
+pci 0000:00:02.0: reg 0x14: [mem 0xfd000000-0xfdffffff pref]
+pci 0000:00:03.0: [1af4:1000] type 00 class 0x020000
+pci 0000:00:03.0: reg 0x10: [io  0xc100-0xc11f]
+pci 0000:00:03.0: reg 0x14: [mem 0xfebc0000-0xfebc0fff]
+pci 0000:00:03.0: reg 0x20: [mem 0xfe000000-0xfe003fff 64bit pref]
+pci 0000:00:03.0: reg 0x30: [mem 0xfeb80000-0xfebbffff pref]
+ACPI: PCI: Interrupt link LNKA configured for IRQ 10
+ACPI: PCI: Interrupt link LNKB configured for IRQ 10
+ACPI: PCI: Interrupt link LNKC configured for IRQ 11
+ACPI: PCI: Interrupt link LNKD configured for IRQ 11
+ACPI: PCI: Interrupt link LNKS configured for IRQ 9
+xen:balloon: Initialising balloon driver
+iommu: Default domain type: Translated 
+iommu: DMA domain TLB invalidation policy: lazy mode 
+SCSI subsystem initialized
+ACPI: bus type USB registered
+usbcore: registered new interface driver usbfs
+usbcore: registered new interface driver hub
+usbcore: registered new device driver usb
+pps_core: LinuxPPS API ver. 1 registered
+pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
+PTP clock support registered
+Advanced Linux Sound Architecture Driver Initialized.
+PCI: Using ACPI for IRQ routing
+hpet: 3 channels of 0 reserved for per-cpu timers
+clocksource: Switched to clocksource tsc-early
+FS-Cache: Loaded
+pnp: PnP ACPI init
+pnp: PnP ACPI: found 6 devices
+NET: Registered PF_INET protocol family
+IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
+tcp_listen_portaddr_hash hash table entries: 128 (order: 0, 4096 bytes, linear)
+Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
+TCP established hash table entries: 1024 (order: 1, 8192 bytes, linear)
+TCP bind hash table entries: 1024 (order: 4, 65536 bytes, linear)
+TCP: Hash tables configured (established 1024 bind 1024)
+UDP hash table entries: 256 (order: 2, 24576 bytes, linear)
+UDP-Lite hash table entries: 256 (order: 2, 24576 bytes, linear)
+NET: Registered PF_UNIX/PF_LOCAL protocol family
+RPC: Registered named UNIX socket transport module.
+RPC: Registered udp transport module.
+RPC: Registered tcp transport module.
+RPC: Registered tcp NFSv4.1 backchannel transport module.
+pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
+pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
+pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
+pci_bus 0000:00: resource 7 [mem 0x08000000-0xfebfffff window]
+pci_bus 0000:00: resource 8 [mem 0x100000000-0x17fffffff window]
+pci 0000:00:01.0: PIIX3: Enabling Passive Release
+pci 0000:00:00.0: Limiting direct PCI/PCI transfers
+PCI: CLS 0 bytes, default 64
+kvm_intel: VMX not supported by CPU 0
+workingset: timestamp_bits=46 max_order=15 bucket_order=0
+squashfs: version 4.0 (2009/01/31) Phillip Lougher
+fuse: init (API version 7.38)
+9p: Installing v9fs 9p2000 file system support
+Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245)
+io scheduler mq-deadline registered
+io scheduler kyber registered
+ACPI: \_SB_.LNKC: Enabled at IRQ 11
+xen:xen_evtchn: Event-channel device installed
+ACPI: \_SB_.LNKB: Enabled at IRQ 10
+xen:grant_table: Grant tables using version 1 layout
+Grant table initialized
+Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
+Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
+Non-volatile memory driver v1.3
+ACPI: bus type drm_connector registered
+loop: module loaded
+Invalid max_queues (4), will use default max: 2.
+tun: Universal TUN/TAP device driver, 1.6
+e100: Intel(R) PRO/100 Network Driver
+e100: Copyright(c) 1999-2006 Intel Corporation
+e1000: Intel(R) PRO/1000 Network Driver
+e1000: Copyright (c) 1999-2006 Intel Corporation.
+e1000e: Intel(R) PRO/1000 Network Driver
+e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
+igb: Intel(R) Gigabit Ethernet Network Driver
+igb: Copyright (c) 2007-2014 Intel Corporation.
+igbvf: Intel(R) Gigabit Virtual Function Network Driver
+igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
+VMware vmxnet3 virtual NIC driver - version 1.7.0.0-k-NAPI
+xen_netfront: Initialising Xen virtual ethernet driver
+usbcore: registered new interface driver cdc_ether
+usbcore: registered new interface driver cdc_eem
+usbcore: registered new interface driver cdc_ncm
+usbcore: registered new interface driver r8153_ecm
+usbcore: registered new interface driver cdc_acm
+cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
+usbcore: registered new interface driver usb-storage
+usbcore: registered new interface driver usbserial_generic
+usbserial: USB Serial support registered for generic
+usbcore: registered new interface driver ch341
+usbserial: USB Serial support registered for ch341-uart
+usbcore: registered new interface driver cp210x
+usbserial: USB Serial support registered for cp210x
+usbcore: registered new interface driver ftdi_sio
+usbserial: USB Serial support registered for FTDI USB Serial Device
+usbcore: registered new interface driver keyspan
+usbserial: USB Serial support registered for Keyspan - (without firmware)
+usbserial: USB Serial support registered for Keyspan 1 port adapter
+usbserial: USB Serial support registered for Keyspan 2 port adapter
+usbserial: USB Serial support registered for Keyspan 4 port adapter
+usbcore: registered new interface driver pl2303
+usbserial: USB Serial support registered for pl2303
+usbcore: registered new interface driver usb_serial_simple
+usbserial: USB Serial support registered for carelink
+usbserial: USB Serial support registered for zio
+usbserial: USB Serial support registered for funsoft
+usbserial: USB Serial support registered for flashloader
+usbserial: USB Serial support registered for google
+usbserial: USB Serial support registered for libtransistor
+usbserial: USB Serial support registered for vivopay
+usbserial: USB Serial support registered for moto_modem
+usbserial: USB Serial support registered for motorola_tetra
+usbserial: USB Serial support registered for nokia
+usbserial: USB Serial support registered for novatel_gps
+usbserial: USB Serial support registered for hp4x
+usbserial: USB Serial support registered for suunto
+usbserial: USB Serial support registered for siemens_mpi
+rtc_cmos 00:05: RTC can wake from S4
+rtc_cmos 00:05: registered as rtc0
+rtc_cmos 00:05: alarms up to one day, y3k, 242 bytes nvram, hpet irqs
+fail to initialize ptp_kvm
+intel_pstate: CPU model not supported
+usbcore: registered new interface driver usbhid
+usbhid: USB HID core driver
+GACT probability NOT on
+xt_time: kernel timezone is -0000
+IPVS: Registered protocols (TCP, UDP)
+IPVS: Connection hash table configured (size=4096, memory=32Kbytes)
+IPVS: ipvs loaded.
+IPVS: [rr] scheduler registered.
+Initializing XFRM netlink socket
+NET: Registered PF_INET6 protocol family
+Segment Routing with IPv6
+In-situ OAM (IOAM) with IPv6
+NET: Registered PF_PACKET protocol family
+8021q: 802.1Q VLAN Support v1.8
+9pnet: Installing 9P2000 support
+NET: Registered PF_VSOCK protocol family
+IPI shorthand broadcast: enabled
+sched_clock: Marking stable (402156364, -4933103)->(420983909, -23760648)
+Clockevents: could not switch to one-shot mode: lapic is not functional.
+Could not switch to high resolution mode on CPU 0
+Clockevents: could not switch to one-shot mode: lapic is not functional.
+Could not switch to high resolution mode on CPU 1
+tsc: Refined TSC clocksource calibration: 2495.955 MHz
+clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x23fa4cd42c8, max_idle_ns: 440795310990 ns
+clocksource: Switched to clocksource tsc
+Clockevents: could not switch to one-shot mode: lapic is not functional.
+Could not switch to high resolution mode on CPU 1
+Clockevents: could not switch to one-shot mode: lapic is not functional.
+Could not switch to high resolution mode on CPU 0
+xenbus_probe_frontend: Waiting for devices to initialise: 25s...20s...15s...
+random: crng init done
+10s...5s...0s...
+```
+Steps to reproduce:
+Either run the mentioned avocado/functional test, or directly the mentioned QEMU command line >= 50 times
+Additional information:
+I think it reproduces more easily if the host machine is under load (not quite sure about it, though).
+
+See this discussion on the mailing list for some more details:
+
+https://lore.kernel.org/qemu-devel/999a8203f0c800f1305aacdb500dbf6038ebf147.camel@infradead.org/
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/2956 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2956
new file mode 100644
index 00000000..e0173768
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/2956
@@ -0,0 +1,214 @@
+AMD SEV-SNP: vhost-user-fs-pci iommu_platform=true is not supported by the device
+Description of problem:
+Trying to make use of `vhost-user-fs-pci` with `sev-snp-guest` enabled doesn't work.
+The system reports that `vhost-user-fs-pci` doesn't support IOMMU but as far as I understand
+we need IOMMU for the virtio protocol to fully function.
+Steps to reproduce:
+1. Ensure you are running on a system with AMD SNP support:
+```
+sudo dmesg | grep -i sev
+[    0.000000] SEV-SNP: RMP table physical range [0x000000bfbd000000 - 0x000000c07d8fffff]
+[    0.003807] SEV-SNP: Reserving start/end of RMP table on a 2MB boundary [0x000000c07d800000]
+[    8.085220] ccp 0000:06:00.5: sev enabled
+[   16.226155] ccp 0000:06:00.5: SEV API:1.55 build:28
+[   16.226162] ccp 0000:06:00.5: SEV-SNP API:1.55 build:28
+[   16.239284] kvm_amd: SEV enabled (ASIDs 15 - 1006)
+[   16.239289] kvm_amd: SEV-ES enabled (ASIDs 1 - 14)
+[   16.239292] kvm_amd: SEV-SNP enabled (ASIDs 1 - 14)
+```
+2. Use an OVMF which supports AMD SNP: https://github.com/tianocore/edk2.git branch: edk2-stable202502
+3. Launch the virtiofs daemon process.
+4. Launch qemu with device `vhost-user-fs-pci`
+5. The qemu process will terminate with the following error message:
+
+```
+qemu-system-x86_64: -device vhost-user-fs-pci,chardev=fs0,tag=cfg: iommu_platform=true is not supported by the device
+```
+Additional information:
+It does launch if I disable any AMD SEV-SNP functionality from the VM:
+
+```
+sudo ./qemu-system-x86_64  \
+         -nodefaults \
+	 -enable-kvm \
+	 -cpu host \
+	 -object memory-backend-memfd,id=mem0,size=2048M,share=on \
+	 -machine q35,memory-backend=mem0 \
+	 -smp cpus=1 \
+	 -drive file=ubuntu.qcow2,if=none,id=disk0,format=qcow2 \
+	 -device virtio-blk-pci,drive=disk0 \
+	 -device amd-iommu \
+	 -chardev socket,id=fs0,path=/var/run/virtiofs/cfg.sock \
+	 -device vhost-user-fs-pci,chardev=fs0,tag=cfg \
+	 -bios ./ovmf-dist/x86_64/OVMF.fd \
+	 -kernel ./linux-guest-6.12.15-1-/boot/vmlinuz-6.12.15-1 \
+	 -initrd ./initrd/initrd.img \
+	 -append 'console=ttyS0' \
+	 -display none
+	 -nographic
+	 -chardev stdio,id=stdio0,signal=off \
+	 -serial chardev:stdio0 \
+	 -D /tmp/qemu-vmm.log \
+	 -d 'guest_errors,unimp,trace:virtio*'
+```
+
+BTW: I've also managed to reproduce the same bug on AMD's fork:
+- Repo: https://github.com/AMDESE/qemu.git
+- Branch: snp-latest
+
+Configure flags:
+```
+    --target-list=x86_64-softmmu \
+    --prefix=/builder/out/qemu-dist \
+    --sysconfdir=/builder/out/qemu-dist/etc \
+    --libdir=/builder/out/qemu-dist/lib \
+    --libexecdir=/builder/out/qemu-dist/lib/qemu \
+    --localstatedir=/builder/out/qemu-dist/var \
+    --ninja=/usr/bin/ninja \
+    --python=/usr/bin/python3 \
+    --with-pkgversion=qemu \
+    --cc=/usr/bin/x86_64-linux-gnu-gcc-13 \
+    --static \
+    --disable-cocoa \
+    --disable-curses \
+    --disable-dbus-display \
+    --disable-gtk \
+    --disable-gtk-clipboard \
+    --disable-opengl \
+    --disable-png \
+    --disable-sdl \
+    --disable-sdl-image \
+    --disable-spice \
+    --disable-spice-protocol \
+    --disable-virglrenderer \
+    --disable-vnc \
+    --disable-vnc-jpeg \
+    --disable-vnc-sasl \
+    --disable-vte \
+    --disable-alsa \
+    --disable-coreaudio \
+    --disable-dsound \
+    --disable-jack \
+    --disable-oss \
+    --disable-pa \
+    --disable-pipewire \
+    --disable-sndio \
+    --disable-vvfat \
+    --disable-vdi \
+    --disable-qed \
+    --disable-qcow1 \
+    --disable-bochs \
+    --disable-cloop \
+    --disable-dmg \
+    --disable-parallels \
+    --disable-vpc \
+    --disable-vmdk \
+    --disable-vhdx \
+    --disable-bzip2 \
+    --disable-lzfse \
+    --disable-snappy \
+    --disable-lzo \
+    --disable-netmap \
+    --disable-l2tpv3 \
+    --disable-slirp-smbd \
+    --disable-vde \
+    --disable-vmnet \
+    --disable-vhost-user-blk-server \
+    --disable-vfio-user-server \
+    --disable-curl \
+    --disable-glusterfs \
+    --disable-libiscsi \
+    --disable-libnfs \
+    --disable-libssh \
+    --disable-mpath \
+    --disable-rbd \
+    --disable-vduse-blk-export \
+    --disable-virtfs \
+    --disable-fuse \
+    --disable-fuse-lseek \
+    --disable-blkio \
+    --disable-nettle \
+    --disable-gcrypt \
+    --disable-gnutls \
+    --disable-crypto-afalg \
+    --disable-libkeyutils \
+    --disable-libkeyutils \
+    --disable-auth-pam \
+    --disable-keyring \
+    --disable-selinux \
+    --disable-u2f \
+    --disable-brlapi \
+    --disable-canokey \
+    --disable-hvf \
+    --disable-hv-balloon \
+    --disable-libdaxctl \
+    --disable-libudev \
+    --disable-libusb \
+    --disable-nvmm \
+    --disable-rdma \
+    --disable-smartcard \
+    --disable-usb-redir \
+    --disable-whpx \
+    --disable-xen \
+    --disable-xen-pci-passthrough \
+    --disable-guest-agent \
+    --disable-guest-agent-msi \
+    --disable-colo-proxy \
+    --disable-rutabaga-gfx \
+    --disable-vhost-crypto \
+    --disable-capstone \
+    --disable-docs \
+    --disable-gettext \
+    --disable-iconv \
+    --disable-libdw \
+    --disable-pixman \
+    --disable-sparse \
+    --disable-xkbcommon \
+    --disable-attr \
+    --disable-gio \
+    --disable-multiprocess \
+    --disable-plugins \
+    --disable-qpl \
+    --disable-replication \
+    --disable-uadk \
+    --disable-libvduse \
+    --disable-libpmem \
+    --disable-user \
+    --disable-bsd-user \
+    --disable-linux-user \
+    --disable-tcg \
+    --disable-debug-tcg \
+    --disable-tcg-interpreter \
+    --disable-hexagon-idef-parser \
+    --disable-qom-cast-debug \
+    --enable-kvm \
+    --enable-system \
+    --enable-pie \
+    --enable-lto \
+    --enable-af-xdp \
+    --enable-slirp \
+    --enable-vhost-kernel \
+    --enable-vhost-net \
+    --enable-vhost-user \
+    --enable-vhost-vdpa \
+    --enable-bpf \
+    --enable-coroutine-pool \
+    --enable-linux-aio \
+    --enable-linux-io-uring \
+    --enable-malloc-trim \
+    --enable-membarrier \
+    --enable-cap-ng \
+    --enable-seccomp \
+    --enable-stack-protector \
+    --enable-tpm \
+    --enable-zstd \
+    --enable-numa \
+    --enable-fdt=disabled \
+    --enable-install-blobs \
+    --enable-tools \
+    --enable-trace-backends=log \
+    --enable-strip \
+    --x86-version=4 \
+    --extra-cflags=-O2 -fno-semantic-interposition -fdevirtualize-at-ltrans -flto=auto -fuse-linker-plugin -falign-functions=32 -D_FORTIFY_SOURCE=2 -Wno-deprecated-declarations -Wno-error=stringop-overflow -Wformat -Werror=format-security -Werror=implicit-function-declaration -fstack-protector-strong -fstack-clash-protection -fcf-protection -fipa-pta \
+    --extra-ldflags=-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,--as-needed
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/352 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/352
new file mode 100644
index 00000000..3285d990
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/352
@@ -0,0 +1 @@
+audio input crack
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/353 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/353
new file mode 100644
index 00000000..ab9a9899
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/353
@@ -0,0 +1 @@
+video capture, slowness
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/361 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/361
new file mode 100644
index 00000000..f1c6645d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/361
@@ -0,0 +1 @@
+-cpu host results in unsupported AVX512 instructions
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/466 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/466
new file mode 100644
index 00000000..3d848196
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/466
@@ -0,0 +1 @@
+3x 100% host CPU core usage while virtual machine is in idle
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/530 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/530
new file mode 100644
index 00000000..8c2328a8
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/530
@@ -0,0 +1,43 @@
+Invalid guest state when rebooting a nesting hypervisor
+Description of problem:
+On a standard Linux machine, I run a custom hypervisor stack based on [Hedron](https://github.com/cyberus-technology/hedron) in a qemu VM with nesting capabilities. The Hedron stack starts a nested Linux guest with complete pass-through of all resources not required for virtualizing the nested guest. In particular, ACPI and PCI including the reset functionality are directly accessible to the nested guest. As soon as the nested guest issues a machine reset, I get a hardware error with the following error message:
+
+<details><summary>KVM: entry failed, hardware error 0x80000021</summary>
+<pre>
+If you're running a guest on an Intel machine without unrestricted mode
+support, the failure can be most likely due to the guest entering an invalid
+state for Intel VT. For example, the guest maybe running in big real mode
+which is not supported on less recent Intel processors.
+
+EAX=00000000 EBX=00000000 ECX=00000000 EDX=00050657
+ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
+EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0000 00000000 0000ffff 00009300
+CS =f000 ffff0000 0000ffff 00009b00
+SS =0000 00000000 0000ffff 00009300
+DS =0000 00000000 0000ffff 00009300
+FS =0000 00000000 0000ffff 00009300
+GS =0000 00000000 0000ffff 00009300
+LDT=0000 00000000 0000ffff 00008200
+TR =0000 00000000 0000ffff 00008b00
+GDT=     00000000 0000ffff
+IDT=     00000000 0000ffff
+CR0=60000010 CR2=00000000 CR3=00000000 CR4=003726f8
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000000
+</pre>
+</details>
+
+If I'm not mistaken, the CR4 value of `0x003726f8` is the offending state here, because PCIDE (bit 17) is set, even though the arch state indicates real-mode and the Intel SDM states:
+
+> If the “IA-32e mode guest” VM-entry control is 0, bit 17 in the CR4 field (corresponding to CR4.PCIDE) must be 0.
+
+Furthermore, the issue is not present when not using PCID in the L1 hypervisor or when PCID/VPID are fused out using `qemu-kvm -cpu host,-pcid,-vmx-vpid,-vmx-invpcid-exit`.
+Steps to reproduce:
+1. Boot custom hypervisor stack (unfortunately not yet publicly available, I'm working on that)
+2. In nested Linux guest, type `reboot`, which eventually directly reboots the main VM (all main VM hardware is passed through to the single nested guest)
+Additional information:
+I have tracked down the [change](https://gitlab.com/qemu/qemu/-/commit/b16c0e20c74218f2d69710cedad11da7dd4d2190#063d8f78716c7a658841a1d51cc66bf30f697082_3920_3944) that likely introduced this issue. Moving the call to `kvm_put_sregs` back down (I suspect after `kvm_put_nested_state`, but I did not verify that yet) solves the reboot issue for me. The comment makes it clear that it is important to keep a certain order here, so I'm aware just reversing it is not an option.
+
+Maybe this already helps enough to figure out what exactly the issue and correct fix is, and I am happy to try any suggestions as long as I cannot provide a proper reproducer.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/674 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/674
new file mode 100644
index 00000000..2ba7d97e
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/674
@@ -0,0 +1,14 @@
+Windows 7 fails with blue screen when KVM is enabled.
+Description of problem:
+The problem appeared immediately after a full system update of Arch Linux (The first for several months). Windows 7 images that had been running normally would fail with a blue screen and Error 0x7E immediately after displaying "Starting Windows". The same error would occur with a Windows 7 installation image, as in the command line above. When the "-enable-kvm" option was removed Windows would run normally but slowly. An old Clonezilla image booted without apparent problems.
+
+The final line on the blue screen reads:
+*** STOP: 0x0000007E (0xC0000005,0x8BA3CA36,0x85186AA0,0x85186680)
+
+After getting the problem with the Arch package I cloned the source and built the latest version, getting the same error. However, when I build version 5.2.95 (v6.0.0-rc5-dirty) I found that this would run my existing Windows images (qcow2) and the installation ISO image.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/742 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/742
new file mode 100644
index 00000000..1a48498c
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/742
@@ -0,0 +1,44 @@
+Cache Layout wrong on many Zen Arch CPUs
+Description of problem:
+This is `coreinfo -l` when running Windows as host:
+
+![image](/uploads/b4217fd80071c95e20e7d729e0fd19fa/image.png)
+
+This is `coreinfo -l` when running the same Windows as guest with 6 cores and 6 threads (half of each):
+
+![image](/uploads/bb6f2ccbec661273e83e36d3e1bff309/image.png)
+Steps to reproduce:
+1. You need a AMD Ryzen 3900X. It has an L3 cache over 3 cores
+2. Use `-cpu host,+topoext,host-cache-info=on`
+3. Use `coreinfo -l` to see how the L3 cache is distributed
+Additional information:
+1. When running without `host-cache-info=on` then the L3 cache is spread on all the cpus.
+2. `lscpu -e`:
+
+```
+CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ    MINMHZ      MHZ
+  0    0      0    0 0:0:0:0          yes 4672.0698 2200.0000 3800.000
+  1    0      0    1 1:1:1:0          yes 4672.0698 2200.0000 3800.000
+  2    0      0    2 2:2:2:0          yes 4672.0698 2200.0000 3800.000
+  3    0      0    3 4:4:4:1          yes 4672.0698 2200.0000 3800.000
+  4    0      0    4 5:5:5:1          yes 4672.0698 2200.0000 3800.000
+  5    0      0    5 6:6:6:1          yes 4672.0698 2200.0000 3800.000
+  6    0      0    6 8:8:8:2          yes 4672.0698 2200.0000 3800.000
+  7    0      0    7 9:9:9:2          yes 4672.0698 2200.0000 3610.580
+  8    0      0    8 10:10:10:2       yes 4672.0698 2200.0000 3800.000
+  9    0      0    9 12:12:12:3       yes 4672.0698 2200.0000 3800.000
+ 10    0      0   10 13:13:13:3       yes 4672.0698 2200.0000 3800.000
+ 11    0      0   11 14:14:14:3       yes 4672.0698 2200.0000 3800.000
+ 12    0      0    0 0:0:0:0          yes 4672.0698 2200.0000 3800.000
+ 13    0      0    1 1:1:1:0          yes 4672.0698 2200.0000 3800.000
+ 14    0      0    2 2:2:2:0          yes 4672.0698 2200.0000 3800.000
+ 15    0      0    3 4:4:4:1          yes 4672.0698 2200.0000 3800.000
+ 16    0      0    4 5:5:5:1          yes 4672.0698 2200.0000 3800.000
+ 17    0      0    5 6:6:6:1          yes 4672.0698 2200.0000 3800.000
+ 18    0      0    6 8:8:8:2          yes 4672.0698 2200.0000 3800.000
+ 19    0      0    7 9:9:9:2          yes 4672.0698 2200.0000 3800.000
+ 20    0      0    8 10:10:10:2       yes 4672.0698 2200.0000 3800.000
+ 21    0      0    9 12:12:12:3       yes 4672.0698 2200.0000 3800.000
+ 22    0      0   10 13:13:13:3       yes 4672.0698 2200.0000 3800.000
+ 23    0      0   11 14:14:14:3       yes 4672.0698 2200.0000 3800.000
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/755 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/755
new file mode 100644
index 00000000..6a6977f2
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/755
@@ -0,0 +1,59 @@
+Qemu is stuck on the startup intermittently.
+Description of problem:
+Qemu is stuck on the startup intermittently. 
+
+We are using kubevirt to launch the VM in kubernetes env. We have compiled qemu with a few flags enabled and using it. 
+All things are working as expected except we are seeing qemu stuck issue during VM startup. Please find logs from system in additional information
+
+Qemu version: qemu-system-x86-core-5.1.0-9.fc32.x86_64.rpm
+Libvirtd version: 6.6.0
+Steps to reproduce:
+1. Create and start a VM.
+Additional information:
+TOP OUTPUT:
+--------------
+```
+  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                                                                  
+  **125 qemu       0 -20 8519896  73392  15412 R  99.9   0.1  85:27.96 CPU 0/KVM **                                                                                                                                               
+  113 qemu      20   0 8519896  73392  15412 S   0.0   0.1   0:00.14 qemu-system-ori                                                                                                                                          
+  121 qemu      20   0 8519896  73392  15412 S   0.0   0.1   0:00.00 qemu-system-ori                                                                                                                                          
+  122 qemu      20   0 8519896  73392  15412 S   0.0   0.1   0:00.00 IO iothread1                                                                                                                                             
+  124 qemu      20   0 8519896  73392  15412 S   0.0   0.1   0:00.23 IO mon_iothread                                                                                                                                          
+  126 qemu       0 -20 8519896  73392  15412 S   0.0   0.1   0:00.00 CPU 1/KVM                                                                                                                                                
+  128 qemu      20   0 8519896  73392  15412 S   0.0   0.1   0:00.00 vnc_worker 
+```
+
+qemu logs on error:
+-------------------
+```
+KVM: injection failed, MSI lost (Operation not permitted)
+KVM: injection failed, MSI lost (Operation not permitted)
+KVM: injection failed, MSI lost (Operation not permitted)
+KVM: injection failed, MSI lost (Operation not permitted)
+KVM: injection failed, MSI lost (Operation not permitted)
+KVM: injection failed, MSI lost (Operation not permitted)
+KVM: injection failed, MSI lost (Operation not permitted)
+```
+
+dmesg logs from host:-
+----------------------
+```
+[ 7853.643187] kvm: apic: phys broadcast and lowest prio
+[ 7853.643265] kvm: apic: phys broadcast and lowest prio
+[ 7853.643341] kvm: apic: phys broadcast and lowest prio
+[ 7853.643413] kvm: apic: phys broadcast and lowest prio
+[ 7853.643486] kvm: apic: phys broadcast and lowest prio
+[ 7853.643559] kvm: apic: phys broadcast and lowest prio
+[ 7853.643631] kvm: apic: phys broadcast and lowest prio
+[ 7853.643703] kvm: apic: phys broadcast and lowest prio
+[ 7853.643776] kvm: apic: phys broadcast and lowest prio
+[ 7853.643848] kvm: apic: phys broadcast and lowest prio
+[ 7853.643920] kvm: apic: phys broadcast and lowest prio
+[ 7853.643992] kvm: apic: phys broadcast and lowest prio
+[ 7853.644065] kvm: apic: phys broadcast and lowest prio
+[ 7853.644137] kvm: apic: phys broadcast and lowest prio
+[ 7853.644209] kvm: apic: phys broadcast and lowest prio
+[ 7853.644289] kvm: apic: phys broadcast and lowest prio
+```
+
+-->
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/772 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/772
new file mode 100644
index 00000000..0113425f
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/772
@@ -0,0 +1,12 @@
+Pop!_OS 20.10 host + RHEL 8.5 guest = Oh no! Something has gone wrong.
+Description of problem:
+Whenever starting the Qemu VM, there is an error covering the whole desktop "Oh no! Something has gone wrong. A problem has occurred and the system can't recover. Please log out and try again." After clicking the "Log Out" button and waiting for hours, the guest RHEL may or may not recover, based on your luck and other qemu options used.
+Steps to reproduce:
+1. Build qemu using the following `./configure` options:
+```
+--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-avx512f --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-gio --enable-fuse --enable-fuse-lseek
+```
+2. Install Red Hat Enterprise Linux 8.5 in qemu
+3. Run qemu using the above command line.
+Additional information:
+![image](/uploads/6ccb8dabb1022b548975e63b389a037a/image.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/777 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/777
new file mode 100644
index 00000000..8561941f
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/777
@@ -0,0 +1,9 @@
+Hang on Alder Lake with multiple cores
+Description of problem:
+The guest silently hangs after a few seconds or minutes. No output in log, no errors in guest.
+Steps to reproduce:
+1. Start guest, do anything or nothing for a few minutes
+Additional information:
+More cores seem to make it less stable. With a single core, I haven't had a problem but at 8 cores it usually doesn't make it much past login on Windows or Linux.
+
+The guests are stable with 8 cores if I pin the vcpus to P cores.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/916 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/916
new file mode 100644
index 00000000..0e4a0de6
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/916
@@ -0,0 +1,11 @@
+QEMU system emulators immediately crash on AMD hosts when KVM is used
+Description of problem:
+```
+$ qemu-system-x86_64  -accel kvm
+qemu-system-x86_64: ../target/i386/kvm/kvm-cpu.c:105: kvm_cpu_xsave_init: Assertion `esa->size == eax' failed.
+Aborted (core dumped)
+```
+
+This is a regression introduced in
+
+https://lists.gnu.org/archive/html/qemu-devel/2022-03/msg04312.html
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_KVM/954 b/gitlab/issues_text/target_i386/host_missing/accel_KVM/954
new file mode 100644
index 00000000..d2ad8d1d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_KVM/954
@@ -0,0 +1,1257 @@
+qemu 6.2.0 with SEV in x86_64 initrd unpack ?
+Description of problem:
+The guest kernel panic from qemu 6.2.0, works fine on 6.0.0 and 6.1.0, works fine without SEV on 6.2.0 too.
+
+From our research it seems that initrd is not unpacked and initialized in an SEV context on 6.2.0 as we can see in logs without SEV that the initrd is well unpacked. Please have a look on additional informations for all the logs.
+
+We can see this crash during guest initialization:  
+```
+[    0.252891] VFS: Cannot open root device \(null)\ or unknown-block(0,0): error -6
+[    0.253054] Please append a correct \root=\ boot option; here are the available partitions:
+[    0.253179] 0100            4096 ram0 
+[    0.253181]  (driver?)
+[    0.253285] 0101            4096 ram1 
+[    0.253286]  (driver?)
+[    0.253389] 0102            4096 ram2 
+[    0.253390]  (driver?)
+[    0.253490] 0103            4096 ram3 
+[    0.253491]  (driver?)
+[    0.253595] 0104            4096 ram4 
+[    0.253596]  (driver?)
+[    0.253708] 0105            4096 ram5 
+[    0.253709]  (driver?)
+[    0.253816] 0106            4096 ram6 
+[    0.253817]  (driver?)
+[    0.253965] 0107            4096 ram7 
+[    0.253967]  (driver?)
+[    0.254065] 0108            4096 ram8 
+[    0.254066]  (driver?)
+[    0.254170] 0109            4096 ram9 
+[    0.254171]  (driver?)
+[    0.254274] 010a            4096 ram10 
+[    0.254276]  (driver?)
+[    0.254392] 010b            4096 ram11 
+[    0.254393]  (driver?)
+[    0.254514] 010c            4096 ram12 
+[    0.254516]  (driver?)
+[    0.254639] 010d            4096 ram13 
+[    0.254640]  (driver?)
+[    0.254755] 010e            4096 ram14 
+[    0.254756]  (driver?)
+[    0.254871] 010f            4096 ram15 
+[    0.254872]  (driver?)
+[    0.254996] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
+[    0.255115] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.31 #1
+[    0.255215] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
+[    0.255339] Call Trace:
+[    0.255387]  <TASK>
+[    0.255430]  dump_stack_lvl+0x34/0x44
+[    0.255499]  panic+0xe8/0x27a
+[    0.255563]  mount_block_root+0x16b/0x1fe
+[    0.255631]  ? rest_init+0xc0/0xc0
+[    0.255692]  prepare_namespace+0x131/0x160
+[    0.255757]  ? rest_init+0xc0/0xc0
+[    0.255823]  kernel_init+0x11/0x100
+[    0.255889]  ret_from_fork+0x22/0x30
+[    0.255969]  </TASK>
+[    0.256061] Kernel Offset: disabled
+[    0.256130] Rebooting in 1 seconds..
+```
+Steps to reproduce:
+1. build kernel with right config (build_kernel from kata-containers) with sev support (-x sev) & get kata-containers initrd
+2. Launch the command on a AMD SEV compatible device
+
+This is a complex problem I guess I can provide more informations if needed.
+Additional information:
+We didn't see any logs from QEMU when running this command line even when putting -D file...
+
+Complete output from QEMU 6.2.0 with SEV :  
+```
+[    0.000000] Linux version 5.10.25 (gitlab-runner@runner-buildah0) (gcc (Debian 11.2.0-12) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Tue Dec 7 11:43:22 CET 2021
+[    0.000000] Command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug
+[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
+[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
+[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
+[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
+[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.
+[    0.000000] BIOS-provided physical RAM map:
+[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007f6eefff] usable
+[    0.000000] BIOS-e820: [mem 0x000000007f6ef000-0x000000007f96efff] reserved
+[    0.000000] BIOS-e820: [mem 0x000000007f96f000-0x000000007f97efff] ACPI data
+[    0.000000] BIOS-e820: [mem 0x000000007f97f000-0x000000007f9fefff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x000000007f9ff000-0x000000007fe5ffff] usable
+[    0.000000] BIOS-e820: [mem 0x000000007fe60000-0x000000007fe7ffff] reserved
+[    0.000000] BIOS-e820: [mem 0x000000007fe80000-0x000000007fffffff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
+[    0.000000] NX (Execute Disable) protection: active
+[    0.000000] efi: EFI v2.70 by EDK II
+[    0.000000] efi: SMBIOS=0x7f7ab000 ACPI=0x7f97e000 ACPI 2.0=0x7f97e014 MEMATTR=0x7e9d8118
+[    0.000000] SMBIOS 2.8 present.
+[    0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
+[    0.000000] Hypervisor detected: KVM
+[    0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
+[    0.000000] kvm-clock: cpu 0, msr 3d401001, primary cpu clock
+[    0.000000] kvm-clock: using sched offset of 4061892066 cycles
+[    0.000003] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
+[    0.000006] tsc: Detected 2994.372 MHz processor
+[    0.000159] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
+[    0.000162] e820: remove [mem 0x000a0000-0x000fffff] usable
+[    0.000169] last_pfn = 0x7fe60 max_arch_pfn = 0x400000000
+[    0.000215] MTRR default type: write-back
+[    0.000216] MTRR fixed ranges enabled:
+[    0.000218]   00000-9FFFF write-back
+[    0.000219]   A0000-FFFFF uncachable
+[    0.000220] MTRR variable ranges enabled:
+[    0.000222]   0 base 0000C0000000 mask FFFFC0000000 uncachable
+[    0.000224]   1 base 0000B0000000 mask FFFFF0000000 uncachable
+[    0.000225]   2 base 001000000000 mask FFF800000000 uncachable
+[    0.000226]   3 disabled
+[    0.000227]   4 disabled
+[    0.000228]   5 disabled
+[    0.000229]   6 disabled
+[    0.000229]   7 disabled
+[    0.000277] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
+[    0.008747] Using GB pages for direct mapping
+[    0.009448] Secure boot could not be determined
+[    0.009466] ACPI: Early table checksum verification disabled
+[    0.009476] ACPI: RSDP 0x000000007F97E014 000024 (v02 BOCHS )
+[    0.009482] ACPI: XSDT 0x000000007F97D0E8 000054 (v01 BOCHS  BXPC     00000001      01000013)
+[    0.009490] ACPI: FACP 0x000000007F978000 0000F4 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.009497] ACPI: DSDT 0x000000007F979000 003EAE (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.009502] ACPI: FACS 0x000000007F9DD000 000040
+[    0.009506] ACPI: APIC 0x000000007F977000 000170 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.009510] ACPI: HPET 0x000000007F976000 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.009515] ACPI: SRAT 0x000000007F975000 0002D0 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.009519] ACPI: MCFG 0x000000007F974000 00003C (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.009523] ACPI: WAET 0x000000007F973000 000028 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.009532] ACPI: Local APIC address 0xfee00000
+[    0.009575] Zone ranges:
+[    0.009576]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
+[    0.009578]   DMA32    [mem 0x0000000001000000-0x000000007fe5ffff]
+[    0.009580]   Normal   empty
+[    0.009581]   Device   empty
+[    0.009582] Movable zone start for each node
+[    0.009583] Early memory node ranges
+[    0.009585]   node   0: [mem 0x0000000000001000-0x000000000009ffff]
+[    0.009587]   node   0: [mem 0x0000000000100000-0x00000000007fffff]
+[    0.009588]   node   0: [mem 0x0000000000808000-0x000000000080ffff]
+[    0.009589]   node   0: [mem 0x0000000000900000-0x000000007f6eefff]
+[    0.009590]   node   0: [mem 0x000000007f9ff000-0x000000007fe5ffff]
+[    0.009592] Initmem setup node 0 [mem 0x0000000000001000-0x000000007fe5ffff]
+[    0.009595] On node 0 totalpages: 522743
+[    0.009596]   DMA zone: 59 pages used for memmap
+[    0.009597]   DMA zone: 1814 pages reserved
+[    0.009599]   DMA zone: 3751 pages, LIFO batch:0
+[    0.009931]   DMA zone: 29017 pages in unavailable ranges
+[    0.009933]   DMA32 zone: 8122 pages used for memmap
+[    0.009934]   DMA32 zone: 518992 pages, LIFO batch:63
+[    0.014254]   DMA32 zone: 1200 pages in unavailable ranges
+[    0.014984] ACPI: PM-Timer IO Port: 0x608
+[    0.014988] ACPI: Local APIC address 0xfee00000
+[    0.015002] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
+[    0.015201] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
+[    0.015205] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
+[    0.015207] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
+[    0.015209] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
+[    0.015210] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
+[    0.015212] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
+[    0.015213] ACPI: IRQ0 used by override.
+[    0.015214] ACPI: IRQ5 used by override.
+[    0.015216] ACPI: IRQ9 used by override.
+[    0.015217] ACPI: IRQ10 used by override.
+[    0.015217] ACPI: IRQ11 used by override.
+[    0.015220] Using ACPI (MADT) for SMP configuration information
+[    0.015223] ACPI: HPET id: 0x8086a201 base: 0xfed00000
+[    0.015228] TSC deadline timer available
+[    0.015233] smpboot: Allowing 32 CPUs, 31 hotplug CPUs
+[    0.015245] kvm-guest: KVM setup pv remote TLB flush
+[    0.015254] kvm-guest: setup PV sched yield
+[    0.015272] [mem 0xc0000000-0xffffffff] available for PCI devices
+[    0.015274] Booting paravirtualized kernel on KVM
+[    0.015278] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
+[    0.020479] setup_percpu: NR_CPUS:240 nr_cpumask_bits:240 nr_cpu_ids:32 nr_node_ids:1
+[    0.021723] percpu: Embedded 42 pages/cpu s143360 r0 d28672 u262144
+[    0.021732] pcpu-alloc: s143360 r0 d28672 u262144 alloc=1*2097152
+[    0.021734] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 12 13 14 15
+[    0.021744] pcpu-alloc: [0] 16 17 18 19 20 21 22 23 [0] 24 25 26 27 28 29 30 31
+[    0.027310] kvm-guest: KVM setup async PF for cpu 0
+[    0.027318] kvm-guest: stealtime: cpu 0, msr 7d622080
+[    0.027332] Built 1 zonelists, mobility grouping on.  Total pages: 512748
+[    0.027335] Kernel command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug
+[    0.027480] printk: log_buf_len individual max cpu contribution: 4096 bytes
+[    0.027481] printk: log_buf_len total cpu_extra contributions: 126976 bytes
+[    0.027483] printk: log_buf_len min size: 131072 bytes
+[    0.027731] printk: log_buf_len: 262144 bytes
+[    0.027733] printk: early log buf free: 123344(94%)
+[    0.027942] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
+[    0.028047] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
+[    0.028190] mem auto-init: stack:off, heap alloc:off, heap free:off
+[    0.041061] Memory: 1815804K/2090972K available (10242K kernel code, 956K rwdata, 1456K rodata, 892K init, 3564K bss, 274912K reserved, 0K cma-reserved)
+[    0.041173] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=1
+[    0.041309] rcu: Hierarchical RCU implementation.
+[    0.041311] rcu: 	RCU restricting CPUs from NR_CPUS=240 to nr_cpu_ids=32.
+[    0.041312] 	All grace periods are expedited (rcu_expedited).
+[    0.041313] 	Tracing variant of Tasks RCU enabled.
+[    0.041315] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
+[    0.041316] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=32
+[    0.041372] NR_IRQS: 15616, nr_irqs: 680, preallocated irqs: 16
+[    0.041910] rcu: 	Offload RCU callbacks from CPUs: (none).
+[    0.042080] random: get_random_bytes called from start_kernel+0x2fc/0x4ae with crng_init=0
+[    0.042159] Console: colour dummy device 80x25
+[    0.162231] printk: console [ttyS0] enabled
+[    0.175286] AMD Memory Encryption Features active: SEV
+[    0.176044] ACPI: Core revision 20200925
+[    0.176768] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
+[    0.178070] APIC: Switch to symmetric I/O mode setup
+[    0.180011] x2apic enabled
+[    0.182376] Switched APIC routing to physical x2apic.
+[    0.183044] kvm-guest: setup PV IPIs
+[    0.189694] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
+[    0.190655] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns
+[    0.191992] Calibrating delay loop (skipped) preset value.. 5988.74 BogoMIPS (lpj=11977488)
+[    0.193096] pid_max: default: 32768 minimum: 301
+[    0.224045] LSM: Security Framework initializing
+[    0.225340] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
+[    0.226368] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
+[    0.227912] x86/cpu: User Mode Instruction Prevention (UMIP) activated
+[    0.228021] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127
+[    0.228758] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0
+[    0.229578] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
+[    0.230655] Spectre V2 : Mitigation: Full AMD retpoline
+[    0.231993] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
+[    0.233038] Spectre V2 : Enabling Restricted Speculation for firmware calls
+[    0.234868] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
+[    0.235997] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp
+[    0.237657] Freeing SMP alternatives memory: 28K
+[    0.238528] smpboot: CPU0: AMD EPYC 7302P 16-Core Processor (family: 0x17, model: 0x31, stepping: 0x0)
+[    0.239991] Performance Events: Fam17h+ core perfctr, AMD PMU driver.
+[    0.239991] ... version:                0
+[    0.239991] ... bit width:              48
+[    0.239991] ... generic registers:      6
+[    0.239997] ... value mask:             0000ffffffffffff
+[    0.240552] ... max period:             00007fffffffffff
+[    0.241107] ... fixed-purpose events:   0
+[    0.241610] ... event mask:             000000000000003f
+[    0.242405] rcu: Hierarchical SRCU implementation.
+[    0.243319] smp: Bringing up secondary CPUs ...
+[    0.243787] smp: Brought up 1 node, 1 CPU
+[    0.244000] smpboot: Max logical packages: 32
+[    0.244475] smpboot: Total of 1 processors activated (5988.74 BogoMIPS)
+[    0.245487] devtmpfs: initialized
+[    0.245852] x86/mm: Memory block size: 128MB
+[    0.246502] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
+[    0.247472] futex hash table entries: 8192 (order: 7, 524288 bytes, linear)
+[    0.248308] NET: Registered protocol family 16
+[    0.249031] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations
+[    0.250111] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
+[    0.251331] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
+[    0.252043] thermal_sys: Registered thermal governor 'step_wise'
+[    0.252048] cpuidle: using governor menu
+[    0.253569] ACPI: bus type PCI registered
+[    0.253974] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
+[    0.254656] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000)
+[    0.255546] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820
+[    0.256020] PCI: Using configuration type 1 for base access
+[    0.257219] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
+[    0.257889] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
+[    0.258633] ACPI: Added _OSI(Module Device)
+[    0.259073] ACPI: Added _OSI(Processor Device)
+[    0.259531] ACPI: Added _OSI(3.0 _SCP Extensions)
+[    0.259999] ACPI: Added _OSI(Processor Aggregator Device)
+[    0.260534] ACPI: Added _OSI(Linux-Dell-Video)
+[    0.260979] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
+[    0.261508] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
+[    0.263748] ACPI: 1 ACPI AML tables successfully acquired and loaded
+[    0.264963] ACPI: Interpreter enabled
+[    0.265375] ACPI: (supports S0 S5)
+[    0.265743] ACPI: Using IOAPIC for interrupt routing
+[    0.266290] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
+[    0.267390] ACPI: Enabled 3 GPEs in block 00 to 3F
+[    0.272364] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
+[    0.273025] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
+[    0.274136] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR]
+[    0.275108] acpi PNP0A08:00: _OSC: OS now controls [SHPCHotplug PME PCIeCapability]
+[    0.276009] PCI host bridge to bus 0000:00
+[    0.276413] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
+[    0.277047] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
+[    0.277707] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
+[    0.278440] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window]
+[    0.279154] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window]
+[    0.279885] pci_bus 0000:00: root bus resource [mem 0x1000000000-0x17ffffffff window]
+[    0.279995] pci_bus 0000:00: root bus resource [bus 00-ff]
+[    0.280579] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000
+[    0.281678] pci 0000:00:01.0: [1af4:1043] type 00 class 0x078000
+[    0.283998] pci 0000:00:01.0: reg 0x14: [mem 0xc0003000-0xc0003fff]
+[    0.287128] pci 0000:00:01.0: reg 0x20: [mem 0x1000000000-0x1000003fff 64bit pref]
+[    0.288918] pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
+[    0.294626] pci 0000:00:03.0: [1af4:1048] type 00 class 0x010000
+[    0.296349] pci 0000:00:03.0: reg 0x14: [mem 0xc0002000-0xc0002fff]
+[    0.299044] pci 0000:00:03.0: reg 0x20: [mem 0x1000004000-0x1000007fff 64bit pref]
+[    0.300892] pci 0000:00:04.0: [1af4:1044] type 00 class 0x00ff00
+[    0.303526] pci 0000:00:04.0: reg 0x20: [mem 0x1000008000-0x100000bfff 64bit pref]
+[    0.304902] pci 0000:00:05.0: [1af4:1049] type 00 class 0x000200
+[    0.306875] pci 0000:00:05.0: reg 0x14: [mem 0xc0001000-0xc0001fff]
+[    0.309436] pci 0000:00:05.0: reg 0x20: [mem 0x100000c000-0x100000ffff 64bit pref]
+[    0.311525] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100
+[    0.312373] pci 0000:00:1f.0: quirk: [io  0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO
+[    0.314653] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601
+[    0.318160] pci 0000:00:1f.2: reg 0x20: [io  0x6040-0x605f]
+[    0.319336] pci 0000:00:1f.2: reg 0x24: [mem 0xc0000000-0xc0000fff]
+[    0.320607] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500
+[    0.323429] pci 0000:00:1f.3: reg 0x20: [io  0x6000-0x603f]
+[    0.325167] pci_bus 0000:01: extended config space not accessible
+[    0.325943] acpiphp: Slot [0] registered
+[    0.326344] acpiphp: Slot [1] registered
+[    0.326753] acpiphp: Slot [2] registered
+[    0.327153] acpiphp: Slot [3] registered
+[    0.327557] acpiphp: Slot [4] registered
+[    0.327962] acpiphp: Slot [5] registered
+[    0.328009] acpiphp: Slot [6] registered
+[    0.328416] acpiphp: Slot [7] registered
+[    0.328817] acpiphp: Slot [8] registered
+[    0.329218] acpiphp: Slot [9] registered
+[    0.329625] acpiphp: Slot [10] registered
+[    0.330033] acpiphp: Slot [11] registered
+[    0.330448] acpiphp: Slot [12] registered
+[    0.330854] acpiphp: Slot [13] registered
+[    0.331261] acpiphp: Slot [14] registered
+[    0.331675] acpiphp: Slot [15] registered
+[    0.332008] acpiphp: Slot [16] registered
+[    0.332419] acpiphp: Slot [17] registered
+[    0.332827] acpiphp: Slot [18] registered
+[    0.333234] acpiphp: Slot [19] registered
+[    0.333647] acpiphp: Slot [20] registered
+[    0.334055] acpiphp: Slot [21] registered
+[    0.334468] acpiphp: Slot [22] registered
+[    0.334886] acpiphp: Slot [23] registered
+[    0.335298] acpiphp: Slot [24] registered
+[    0.335702] acpiphp: Slot [25] registered
+[    0.336008] acpiphp: Slot [26] registered
+[    0.336420] acpiphp: Slot [27] registered
+[    0.336824] acpiphp: Slot [28] registered
+[    0.337232] acpiphp: Slot [29] registered
+[    0.337636] acpiphp: Slot [30] registered
+[    0.338041] acpiphp: Slot [31] registered
+[    0.338650] pci 0000:00:02.0: PCI bridge to [bus 01]
+[    0.339776] pci_bus 0000:00: on NUMA node 0
+[    0.340242] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
+[    0.340849] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
+[    0.341462] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
+[    0.342076] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
+[    0.342685] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11)
+[    0.343300] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11)
+[    0.343918] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11)
+[    0.344059] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11)
+[    0.344636] ACPI: PCI Interrupt Link [GSIA] (IRQs *16)
+[    0.345142] ACPI: PCI Interrupt Link [GSIB] (IRQs *17)
+[    0.345660] ACPI: PCI Interrupt Link [GSIC] (IRQs *18)
+[    0.346245] ACPI: PCI Interrupt Link [GSID] (IRQs *19)
+[    0.346799] ACPI: PCI Interrupt Link [GSIE] (IRQs *20)
+[    0.347365] ACPI: PCI Interrupt Link [GSIF] (IRQs *21)
+[    0.347889] ACPI: PCI Interrupt Link [GSIG] (IRQs *22)
+[    0.348004] ACPI: PCI Interrupt Link [GSIH] (IRQs *23)
+[    0.349647] iommu: Default domain type: Translated
+[    0.350207] vgaarb: loaded
+[    0.350578] SCSI subsystem initialized
+[    0.350959] pps_core: LinuxPPS API ver. 1 registered
+[    0.351500] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
+[    0.352007] PTP clock support registered
+[    0.352415] Registered efivars operations
+[    0.352914] PCI: Using ACPI for IRQ routing
+[    0.353321] PCI: pci_cache_line_size set to 64 bytes
+[    0.353916] e820: reserve RAM buffer [mem 0x00810000-0x008fffff]
+[    0.354487] e820: reserve RAM buffer [mem 0x7f6ef000-0x7fffffff]
+[    0.355053] e820: reserve RAM buffer [mem 0x7fe60000-0x7fffffff]
+[    0.355719] clocksource: Switched to clocksource kvm-clock
+[    0.355991] pnp: PnP ACPI init
+[    0.355991] pnp 00:00: Plug and Play ACPI device, IDs PNP0303 (active)
+[    0.355991] pnp 00:01: Plug and Play ACPI device, IDs PNP0f13 (active)
+[    0.355991] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
+[    0.355991] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
+[    0.355991] system 00:04: [mem 0xb0000000-0xbfffffff window] has been reserved
+[    0.356347] system 00:04: Plug and Play ACPI device, IDs PNP0c01 (active)
+[    0.357410] pnp: PnP ACPI: found 5 devices
+[    0.362961] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
+[    0.363871] NET: Registered protocol family 2
+[    0.364474] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes, linear)
+[    0.365307] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear)
+[    0.366095] TCP bind hash table entries: 16384 (order: 6, 262144 bytes, linear)
+[    0.366893] TCP: Hash tables configured (established 16384 bind 16384)
+[    0.367563] UDP hash table entries: 1024 (order: 3, 32768 bytes, linear)
+[    0.368255] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes, linear)
+[    0.369036] NET: Registered protocol family 1
+[    0.369533] pci 0000:00:02.0: PCI bridge to [bus 01]
+[    0.371860] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
+[    0.372477] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
+[    0.373092] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
+[    0.373765] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window]
+[    0.374428] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window]
+[    0.375109] pci_bus 0000:00: resource 9 [mem 0x1000000000-0x17ffffffff window]
+[    0.375904] PCI: CLS 0 bytes, default 64
+[    0.376370] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
+[    0.377008] software IO TLB: mapped [mem 0x000000006f600000-0x0000000073600000] (64MB)
+[    0.377807] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns
+[    0.379980] workingset: timestamp_bits=46 max_order=19 bucket_order=0
+[    0.381847] fuse: init (API version 7.32)
+[    0.382462] SGI XFS with security attributes, no debug enabled
+[    0.383337] 9p: Installing v9fs 9p2000 file system support
+[    0.383950] NET: Registered protocol family 38
+[    0.384407] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
+[    0.385291] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
+[    0.386003] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
+[    0.386731] ACPI: Power Button [PWRF]
+[    0.387428] PCI Interrupt Link [GSIF] enabled at IRQ 21
+[    0.388885] PCI Interrupt Link [GSIH] enabled at IRQ 23
+[    0.390255] PCI Interrupt Link [GSIE] enabled at IRQ 20
+[    0.393749] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+[    0.394570] 00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
+[    0.409740] software IO TLB: Memory encryption is active and system is using DMA bounce buffers
+[    0.411320] printk: console [hvc0] enabled
+[    0.413415] brd: module loaded
+[    0.414644] loop: module loaded
+[    0.416081] scsi host0: Virtio SCSI HBA
+[    0.417023] random: fast init done
+[    0.417469] VFIO - User Level meta-driver version: 0.3
+[    0.418175] random: crng init done
+[    0.418975] xt_time: kernel timezone is -0000
+[    0.419488] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
+[    0.420221] IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
+[    0.421119] IPVS: ipvs loaded.
+[    0.421478] IPVS: [rr] scheduler registered.
+[    0.421979] IPVS: [wrr] scheduler registered.
+[    0.422475] IPVS: [lc] scheduler registered.
+[    0.422970] IPVS: [wlc] scheduler registered.
+[    0.423461] IPVS: [fo] scheduler registered.
+[    0.423982] IPVS: [ovf] scheduler registered.
+[    0.424546] IPVS: [lblc] scheduler registered.
+[    0.425067] IPVS: [lblcr] scheduler registered.
+[    0.425580] IPVS: [dh] scheduler registered.
+[    0.426081] IPVS: [sh] scheduler registered.
+[    0.426572] IPVS: [sed] scheduler registered.
+[    0.427084] IPVS: [nq] scheduler registered.
+[    0.427578] IPVS: ftp: loaded support on port[0] = 21
+[    0.428167] IPVS: [sip] pe registered.
+[    0.428794] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
+[    0.429549] Initializing XFRM netlink socket
+[    0.430136] NET: Registered protocol family 10
+[    0.430960] Segment Routing with IPv6
+[    0.431417] NET: Registered protocol family 17
+[    0.431971] 9pnet: Installing 9P2000 support
+[    0.433142] NET: Registered protocol family 40
+[    0.433718] IPI shorthand broadcast: enabled
+[    0.434218] sched_clock: Marking stable (290414430, 142054672)->(447457221, -14988119)
+[    0.435600] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
+[    0.436567] Please append a correct "root=" boot option; here are the available partitions:
+[    0.437750] 0100            4096 ram0
+[    0.437750]  (driver?)
+[    0.438478] 0101            4096 ram1
+[    0.438478]  (driver?)
+[    0.439182] 0102            4096 ram2
+[    0.439183]  (driver?)
+[    0.439896] 0103            4096 ram3
+[    0.439897]  (driver?)
+[    0.440629] 0104            4096 ram4
+[    0.440630]  (driver?)
+[    0.441346] 0105            4096 ram5
+[    0.441346]  (driver?)
+[    0.442052] 0106            4096 ram6
+[    0.442053]  (driver?)
+[    0.442756] 0107            4096 ram7
+[    0.442756]  (driver?)
+[    0.443457] 0108            4096 ram8
+[    0.443457]  (driver?)
+[    0.444177] 0109            4096 ram9
+[    0.444177]  (driver?)
+[    0.444893] 010a            4096 ram10
+[    0.444893]  (driver?)
+[    0.445609] 010b            4096 ram11
+[    0.445610]  (driver?)
+[    0.446339] 010c            4096 ram12
+[    0.446340]  (driver?)
+[    0.447056] 010d            4096 ram13
+[    0.447057]  (driver?)
+[    0.447781] 010e            4096 ram14
+[    0.447781]  (driver?)
+[    0.448512] 010f            4096 ram15
+[    0.448513]  (driver?)
+[    0.449263] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
+[    0.450170] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.25 #1
+[    0.450848] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
+[    0.451699] Call Trace:
+[    0.451995]  dump_stack+0x57/0x6a
+[    0.452378]  panic+0xf6/0x292
+[    0.452745]  mount_block_root+0x2aa/0x324
+[    0.453197]  ? rest_init+0xaa/0xaa
+[    0.453587]  prepare_namespace+0x131/0x160
+[    0.454053]  ? rest_init+0xaa/0xaa
+[    0.454442]  kernel_init+0x5/0xf6
+[    0.454838]  ret_from_fork+0x22/0x30
+[    0.455282] Kernel Offset: disabled
+[    0.455676] Rebooting in 1 seconds..
+```
+
+Complete output from QEMU 6.2.0 without SEV :  
+```
+[    0.000000] Linux version 5.10.25 (gitlab-runner@runner-buildah0) (gcc (Debian 11.2.0-12) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Tue Dec 7 11:43:22 CET 2021
+[    0.000000] Command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug
+[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
+[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
+[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
+[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
+[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.
+[    0.000000] BIOS-provided physical RAM map:
+[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007f6eefff] usable
+[    0.000000] BIOS-e820: [mem 0x000000007f6ef000-0x000000007f96efff] reserved
+[    0.000000] BIOS-e820: [mem 0x000000007f96f000-0x000000007f97efff] ACPI data
+[    0.000000] BIOS-e820: [mem 0x000000007f97f000-0x000000007f9fefff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x000000007f9ff000-0x000000007fe5ffff] usable
+[    0.000000] BIOS-e820: [mem 0x000000007fe60000-0x000000007fe7ffff] reserved
+[    0.000000] BIOS-e820: [mem 0x000000007fe80000-0x000000007fffffff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
+[    0.000000] NX (Execute Disable) protection: active
+[    0.000000] efi: EFI v2.70 by EDK II
+[    0.000000] efi: SMBIOS=0x7f7ab000 ACPI=0x7f97e000 ACPI 2.0=0x7f97e014 MEMATTR=0x7e687118
+[    0.000000] SMBIOS 2.8 present.
+[    0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
+[    0.000000] Hypervisor detected: KVM
+[    0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
+[    0.000000] kvm-clock: cpu 0, msr 37201001, primary cpu clock
+[    0.000000] kvm-clock: using sched offset of 2589542167 cycles
+[    0.000002] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
+[    0.000004] tsc: Detected 2994.372 MHz processor
+[    0.000078] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
+[    0.000081] e820: remove [mem 0x000a0000-0x000fffff] usable
+[    0.000084] last_pfn = 0x7fe60 max_arch_pfn = 0x400000000
+[    0.000106] MTRR default type: write-back
+[    0.000107] MTRR fixed ranges enabled:
+[    0.000108]   00000-9FFFF write-back
+[    0.000109]   A0000-FFFFF uncachable
+[    0.000110] MTRR variable ranges enabled:
+[    0.000111]   0 base 0000C0000000 mask FFFFC0000000 uncachable
+[    0.000111]   1 base 0000B0000000 mask FFFFF0000000 uncachable
+[    0.000112]   2 base 001000000000 mask FFF800000000 uncachable
+[    0.000113]   3 disabled
+[    0.000113]   4 disabled
+[    0.000114]   5 disabled
+[    0.000114]   6 disabled
+[    0.000114]   7 disabled
+[    0.000141] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
+[    0.004269] Using GB pages for direct mapping
+[    0.004654] Secure boot could not be determined
+[    0.004655] RAMDISK: [mem 0x6f1ee000-0x757f5fff]
+[    0.004668] ACPI: Early table checksum verification disabled
+[    0.004673] ACPI: RSDP 0x000000007F97E014 000024 (v02 BOCHS )
+[    0.004676] ACPI: XSDT 0x000000007F97D0E8 000054 (v01 BOCHS  BXPC     00000001      01000013)
+[    0.004682] ACPI: FACP 0x000000007F978000 0000F4 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.004686] ACPI: DSDT 0x000000007F979000 003EAE (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.004688] ACPI: FACS 0x000000007F9DD000 000040
+[    0.004690] ACPI: APIC 0x000000007F977000 000170 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.004692] ACPI: HPET 0x000000007F976000 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.004694] ACPI: SRAT 0x000000007F975000 0002D0 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.004696] ACPI: MCFG 0x000000007F974000 00003C (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.004698] ACPI: WAET 0x000000007F973000 000028 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.004703] ACPI: Local APIC address 0xfee00000
+[    0.004734] Zone ranges:
+[    0.004735]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
+[    0.004736]   DMA32    [mem 0x0000000001000000-0x000000007fe5ffff]
+[    0.004737]   Normal   empty
+[    0.004738]   Device   empty
+[    0.004739] Movable zone start for each node
+[    0.004740] Early memory node ranges
+[    0.004741]   node   0: [mem 0x0000000000001000-0x000000000009ffff]
+[    0.004742]   node   0: [mem 0x0000000000100000-0x00000000007fffff]
+[    0.004743]   node   0: [mem 0x0000000000808000-0x000000000080ffff]
+[    0.004743]   node   0: [mem 0x0000000000900000-0x000000007f6eefff]
+[    0.004744]   node   0: [mem 0x000000007f9ff000-0x000000007fe5ffff]
+[    0.004746] Initmem setup node 0 [mem 0x0000000000001000-0x000000007fe5ffff]
+[    0.004747] On node 0 totalpages: 522743
+[    0.004748]   DMA zone: 59 pages used for memmap
+[    0.004749]   DMA zone: 1814 pages reserved
+[    0.004750]   DMA zone: 3751 pages, LIFO batch:0
+[    0.005315]   DMA zone: 29017 pages in unavailable ranges
+[    0.005316]   DMA32 zone: 8122 pages used for memmap
+[    0.005317]   DMA32 zone: 518992 pages, LIFO batch:63
+[    0.011640]   DMA32 zone: 1200 pages in unavailable ranges
+[    0.012025] ACPI: PM-Timer IO Port: 0x608
+[    0.012028] ACPI: Local APIC address 0xfee00000
+[    0.012037] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
+[    0.012063] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23
+[    0.012065] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
+[    0.012067] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
+[    0.012068] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
+[    0.012069] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
+[    0.012070] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
+[    0.012071] ACPI: IRQ0 used by override.
+[    0.012072] ACPI: IRQ5 used by override.
+[    0.012073] ACPI: IRQ9 used by override.
+[    0.012073] ACPI: IRQ10 used by override.
+[    0.012074] ACPI: IRQ11 used by override.
+[    0.012076] Using ACPI (MADT) for SMP configuration information
+[    0.012077] ACPI: HPET id: 0x8086a201 base: 0xfed00000
+[    0.012082] TSC deadline timer available
+[    0.012085] smpboot: Allowing 32 CPUs, 31 hotplug CPUs
+[    0.012093] kvm-guest: KVM setup pv remote TLB flush
+[    0.012099] kvm-guest: setup PV sched yield
+[    0.012110] [mem 0xc0000000-0xffffffff] available for PCI devices
+[    0.012116] Booting paravirtualized kernel on KVM
+[    0.012119] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
+[    0.015048] setup_percpu: NR_CPUS:240 nr_cpumask_bits:240 nr_cpu_ids:32 nr_node_ids:1
+[    0.016599] percpu: Embedded 42 pages/cpu s143360 r0 d28672 u262144
+[    0.016605] pcpu-alloc: s143360 r0 d28672 u262144 alloc=1*2097152
+[    0.016606] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 12 13 14 15
+[    0.016611] pcpu-alloc: [0] 16 17 18 19 20 21 22 23 [0] 24 25 26 27 28 29 30 31
+[    0.016637] kvm-guest: KVM setup async PF for cpu 0
+[    0.016641] kvm-guest: stealtime: cpu 0, msr 6e822080
+[    0.016645] Built 1 zonelists, mobility grouping on.  Total pages: 512748
+[    0.016646] Kernel command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug
+[    0.016721] printk: log_buf_len individual max cpu contribution: 4096 bytes
+[    0.016722] printk: log_buf_len total cpu_extra contributions: 126976 bytes
+[    0.016723] printk: log_buf_len min size: 131072 bytes
+[    0.016904] printk: log_buf_len: 262144 bytes
+[    0.016905] printk: early log buf free: 123296(94%)
+[    0.017240] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
+[    0.017535] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
+[    0.017618] mem auto-init: stack:off, heap alloc:off, heap free:off
+[    0.021841] Memory: 1782444K/2090972K available (10242K kernel code, 956K rwdata, 1456K rodata, 892K init, 3564K bss, 308272K reserved, 0K cma-reserved)
+[    0.021920] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=1
+[    0.022033] rcu: Hierarchical RCU implementation.
+[    0.022034] rcu: 	RCU restricting CPUs from NR_CPUS=240 to nr_cpu_ids=32.
+[    0.022035] 	All grace periods are expedited (rcu_expedited).
+[    0.022036] 	Tracing variant of Tasks RCU enabled.
+[    0.022037] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
+[    0.022038] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=32
+[    0.022058] NR_IRQS: 15616, nr_irqs: 680, preallocated irqs: 16
+[    0.022381] rcu: 	Offload RCU callbacks from CPUs: (none).
+[    0.022525] random: get_random_bytes called from start_kernel+0x2fc/0x4ae with crng_init=0
+[    0.022585] Console: colour dummy device 80x25
+[    0.103996] printk: console [ttyS0] enabled
+[    0.104387] ACPI: Core revision 20200925
+[    0.104866] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
+[    0.105761] APIC: Switch to symmetric I/O mode setup
+[    0.106341] x2apic enabled
+[    0.106708] Switched APIC routing to physical x2apic.
+[    0.107178] kvm-guest: setup PV IPIs
+[    0.108191] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
+[    0.108739] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns
+[    0.109650] Calibrating delay loop (skipped) preset value.. 5988.74 BogoMIPS (lpj=11977488)
+[    0.113651] pid_max: default: 32768 minimum: 301
+[    0.129407] LSM: Security Framework initializing
+[    0.129680] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
+[    0.130330] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
+[    0.131738] x86/cpu: User Mode Instruction Prevention (UMIP) activated
+[    0.132339] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127
+[    0.132849] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0
+[    0.133655] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
+[    0.134398] Spectre V2 : Mitigation: Full AMD retpoline
+[    0.134857] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
+[    0.135570] Spectre V2 : Enabling Restricted Speculation for firmware calls
+[    0.136182] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
+[    0.136913] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp
+[    0.137807] Freeing SMP alternatives memory: 28K
+[    0.138326] smpboot: CPU0: AMD EPYC 7302P 16-Core Processor (family: 0x17, model: 0x31, stepping: 0x0)
+[    0.141129] Performance Events: Fam17h+ core perfctr, AMD PMU driver.
+[    0.141649] ... version:                0
+[    0.141657] ... bit width:              48
+[    0.142342] ... generic registers:      6
+[    0.143012] ... value mask:             0000ffffffffffff
+[    0.143904] ... max period:             00007fffffffffff
+[    0.144790] ... fixed-purpose events:   0
+[    0.145529] ... event mask:             000000000000003f
+[    0.145867] rcu: Hierarchical SRCU implementation.
+[    0.147346] smp: Bringing up secondary CPUs ...
+[    0.148411] smp: Brought up 1 node, 1 CPU
+[    0.149351] smpboot: Max logical packages: 32
+[    0.149660] smpboot: Total of 1 processors activated (5988.74 BogoMIPS)
+[    0.151208] devtmpfs: initialized
+[    0.151830] x86/mm: Memory block size: 128MB
+[    0.152836] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
+[    0.153662] futex hash table entries: 8192 (order: 7, 524288 bytes, linear)
+[    0.155199] NET: Registered protocol family 16
+[    0.156041] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations
+[    0.157242] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
+[    0.157661] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
+[    0.159023] thermal_sys: Registered thermal governor 'step_wise'
+[    0.159027] cpuidle: using governor menu
+[    0.161335] ACPI: bus type PCI registered
+[    0.161655] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
+[    0.162805] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000)
+[    0.164441] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820
+[    0.165592] PCI: Using configuration type 1 for base access
+[    0.166553] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
+[    0.167679] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
+[    0.169123] ACPI: Added _OSI(Module Device)
+[    0.169657] ACPI: Added _OSI(Processor Device)
+[    0.170402] ACPI: Added _OSI(3.0 _SCP Extensions)
+[    0.171180] ACPI: Added _OSI(Processor Aggregator Device)
+[    0.172120] ACPI: Added _OSI(Linux-Dell-Video)
+[    0.172866] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
+[    0.173655] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
+[    0.176672] ACPI: 1 ACPI AML tables successfully acquired and loaded
+[    0.178693] ACPI: Interpreter enabled
+[    0.179358] ACPI: (supports S0 S5)
+[    0.179937] ACPI: Using IOAPIC for interrupt routing
+[    0.180969] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
+[    0.181842] ACPI: Enabled 3 GPEs in block 00 to 3F
+[    0.188692] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
+[    0.189662] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
+[    0.191262] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR]
+[    0.192546] acpi PNP0A08:00: _OSC: OS now controls [SHPCHotplug PME PCIeCapability]
+[    0.193820] PCI host bridge to bus 0000:00
+[    0.194509] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
+[    0.195642] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
+[    0.196770] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
+[    0.197654] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window]
+[    0.198902] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window]
+[    0.200182] pci_bus 0000:00: root bus resource [mem 0x1000000000-0x17ffffffff window]
+[    0.201533] pci_bus 0000:00: root bus resource [bus 00-ff]
+[    0.201712] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000
+[    0.203324] pci 0000:00:01.0: [1af4:1003] type 00 class 0x078000
+[    0.205657] pci 0000:00:01.0: reg 0x10: [io  0x60c0-0x60ff]
+[    0.208353] pci 0000:00:01.0: reg 0x14: [mem 0xc0003000-0xc0003fff]
+[    0.213657] pci 0000:00:01.0: reg 0x20: [mem 0x1000000000-0x1000003fff 64bit pref]
+[    0.218281] pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
+[    0.223034] pci 0000:00:03.0: [1af4:1004] type 00 class 0x010000
+[    0.225394] pci 0000:00:03.0: reg 0x10: [io  0x6080-0x60bf]
+[    0.226822] pci 0000:00:03.0: reg 0x14: [mem 0xc0002000-0xc0002fff]
+[    0.230911] pci 0000:00:03.0: reg 0x20: [mem 0x1000004000-0x1000007fff 64bit pref]
+[    0.235919] pci 0000:00:04.0: [1af4:1005] type 00 class 0x00ff00
+[    0.237656] pci 0000:00:04.0: reg 0x10: [io  0x6120-0x613f]
+[    0.241656] pci 0000:00:04.0: reg 0x20: [mem 0x1000008000-0x100000bfff 64bit pref]
+[    0.244288] pci 0000:00:05.0: [1af4:1009] type 00 class 0x000200
+[    0.247672] pci 0000:00:05.0: reg 0x10: [io  0x6040-0x607f]
+[    0.249624] pci 0000:00:05.0: reg 0x14: [mem 0xc0001000-0xc0001fff]
+[    0.252855] pci 0000:00:05.0: reg 0x20: [mem 0x100000c000-0x100000ffff 64bit pref]
+[    0.257540] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100
+[    0.258154] pci 0000:00:1f.0: quirk: [io  0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO
+[    0.259985] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601
+[    0.264875] pci 0000:00:1f.2: reg 0x20: [io  0x6100-0x611f]
+[    0.267416] pci 0000:00:1f.2: reg 0x24: [mem 0xc0000000-0xc0000fff]
+[    0.269582] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500
+[    0.271746] pci 0000:00:1f.3: reg 0x20: [io  0x6000-0x603f]
+[    0.274063] pci_bus 0000:01: extended config space not accessible
+[    0.275352] acpiphp: Slot [0] registered
+[    0.276038] acpiphp: Slot [1] registered
+[    0.277675] acpiphp: Slot [2] registered
+[    0.278353] acpiphp: Slot [3] registered
+[    0.279150] acpiphp: Slot [4] registered
+[    0.279837] acpiphp: Slot [5] registered
+[    0.280509] acpiphp: Slot [6] registered
+[    0.281280] acpiphp: Slot [7] registered
+[    0.281677] acpiphp: Slot [8] registered
+[    0.282360] acpiphp: Slot [9] registered
+[    0.283032] acpiphp: Slot [10] registered
+[    0.283814] acpiphp: Slot [11] registered
+[    0.284510] acpiphp: Slot [12] registered
+[    0.285203] acpiphp: Slot [13] registered
+[    0.285678] acpiphp: Slot [14] registered
+[    0.286378] acpiphp: Slot [15] registered
+[    0.287111] acpiphp: Slot [16] registered
+[    0.288055] acpiphp: Slot [17] registered
+[    0.288803] acpiphp: Slot [18] registered
+[    0.289541] acpiphp: Slot [19] registered
+[    0.289674] acpiphp: Slot [20] registered
+[    0.290384] acpiphp: Slot [21] registered
+[    0.291086] acpiphp: Slot [22] registered
+[    0.291778] acpiphp: Slot [23] registered
+[    0.292480] acpiphp: Slot [24] registered
+[    0.293211] acpiphp: Slot [25] registered
+[    0.293674] acpiphp: Slot [26] registered
+[    0.294385] acpiphp: Slot [27] registered
+[    0.295071] acpiphp: Slot [28] registered
+[    0.295953] acpiphp: Slot [29] registered
+[    0.296769] acpiphp: Slot [30] registered
+[    0.297594] acpiphp: Slot [31] registered
+[    0.297916] pci 0000:00:02.0: PCI bridge to [bus 01]
+[    0.300138] pci_bus 0000:00: on NUMA node 0
+[    0.301275] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
+[    0.301748] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
+[    0.302965] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
+[    0.304172] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
+[    0.305263] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11)
+[    0.305787] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11)
+[    0.306849] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11)
+[    0.308110] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11)
+[    0.309202] ACPI: PCI Interrupt Link [GSIA] (IRQs *16)
+[    0.309667] ACPI: PCI Interrupt Link [GSIB] (IRQs *17)
+[    0.310565] ACPI: PCI Interrupt Link [GSIC] (IRQs *18)
+[    0.311446] ACPI: PCI Interrupt Link [GSID] (IRQs *19)
+[    0.312329] ACPI: PCI Interrupt Link [GSIE] (IRQs *20)
+[    0.313253] ACPI: PCI Interrupt Link [GSIF] (IRQs *21)
+[    0.313672] ACPI: PCI Interrupt Link [GSIG] (IRQs *22)
+[    0.314722] ACPI: PCI Interrupt Link [GSIH] (IRQs *23)
+[    0.317172] iommu: Default domain type: Translated
+[    0.317728] vgaarb: loaded
+[    0.318310] SCSI subsystem initialized
+[    0.318954] pps_core: LinuxPPS API ver. 1 registered
+[    0.319804] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
+[    0.321326] PTP clock support registered
+[    0.321687] Registered efivars operations
+[    0.322500] PCI: Using ACPI for IRQ routing
+[    0.323211] PCI: pci_cache_line_size set to 64 bytes
+[    0.324206] e820: reserve RAM buffer [mem 0x00810000-0x008fffff]
+[    0.325212] e820: reserve RAM buffer [mem 0x7f6ef000-0x7fffffff]
+[    0.325657] e820: reserve RAM buffer [mem 0x7fe60000-0x7fffffff]
+[    0.326754] clocksource: Switched to clocksource kvm-clock
+[    0.327844] pnp: PnP ACPI init
+[    0.328425] pnp 00:00: Plug and Play ACPI device, IDs PNP0303 (active)
+[    0.329649] pnp 00:01: Plug and Play ACPI device, IDs PNP0f13 (active)
+[    0.329809] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
+[    0.331078] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
+[    0.332465] system 00:04: [mem 0xb0000000-0xbfffffff window] has been reserved
+[    0.333902] system 00:04: Plug and Play ACPI device, IDs PNP0c01 (active)
+[    0.335579] pnp: PnP ACPI: found 5 devices
+[    0.341670] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
+[    0.343568] NET: Registered protocol family 2
+[    0.345189] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes, linear)
+[    0.346697] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear)
+[    0.348298] TCP bind hash table entries: 16384 (order: 6, 262144 bytes, linear)
+[    0.349954] TCP: Hash tables configured (established 16384 bind 16384)
+[    0.351468] UDP hash table entries: 1024 (order: 3, 32768 bytes, linear)
+[    0.352774] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes, linear)
+[    0.354001] NET: Registered protocol family 1
+[    0.354738] pci 0000:00:02.0: PCI bridge to [bus 01]
+[    0.359275] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
+[    0.360332] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
+[    0.361390] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
+[    0.362681] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window]
+[    0.364042] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window]
+[    0.365243] pci_bus 0000:00: resource 9 [mem 0x1000000000-0x17ffffffff window]
+[    0.366666] PCI: CLS 0 bytes, default 64
+[    0.367453] Trying to unpack rootfs image as initramfs...
+[    2.474287] Freeing initrd memory: 104480K
+[    2.474789] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns
+[    2.476083] workingset: timestamp_bits=46 max_order=19 bucket_order=0
+[    2.477757] fuse: init (API version 7.32)
+[    2.478215] SGI XFS with security attributes, no debug enabled
+[    2.478997] 9p: Installing v9fs 9p2000 file system support
+[    2.479591] NET: Registered protocol family 38
+[    2.480035] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
+[    2.480870] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
+[    2.481582] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
+[    2.482309] ACPI: Power Button [PWRF]
+[    2.482943] PCI Interrupt Link [GSIF] enabled at IRQ 21
+[    2.484131] PCI Interrupt Link [GSIH] enabled at IRQ 23
+[    2.485303] PCI Interrupt Link [GSIE] enabled at IRQ 20
+[    2.486896] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+[    2.487599] 00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
+[    2.513070] printk: console [hvc0] enabled
+[    2.514550] brd: module loaded
+[    2.515360] random: fast init done
+[    2.516052] loop: module loaded
+[    2.516563] random: crng init done
+[    2.517477] scsi host0: Virtio SCSI HBA
+[    2.518342] VFIO - User Level meta-driver version: 0.3
+[    2.519286] xt_time: kernel timezone is -0000
+[    2.519803] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
+[    2.520504] IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
+[    2.521364] IPVS: ipvs loaded.
+[    2.521734] IPVS: [rr] scheduler registered.
+[    2.522232] IPVS: [wrr] scheduler registered.
+[    2.522732] IPVS: [lc] scheduler registered.
+[    2.523234] IPVS: [wlc] scheduler registered.
+[    2.523733] IPVS: [fo] scheduler registered.
+[    2.524237] IPVS: [ovf] scheduler registered.
+[    2.524741] IPVS: [lblc] scheduler registered.
+[    2.525253] IPVS: [lblcr] scheduler registered.
+[    2.525778] IPVS: [dh] scheduler registered.
+[    2.526281] IPVS: [sh] scheduler registered.
+[    2.526770] IPVS: [sed] scheduler registered.
+[    2.527273] IPVS: [nq] scheduler registered.
+[    2.527761] IPVS: ftp: loaded support on port[0] = 21
+[    2.528335] IPVS: [sip] pe registered.
+[    2.528913] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
+[    2.529668] Initializing XFRM netlink socket
+[    2.530243] NET: Registered protocol family 10
+[    2.530990] Segment Routing with IPv6
+[    2.531446] NET: Registered protocol family 17
+[    2.531980] 9pnet: Installing 9P2000 support
+[    2.532904] NET: Registered protocol family 40
+[    2.533452] IPI shorthand broadcast: enabled
+[    2.533957] sched_clock: Marking stable (2450694990, 83251786)->(2555552194, -21605418)
+[    2.535774] Freeing unused decrypted memory: 2036K
+[    2.536717] Freeing unused kernel image (initmem) memory: 892K
+[    2.537482] Write protecting the kernel read-only data: 14336k
+[    2.538869] Freeing unused kernel image (text/rodata gap) memory: 2044K
+[    2.539890] Freeing unused kernel image (rodata/data gap) memory: 592K
+[    2.540714] Run /init as init process
+[    2.541191]   with arguments:
+[    2.541582]     /init
+[    2.541885]   with environment:
+[    2.542325]     HOME=/
+[    2.542640]     TERM=linux
+```
+
+Expected output as previous versions 
+Complete output from QEMU 6.0.0 with SEV :  
+```
+[    0.000000] Linux version 5.10.25 (gitlab-runner@runner-buildah0) (gcc (Debian 11.2.0-12) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Tue Dec 7 11:43:22 CET 2021
+[    0.000000] Command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug
+[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
+[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
+[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
+[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
+[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.
+[    0.000000] BIOS-provided physical RAM map:
+[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007f6eefff] usable
+[    0.000000] BIOS-e820: [mem 0x000000007f6ef000-0x000000007f96efff] reserved
+[    0.000000] BIOS-e820: [mem 0x000000007f96f000-0x000000007f97efff] ACPI data
+[    0.000000] BIOS-e820: [mem 0x000000007f97f000-0x000000007f9fefff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x000000007f9ff000-0x000000007fe5ffff] usable
+[    0.000000] BIOS-e820: [mem 0x000000007fe60000-0x000000007fe7ffff] reserved
+[    0.000000] BIOS-e820: [mem 0x000000007fe80000-0x000000007fffffff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
+[    0.000000] NX (Execute Disable) protection: active
+[    0.000000] efi: EFI v2.70 by EDK II
+[    0.000000] efi: SMBIOS=0x7f7ab000 ACPI=0x7f97e000 ACPI 2.0=0x7f97e014 MEMATTR=0x7e9d8118
+[    0.000000] SMBIOS 2.8 present.
+[    0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
+[    0.000000] Hypervisor detected: KVM
+[    0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
+[    0.000000] kvm-clock: cpu 0, msr 14201001, primary cpu clock
+[    0.000001] kvm-clock: using sched offset of 3987202924 cycles
+[    0.000004] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
+[    0.000006] tsc: Detected 2994.372 MHz processor
+[    0.000158] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
+[    0.000161] e820: remove [mem 0x000a0000-0x000fffff] usable
+[    0.000168] last_pfn = 0x7fe60 max_arch_pfn = 0x400000000
+[    0.000215] MTRR default type: write-back
+[    0.000216] MTRR fixed ranges enabled:
+[    0.000218]   00000-9FFFF write-back
+[    0.000220]   A0000-FFFFF uncachable
+[    0.000220] MTRR variable ranges enabled:
+[    0.000222]   0 base 0000C0000000 mask FFFFC0000000 uncachable
+[    0.000224]   1 base 0000B0000000 mask FFFFF0000000 uncachable
+[    0.000226]   2 base 001000000000 mask FFF800000000 uncachable
+[    0.000227]   3 disabled
+[    0.000227]   4 disabled
+[    0.000228]   5 disabled
+[    0.000229]   6 disabled
+[    0.000230]   7 disabled
+[    0.000274] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
+[    0.008664] Using GB pages for direct mapping
+[    0.009370] Secure boot could not be determined
+[    0.009372] RAMDISK: [mem 0x6f1ee000-0x757f5fff]
+[    0.009399] ACPI: Early table checksum verification disabled
+[    0.009410] ACPI: RSDP 0x000000007F97E014 000024 (v02 BOCHS )
+[    0.009415] ACPI: XSDT 0x000000007F97D0E8 000054 (v01 BOCHS  BXPC     00000001      01000013)
+[    0.009423] ACPI: FACP 0x000000007F978000 0000F4 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.009430] ACPI: DSDT 0x000000007F979000 003278 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.009435] ACPI: FACS 0x000000007F9DD000 000040
+[    0.009439] ACPI: APIC 0x000000007F977000 000170 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.009443] ACPI: HPET 0x000000007F976000 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.009448] ACPI: SRAT 0x000000007F975000 0002D0 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.009452] ACPI: MCFG 0x000000007F974000 00003C (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.009456] ACPI: WAET 0x000000007F973000 000028 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.009466] ACPI: Local APIC address 0xfee00000
+[    0.009507] Zone ranges:
+[    0.009508]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
+[    0.009511]   DMA32    [mem 0x0000000001000000-0x000000007fe5ffff]
+[    0.009513]   Normal   empty
+[    0.009514]   Device   empty
+[    0.009516] Movable zone start for each node
+[    0.009517] Early memory node ranges
+[    0.009518]   node   0: [mem 0x0000000000001000-0x000000000009ffff]
+[    0.009520]   node   0: [mem 0x0000000000100000-0x00000000007fffff]
+[    0.009521]   node   0: [mem 0x0000000000808000-0x000000000080ffff]
+[    0.009522]   node   0: [mem 0x0000000000900000-0x000000007f6eefff]
+[    0.009523]   node   0: [mem 0x000000007f9ff000-0x000000007fe5ffff]
+[    0.009525] Initmem setup node 0 [mem 0x0000000000001000-0x000000007fe5ffff]
+[    0.009528] On node 0 totalpages: 522743
+[    0.009529]   DMA zone: 59 pages used for memmap
+[    0.009531]   DMA zone: 1814 pages reserved
+[    0.009532]   DMA zone: 3751 pages, LIFO batch:0
+[    0.009843]   DMA zone: 29017 pages in unavailable ranges
+[    0.009845]   DMA32 zone: 8122 pages used for memmap
+[    0.009846]   DMA32 zone: 518992 pages, LIFO batch:63
+[    0.014033]   DMA32 zone: 1200 pages in unavailable ranges
+[    0.014785] ACPI: PM-Timer IO Port: 0x608
+[    0.014788] ACPI: Local APIC address 0xfee00000
+[    0.014803] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
+[    0.014994] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
+[    0.014998] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
+[    0.015001] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
+[    0.015003] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
+[    0.015005] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
+[    0.015006] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
+[    0.015007] ACPI: IRQ0 used by override.
+[    0.015009] ACPI: IRQ5 used by override.
+[    0.015010] ACPI: IRQ9 used by override.
+[    0.015011] ACPI: IRQ10 used by override.
+[    0.015011] ACPI: IRQ11 used by override.
+[    0.015014] Using ACPI (MADT) for SMP configuration information
+[    0.015017] ACPI: HPET id: 0x8086a201 base: 0xfed00000
+[    0.015021] TSC deadline timer available
+[    0.015027] smpboot: Allowing 32 CPUs, 31 hotplug CPUs
+[    0.015039] kvm-guest: KVM setup pv remote TLB flush
+[    0.015048] kvm-guest: setup PV sched yield
+[    0.015065] [mem 0xc0000000-0xffffffff] available for PCI devices
+[    0.015066] Booting paravirtualized kernel on KVM
+[    0.015070] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
+[    0.020345] setup_percpu: NR_CPUS:240 nr_cpumask_bits:240 nr_cpu_ids:32 nr_node_ids:1
+[    0.021575] percpu: Embedded 42 pages/cpu s143360 r0 d28672 u262144
+[    0.021585] pcpu-alloc: s143360 r0 d28672 u262144 alloc=1*2097152
+[    0.021587] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 12 13 14 15
+[    0.021596] pcpu-alloc: [0] 16 17 18 19 20 21 22 23 [0] 24 25 26 27 28 29 30 31
+[    0.027137] kvm-guest: KVM setup async PF for cpu 0
+[    0.027144] kvm-guest: stealtime: cpu 0, msr 7d622080
+[    0.027159] Built 1 zonelists, mobility grouping on.  Total pages: 512748
+[    0.027161] Kernel command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug
+[    0.027288] printk: log_buf_len individual max cpu contribution: 4096 bytes
+[    0.027290] printk: log_buf_len total cpu_extra contributions: 126976 bytes
+[    0.027291] printk: log_buf_len min size: 131072 bytes
+[    0.027523] printk: log_buf_len: 262144 bytes
+[    0.027524] printk: early log buf free: 123296(94%)
+[    0.027737] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
+[    0.027850] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
+[    0.027991] mem auto-init: stack:off, heap alloc:off, heap free:off
+[    0.040909] Memory: 1711324K/2090972K available (10242K kernel code, 956K rwdata, 1456K rodata, 892K init, 3564K bss, 379392K reserved, 0K cma-reserved)
+[    0.041029] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=1
+[    0.041170] rcu: Hierarchical RCU implementation.
+[    0.041171] rcu: 	RCU restricting CPUs from NR_CPUS=240 to nr_cpu_ids=32.
+[    0.041173] 	All grace periods are expedited (rcu_expedited).
+[    0.041174] 	Tracing variant of Tasks RCU enabled.
+[    0.041176] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
+[    0.041177] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=32
+[    0.041233] NR_IRQS: 15616, nr_irqs: 680, preallocated irqs: 16
+[    0.041739] rcu: 	Offload RCU callbacks from CPUs: (none).
+[    0.041913] random: get_random_bytes called from start_kernel+0x2fc/0x4ae with crng_init=0
+[    0.041995] Console: colour dummy device 80x25
+[    0.140890] printk: console [ttyS0] enabled
+[    0.154171] AMD Memory Encryption Features active: SEV
+[    0.154858] ACPI: Core revision 20200925
+[    0.155536] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
+[    0.156743] APIC: Switch to symmetric I/O mode setup
+[    0.158619] x2apic enabled
+[    0.160959] Switched APIC routing to physical x2apic.
+[    0.161554] kvm-guest: setup PV IPIs
+[    0.168397] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
+[    0.169300] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns
+[    0.170521] Calibrating delay loop (skipped) preset value.. 5988.74 BogoMIPS (lpj=11977488)
+[    0.171487] pid_max: default: 32768 minimum: 301
+[    0.202181] LSM: Security Framework initializing
+[    0.202548] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
+[    0.203685] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
+[    0.205011] x86/cpu: User Mode Instruction Prevention (UMIP) activated
+[    0.205802] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127
+[    0.206525] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0
+[    0.207435] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
+[    0.208419] Spectre V2 : Mitigation: Full AMD retpoline
+[    0.209026] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
+[    0.209975] Spectre V2 : Enabling Restricted Speculation for firmware calls
+[    0.210523] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
+[    0.211737] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp
+[    0.213043] Freeing SMP alternatives memory: 28K
+[    0.213721] smpboot: CPU0: AMD EPYC 7302P 16-Core Processor (family: 0x17, model: 0x31, stepping: 0x0)
+[    0.214519] Performance Events: Fam17h+ core perfctr, AMD PMU driver.
+[    0.214519] ... version:                0
+[    0.214519] ... bit width:              48
+[    0.214519] ... generic registers:      6
+[    0.214519] ... value mask:             0000ffffffffffff
+[    0.214525] ... max period:             00007fffffffffff
+[    0.215142] ... fixed-purpose events:   0
+[    0.215616] ... event mask:             000000000000003f
+[    0.216346] rcu: Hierarchical SRCU implementation.
+[    0.217174] smp: Bringing up secondary CPUs ...
+[    0.217714] smp: Brought up 1 node, 1 CPU
+[    0.218184] smpboot: Max logical packages: 32
+[    0.218527] smpboot: Total of 1 processors activated (5988.74 BogoMIPS)
+[    0.219686] devtmpfs: initialized
+[    0.220119] x86/mm: Memory block size: 128MB
+[    0.220864] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
+[    0.221995] futex hash table entries: 8192 (order: 7, 524288 bytes, linear)
+[    0.222863] NET: Registered protocol family 16
+[    0.223660] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations
+[    0.224813] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
+[    0.225857] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
+[    0.226565] thermal_sys: Registered thermal governor 'step_wise'
+[    0.226569] cpuidle: using governor menu
+[    0.228447] ACPI: bus type PCI registered
+[    0.228925] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
+[    0.229775] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000)
+[    0.230527] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820
+[    0.231331] PCI: Using configuration type 1 for base access
+[    0.232839] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
+[    0.233641] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
+[    0.234545] ACPI: Added _OSI(Module Device)
+[    0.235040] ACPI: Added _OSI(Processor Device)
+[    0.235568] ACPI: Added _OSI(3.0 _SCP Extensions)
+[    0.236115] ACPI: Added _OSI(Processor Aggregator Device)
+[    0.236745] ACPI: Added _OSI(Linux-Dell-Video)
+[    0.237264] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
+[    0.237886] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
+[    0.240277] ACPI: 1 ACPI AML tables successfully acquired and loaded
+[    0.242125] ACPI: Interpreter enabled
+[    0.242530] ACPI: (supports S0 S5)
+[    0.242933] ACPI: Using IOAPIC for interrupt routing
+[    0.243537] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
+[    0.244744] ACPI: Enabled 2 GPEs in block 00 to 3F
+[    0.250149] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
+[    0.250531] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
+[    0.251661] acpi PNP0A08:00: _OSC: platform does not support [LTR]
+[    0.252454] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug SHPCHotplug PME PCIeCapability]
+[    0.253626] PCI host bridge to bus 0000:00
+[    0.254115] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
+[    0.254526] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
+[    0.255309] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
+[    0.256179] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window]
+[    0.257045] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window]
+[    0.257910] pci_bus 0000:00: root bus resource [mem 0x1000000000-0x17ffffffff window]
+[    0.258525] pci_bus 0000:00: root bus resource [bus 00-ff]
+[    0.259223] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000
+[    0.260509] pci 0000:00:01.0: [1af4:1043] type 00 class 0x078000
+[    0.263098] pci 0000:00:01.0: reg 0x14: [mem 0xc0003000-0xc0003fff]
+[    0.267149] pci 0000:00:01.0: reg 0x20: [mem 0x1000000000-0x1000003fff 64bit pref]
+[    0.269843] pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
+[    0.275338] pci 0000:00:03.0: [1af4:1048] type 00 class 0x010000
+[    0.277811] pci 0000:00:03.0: reg 0x14: [mem 0xc0002000-0xc0002fff]
+[    0.281320] pci 0000:00:03.0: reg 0x20: [mem 0x1000004000-0x1000007fff 64bit pref]
+[    0.284951] pci 0000:00:04.0: [1af4:1044] type 00 class 0x00ff00
+[    0.287749] pci 0000:00:04.0: reg 0x20: [mem 0x1000008000-0x100000bfff 64bit pref]
+[    0.289851] pci 0000:00:05.0: [1af4:1049] type 00 class 0x000200
+[    0.292301] pci 0000:00:05.0: reg 0x14: [mem 0xc0001000-0xc0001fff]
+[    0.295709] pci 0000:00:05.0: reg 0x20: [mem 0x100000c000-0x100000ffff 64bit pref]
+[    0.298275] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100
+[    0.299038] pci 0000:00:1f.0: quirk: [io  0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO
+[    0.300211] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601
+[    0.306084] pci 0000:00:1f.2: reg 0x20: [io  0x6040-0x605f]
+[    0.307285] pci 0000:00:1f.2: reg 0x24: [mem 0xc0000000-0xc0000fff]
+[    0.309200] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500
+[    0.312072] pci 0000:00:1f.3: reg 0x20: [io  0x6000-0x603f]
+[    0.314207] pci_bus 0000:01: extended config space not accessible
+[    0.314817] pci 0000:00:02.0: PCI bridge to [bus 01]
+[    0.317358] pci_bus 0000:00: on NUMA node 0
+[    0.318107] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
+[    0.318611] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
+[    0.319355] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
+[    0.320094] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
+[    0.320826] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11)
+[    0.321565] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11)
+[    0.322302] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11)
+[    0.322608] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11)
+[    0.323292] ACPI: PCI Interrupt Link [GSIA] (IRQs *16)
+[    0.323908] ACPI: PCI Interrupt Link [GSIB] (IRQs *17)
+[    0.324522] ACPI: PCI Interrupt Link [GSIC] (IRQs *18)
+[    0.325132] ACPI: PCI Interrupt Link [GSID] (IRQs *19)
+[    0.325746] ACPI: PCI Interrupt Link [GSIE] (IRQs *20)
+[    0.326356] ACPI: PCI Interrupt Link [GSIF] (IRQs *21)
+[    0.326533] ACPI: PCI Interrupt Link [GSIG] (IRQs *22)
+[    0.327148] ACPI: PCI Interrupt Link [GSIH] (IRQs *23)
+[    0.329169] iommu: Default domain type: Translated
+[    0.329808] vgaarb: loaded
+[    0.330245] SCSI subsystem initialized
+[    0.330537] pps_core: LinuxPPS API ver. 1 registered
+[    0.331124] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
+[    0.332182] PTP clock support registered
+[    0.332667] Registered efivars operations
+[    0.333281] PCI: Using ACPI for IRQ routing
+[    0.333783] PCI: pci_cache_line_size set to 64 bytes
+[    0.334528] e820: reserve RAM buffer [mem 0x00810000-0x008fffff]
+[    0.335230] e820: reserve RAM buffer [mem 0x7f6ef000-0x7fffffff]
+[    0.335932] e820: reserve RAM buffer [mem 0x7fe60000-0x7fffffff]
+[    0.336675] clocksource: Switched to clocksource kvm-clock
+[    0.337485] pnp: PnP ACPI init
+[    0.337896] pnp 00:00: Plug and Play ACPI device, IDs PNP0303 (active)
+[    0.338519] pnp 00:01: Plug and Play ACPI device, IDs PNP0f13 (active)
+[    0.338519] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
+[    0.338519] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
+[    0.338920] system 00:04: [mem 0xb0000000-0xbfffffff window] has been reserved
+[    0.339770] system 00:04: Plug and Play ACPI device, IDs PNP0c01 (active)
+[    0.341103] pnp: PnP ACPI: found 5 devices
+[    0.346943] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
+[    0.348014] NET: Registered protocol family 2
+[    0.348722] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes, linear)
+[    0.349720] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear)
+[    0.350698] TCP bind hash table entries: 16384 (order: 6, 262144 bytes, linear)
+[    0.351620] TCP: Hash tables configured (established 16384 bind 16384)
+[    0.352423] UDP hash table entries: 1024 (order: 3, 32768 bytes, linear)
+[    0.353213] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes, linear)
+[    0.354115] NET: Registered protocol family 1
+[    0.354654] pci 0000:00:02.0: PCI bridge to [bus 01]
+[    0.357279] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
+[    0.358008] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
+[    0.358744] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
+[    0.359541] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window]
+[    0.360345] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window]
+[    0.361145] pci_bus 0000:00: resource 9 [mem 0x1000000000-0x17ffffffff window]
+[    0.362089] PCI: CLS 0 bytes, default 64
+[    0.362638] Trying to unpack rootfs image as initramfs...
+[    2.307254] Freeing initrd memory: 104480K
+[    2.307791] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
+[    2.308521] software IO TLB: mapped [mem 0x0000000069000000-0x000000006d000000] (64MB)
+[    2.309454] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns
+[    2.311063] workingset: timestamp_bits=46 max_order=19 bucket_order=0
+[    2.313608] fuse: init (API version 7.32)
+[    2.314181] SGI XFS with security attributes, no debug enabled
+[    2.315435] 9p: Installing v9fs 9p2000 file system support
+[    2.316233] NET: Registered protocol family 38
+[    2.316827] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
+[    2.317926] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
+[    2.318847] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
+[    2.319752] ACPI: Power Button [PWRF]
+[    2.320661] PCI Interrupt Link [GSIF] enabled at IRQ 21
+[    2.322549] PCI Interrupt Link [GSIH] enabled at IRQ 23
+[    2.324157] PCI Interrupt Link [GSIE] enabled at IRQ 20
+[    2.326555] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+[    2.327388] 00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
+[    2.341959] software IO TLB: Memory encryption is active and system is using DMA bounce buffers
+[    2.344242] printk: console [hvc0] enabled
+[    2.346335] brd: module loaded
+[    2.347023] random: fast init done
+[    2.347786] random: crng init done
+[    2.349418] loop: module loaded
+[    2.351182] scsi host0: Virtio SCSI HBA
+[    2.352317] VFIO - User Level meta-driver version: 0.3
+[    2.353380] xt_time: kernel timezone is -0000
+[    2.354028] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
+[    2.354873] IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
+[    2.355859] IPVS: ipvs loaded.
+[    2.356319] IPVS: [rr] scheduler registered.
+[    2.356933] IPVS: [wrr] scheduler registered.
+[    2.357542] IPVS: [lc] scheduler registered.
+[    2.358152] IPVS: [wlc] scheduler registered.
+[    2.358787] IPVS: [fo] scheduler registered.
+[    2.359343] IPVS: [ovf] scheduler registered.
+[    2.359968] IPVS: [lblc] scheduler registered.
+[    2.360595] IPVS: [lblcr] scheduler registered.
+[    2.361236] IPVS: [dh] scheduler registered.
+[    2.361846] IPVS: [sh] scheduler registered.
+[    2.362468] IPVS: [sed] scheduler registered.
+[    2.363060] IPVS: [nq] scheduler registered.
+[    2.363623] IPVS: ftp: loaded support on port[0] = 21
+[    2.364272] IPVS: [sip] pe registered.
+[    2.364967] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
+[    2.365818] Initializing XFRM netlink socket
+[    2.366474] NET: Registered protocol family 10
+[    2.367351] Segment Routing with IPv6
+[    2.367888] NET: Registered protocol family 17
+[    2.368518] 9pnet: Installing 9P2000 support
+[    2.369955] NET: Registered protocol family 40
+[    2.370608] IPI shorthand broadcast: enabled
+[    2.371198] sched_clock: Marking stable (2249797515, 120751625)->(2381329269, -10780129)
+[    2.373554] Freeing unused decrypted memory: 2036K
+[    2.374622] Freeing unused kernel image (initmem) memory: 892K
+[    2.375403] Write protecting the kernel read-only data: 14336k
+[    2.377004] Freeing unused kernel image (text/rodata gap) memory: 2044K
+[    2.378219] Freeing unused kernel image (rodata/data gap) memory: 592K
+[    2.379114] Run /init as init process
+[    2.379599]   with arguments:
+[    2.380009]     /init
+[    2.380321]   with environment:
+[    2.380749]     HOME=/
+[    2.381071]     TERM=linux
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1023 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1023
new file mode 100644
index 00000000..d3534699
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1023
@@ -0,0 +1,60 @@
+TCG & LA57 (5-level page tables) causes intermittent triple fault when setting %CR3
+Description of problem:
+Enabling LA57 (5-level page tables) + TCG causes an intermittent triple fault when the kernel loads %cr3 in preparation for jumping to protected mode.  It is quite rare, only happening on perhaps 1 in 20 runs.
+
+The observed behaviour for most users is that we see SeaBIOS messages, and no kernel messages, and qemu exits.  (Triple fault in TCG code causes qemu to reset the virtual CPU, and we are using `-no-reboot` so that causes qemu to exit).
+
+There's a simple reproducer below.  I enabled qemu -d options to capture the full instruction traces which can be found here:
+
+http://oirase.annexia.org/tmp/fullexec-failed (error case)
+http://oirase.annexia.org/tmp/fullexec-good (successful run)
+
+I also added an `abort()` into qemu after the triple fault message in order to capture a stack trace, which can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=2082806#c8
+Steps to reproduce:
+1. Save the following script into a file, adjusting the two variables at the top as appropriate:
+
+```
+#!/bin/bash -
+
+# Point this to any kernel in /boot:
+kernel=/boot/vmlinuz-4.18.0-387.el8.x86_64
+
+# Point this to qemu:
+qemu=/usr/libexec/qemu-kvm
+#qemu=/home/rjones/d/qemu/build/qemu-system-x86_64
+
+log=/tmp/log
+
+cpu=max
+#cpu=max,la57=off
+
+while $qemu \
+    -global virtio-blk-pci.scsi=off \
+    -no-user-config \
+    -nodefaults \
+    -display none \
+    -machine accel=tcg,graphics=off \
+    -cpu "$cpu" \
+    -m 2048 \
+    -no-reboot \
+    -rtc driftfix=slew \
+    -no-hpet \
+    -global kvm-pit.lost_tick_policy=discard \
+    -kernel $kernel \
+    -object rng-random,filename=/dev/urandom,id=rng0 \
+    -device virtio-rng-pci,rng=rng0 \
+    -device virtio-serial-pci \
+    -serial stdio \
+    -append "panic=1 console=ttyS0" >& $log &&
+    grep -sq "Linux version" $log; do
+    echo -n .
+done
+```
+
+2. Run the script.  It will run qemu many times, checking that it reaches the kernel.
+3. Eventually the script may exit. 
+4. Check `/tmp/log` and see if you only see SeaBIOS messages.
+5. Modify the script to add `-cpu max,la57=off` and the error will stop happening.
+Additional information:
+Downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=2082806
+LA57 was enabled here: https://gitlab.com/qemu-project/qemu/-/issues/661
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1059 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1059
new file mode 100644
index 00000000..a336146a
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1059
@@ -0,0 +1,10 @@
+qemu: uncaught target signal 6 (Aborted) - core dumped Issue
+Description of problem:
+When we are trying to use the docker images which is using Qemu internally in mac Os then we are getting the qemu: uncaught target signal 6 (Aborted) - core dumped Issue
+Steps to reproduce:
+1. https://botfront.io/docs/installation/local-machine install in local machine
+2. run bot front run
+3. Go to the docker dashboard and open the botfront-rasa. 
+4. ![Screenshot_2022-06-03_at_12.34.54_PM](/uploads/db4f0ba030cac850e1ae90189d1f8a55/Screenshot_2022-06-03_at_12.34.54_PM.png)
+Additional information:
+Looking forward to get some updates regarding how we can solve this or any hack we can apply here. Thanks in advance.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1143 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1143
new file mode 100644
index 00000000..c3576e3b
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1143
@@ -0,0 +1,78 @@
+Breakpoints missed when a function is split into two memory pages.
+Description of problem:
+Qemu seems to ignore some breakpoints when the start of a function is 
+in another page than where the breakpoint is set. 
+
+In my case, I've a function `__gnat_debug_raise_exception` which starts at `0x10bff2` and I've set with gdb a breakpoint at `0x10c00e` (in another page). 
+While running with `qemu -d in_asm,exec`, I can see that the whole function is executed at once and that no breakpoint is fired.
+
+```
+(gdb) b *0x00108fbc
+(gdb) b *0x0010c00e
+(gdb) target remote :1234 
+(gdb) c
+
+Trace 0: 0x7f277c0174c0 [0000000000000000/0000000000108fb9/0040c0b0/ff000201] ada__exceptions__complete_occurrence
+----------------
+
+// gdb hits first breakpoint here. 
+Breakpoint 3, 0x0000000000108fbc ....
+(gdb) ni
+
+IN: ada__exceptions__complete_occurrence
+0x00108fbc:  e8 31 30 00 00           callq    0x10bff2
+
+Trace 0: 0x7f277c000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence
+----------------
+IN: __gnat_debug_raise_exception
+0x0010bff2:  55                       pushq    %rbp
+0x0010bff3:  48 89 e5                 movq     %rsp, %rbp
+0x0010bff6:  48 89 7d f8              movq     %rdi, -8(%rbp)
+0x0010bffa:  48 89 d1                 movq     %rdx, %rcx
+0x0010bffd:  48 89 f0                 movq     %rsi, %rax
+0x0010c000:  48 89 fa                 movq     %rdi, %rdx
+0x0010c003:  48 89 ca                 movq     %rcx, %rdx
+0x0010c006:  48 89 45 e0              movq     %rax, -0x20(%rbp)
+0x0010c00a:  48 89 55 e8              movq     %rdx, -0x18(%rbp)
+0x0010c00e:  48 8b 45 e0              movq     -0x20(%rbp), %rax
+0x0010c012:  90                       nop      
+0x0010c013:  5d                       popq     %rbp
+0x0010c014:  c3                       retq     
+
+Trace 0: 0x7f277c000100 [0000000000000000/000000000010bff2/0040c0b0/ff000000] __gnat_debug_raise_exception
+Digging a bit more, it seems that it seems related to 
+
+// gdb ni stop here. Breakpoints at 0x10c00e have been ignored. 
+```
+
+Note that if I'm setting another breakpoint at `0x0010bffd` (thus not at the start of the function but still in the same page), the execution 
+will be executed step by step and the breakpoint at 0x10c00e will be triggered normally. 
+
+
+```
+IN: ada__exceptions__complete_occurrence
+0x00108fbc:  e8 31 30 00 00           callq    0x10bff2
+
+Trace 0: 0x7f6af4000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence
+----------------
+IN: __gnat_debug_raise_exception
+0x0010bff2:  55                       pushq    %rbp
+
+Trace 0: 0x7f6af4000100 [0000000000000000/000000000010bff2/0040c0b0/ff000201] __gnat_debug_raise_exception
+----------------
+IN: __gnat_debug_raise_exception
+0x0010bff3:  48 89 e5                 movq     %rsp, %rbp
+
+Trace 0: 0x7f6af4000280 [0000000000000000/000000000010bff3/0040c0b0/ff000201] __gnat_debug_raise_exception
+----------------
+IN: __gnat_debug_raise_exception
+0x0010bff6:  48 89 7d f8              movq     %rdi, -8(%rbp)
+...
+```
+
+I've dug a bit into qemu translator code and I guess `check_for_breakpoint` should check that the whole function is in the same page before skipping step by step. But I'm not sure if it's possible because the TB is created after `check_for_breakpoint` IIUC. 
+
+Sadly as of now, I don't have a C reproducer. I can try to provide you my "foo" program which is an Ada program. But maybe if you've a better idea how to reproduce that or an idea of to fix that, I'll be glad to help you.  
+
+Thanks, 
+Clément
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/125 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/125
new file mode 100644
index 00000000..002916f9
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/125
@@ -0,0 +1 @@
+x86: ret, lret and iret with noncanonical IP saves wrong IP on the exception stack
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1269 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1269
new file mode 100644
index 00000000..1e96cc92
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1269
@@ -0,0 +1,26 @@
+qemu-system-i386 no longer boots NetBSD
+Description of problem:
+Since qemu commit e3a79e0e87831602e41819591a8e6dcc70a2a231, NetBSD
+no longer boots under qemu-system-i386.
+Steps to reproduce:
+1. `wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.2/i386/installation/cdrom/boot-com.iso`
+2. `qemu-system-i386 -nographic -cdrom boot-com.iso`
+
+Expected behavior: the system boots and prompts you for a terminal type with
+
+    Terminal type (just hit ENTER for 'vt220'):
+
+Observed incorrect behavior: the guest kernel either hangs during boot at
+
+    Loading /stand/i386/9.2/modules/cd9660/cd9660.kmod  
+    WARNING: 1 module failed to load
+
+or panics during boot with
+
+    kernel: supervisor trap page fault, code=0
+    Stopped in pid 0.1 (system) at  netbsd:idt_vec_reserve+0xa:     cmpb    $0,netbs
+    d:idt_allocmap(%ebx)
+    db{0}>
+Additional information:
+This regression is a critical issue to the NetBSD project as its automated
+testing infrastructure is heavily dependent on qemu-system-i386.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/130 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/130
new file mode 100644
index 00000000..09099b7d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/130
@@ -0,0 +1 @@
+QEmu translation is incorrect when using REX in combination with LAHF/SAHF
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/132 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/132
new file mode 100644
index 00000000..f655cda6
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/132
@@ -0,0 +1 @@
+AVX instruction VMOVDQU implementation error for YMM registers
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1324 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1324
new file mode 100644
index 00000000..b794f4d6
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1324
@@ -0,0 +1,40 @@
+Unhandled exception when booting UEFI x86_64 system image
+Description of problem:
+I have a bootable Ubuntu 20.04-based operating system image that I typically flash to the internal storage of an embedded Intel Atom computer. When I try booting it under QEMU, I reach the GRUB boot menu, but when it attempts to start the kernel, it outputs:
+
+```
+ERROR:../target/i386/tcg/sysemu/excp_helper.c:517:raise_stage2: code should not be reached
+Bail out! ERROR:../target/i386/tcg/sysemu/excp_helper.c:517:raise_stage2: code should not be reached
+Aborted (core dumped)
+``` 
+
+The kernel settings configured in GRUB are:
+
+```
+linux         /boot/vmlinuz-5.4.0-132-generic root=UUID=816fe083-fc26-4a0d-ae4a-68d1b16dfb66 ro console=uart,mmio32,0xd091c000 console=ttyS4,115200n8 console=tty0                                                         ?
+initrd        /boot/initrd.img-5.4.0-132-generic 
+```
+
+If I run an older QEMU 4.2.1 that ships with Ubuntu:
+
+```
+!!!! X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 00000000 !!!!
+ExceptionData - 0000000000000000
+RIP  - 0000000007F2CD0E, CS  - 0000000000000038, RFLAGS - 0000000000200206
+RAX  - AFAFAFAFAFAFAFAF, RCX - 000000000657F408, RDX - AFAFAFAFAFAFAFAF
+RBX  - 0000000000000288, RSP - 0000000007F1BC48, RBP - 0000000007F336A0
+RSI  - 0000000007F336F8, RDI - 0000000000001000
+R8   - 000000000657F408, R9  - 0000000000000320, R10 - 0000000000000000
+R11  - 0000000000000000, R12 - 0000000000000004, R13 - 000000000657F400
+R14  - 0000000000000000, R15 - 0000000000000000
+DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
+GS   - 0000000000000030, SS  - 0000000000000030
+CR0  - 0000000080010033, CR2 - 0000000000000000, CR3 - 0000000007C01000
+CR4  - 0000000000000668, CR8 - 0000000000000000
+DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
+DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
+GDTR - 0000000007BEEA98 0000000000000047, LDTR - 0000000000000000
+IDTR - 00000000072D1018 0000000000000FFF,   TR - 0000000000000000
+FXSAVE_STATE - 0000000007F1B8A0
+!!!! Find image based on IP(0x7F2CD0E) /build/edk2-xUnmxG/edk2-0~20191122.bd85bf54/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll (ImageBase=0000000007F1D000, EntryPoint=0000000007F2FAAE) !!!!
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1350 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1350
new file mode 100644
index 00000000..87fc45ef
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1350
@@ -0,0 +1,89 @@
+Regression in 7.2.0rc3: No snow by efi firmware in advent calendar 2020, door 15 anymore
+Description of problem:
+Advent calendar 2020, door 15 is expected to produce snow on the terminal while executing the provided efi firmware:
+
+> snow in micropython on slimbootloader by eldon
+> -------------------------------------------
+> 
+> Today's advent is a custom efi firmware build of a new bootloader from intel called
+> slimbootloader[1], a recent project by intel which has adapted micropython[2] as a 
+> utility for configuration and board testing. This build, however, will show snowfall on
+> the console for a while. Eventually an exception drops the firmware into the micropython
+> repl.
+> 
+> [1] https://slimbootloader.github.io/supported-hardware/qemu.html
+> [2] http://docs.micropython.org/en/latest/index.html
+
+
+Snow does not fall anymore as it did with 7.1.0, it seems like execution is stopped/not started
+Steps to reproduce:
+- Build & Install from git source
+    ```
+    /home/helge/qemu-project/qemu/configure --prefix=/home/helge/qemu-project/install \
+      --target-list=x86_64-softmmu --disable-linux-user
+    make -j2
+    make install
+    ```
+ - Execute 
+   ```
+   PATH="/home/helge/qemu-project/install/bin" qemu-system-x86_64 \
+      -m 256M -machine q35 -serial mon:stdio -vga none \
+      -drive if=pflash,format=raw,file=snow.bin -boot a
+   ```
+Additional information:
+Performing git bisect starting with tag v7.1.0 as good and tag v7.2.0-rc3 as bad reveals 92ec056a6b2fc5d5a5593121c5d9475d2a2461d6 as culprit:
+   ```
+$ git bisect start c4ffd91aba1c3d878e99a3e7ba8aad4826728ece 621da7789083b80d6f1ff1c0fb499334007b4f51
+binäre Suche: danach noch 965 Commits zum Testen übrig (ungefähr 10 Schritte)
+[2ba341b3694cf3cff7b8a1df4cc765900d5c4f60] Merge tag 'kraxel-20221013-pull-request' of https://gitlab.com/kraxel/qemu into staging
+$ git bisect good
+binäre Suche: danach noch 482 Commits zum Testen übrig (ungefähr 9 Schritte)
+[05c049f12b88370de7289bf39b14088c7d656caa] hw/isa/piix3: Remove extra ';' outside of functions
+$ git bisect bad
+binäre Suche: danach noch 228 Commits zum Testen übrig (ungefähr 8 Schritte)
+[08a5d04606292b3cf6f5756bf2a095654a290626] Merge tag 'pull-tcg-20221026' of https://gitlab.com/rth7680/qemu into staging
+$ git bisect bad
+binäre Suche: danach noch 126 Commits zum Testen übrig (ungefähr 7 Schritte)
+[168122419ed1c4087748e21131a523c6d9b632e1] target/arm: Change gen_goto_tb to work on displacements
+$ git bisect bad
+binäre Suche: danach noch 69 Commits zum Testen übrig (ungefähr 6 Schritte)
+[2c65091fd9d387b8dca8115dbdd9c3c61f658a9e] Merge tag 'pull-ppc-20221017' of https://gitlab.com/danielhb/qemu into staging
+$ git bisect good
+binäre Suche: danach noch 34 Commits zum Testen übrig (ungefähr 5 Schritte)
+[92ec056a6b2fc5d5a5593121c5d9475d2a2461d6] target/i386: reimplement 0x0f 0x60-0x6f, add AVX
+$ git bisect bad
+binäre Suche: danach noch 17 Commits zum Testen übrig (ungefähr 4 Schritte)
+[8629e77be5f8106b3497cc197fbd57a12ae6333f] target/i386: Use probe_access_full for final stage2 translation
+$ git bisect good
+binäre Suche: danach noch 8 Commits zum Testen übrig (ungefähr 3 Schritte)
+[20581aadec5e5a9d6836e4612b6f44a7cbda7d16] target/i386: validate VEX prefixes via the instructions' exception classes
+$ git bisect good
+binäre Suche: danach noch 4 Commits zum Testen übrig (ungefähr 2 Schritte)
+[f05f9789f57d5394fc118fe31aa2a9f563311140] target/i386: extend helpers to support VEX.V 3- and 4- operand encodings
+$ git bisect good
+binäre Suche: danach noch 2 Commits zum Testen übrig (ungefähr 1 Schritt)
+[620f75566a5d81d7b82b3788b83d0b95c7d21dcd] target/i386: provide 3-operand versions of unary scalar helpers
+$ git bisect good
+binäre Suche: danach noch 0 Commits zum Testen übrig (ungefähr 1 Schritt)
+[b98f886c8f8661773047197d132efec97810b37a] target/i386: Introduce 256-bit vector helpers
+$ git bisect good
+92ec056a6b2fc5d5a5593121c5d9475d2a2461d6 is the first bad commit
+commit 92ec056a6b2fc5d5a5593121c5d9475d2a2461d6
+Author: Paolo Bonzini <pbonzini@redhat.com>
+Date:   Tue Sep 20 05:42:45 2022 -0400
+
+    target/i386: reimplement 0x0f 0x60-0x6f, add AVX
+    
+    These are both MMX and SSE/AVX instructions, except for vmovdqu.  In both
+    cases the inputs and output is in s->ptr{0,1,2}, so the only difference
+    between MMX, SSE, and AVX is which helper to call.
+    
+    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
+    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+
+ target/i386/tcg/decode-new.c.inc |  42 ++++++++
+ target/i386/tcg/emit.c.inc       | 202 +++++++++++++++++++++++++++++++++++++++
+ target/i386/tcg/translate.c      |  19 +++-
+ 3 files changed, 262 insertions(+), 1 deletion(-)
+
+   ```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1370 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1370
new file mode 100644
index 00000000..763211be
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1370
@@ -0,0 +1,13 @@
+x86 BLSI and BLSR semantic bug
+Description of problem:
+The result of instruction BLSI and BLSR is different from the CPU. The value of CF is different.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("blsi rax, rbx");
+}
+```
+2. Execute and compare the result with the CPU. The value of `CF` is exactly the opposite. This problem happens with BLSR, too.
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1371 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1371
new file mode 100644
index 00000000..833f1dfc
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1371
@@ -0,0 +1,19 @@
+x86 BLSMSK semantic bug
+Description of problem:
+The result of instruction BLSMSK is different with from the CPU. The value of CF is different.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("mov rax, 0x65b2e276ad27c67");
+    asm("mov rbx, 0x62f34955226b2b5d");
+    asm("blsmsk eax, ebx");
+}
+```
+2. Execute and compare the result with the CPU.
+    - CPU
+        - CF = 0
+    - QEMU
+        - CF = 1
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1372 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1372
new file mode 100644
index 00000000..c0a7f3da
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1372
@@ -0,0 +1,20 @@
+x86 BEXTR semantic bug
+Description of problem:
+The result of instruction BEXTR is different with from the CPU. The value of destination register is different. I think QEMU does not consider the operand size limit.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("mov rax, 0x17b3693f77fb6e9");
+    asm("mov rbx, 0x8f635a775ad3b9b4");
+    asm("mov rcx, 0xb717b75da9983018");
+    asm("bextr eax, ebx, ecx");
+}
+```
+2. Execute and compare the result with the CPU.
+    - CPU
+        - RAX = 0x5a
+    - QEMU
+        - RAX = 0x635a775a
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1373 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1373
new file mode 100644
index 00000000..c25a3a9e
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1373
@@ -0,0 +1,20 @@
+x86 ADOX and ADCX semantic bug
+Description of problem:
+The result of instruction ADOX and ADCX are different from the CPU. The value of one of EFLAGS is different.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("push 512; popfq;");
+    asm("mov rax, 0xffffffff84fdbf24");
+    asm("mov rbx, 0xb197d26043bec15d");
+    asm("adox eax, ebx");
+}
+```
+2. Execute and compare the result with the CPU. This problem happens with ADCX, too (with CF).
+    - CPU
+        - OF = 0
+    - QEMU
+        - OF = 1
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1374 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1374
new file mode 100644
index 00000000..bf04368e
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1374
@@ -0,0 +1,22 @@
+x86 BZHI semantic bug
+Description of problem:
+The result of instruction BZHI is different from the CPU. The value of destination register and SF of EFLAGS are different.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("mov rax, 0xb1aa9da2fe33fe3");
+    asm("mov rbx, 0x80000000ffffffff");
+    asm("mov rcx, 0xf3fce8829b99a5c6");
+    asm("bzhi rax, rbx, rcx");
+}
+```
+2. Execute and compare the result with the CPU.
+    - CPU
+        - RAX = 0x0x80000000ffffffff
+        - SF = 1
+    - QEMU
+        - RAX = 0xffffffff
+        - SF = 0
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1375 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1375
new file mode 100644
index 00000000..d7847c8e
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1375
@@ -0,0 +1,19 @@
+x86 SSE/SSE2/SSE3 instruction semantic bugs with NaN
+Description of problem:
+The result of SSE/SSE2/SSE3 instructions with NaN is different from the CPU. From Intel manual Volume 1 Appendix D.4.2.2, they defined the behavior of such instructions with NaN. But I think QEMU did not implement this semantic exactly because the byte result is different.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("mov rax, 0x000000007fffffff; push rax; mov rax, 0x00000000ffffffff; push rax; movdqu XMM1, [rsp];");
+    asm("mov rax, 0x2e711de7aa46af1a; push rax; mov rax, 0x7fffffff7fffffff; push rax; movdqu XMM2, [rsp];");
+    asm("addsubps xmm1, xmm2");
+}
+```
+2. Execute and compare the result with the CPU. This problem happens with other SSE/SSE2/SSE3 instructions specified in the manual, Volume 1 Appendix D.4.2.2.
+    - CPU
+        - xmm1[3] = 0xffffffff
+    - QEMU
+        - xmm1[3] = 0x7fffffff
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1376 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1376
new file mode 100644
index 00000000..06247c64
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1376
@@ -0,0 +1,15 @@
+x86 LSL and LAR fault
+Description of problem:
+From the description of LSL and LAR instructions in manual, `If the segment descriptor cannot be accessed or is an invalid type for the instruction, the ZF flag is cleared and no value is loaded in the destination operand.`. When it happens at the CPU, it seems they do nothing (nop). However, in QEMU, it crashes.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("mov rax, 0xa02e698e741f5a6a");
+    asm("mov rbx, 0x20959ddd7a0aef");
+    asm("lsl ax, bx");
+}
+```
+2. Execute. QEMU crashes but CPU does not. This problem happens with LAR, too.
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1377 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1377
new file mode 100644
index 00000000..140f34d8
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1377
@@ -0,0 +1,14 @@
+x86 CVT* series instructions fault
+Description of problem:
+For example, CVTSD2SS instruction converts SRC[63:0] double precision floating point to DEST[31:0] single precision floating point. Although the CVTSD2SS instruction uses only 8 bytes, if it overlaps page boundary, I think QEMU tries to access over the valid memory and crashes.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    mmap(0x555555559000, 0x1000, flag, ~~, 0);
+    asm("cvtsd2ss xmm1, qword ptr [0x555555559ff8]");
+}
+```
+2. Execute. QEMU crashes but CPU does not.
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1471 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1471
new file mode 100644
index 00000000..876a6dce
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1471
@@ -0,0 +1,16 @@
+16fc5726a6 breaks curl SSL connections
+Description of problem:
+`./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk` should work, just as `./qemu-aarch64 /path/to/curl-aarch64 https://news.bbc.co.uk` does. However, commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4 broke this (determined via `git bisect`).
+Steps to reproduce:
+1. Checkout and build `qemu` commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4
+2. On an aarch64 host system, download the amd64 build of `curl` from https://github.com/moparisthebest/static-curl/releases/tag/v7.87.0
+3. Run `./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk`
+4. Observe the following error message:
+
+```
+curl: (35) error:1416D07B:SSL routines:tls_process_key_exchange:bad signature
+```
+
+Note that the `aarch64` equivalent works just fine. As does the previous commit using `amd64`. 
+
+Also note, this bug is also present at current tip (13356edb87506c148b163b8c7eb0695647d00c2a).
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1478 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1478
new file mode 100644
index 00000000..c32aa074
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1478
@@ -0,0 +1,66 @@
+Qemu 7.2.0 i386: core2: init crash (glibc)
+Description of problem:
+The toolchain-builder project (a side project of Buildroot to build pre-built toolchains) reported an issue with Qemu 7.2.0 for  x86-core2--glibc--bleeding-edge toolchain, see:
+
+https://gitlab.com/buildroot.org/toolchains-builder/-/jobs/3731683337
+
+Reverting back to Qemu 7.1.0, the system boot correctly with the same system image.
+I reproduced the issue with the current Qemu master (6b433719eabf0abc74cff0cfd5687f0137c4198a)
+
+Here is the boot log obtained with Qemu 7.2.0:
+   ```
+Run /sbin/init as init process
+random: fast init done
+EXT4-fs (vda): warning: mounting unchecked fs, running e2fsck is recommended
+EXT4-fs (vda): re-mounted. Opts: (null). Quota mode: disabled.
+Starting syslogd: OK
+traps: syslogd[52] general protection fault ip:b7e21465 sp:bfe59e6c error:0 in libc.so.6[b7d9b000+123000]
+Starting klogd: OK
+traps: klogd[56] general protection fault ip:b7e94465 sp:bf8f069c error:0 in libc.so.6[b7e0e000+123000]
+Running sysctl: traps: logger[62] general protection fault ip:b7e48b6c sp:bfd7d194 error:0 in libc.so.6[b7e05000+123000]
+Segmentation fault
+traps: logger[64] general protection fault ip:b7dd3b6c sp:bf9b8604 error:0 in libc.so.6[b7d90000+123000]
+Segmentation fault
+
+traps: init[100] general protection fault ip:b7dda465 sp:bfd5f42c error:0 in libc.so.6[b7d54000+123000]
+Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
+CPU: 0 PID: 1 Comm: init Not tainted 5.15.18 #1
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014
+Call Trace:
+ dump_stack_lvl+0x32/0x41
+ dump_stack+0xd/0x10
+ panic+0x90/0x206
+ do_exit.cold+0xa9/0xa9
+ do_group_exit+0x2a/0x90
+ get_signal+0x115/0x7e0
+ arch_do_signal_or_restart+0x90/0x5a0
+ ? put_pid+0xc/0x20
+ ? kernel_clone+0x10b/0x3d0
+ exit_to_user_mode_prepare+0xf8/0x1c0
+ syscall_exit_to_user_mode+0x1b/0x40
+ do_int80_syscall_32+0x41/0x90
+ entry_INT80_32+0xf0/0xf0
+EIP: 0xb7de5d88
+Code: 37 01 00 00 65 ff 15 10 00 00 00 89 d0 5a 5b 5e 5f 5d c3 66 90 66 90 66 90 66 90 66 90 66 90 66 90 90 59 b8 be 00 00 00 cd 80 <51> 3d 01 f0 ff ff 0f 83 06 e9 f6 ff c3 e8 81 a0 06 00 05 9a a0 0e
+EAX: 00000064 EBX: 0059aa1c ECX: 00561f5b EDX: 00000008
+ESI: 0059cc20 EDI: bfd5fa64 EBP: 0059b138 ESP: bfd5fa20
+DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246
+Kernel Offset: disabled
+---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
+   ```
+I did a git bisect on qemu sources up to this commit:
+
+https://gitlab.com/qemu-project/qemu/-/commit/958e1dd1300f37f18b2161dfb4eb806fc8c19b44
+Steps to reproduce:
+Build the Buildroot qemu_x86_defconfig with BR2_x86_core2 target architecture variant added manually
+1. git clone https://gitlab.com/buildroot.org/buildroot.git
+2. git switch --detach c419ef62d84b5be65599452ab84f7ed719bbe470
+3. make qemu_x86_defconfig
+4. make menuconfig (enable BR2_x86_core2)
+5. make
+6. ./output/images/start-qemu.sh
+Additional information:
+System built with gcc options:
+   ```
+i686-buildroot-linux-gnu-gcc.br_real' '--sysroot' 'output/host/i686-buildroot-linux-gnu/sysroot' '-fstack-protector-strong' '-fPIE' '-pie' '-Wl,-z,now' '-Wl,-z,relro'
+   ```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1506 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1506
new file mode 100644
index 00000000..cbc64641
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1506
@@ -0,0 +1 @@
+QEMU not support 32-bit stack in unreal/flat/big 32-bit mode
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1517 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1517
new file mode 100644
index 00000000..8812cc71
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1517
@@ -0,0 +1 @@
+TCG doesn't support requested feature: CPUID.80000001H:EDX.syscall [bit 11]/TCG doesn't support requested feature: CPUID.80000001H:EDX.lm [bit 29]
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1637 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1637
new file mode 100644
index 00000000..5ccb4019
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1637
@@ -0,0 +1 @@
+Crash when executing `ucomiss` instructions emulating an x86-64 CPU on an AArch64 host
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/164 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/164
new file mode 100644
index 00000000..a8077bc9
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/164
@@ -0,0 +1 @@
+qemu x86 TCG doesn't support AVX insns
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1661 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1661
new file mode 100644
index 00000000..550aaae5
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1661
@@ -0,0 +1,11 @@
+x86 cpu support request: LX Geode
+Description of problem:
+The Geode LX family of CPUs were used in early generations of the One Laptop Per Child (OLPC) systems (XO 1.0).
+
+They are _basically_ i686-compatible but they lack the 'long-nop' (0x0f 0x1f) instruction available on many other i686-class devices.
+
+Since i686 is a reasonably common baseline for toolchains and the software that is distributed using those toolchains, it would be convenient to be able to use QEMU to test boundary compatibility cases for this CPU.
+Steps to reproduce:
+N/A - feature does not currently exist
+Additional information:
+I'm not adding additional context here at the moment, but please let me know what else would be helpful to know (and/or if I'm off-track with this feature request for any reason).  Thank you!
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1803 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1803
new file mode 100644
index 00000000..fbed661e
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1803
@@ -0,0 +1,14 @@
+8.x x86_64 system emulation/tcg regression (general protection fault)
+Description of problem:
+Running the ISO available at https://repo.chimera-linux.org/live/20230611/chimera-linux-x86_64-LIVE-20230611-gnome.iso with the above qemu command line, the graphical environment fails to come up. The system boots, and login prompt shows up; then graphical environment startup is attempted, with Wayland (you can tell as the login prompt cursor no longer blinks, being "frozen" for possibly up to a few minutes due to emulation cost). Then the graphical startup crashes (you can tell because the cursor starts blinking again) and an X11-based startup is attempted (you can tell by the X11 cross cursor) which however never fully comes up either.
+Steps to reproduce:
+1. Download the ISO and run with the command line above.
+2. See the issue.
+Additional information:
+It is possible to then switch to tty2 (View->compatmonitor0, `sendkey ctrl-alt-f2`), log in as `root:chimera` or `anon:chimera` as the console prompt instructs, and type in `dmesg` (as `root`) or `doas dmesg` (as `anon`) and see that the `dmesg` contains a number of general protection faults, like this:
+
+![Screenshot_from_2023-08-02_02-08-41](/uploads/b0e613c5191e41fce3958b74dd5dd4b7/Screenshot_from_2023-08-02_02-08-41.png)
+
+The system used to work, but I am not sure which is the last version of QEMU where this worked, I believe 7.x. In 8.0.3 (likewise running in a Chimera environment, but it was also tested on Alpine, and I had somebody on Arch Linux test it with 8.0.2 just to rule out possible issues caused by a musl-based host environment) it crashes. It only appears to affect the `x86_64` guest architecture, as the other-architecture ISOs have graphical environment come up fine after some minutes (e.g. `ppc64le` with `qemu-system-ppc64 -M pseries-2.11,cap-htm=off -m 2048 -boot d -cdrom chimera-linux-ppc64le-LIVE-20230611-gnome.iso` works just fine). It also appears to only affect TCG emulation, as KVM likewise works fine (same command line, just `-enable-kvm` added).
+
+Apologies for a large testcase, but it seems to need specific graphical-adjacent services to reproduce. It should be consistently reproducible though.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1808 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1808
new file mode 100644
index 00000000..c5c9ec95
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1808
@@ -0,0 +1,71 @@
+qemu-system-i386: Crash in tcg_handle_interrupt on fpu_raise_exception call
+Description of problem:
+While I was messing with an old Linux system, QEMU crashed as I tried to run `make test` on a package:
+```
+ERROR:../accel/tcg/tcg-accel-ops.c:83:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked())
+Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:83:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked())
+```
+Running QEMU straight from the master branch (c167c80) didn't help either. The backtrace is as follows:
+```
+(gdb) bt
+#0  0x00007ffff55ac26c in  () at /usr/lib/libc.so.6
+#1  0x00007ffff555ca08 in raise () at /usr/lib/libc.so.6
+#2  0x00007ffff5545538 in abort () at /usr/lib/libc.so.6
+#3  0x00007ffff6bae05e in g_assertion_message
+    (domain=domain@entry=0x0, file=file@entry=0x555555f90a98 "../accel/tcg/tcg-accel-ops.c", line=line@entry=83, func=func@entry=0x55555607a130 <__func__.3> "tcg_handle_interrupt", message=message@entry=0x7fff9c15ee10 "assertion failed: (qemu_mutex_iothread_locked())") at ../glib/glib/gtestutils.c:3450
+#4  0x00007ffff6c0ef40 in g_assertion_message_expr
+    (domain=domain@entry=0x0, file=file@entry=0x555555f90a98 "../accel/tcg/tcg-accel-ops.c", line=line@entry=83, func=func@entry=0x55555607a130 <__func__.3> "tcg_handle_interrupt", expr=expr@entry=0x555555f79cf8 "qemu_mutex_iothread_locked()") at ../glib/glib/gtestutils.c:3476
+#5  0x0000555555c97369 in tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:83
+#6  tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:81
+#7  0x0000555555b4d58b in pic_irq_request (opaque=<optimized out>, irq=<optimized out>, level=1) at ../hw/i386/x86.c:555
+#8  0x0000555555b4f218 in gsi_handler (opaque=0x5555579423d0, n=13, level=1) at ../hw/i386/x86.c:611
+#9  0x00007fffa42bde14 in code_gen_buffer ()
+#10 0x0000555555c724bb in cpu_tb_exec (cpu=cpu@entry=0x555557434cb0, itb=<optimized out>, tb_exit=tb_exit@entry=0x7fffe9bfd658) at ../accel/tcg/cpu-exec.c:457
+#11 0x0000555555c7298e in cpu_loop_exec_tb (tb_exit=0x7fffe9bfd658, last_tb=<synthetic pointer>, pc=3221283547, tb=<optimized out>, cpu=<optimized out>) at ../accel/tcg/cpu-exec.c:919
+#12 cpu_exec_loop (cpu=cpu@entry=0x555557434cb0, sc=sc@entry=0x7fffe9bfd6f0) at ../accel/tcg/cpu-exec.c:1040
+#13 0x0000555555c731dd in cpu_exec_setjmp (cpu=cpu@entry=0x555557434cb0, sc=sc@entry=0x7fffe9bfd6f0) at ../accel/tcg/cpu-exec.c:1057
+#14 0x0000555555c73810 in cpu_exec (cpu=cpu@entry=0x555557434cb0) at ../accel/tcg/cpu-exec.c:1083
+#15 0x0000555555c974ff in tcg_cpus_exec (cpu=cpu@entry=0x555557434cb0) at ../accel/tcg/tcg-accel-ops.c:75
+#16 0x0000555555c97657 in mttcg_cpu_thread_fn (arg=arg@entry=0x555557434cb0) at ../accel/tcg/tcg-accel-ops-mttcg.c:95
+#17 0x0000555555e283e8 in qemu_thread_start (args=0x5555574935f0) at ../util/qemu-thread-posix.c:541
+#18 0x00007ffff55aa44b in  () at /usr/lib/libc.so.6
+#19 0x00007ffff562de40 in  () at /usr/lib/libc.so.6
+```
+
+After further testing, it seems related to inftest.awk. However, the crash doesn't occur right after I run the file, but only when I do specific operations afterwards.
+
+With `-accel kvm`
+```
+> gawk -f test/inftest.awk
+(output trimmed)
+1e+305 1e+302
+1e+308 1e+305
+gawk: test/inftest.awk:3: fatal: floating point exception
+> echo Test # No crash
+Test
+> cat test/inftest.awk # No crash
+```
+
+With `-accel tcg`
+```
+> gawk -f test/inftest.awk
+(output trimmed)
+1e+308 1e+305
+Infinity 1e+308
+Infinity Infinity
+loop terminated
+> echo Test # No crash
+Test
+> cat test/inftest.awk # QEMU crash
+```
+Steps to reproduce:
+1. Start the VM
+2. Press any key except for enter to go through the SVGA prompt
+3. Enter `root` to login. No password is required
+4. Run `cd /usr/src2/gawk-2.14`
+5. Run `gawk -f test/inftest.awk`
+6. Run certain commands that interact with the kernel (ex. `ls`, `cat test/inftest.awk`, `whoami`)
+7. Observe the crash
+Additional information:
+[00000-bootFloppy.raw](/uploads/379f6b601132980af4ea721fe77dbae4/00000-bootFloppy.raw)
+[artifact.qcow2](/uploads/d721a35bc55e764e17087e8bc1a7531e/artifact.qcow2)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1826 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1826
new file mode 100644
index 00000000..906e535a
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1826
@@ -0,0 +1,29 @@
+Segfault in memory_region_dispatch_write()
+Description of problem:
+Several possible outcomes
+- Kernel freeze and rcu lockup messages.
+- segfault
+ 
+For segfault, using gdb.
+```
+in memory_region_dispatch_write (mr=mr@entry=0x130013001300013, addr=addr@entry=176, data=dat@entry=0, op=op@entry=M0_42, attrs=...) at ../../softwmmu/memory.c:1515
+1515     if (mr->alias) {
+
+in memory_region_dispatch_write(  .. as above...)
+in io_writex(env=env@entry=0x555556a84320, full=full@entry=0x7ffda010f630, mmu_idx=mmu_idx@entry=0, val=0, addr=addr@entry=18446744073699049648, retaddr=retaddr@entry=140736023420498, op=MO_32) at ../../accel/tcg/cputlb.c:1448
+in do_st_mmio_leN (env=env@entry=0x555556a84320, full=full@entry=0x7ffda010f630, val_le=<optmized out>, val_le@entry=0, addr=addr@entry=18446744073699049648, size=size@entry=4, mmu_idx=mmu_idx@entry=0, ra=140736023420498) at ../../accel/tcg/cputlb.c:2755
+in do_st_4 (ra=<optmized_out>, memop=<optimized out> mmu_idx=0, val=0, p=0x7ffff529c140, env=0x555556a84320) at ../../accel/tcg/cputbl.c:2921
+do_st4_mmu (env=0x555556a84320, addr=<optimized out> val=<optmized out>, oi=<otpmized out> ra=140736023420498) at ../../accel/tcg/cputlb.c:3006
+in code_gen_buffer()
+in cpu_tb_exec(..) //getting lazy on typing as seems unlikely anything useful beyond here.
+in cpu_loop_exec_tb()
+cpu_exec_loop
+in cpu_exec_setjmp()
+in cpu_exec()
+in tcg_cpus_exec()
+```
+Steps to reproduce:
+1. Boot.
+2. Use gdb to grab back trace after segfault.
+Additional information:
+Seems to segfault mid way through PCI enumeration in the kernel.  Which device seems to vary between runs.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1832 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1832
new file mode 100644
index 00000000..bb159c82
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1832
@@ -0,0 +1 @@
+i386 test registers are not handled
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1834 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1834
new file mode 100644
index 00000000..bfa02c1f
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1834
@@ -0,0 +1,184 @@
+qemu-system-x86_64: ../hw/pci/msix.c:227: msix_table_mmio_write: Assertion `addr + size <= dev->msix_entries_nr * PCI_MSIX_ENTRY_SIZE' failed.
+Description of problem:
+
+Steps to reproduce:
+1. Run qemu using the provided command line
+2. linux kernel boot and qemu crashes at pci bus scan step
+3.
+Additional information:
+```
+SeaBIOS (version rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org
+iPXE (http://ipxe.org) 00:02.0 CA00 PCI2.10 PnP PMM+3EFD0CE0+3EF30CE0 CA00
+iPXE (http://ipxe.org) 00:05.0 CB00 PCI2.10 PnP PMM+3EF1FCE0 3EF30CE0 CB00
+Booting from ROM...
+[    0.000000] Linux version 6.1.38-yocto-standard (oe-user@oe-host) (x86_64-poky-linux-gcc (GCC) 12.3.0, GNU ld (GNU Binutils) 2.40.0.20230620) #1 SMP PREEMPT_DYNAMIC Thu Jul  6 18:52:54 UTC 2023
+[    0.000000] Command line: console=ttyS0
+[    0.000000] x86/fpu: x87 FPU will use FXSAVE
+[    0.000000] signal: max sigframe size: 1040
+[    0.000000] BIOS-provided physical RAM map:
+[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
+[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
+[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
+[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003ffdefff] usable
+[    0.000000] BIOS-e820: [mem 0x000000003ffdf000-0x000000003fffffff] reserved
+[    0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
+[    0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
+[    0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
+[    0.000000] BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved
+[    0.000000] NX (Execute Disable) protection: active
+[    0.000000] SMBIOS 3.0.0 present.
+[    0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
+[    0.000000] last_pfn = 0x3ffdf max_arch_pfn = 0x400000000
+[    0.000000] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
+[    0.000000] found SMP MP-table at [mem 0x000f5b80-0x000f5b8f]
+[    0.000000] ACPI: Early table checksum verification disabled
+[    0.000000] ACPI: RSDP 0x00000000000F59A0 000014 (v00 BOCHS )
+[    0.000000] ACPI: RSDT 0x000000003FFE238A 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: FACP 0x000000003FFE217A 0000F4 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: DSDT 0x000000003FFE0040 00213A (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: FACS 0x000000003FFE0000 000040
+[    0.000000] ACPI: APIC 0x000000003FFE226E 000080 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: FACS 0x000000003FFE0000 000040 
+[    0.000000] ACPI: APIC 0x000000003FFE226E 000080 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: HPET 0x000000003FFE22EE 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: MCFG 0x000000003FFE2326 00003C (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: WAET 0x000000003FFE2362 000028 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: Reserving FACP table memory at [mem 0x3ffe217a-0x3ffe226d]
+[    0.000000] ACPI: Reserving DSDT table memory at [mem 0x3ffe0040-0x3ffe2179]
+[    0.000000] ACPI: Reserving FACS table memory at [mem 0x3ffe0000-0x3ffe003f]
+[    0.000000] ACPI: Reserving APIC table memory at [mem 0x3ffe226e-0x3ffe22ed]
+[    0.000000] ACPI: Reserving HPET table memory at [mem 0x3ffe22ee-0x3ffe2325]
+[    0.000000] ACPI: Reserving MCFG table memory at [mem 0x3ffe2326-0x3ffe2361]
+[    0.000000] ACPI: Reserving WAET table memory at [mem 0x3ffe2362-0x3ffe2389]
+[    0.000000] Zone ranges:
+[    0.000000]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
+[    0.000000]   DMA32    [mem 0x0000000001000000-0x000000003ffdefff]
+[    0.000000]   Normal   empty
+[    0.000000]   Device   empty
+[    0.000000] Movable zone start for each node
+[    0.000000] Early memory node ranges
+[    0.000000]   node   0: [mem 0x0000000000001000-0x000000000009efff]
+[    0.000000]   node   0: [mem 0x0000000000100000-0x000000003ffdefff]
+[    0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000003ffdefff]
+[    0.000000] On node 0, zone DMA: 1 pages in unavailable ranges
+[    0.000000] On node 0, zone DMA: 97 pages in unavailable ranges
+[    0.000000] On node 0, zone DMA32: 33 pages in unavailable ranges
+[    0.000000] ACPI: PM-Timer IO Port: 0x608
+[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
+[    0.000000] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
+[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
+[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
+[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
+[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
+[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
+[    0.000000] ACPI: Using ACPI (MADT) for SMP configuration information
+[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
+[    0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs
+[    0.000000] [mem 0x40000000-0xafffffff] available for PCI devices
+[    0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+[    0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1
+[    0.000000] percpu: Embedded 52 pages/cpu s173288 r8192 d31512 u1048576
+[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 257759
+[    0.000000] Kernel command line: console=ttyS0
+[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
+[    0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
+[    0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
+[    0.000000] Memory: 1002116K/1048052K available (12294K kernel code, 1469K rwdata, 2600K rodata, 1488K init, 2040K bss, 45680K reserved, 0K cma-reserved)
+[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
+[    0.000000] ftrace: allocating 31276 entries in 123 pages
+[    0.000000] ftrace: allocated 123 pages with 6 groups
+[    0.000000] ftrace: allocating 31276 entries in 123 pages
+[    0.000000] ftrace: allocated 123 pages with 6 groups
+[    0.000000] Dynamic Preempt: none
+[    0.000000] rcu: Preemptible hierarchical RCU implementation.
+[    0.000000] rcu:     RCU event tracing is enabled.
+[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
+[    0.000000]  Trampoline variant of Tasks RCU enabled.
+[    0.000000]  Rude variant of Tasks RCU enabled.
+[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
+[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
+[    0.000000] NR_IRQS: 4352, nr_irqs: 440, preallocated irqs: 16
+[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
+[    0.000000] Console: colour VGA+ 80x25
+[    0.000000] printk: console [ttyS0] enabled
+[    0.000000] ACPI: Core revision 20220331
+[    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
+[    0.020000] APIC: Switch to symmetric I/O mode setup
+[    0.040000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
+[    0.120000] tsc: Unable to calibrate against PIT
+[    0.120000] tsc: using HPET reference calibration
+[    0.120000] tsc: Detected 2299.960 MHz processor
+[    0.001362] tsc: Marking TSC unstable due to TSCs unsynchronized
+[    0.002851] Calibrating delay loop (skipped), value calculated using timer frequency.. 4599.92 BogoMIPS (lpj=22999600)
+[    0.004441] pid_max: default: 32768 minimum: 301
+[    0.019780] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
+[    0.020332] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
+[    0.078474] process: using AMD E400 aware idle routine
+[    0.079221] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127
+[    0.079631] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0
+[    0.081092] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
+[    0.082698] Spectre V2 : Mitigation: Retpolines
+[    0.083053] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
+[    0.083616] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT
+[    0.348864] Freeing SMP alternatives memory: 32K
+[    0.514732] smpboot: CPU0: AMD QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1)
+[    0.536546] cblist_init_generic: Setting adjustable number of callback queues.
+[    0.537604] cblist_init_generic: Setting shift to 1 and lim to 1.
+[    0.538995] cblist_init_generic: Setting shift to 1 and lim to 1.
+[    0.541338] Performance Events: PMU not available due to virtualization, using software events only.
+[    0.548504] rcu: Hierarchical SRCU implementation.
+[    0.548986] rcu:     Max phase no-delay instances is 1000.
+[    0.563842] smp: Bringing up secondary CPUs ...
+[    0.583950] x86: Booting SMP configuration:
+[    0.584395] .... node  #0, CPUs:      #1
+[    0.802667] smp: Brought up 1 node, 2 CPUs
+[    0.803300] smpboot: Max logical packages: 1
+[    0.803821] smpboot: Total of 2 processors activated (9202.49 BogoMIPS)
+[    0.864556] devtmpfs: initialized
+[    0.897545] x86/mm: Memory block size: 128MB
+[    0.936982] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+[    0.938878] futex hash table entries: 512 (order: 3, 32768 bytes, linear)
+[    0.980994] NET: Registered PF_NETLINK/PF_ROUTE protocol family
+[    1.004001] thermal_sys: Registered thermal governor 'step_wise'
+[    1.004143] thermal_sys: Registered thermal governor 'user_space'
+[    1.009528] cpuidle: using governor menu
+[    1.022723] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
+[    1.043717] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000)
+[    1.050546] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820
+[    1.060576] PCI: Using configuration type 1 for base access
+[    1.074215] mtrr: your CPUs had inconsistent fixed MTRR settings
+[    1.075157] mtrr: your CPUs had inconsistent variable MTRR settings
+[    1.076043] mtrr: your CPUs had inconsistent MTRRdefType settings
+[    1.076840] mtrr: probably your BIOS does not setup all CPUs.
+[    1.077612] mtrr: corrected configuration.
+[    1.453630] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
+[    1.454286] HugeTLB: 28 KiB vmemmap can be freed for a 2.00 MiB page
+[    1.467152] raid6: skipped pq benchmark and selected sse2x4
+[    1.467152] raid6: using intx1 recovery algorithm
+[    1.485004] ACPI: Added _OSI(Module Device)
+[    1.485539] ACPI: Added _OSI(Processor Device)
+[    1.485909] ACPI: Added _OSI(3.0 _SCP Extensions)
+[    1.486309] ACPI: Added _OSI(Processor Aggregator Device)
+[    1.578101] ACPI: 1 ACPI AML tables successfully acquired and loaded
+[    1.670966] ACPI: Interpreter enabled
+[    1.676848] ACPI: PM: (supports S0 S3 S5)
+[    1.677404] ACPI: Using IOAPIC for interrupt routing
+[    1.683268] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
+[    1.684107] PCI: Using E820 reservations for host bridge windows
+[    1.691382] ACPI: Enabled 2 GPEs in block 00 to 3F
+[    1.828171] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
+[    1.831923] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
+[    1.839401] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR DPC]
+[    1.843631] acpi PNP0A08:00: _OSC: OS now controls [SHPCHotplug PME AER PCIeCapability]
+[    1.867627] PCI host bridge to bus 0000:00
+[    1.868866] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
+[    1.870044] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
+[    1.870572] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
+[    1.871151] pci_bus 0000:00: root bus resource [mem 0x40000000-0xafffffff window]
+[    1.871719] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window]
+[    1.872269] pci_bus 0000:00: root bus resource [mem 0x100000000-0x8ffffffff window]
+[    1.873668] pci_bus 0000:00: root bus resource [bus 00-ff]
+[    1.880983] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000
+[    1.898659] pci 0000:00:01.0: [1234:1111] type 00 class 0x030000
+qemu-system-x86_64: ../hw/pci/msix.c:227: msix_table_mmio_write: Assertion `addr + size <= dev->msix_entries_nr * PCI_MSIX_ENTRY_SIZE' failed.
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/184 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/184
new file mode 100644
index 00000000..bacc2f12
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/184
@@ -0,0 +1 @@
+SSE CMP ops with 8bit immediate throw sigill with oversized byte
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1864 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1864
new file mode 100644
index 00000000..eb381d11
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1864
@@ -0,0 +1,21 @@
+x86 VM with TCG and SMP fails to start on 8.1.0
+Description of problem:
+I'm running Colima on MacOS to run Docker. After upgrading qemu to 8.1.0 my x86_64 VM fails to start. If I downgrade qemu to 8.0.4 everything runs normally. Relevant logs:
+
+```
+[   60.976187] rcu: 	0-...!: (0 ticks this GP) idle=0d58/0/0x0 softirq=44/44 fqs=0 (false positive?)
+[   60.979262] 	(detected by 1, t=6005 jiffies, g=-1171, q=1981 ncpus=2)
+[   60.982317] Sending NMI from CPU 1 to CPUs 0:
+[   11.583693] NMI backtrace for cpu 0 skipped: idling at native_safe_halt+0xb/0x10
+[   11.583693] INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 2.006 msecs
+[   60.982317] rcu: rcu_preempt kthread timer wakeup didn't happen for 6004 jiffies! g-1171 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
+[   60.982317] rcu: 	Possible timer handling issue on cpu=0 timer-softirq=15
+[   60.982317] rcu: rcu_preempt kthread starved for 6005 jiffies! g-1171 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
+[   60.982317] rcu: 	Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
+[   60.982317] rcu: RCU grace-period kthread stack dump:
+[   60.982317] task:rcu_preempt     state:I stack:0     pid:15    ppid:2      flags:0x00004000
+```
+
+[serial.log](/uploads/1039eceff37133504eb93401df1db137/serial.log)
+Steps to reproduce:
+1. `colima start --arch x86_64`
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/1964 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1964
new file mode 100644
index 00000000..35aaed91
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/1964
@@ -0,0 +1,7 @@
+QEMU TCG faulted in RUNDLL32 at Windows 98SE Display Properties
+Description of problem:
+QEMU TCG faulted in RUNDLL32 at Windows 98SE Display Properties. 100% consistently reproducible across multiple host operating systems and CPU architectures and all types of QEMU emulated display controllers supported by Windows 98SE (`VGA, cirrus-vga and vmware-svga`). It is a user-mode fault so the OS simply terminated the faulting process, OS remains fully functional after the fault and the same fault can be repeated. Should be extremely helpful in debugging. Last known good QEMU version without this bug is 7.1.0. For x86_64, KVM and WHPX do not have the issue and can be used to gain access to Display Properties. On AArch64, last known good QEMU version is the only way to gain access to Display Properties.
+Steps to reproduce:
+See attached recorded video.
+
+![Screen_Recording_2023-10-27_at_2.44.18_AM](/uploads/0b8cff9b70606532312593d48b7df79a/Screen_Recording_2023-10-27_at_2.44.18_AM.mov)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2022 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2022
new file mode 100644
index 00000000..ea35fbbd
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2022
@@ -0,0 +1,11 @@
+Win32s crashes qemu (regression, bisected)
+Description of problem:
+Whenever I start a Win32s application (FREECELL.EXE), qemu says "qemu: Bad ram pointer 0x7f4b13a80000" and aborts. I tried a few different versions of Win32s (I specifically remember 1.15a and 1.25a), but it does not seem to matter. I am using only the standard VGA driver and nothing else that would not be present in a standard install of the guest components.
+Steps to reproduce:
+1. Run any Win32s application
+2.
+3.
+Additional information:
+It worked fine before this commit, both on stable-8.1 as well as the master branch:
+
+4f8f41272e accel: Replace target_ulong with vaddr in probe_*()
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2040 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2040
new file mode 100644
index 00000000..1b3e8b6c
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2040
@@ -0,0 +1,24 @@
+x86 TCG incorrectly truncates physical addresses to 32 bits when PAE is enabled
+Description of problem:
+Originally observed as 32-bit Windows failing to boot on systems with RAM above 4G when using TCG (but working fine under KVM).  Windows kernel debugger showed the kernel allocating a block of memory but somehow failing to create a page table mapping for it.
+
+Bisection in QEMU produced the first bad commit as 4a1e9d4 ("target/i386: Use atomic operations for pte updates"), which changed the PTE accessing code from using e.g. `x86_ldq_phys()` to using `probe_access_full()` and `ldq_p()`.
+
+Further deconstruction of the changes in this commit found that at some point during the boot, the value obtained from `ldq_p()` was completely different to the value obtained from `x86_ldq_phys()`.  Debugging revealed that the underlying host addresses used by each method were exactly 4G apart, with the new method (`ldq_p()`) accessing a host location 4G below the correct address.
+
+Inspection of the code revealed one place where addresses are truncated to 32 bits, which would cause this 4G offset: in `get_physical_address()` we have the code:
+
+```
+    if (!(env->hflags & HF_LMA_MASK)) {
+        /* Without long mode we can only address 32bits in real mode */
+        out->paddr = (uint32_t)out->paddr;
+    }
+```
+
+This looks wrong, since PAE allows for physical addresses above 4G to be accessed without long mode.  (This is the whole point of PAE.)
+
+A quick experiment shows that commenting out the above block of code fixes the symptom and allows Windows 10 to boot with RAM above 4G.
+
+I suspect that the test should be checking for PAE being enabled rather than long mode being enabled.  (Enabling PAE is part of setting up the CPU for long mode, so it is impossible to be in long mode without PAE already enabled.)
+Steps to reproduce:
+Run the command given above.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2092 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2092
new file mode 100644
index 00000000..5e891e4d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2092
@@ -0,0 +1,70 @@
+i386: TCG + virtiofs fails to boot Fedora/CentOS/OpenSUSE since QEMU v7.2
+Description of problem:
+When booting from virtiofs with TCG acceleration, after switch root from initramfs to rootfs, the system crashes horribly, see logs below. The failures only happen when TCG acceleration is used with a virtiofs rootfs. Switching TCG for KVM acceleration or virtiofs for a disk image makes the issue disappear. This has started happening since QEMU version 7.2. Using any qemu version before QEMU version 7.2 works fine. Additionally, it only seems to happen with CentOS Stream, Fedora and OpenSUSE. Using Debian, Ubuntu or Arch Linux, this combination boots fine.
+
+cc @bonzini since you made quite a few changes to TCG acceleration in QEMU v7.2.
+Steps to reproduce:
+1. `git clone https://github.com/systemd/mkosi`
+2. `cd mkosi`
+3. `bin/mkosi -d fedora -t directory --tools-tree=default --qemu-kvm=no --debug qemu` (this will build an image first so will take a while. Depending on your distribution you might need to install `dnf` and `bubblewrap`)
+Additional information:
+```
+<initramfs boot logs skipped for brevity>
+Welcome to Fedora Linux 39 (Thirty Nine)!
+
+[   37.137287] systemd[1]: Initializing machine ID from random generator.
+[   37.209193] kauditd_printk_skb: 9 callbacks suppressed
+[   37.209227] audit: type=1334 audit(1704961693.242:45): prog-id=16 op=LOAD
+[   37.210718] audit: type=1334 audit(1704961693.243:46): prog-id=16 op=UNLOAD
+[   37.211491] audit: type=1334 audit(1704961693.244:47): prog-id=17 op=LOAD
+[   37.212766] audit: type=1334 audit(1704961693.245:48): prog-id=17 op=UNLOAD
+[   37.241136] audit: type=1334 audit(1704961693.274:49): prog-id=18 op=LOAD
+[   37.242803] audit: type=1334 audit(1704961693.275:50): prog-id=18 op=UNLOAD
+[   37.244114] audit: type=1334 audit(1704961693.277:51): prog-id=19 op=LOAD
+[   37.245790] audit: type=1334 audit(1704961693.278:52): prog-id=19 op=UNLOAD
+[   37.259849] audit: type=1334 audit(1704961693.291:53): prog-id=20 op=LOAD
+[   37.260072] audit: type=1334 audit(1704961693.292:54): prog-id=20 op=UNLOAD
+[   37.870091] systemd[1]: bpf-lsm: BPF LSM hook not enabled in the kernel, BPF LSM not supported
+[   38.074465] Process 299(false) has RLIMIT_CORE set to 1
+[   38.074793] Aborting core
+[   38.077885] Process 297(false) has RLIMIT_CORE set to 1
+[   38.078066] Aborting core
+[   38.079360] Process 298(false) has RLIMIT_CORE set to 1
+[   38.079516] Aborting core
+[   38.114888] Process 301(false) has RLIMIT_CORE set to 1
+[   38.115072] Aborting core
+[   38.217830] Process 305(false) has RLIMIT_CORE set to 1
+[   38.218038] Aborting core
+[   38.219161] Process 304(false) has RLIMIT_CORE set to 1
+[   38.219337] Aborting core
+[   38.287937] Process 308(false) has RLIMIT_CORE set to 1
+[   38.288169] Aborting core
+[   38.323829] Process 309(false) has RLIMIT_CORE set to 1
+[   38.324045] Aborting core
+[   38.325457] Process 310(false) has RLIMIT_CORE set to 1
+[   38.325811] Aborting core
+[   38.447773] Process 315(false) has RLIMIT_CORE set to 1
+[   38.447934] Aborting core
+[   38.449525] Process 314(false) has RLIMIT_CORE set to 1
+[   38.449768] Aborting core
+[   38.462210] (sd-execu[291]: /usr/lib/systemd/system-generators/systemd-integritysetup-generator terminated by signal SEGV.
+[   38.478826] Process 316(false) has RLIMIT_CORE set to 1
+[   38.479001] Aborting core
+[   42.397416] systemd[1]: Populated /etc with preset unit settings.
+[   42.532156] show_signal_msg: 68 callbacks suppressed
+[   42.535164] systemd[1]: segfault at b0 ip 00007f3ca95074ed sp 00007ffc7aa5f1c0 error 4 in libsystemd-core-254.7-1.fc39.so[7f3ca944c000+135000] likely on CPU 0 (core 0, socket 0)
+[   42.536289] Code: 00 48 89 fb 75 6f c6 87 88 04 00 00 01 48 8b 7f 70 45 31 ed 48 85 ff 75 1e e9 7f 00 00 00 0f 1f 80 00 00 00 00 e8 f3 24 f5 ff <48> 8b 7b 70 41 83 c5 01 48 85 ff 74 66 f6 87 63 04 00 00 01 75 e5
+[   42.543019] systemd[1]: Caught <SEGV> from PID 176.
+[   42.543516] audit: type=1701 audit(1704961698.576:99): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=317 comm="systemd" exe="/usr/lib/systemd/systemd" sig=11 res=1
+[   42.593878] traps: false[318] general protection fault ip:7fcccd942fa0 sp:7ffd528a8020 error:0 in libc.so.6[7fcccd928000+160000]
+[   42.594494] Process 318(false) has RLIMIT_CORE set to 1
+[   42.594831] Aborting core
+[   42.595808] audit: type=1701 audit(1704961698.627:100): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=318 comm="false" exe="/usr/bin/false" sig=11 res=1
+[   42.603224] systemd[1]: Caught <SEGV>, dumped core as pid 317.
+[   42.604202] systemd[1]: Freezing execution.
+[   42.656248] audit: type=1335 audit(1704961698.689:101): pid=1 uid=0 auid=4294967295 tty=(none) ses=4294967295 comm="systemd" exe="/usr/lib/systemd/systemd" nl-mcgrp=1 op=disconnect res=1
+[   42.657685] audit: type=1334 audit(1704961698.690:102): prog-id=14 op=UNLOAD
+[   42.657852] audit: type=1334 audit(1704961698.690:103): prog-id=15 op=UNLOAD
+[   42.658011] audit: type=1334 audit(1704961698.690:104): prog-id=11 op=UNLOAD
+[   42.658201] audit: type=1334 audit(1704961698.690:105): prog-id=12 op=UNLOAD
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2096 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2096
new file mode 100644
index 00000000..c0f7c1f2
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2096
@@ -0,0 +1 @@
+test-x86-cpuid-compat qtest produces warnings on TCG
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/215 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/215
new file mode 100644
index 00000000..78dee678
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/215
@@ -0,0 +1 @@
+x86 Floating point exceptions - incorrect support?
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2170 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2170
new file mode 100644
index 00000000..4ad38a0f
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2170
@@ -0,0 +1,44 @@
+qemu-x86_64 crashes when the application calls pthread_getattr_np()
+Description of problem:
+QEMU user emulation crashes with this program:
+```
+#define _GNU_SOURCE
+#include <stdio.h>
+#include <pthread.h>
+
+int main()
+{
+        pthread_attr_t attr;
+        int error = pthread_getattr_np(pthread_self(), &attr);
+
+        printf("%d\n", error);
+        return 0;
+}
+```
+Steps to reproduce:
+1. Compile the program above
+2. Run QEMU
+Additional information:
+QEMU crashes with:
+```
+qemu-x86_64: QEMU internal SIGSEGV {code=MAPERR, addr=0x20}
+Segmentation fault (core dumped)
+
+```
+
+In gdb I get this backtrace:
+```
+#0  0x0000555555627d6d in open_self_maps_2 (opaque=0x7fffffffc020, guest_start=18446744073699065856, guest_end=<optimized out>, flags=12) at ../linux-user/syscall.c:8089
+#1  0x000055555560ce67 in walk_memory_regions (priv=priv@entry=0x7fffffffc020, fn=fn@entry=0x555555627d30 <open_self_maps_2>) at ../accel/tcg/user-exec.c:176
+#2  0x0000555555628b3a in open_self_maps_1 (smaps=<optimized out>, fd=<optimized out>, env=<optimized out>) at ../linux-user/syscall.c:8112
+#3  open_self_maps (cpu_env=<optimized out>, fd=3) at ../linux-user/syscall.c:8122
+#4  0x0000555555631e24 in do_guest_openat (cpu_env=cpu_env@entry=0x55555583ae20, dirfd=dirfd@entry=-100, fname=fname@entry=0x2aaaab496eb4 "/proc/self/maps", flags=524288, mode=mode@entry=0, safe=safe@entry=true) at ../linux-user/syscall.c:8381
+#5  0x0000555555638f71 in do_syscall1 (cpu_env=cpu_env@entry=0x55555583ae20, num=num@entry=257, arg1=arg1@entry=4294967196, arg2=arg2@entry=46912506523316, arg3=arg3@entry=524288, arg4=arg4@entry=0, arg5=<optimized out>, arg6=<optimized out>, arg8=0, arg7=0) at ../linux-user/syscall.c:9075
+#6  0x000055555563b659 in do_syscall (cpu_env=cpu_env@entry=0x55555583ae20, num=257, arg1=4294967196, arg2=46912506523316, arg3=524288, arg4=0, arg5=8, arg6=1, arg7=0, arg8=0) at ../linux-user/syscall.c:13658
+#7  0x000055555558db19 in cpu_loop (env=env@entry=0x55555583ae20) at ../linux-user/x86_64/../i386/cpu_loop.c:242
+#8  0x00005555555898d8 in main (argc=<optimized out>, argv=0x7fffffffdd38, envp=<optimized out>) at ../linux-user/main.c:1012
+
+```
+
+This bug was introduced in the rewrite of `open_self_maps` in 7b7a3366e142d3baeb3fd1d3660a50e7956c19eb.
+The current master (5767815218efd3cbfd409505ed824d5f356044ae) is still affected.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2175 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2175
new file mode 100644
index 00000000..a5c9ec5e
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2175
@@ -0,0 +1,38 @@
+Intel BLSI CF computation bug
+Description of problem:
+CF flag computation of BLSI instruction is wrong. It seems #1370 was not completely fixed.
+Steps to reproduce:
+1. Compile `example.c` using this command: `gcc -o example.bin example.c`. My gcc version is 12.3.0, but other versions may work.
+```
+int main() {
+  __asm__ (
+    "movq $0x1, %r8\n"
+    "mov $0xedbf530a, %r9\n"
+    "push $0x1\n"
+    "popf\n"
+    "blsi %r9d, %r8d\n"
+    "pushf\n"
+    "pop %rax\n"
+    "pop %rbp\n"
+    "ret\n"
+  );
+
+  return 0;
+}
+```
+2. Run `./example.bin`. Then check the return code using `echo $?`. It should be 3.
+```
+$ ./example.bin
+$ echo $?
+3
+```
+3. Run `./qemu-x86_64 ./example.bin`. Then check the return code using `echo $?`. It should be 2.
+```
+$ ./qemu-x86_64 ./example.bin
+$ echo $?
+2
+```
+
+The return code of `./example.bin` contains the value of the `RFLAGS` register after executing the `BLSI` instruction.
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2180 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2180
new file mode 100644
index 00000000..7596ba7d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2180
@@ -0,0 +1,36 @@
+QEMU crashes when an interrupt is triggered whose descriptor is not in physical memory
+Description of problem:
+When an interrupt is triggered whose descriptor is mapped but not in physical memory, QEMU crashes with the following message:
+```
+**
+ERROR:../system/cpus.c:524:bql_lock_impl: assertion failed: (!bql_locked())
+Bail out! ERROR:../system/cpus.c:524:bql_lock_impl: assertion failed: (!bql_locked())
+Aborted (core dumped)
+```
+
+The given code triggers the bug by moving the IDT's base address, but it can also be triggered by any other method of moving the IDT's physical memory location, f.ex paging. With KVM enabled, this specific example loops forever instead of crashing, but if the code is altered to use paging, an internal KVM error is reported and the VM is paused.
+Steps to reproduce:
+1. Assemble the code listed below using NASM: `nasm test.asm -o test.bin`
+2. Run the code using `qemu-system-i386 -drive format=raw,file=test.bin`. Note that the given code only triggers the bug if the guest has 2 gigabytes or less of physical memory.
+3. QEMU crashes.
+Additional information:
+NASM assembly of the code used:
+```
+bits 16
+org 0x7c00
+
+_start:
+    ; Disable interrupts and load new IDT
+    cli
+    o32 lidt [idtdesc]
+    ; Descriptor for INT 0 is in nonexistent physical memory, which crashes QEMU.
+    int 0x00
+
+idtdesc:
+    dw 0x3ff      ; Limit: 1 KiB for IDT
+    dd 0x80000000 ; Base: 2 GiB
+
+; Like most BIOSes, SeaBIOS requires this magic number to boot
+times 510-($-$$) db 0
+dw 0xaa55
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2195 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2195
new file mode 100644
index 00000000..ffcc3d9d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2195
@@ -0,0 +1,39 @@
+qemu-system-x86_64 : cannot resume from S3 suspend for Q35 + OVMF
+Description of problem:
+There is a specific configuration where the resume from S3 does not work:
+
+- Q35 machine + OVMF.fd (https://retrage.github.io/edk2-nightly/)
+- TCG acceleration (it works when --accel=kvm is set)
+
+The output at resume is:
+
+```
+!!!! X64 Exception Type - 05(#BR - BOUND Range Exceeded)  CPU Apic ID - 00000000 !!!!
+RIP  - 0000000000006237, CS  - 0000000000000028, RFLAGS - 0000000000000002
+RAX  - 0000000080000027, RCX - 0000000000000000, RDX - 0000000000000000
+RBX  - 0000000099200000, RSP - 000000000FF96236, RBP - 000000000FF96320
+RSI  - 000000000F74E000, RDI - 0000000000833F31
+R8   - 0000002800000000, R9  - 0000000000000000, R10 - 000000000FF968F0
+R11  - 0000000000828B30, R12 - 000000000FF9ACD0, R13 - 000000000F76B000
+R14  - 000000000F76A000, R15 - 0000000000000000
+DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
+GS   - 0000000000000030, SS  - 0000000000000030
+CR0  - 0000000080000033, CR2 - 0000000000000000, CR3 - 000000000F75B000
+CR4  - 0000000000000668, CR8 - 0000000000000000
+DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
+DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
+GDTR - 0000000000833DE0 0000000000000047, LDTR - 0000000000000000
+IDTR - 000000000FF97D70 000000000000021F,   TR - 0000000000000000
+FXSAVE_STATE - 000000000FF95E90
+!!!! Can't find image information. !!!!
+```
+
+After bisecting, this is caused by commit : 18a536f1f8d6222e562f59179e837fdfd8b92718 If i revert this comment, the resume works nicely.
+
+I used a script to generate a tiny initrd to test but i think the problem can be reproduced with any guest kernel + rootfs. I also verify that this problem can be reproduced with different host kernels (6.5) than the one i used (6.8)
+Steps to reproduce:
+1. Use https://gitlab.com/berrange/tiny-vm-tools/-/blob/master/make-tiny-image.py to generate tiny-initrd.img
+2. Run qemu and drop into shell
+3. Put machine into S3 (echo mem \> /sys/power/state)
+4. Use socat to connect to QEMU monitor and wake up the machine (system_wakeup)
+5. The machine does not resume correctly
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2198 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2198
new file mode 100644
index 00000000..92b00710
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2198
@@ -0,0 +1,25 @@
+Unable to run OS/2 Warp4.52
+Description of problem:
+Operating system crashes upon boot.
+Steps to reproduce:
+1. Install OS/2 Warp4
+2. Apply Fixpack15
+3. Try to boot the system
+Additional information:
+This is a very old bug that seems to render a whole family of Operating Systems (OS/2 Warp4 and eComStation) unusable under Qemu.
+Warp4 works, in the sense that it does install and run, but just until it is updated to 4.52 (which is necessary to get a useable guest)
+
+I found traces of its existence as far as:
+https://bugs.launchpad.net/qemu/+bug/1743441
+https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg02337.html
+
+And i found the issue brieffly commented at https://www.os2world.com/forum/index.php?topic=2346.0
+I quote: 
+ 
+'Regarding QEMU/KVM, OS/2 runs in QEMU mostly fine. Except the trap in os2lvm.dmd and non-working netbeui.os2 and
+tcpbeui.os2. The problem with os2lvm.dmd is because QEMU closely follows the intel spec, which is incorrect. The spec says
+that 16-bit SGDT instruction behaves the same like in i286 processor. But it's not true, it behaves like i386 instruction. So, QEMU
+emulates SGDT 16-bit instruction incorrectly. OS2LVM.DMD uses 16-bit SGDT instruction and it hits the problem.'
+
+After a brief discussion on the Warp4 group at groups.io where I was told that this is indeed a Qemu bug, I thought someone has 
+to report on that.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2206 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2206
new file mode 100644
index 00000000..5d2803a0
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2206
@@ -0,0 +1,10 @@
+PAGE_FAULT_IN_NONPAGED_AREA in Windows 7 x64.
+Description of problem:
+When trying to install Windows 7, it always crashes with PAGE_FAULT_IN_NONPAGED_AREA. This also impacts Windows 8.1, but crashes when it tries to start up the installation disc.
+Steps to reproduce:
+1. Create A VM with the Windows 7 installation disc inside the cdrom.
+2. Go through the installation
+3. At some point, it will pull a blue screen with a PAGE_FAULT_IN_NONPAGED_AREA. (around expanding windows files or completing installation)
+Additional information:
+It looks like this bsod is relating to some non-canonical (illegal) virtual address being referenced. (It's just my guess based on the stop code)
+![image](/uploads/910a863461a99713ff8566e5c2212ce2/image.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2207 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2207
new file mode 100644
index 00000000..be799c2e
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2207
@@ -0,0 +1,11 @@
+WerFault.exe – Application Error. The memory could not be read in Win7 i386
+Description of problem:
+WerFault Application Errors always occur when I open IE or even control panel. It's OK on QEMU 7.2 & 8.0 version according to my debug experience about qemu-system-i386 flavor in the last few months.
+Steps to reproduce:
+1. pulling _tag: v8.2.0_ code 
+2. emulating Windows 7 OS on aarch64 Host with TCG acceleration mechanism
+3. just opening IE for maybe two or three times after the virtual machine has started
+Additional information:
+The error is displayed by Chinese. It says _WerFault.exe – Application Error. The instruction at 0x779f77b2 referenced memory at 0x6d0f6d20. The memory could not be read._ in English
+
+![20240305141310](https://juststayrealpicgo.oss-cn-hangzhou.aliyuncs.com/wiz/20240305141310.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2220 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2220
new file mode 100644
index 00000000..b6e1816b
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2220
@@ -0,0 +1,528 @@
+Intermittent QEMU segfaults on x86_64 with TCG accelerator
+Description of problem:
+Recently(-ish) in our upstream systemd CI we started seeing an uptrend of QEMU segfaults when running our integration tests. This was first observed in CentOS Stream 9 runs, but was later followed by Fedora Rawhide and Ubuntu Noble, once they picked up the QEMU 8.x branch. I filed a RHEL-only ticked first (before we started seeing it on other distros as well), so I'll share the same information here as well.
+
+This seems to happen only with TCG - in the CentOS CI infrastructure, where this was first observed, we run two jobs - one on a baremetal, that runs the test VMs with KVM, and one already on VMs that runs the same jobs using TCG; only the TCG job suffer from this issue. The same goes for the Fedora Rawhide and Ubuntu Noble jobs - they also use TCG.
+
+I managed to get a stack trace from one of the segmentation faults on CentOS Stream 9:
+```gdb
+[coredumpctl_collect] Collecting coredumps for '/usr/libexec/qemu-kvm'
+           PID: 1154719 (qemu-system-x86)
+           UID: 0 (root)
+           GID: 0 (root)
+        Signal: 11 (SEGV)
+     Timestamp: Thu 2024-02-01 21:50:04 UTC (1min 23s ago)
+  Command Line: /bin/qemu-system-x86_64 -smp 8 -net none -m 768M -nographic -kernel /boot/vmlinuz-5.14.0-412.el9.x86_64 -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test-TEST-63-PATH_1/default.img -device virtio-rng-pci,max-bytes=1024,period=1000 -cpu max -initrd /var/tmp/ci-initramfs-5.14.0-412.el9.x86_64.img -append $'root=LABEL=systemd_boot rw raid=noautodetect rd.luks=0 loglevel=2 init=/usr/lib/systemd/systemd console=ttyS0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-63.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-63.service noresume oops=panic panic=1 softlockup_panic=1 systemd.wants=end.service enforcing=0 watchdog_thresh=60 workqueue.watchdog_thresh=120'
+    Executable: /usr/libexec/qemu-kvm
+ Control Group: /user.slice/user-0.slice/session-1.scope
+          Unit: session-1.scope
+         Slice: user-0.slice
+       Session: 1
+     Owner UID: 0 (root)
+       Boot ID: 011f8fd0783c464184955c281ce2c1b7
+    Machine ID: af8d424897a0479fa2fc0e5afcff3198
+      Hostname: n27-39-6.pool.ci.centos.org
+       Storage: /var/lib/systemd/coredump/core.qemu-system-x86.0.011f8fd0783c464184955c281ce2c1b7.1154719.1706824204000000.zst (present)
+  Size on Disk: 124.7M
+       Message: Process 1154719 (qemu-system-x86) of user 0 dumped core.
+                
+                Stack trace of thread 1154728:
+                #0  0x0000557669385a13 address_space_translate_for_iotlb (qemu-kvm + 0x73ba13)
+                #1  0x00005576693d149f tlb_set_page_full (qemu-kvm + 0x78749f)
+                #2  0x0000557669248a18 x86_cpu_tlb_fill (qemu-kvm + 0x5fea18)
+                #3  0x00005576693db519 mmu_lookup1 (qemu-kvm + 0x791519)
+                #4  0x00005576693db31b mmu_lookup.llvm.5973256065011438912 (qemu-kvm + 0x79131b)
+                #5  0x00005576693d3173 do_ld4_mmu.llvm.5973256065011438912 (qemu-kvm + 0x789173)
+                #6  0x00005576692d44cf do_interrupt_all (qemu-kvm + 0x68a4cf)
+                #7  0x000055766924f605 x86_cpu_exec_interrupt (qemu-kvm + 0x605605)
+                #8  0x00005576693bdc25 cpu_exec_loop (qemu-kvm + 0x773c25)
+                #9  0x00005576693bcee1 cpu_exec_setjmp (qemu-kvm + 0x772ee1)
+                #10 0x00005576693bcd64 cpu_exec (qemu-kvm + 0x772d64)
+                #11 0x00007fe0c5e4011c mttcg_cpu_thread_fn (accel-tcg-x86_64.so + 0x411c)
+                #12 0x0000557669662ada qemu_thread_start.llvm.13264588188580115644 (qemu-kvm + 0xa18ada)
+                #13 0x00007fe0c68a1912 start_thread (libc.so.6 + 0xa1912)
+                #14 0x00007fe0c683f450 __clone3 (libc.so.6 + 0x3f450)
+                
+                Stack trace of thread 1154721:
+                #0  0x00007fe0c69159e5 clock_nanosleep@GLIBC_2.2.5 (libc.so.6 + 0x1159e5)
+                #1  0x00007fe0c691a597 __nanosleep (libc.so.6 + 0x11a597)
+                #2  0x00007fe0c6b70c87 g_usleep (libglib-2.0.so.0 + 0x7ec87)
+                #3  0x0000557669670c18 call_rcu_thread (qemu-kvm + 0xa26c18)
+                #4  0x0000557669662ada qemu_thread_start.llvm.13264588188580115644 (qemu-kvm + 0xa18ada)
+                #5  0x00007fe0c68a1912 start_thread (libc.so.6 + 0xa1912)
+                #6  0x00007fe0c683f450 __clone3 (libc.so.6 + 0x3f450)
+                
+                Stack trace of thread 1154727:
+                #0  0x00007fe0c689e4aa __futex_abstimed_wait_common (libc.so.6 + 0x9e4aa)
+                #1  0x00007fe0c68a0cb0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa0cb0)
+                #2  0x00005576696620c6 qemu_cond_wait_impl (qemu-kvm + 0xa180c6)
+                #3  0x000055766919425b qemu_wait_io_event (qemu-kvm + 0x54a25b)
+                #4  0x00007fe0c5e40180 mttcg_cpu_thread_fn (accel-tcg-x86_64.so + 0x4180)
+                #5  0x0000557669662ada qemu_thread_start.llvm.13264588188580115644 (qemu-kvm + 0xa18ada)
+                #6  0x00007fe0c68a1912 start_thread (libc.so.6 + 0xa1912)
+                #7  0x00007fe0c683f450 __clone3 (libc.so.6 + 0x3f450)
+                
+                Stack trace of thread 1154719:
+                #0  0x00007fe0c689e670 __GI___lll_lock_wait (libc.so.6 + 0x9e670)
+                #1  0x00007fe0c68a4d02 __pthread_mutex_lock@GLIBC_2.2.5 (libc.so.6 + 0xa4d02)
+                #2  0x0000557669661b76 qemu_mutex_lock_impl (qemu-kvm + 0xa17b76)
+                #3  0x000055766967c937 main_loop_wait (qemu-kvm + 0xa32937)
+                #4  0x00005576691a30c7 qemu_main_loop (qemu-kvm + 0x5590c7)
+                #5  0x0000557668fe3cca qemu_default_main (qemu-kvm + 0x399cca)
+                #6  0x00007fe0c683feb0 __libc_start_call_main (libc.so.6 + 0x3feb0)
+                #7  0x00007fe0c683ff60 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x3ff60)
+                #8  0x0000557668fe33e5 _start (qemu-kvm + 0x3993e5)
+                
+                Stack trace of thread 1154725:
+                #0  0x00007fe0c689e670 __GI___lll_lock_wait (libc.so.6 + 0x9e670)
+                #1  0x00007fe0c68a4d02 __pthread_mutex_lock@GLIBC_2.2.5 (libc.so.6 + 0xa4d02)
+                #2  0x0000557669661b76 qemu_mutex_lock_impl (qemu-kvm + 0xa17b76)
+                #3  0x00005576693dc514 do_st_mmio_leN.llvm.5973256065011438912 (qemu-kvm + 0x792514)
+                #4  0x00005576693d3d22 do_st4_mmu.llvm.5973256065011438912 (qemu-kvm + 0x789d22)
+                #5  0x00007fe07cbfe35b n/a (n/a + 0x0)
+                ELF object binary architecture: AMD x86-64
+
+
+[coredumpctl_collect] Trying to run gdb with 'set print pretty on\nbt full' for '/usr/libexec/qemu-kvm'
+GNU gdb (GDB) Red Hat Enterprise Linux 10.2-13.el9
+Copyright (C) 2021 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+Type "show copying" and "show warranty" for details.
+This GDB was configured as "x86_64-redhat-linux-gnu".
+Type "show configuration" for configuration details.
+For bug reporting instructions, please see:
+<https://www.gnu.org/software/gdb/bugs/>.
+Find the GDB manual and other documentation resources online at:
+    <http://www.gnu.org/software/gdb/documentation/>.
+
+For help, type "help".
+Type "apropos word" to search for commands related to "word"...
+/root/.gdbinit:1: Error in sourced command file:
+No symbol table is loaded.  Use the "file" command.
+Reading symbols from /usr/libexec/qemu-kvm...
+Downloading separate debug info for /usr/libexec/qemu-kvm...
+Reading symbols from /root/.cache/debuginfod_client/6fdfad7763b68956a31a335edd490cef23088a9a/debuginfo...
+Downloading separate debug info for /root/.cache/debuginfod_client/6fdfad7763b68956a31a335edd490cef23088a9a/debuginfo...
+[New LWP 1154728]
+[New LWP 1154721]
+[New LWP 1154727]
+[New LWP 1154719]
+[New LWP 1154725]
+[New LWP 1154729]
+[New LWP 1154726]
+[New LWP 1154723]
+[New LWP 1154730]
+[New LWP 1154724]
+[New LWP 1154722]
+Downloading separate debug info for /lib64/libpixman-1.so.0...
+Downloading separate debug info for /lib64/libcapstone.so.4...
+Downloading separate debug info for /root/.cache/debuginfod_client/fabd9508a8df77430d74e376fc1853545deaa9a4/debuginfo...
+Downloading separate debug info for /lib64/libgnutls.so.30...
+Downloading separate debug info for /root/.cache/debuginfod_client/3ca805ea0a9583fc8272d443181745507c6c1391/debuginfo...
+Downloading separate debug info for /lib64/libpng16.so.16...
+Downloading separate debug info for /lib64/libz.so.1...
+Downloading separate debug info for /lib64/libsasl2.so.3...
+Downloading separate debug info for /root/.cache/debuginfod_client/d5669a4356bbdf6b9dba9d25fe4674098af42f8d/debuginfo...
+Downloading separate debug info for /lib64/libsnappy.so.1...
+Downloading separate debug info for /lib64/liblzo2.so.2...
+Downloading separate debug info for /lib64/libpmem.so.1...
+Downloading separate debug info for /root/.cache/debuginfod_client/571e30ee251154a37d94e8c45def4e0b40fdaa92/debuginfo...
+Downloading separate debug info for /lib64/libseccomp.so.2...
+Downloading separate debug info for /lib64/libfdt.so.1...
+Downloading separate debug info for /root/.cache/debuginfod_client/31a56e0009a8824c7a09267c8205034c91cb4095/debuginfo...
+Downloading separate debug info for /lib64/libnuma.so.1...
+Downloading separate debug info for /root/.cache/debuginfod_client/e78797386b6fc540350223e432c3bfee6034d2e1/debuginfo...
+Downloading separate debug info for /lib64/libgio-2.0.so.0...
+Downloading separate debug info for /root/.cache/debuginfod_client/56c6122b97d5e4dd5fdf68756bdc02058ce02bbf/debuginfo...
+Downloading separate debug info for /lib64/libgobject-2.0.so.0...
+Downloading separate debug info for /lib64/libglib-2.0.so.0...
+Downloading separate debug info for /lib64/librdmacm.so.1...
+Downloading separate debug info for /root/.cache/debuginfod_client/7714785fff3ebddc1077a3fad30fffa35283766f/debuginfo...
+Downloading separate debug info for /lib64/libibverbs.so.1...
+Downloading separate debug info for /lib64/libslirp.so.0...
+Downloading separate debug info for /lib64/liburing.so.2...
+Downloading separate debug info for /root/.cache/debuginfod_client/8f52f15e8dff019c877c3c25083ef4a459429b99/debuginfo...
+Downloading separate debug info for /lib64/libgmodule-2.0.so.0...
+Downloading separate debug info for /lib64/libaio.so.1...
+Downloading separate debug info for /root/.cache/debuginfod_client/9b75d21282f8e17ddfa06aff78dae4f8dcce4106/debuginfo...
+Downloading separate debug info for /lib64/libm.so.6...
+Downloading separate debug info for /lib64/libresolv.so.2...
+Downloading separate debug info for /root/.cache/debuginfod_client/8a914905acea217452c928c2e200afceb83341c5/debuginfo...
+Downloading separate debug info for /lib64/libgcc_s.so.1...
+Downloading separate debug info for /root/.cache/debuginfod_client/ef4c928f1372ad155fea761f0e840ecd264fb153/debuginfo...
+Downloading separate debug info for /lib64/libc.so.6...
+Downloading separate debug info for /lib64/libp11-kit.so.0...
+Downloading separate debug info for /root/.cache/debuginfod_client/b935d795aaf6f8cbc392c922b6c97a4c8db44c41/debuginfo...
+Downloading separate debug info for /lib64/libidn2.so.0...
+Downloading separate debug info for /root/.cache/debuginfod_client/958c50fc94ecb196b24f3619762e7ec3f28a5b40/debuginfo...
+Downloading separate debug info for /lib64/libunistring.so.2...
+Downloading separate debug info for /lib64/libtasn1.so.6...
+Downloading separate debug info for /lib64/libnettle.so.8...
+Downloading separate debug info for /root/.cache/debuginfod_client/0dd622456d9a5330679490d3bd9d812582d9f9d3/debuginfo...
+Downloading separate debug info for /lib64/libhogweed.so.6...
+Downloading separate debug info for /lib64/libcrypt.so.2...
+Downloading separate debug info for /root/.cache/debuginfod_client/6ce4e5eb200e61d07398af52f8bcb316cf8466e0/debuginfo...
+Downloading separate debug info for /lib64/libgssapi_krb5.so.2...
+Downloading separate debug info for /root/.cache/debuginfod_client/5ce5f00c8b502e99ab96853950db60f97a710b28/debuginfo...
+Downloading separate debug info for /lib64/libkrb5.so.3...
+Downloading separate debug info for /lib64/libk5crypto.so.3...
+Downloading separate debug info for /lib64/libcom_err.so.2...
+Downloading separate debug info for /root/.cache/debuginfod_client/2313e22f074e5b67e97bb22e01a722cc727512b1/debuginfo...
+Downloading separate debug info for /lib64/libstdc++.so.6...
+Downloading separate debug info for /lib64/libndctl.so.6...
+Downloading separate debug info for /root/.cache/debuginfod_client/e2e24fd2c7061434b2a0cc849cdcd2854a4a0557/debuginfo...
+Downloading separate debug info for /lib64/libdaxctl.so.1...
+Downloading separate debug info for /lib64/libmount.so.1...
+Downloading separate debug info for /root/.cache/debuginfod_client/98bababfe2b3d1d0ca128831439521f2b5b7aa95/debuginfo...
+Downloading separate debug info for /lib64/libselinux.so.1...
+Downloading separate debug info for /root/.cache/debuginfod_client/bdc4adbb0901b548f448d6f0d92b49c352e3b9f6/debuginfo...
+Downloading separate debug info for /lib64/libffi.so.8...
+Downloading separate debug info for /lib64/libpcre.so.1...
+Downloading separate debug info for /root/.cache/debuginfod_client/cffb947bcc416dca3cd249cdb0a1c6f614549c30/debuginfo...
+Downloading separate debug info for /lib64/libnl-3.so.200...
+Downloading separate debug info for /root/.cache/debuginfod_client/22262a5a1956360f9f4c1daa89e592b1be03cd14/debuginfo...
+Downloading separate debug info for /lib64/libnl-route-3.so.200...
+Downloading separate debug info for /lib64/libkrb5support.so.0...
+Downloading separate debug info for /lib64/libkeyutils.so.1...
+Downloading separate debug info for /root/.cache/debuginfod_client/5f6459dcec3e266d994b8d4e5b23507c4c0df11e/debuginfo...
+Downloading separate debug info for /lib64/libcrypto.so.3...
+Downloading separate debug info for /root/.cache/debuginfod_client/fb8a738ffca8bdbe3172c842ee9d56f969516473/debuginfo...
+Downloading separate debug info for /lib64/libuuid.so.1...
+Downloading separate debug info for /lib64/libkmod.so.2...
+Downloading separate debug info for /root/.cache/debuginfod_client/9057cef69769e25914be12563e5d821aef1bd9cb/debuginfo...
+Downloading separate debug info for /lib64/libblkid.so.1...
+Downloading separate debug info for /lib64/libpcre2-8.so.0...
+Downloading separate debug info for /root/.cache/debuginfod_client/10357f8fa75891b03cd08344d56efa49ad9d607f/debuginfo...
+Downloading separate debug info for /lib64/libcap.so.2...
+Downloading separate debug info for /root/.cache/debuginfod_client/94e5c930fa02b381df948b2d2909d96da9f31407/debuginfo...
+Downloading separate debug info for /lib64/libzstd.so.1...
+Downloading separate debug info for /root/.cache/debuginfod_client/f0c68ad1b3f8941857af47c6887736d835317ccc/debuginfo...
+Downloading separate debug info for /lib64/liblzma.so.5...
+Downloading separate debug info for /usr/libexec/../lib64/qemu-kvm/accel-tcg-x86_64.so...
+Downloading separate debug info for /root/systemd/system-supplied DSO at 0x7ffd4cb6b000...
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/lib64/libthread_db.so.1".
+Core was generated by `/bin/qemu-system-x86_64 -smp 8 -net none -m 768M -nographic -kernel /boot/vmlin'.
+Program terminated with signal SIGSEGV, Segmentation fault.
+#0  memory_region_get_iommu (mr=0x418c0fdb85f05d8b)
+    at /usr/src/debug/qemu-kvm-8.2.0-2.el9.x86_64/include/exec/memory.h:1715
+Downloading source file /usr/src/debug/qemu-kvm-8.2.0-2.el9.x86_64/include/exec/memory.h...
+1715	    if (mr->alias) {
+[Current thread is 1 (Thread 0x7fe033fff640 (LWP 1154728))]
+(gdb) (gdb) #0  memory_region_get_iommu (mr=0x418c0fdb85f05d8b)
+    at /usr/src/debug/qemu-kvm-8.2.0-2.el9.x86_64/include/exec/memory.h:1715
+        addr = 18446603473123421792
+        d = 0x7fe03c135150
+        section = 0x7fe03c621e70
+        imrc = <optimized out>
+        iommu_idx = <optimized out>
+        iotlb = {
+          target_as = <optimized out>,
+          iova = <optimized out>,
+          translated_addr = <optimized out>,
+          addr_mask = <optimized out>,
+          perm = <optimized out>
+        }
+#1  address_space_translate_for_iotlb
+    (cpu=0x55766c32c480, asidx=<optimized out>, orig_addr=472023040, xlat=0x7fe048df9ea0, plen=0x7fe048df9e98, attrs=..., prot=0x7fe048df9e94)
+    at ../system/physmem.c:688
+        addr = 18446603473123421792
+        d = 0x7fe03c135150
+        section = 0x7fe03c621e70
+        imrc = <optimized out>
+        iommu_idx = <optimized out>
+        iotlb = {
+          target_as = <optimized out>,
+          iova = <optimized out>,
+          translated_addr = <optimized out>,
+          addr_mask = <optimized out>,
+          perm = <optimized out>
+        }
+#2  0x00005576693d149f in tlb_set_page_full
+    (cpu=0x55766c32c480, mmu_idx=<optimized out>, addr=18446741874686296064, full=0x7fe048df9ed8) at ../accel/tcg/cputlb.c:1140
+        sz = 4096
+        addr_page = 18446741874686296064
+        paddr_page = 472023040
+        prot = 1
+        asidx = -536727968
+        xlat = 18599936
+        section = <optimized out>
+        read_flags = <optimized out>
+        is_romd = <optimized out>
+        addend = <optimized out>
+        write_flags = <optimized out>
+        iotlb = <optimized out>
+        wp_flags = <optimized out>
+        index = <optimized out>
+        te = <optimized out>
+        tn = {
+          {
+            addr_read = <optimized out>,
+            addr_write = <optimized out>,
+            addr_code = <optimized out>,
+            addend = <optimized out>
+          },
+          addr_idx = {<optimized out>, <optimized out>, <optimized out>, <optimized out>}
+        }
+#3  0x0000557669248a18 in tlb_set_page_with_attrs
+    (cpu=0x55766c32c480, addr=18446741874686296064, paddr=<optimized out>, attrs=..., prot=<optimized out>, mmu_idx=0, size=<optimized out>)
+    at ../accel/tcg/cputlb.c:1290
+        out = {
+          paddr = 472027056,
+          prot = 1,
+          page_size = 4096
+        }
+        err = {
+          exception_index = 472064000,
+          error_code = 0,
+          cr2 = 13915309287368685568,
+          stage2 = (unknown: 0x1c232b28)
+        }
+        env = <optimized out>
+#4  x86_cpu_tlb_fill
+    (cs=0x55766c32c480, addr=<optimized out>, size=<optimized out>, access_type=MMU_DATA_LOAD, mmu_idx=0, probe=<optimized out>, retaddr=0)
+    at ../target/i386/tcg/sysemu/excp_helper.c:610
+        out = {
+          paddr = 472027056,
+          prot = 1,
+          page_size = 4096
+        }
+        err = {
+          exception_index = 472064000,
+          error_code = 0,
+          cr2 = 13915309287368685568,
+          stage2 = (unknown: 0x1c232b28)
+        }
+        env = <optimized out>
+#5  0x00005576693db519 in tlb_fill
+    (addr=18446741874686300080, size=-2047844981, access_type=MMU_DATA_LOAD, mmu_idx=0, retaddr=0, cpu=<optimized out>) at ../accel/tcg/cputlb.c:1315
+        ok = <optimized out>
+        addr = 18446741874686300080
+        index = <optimized out>
+        entry = 0x7fe028017080
+        tlb_addr = <optimized out>
+        maybe_resized = false
+        full = <optimized out>
+        flags = <optimized out>
+#6  mmu_lookup1
+    (cpu=<optimized out>, data=0x7fe048df9f00, mmu_idx=0, access_type=MMU_DATA_LOAD, ra=0) at ../accel/tcg/cputlb.c:1713
+        addr = 18446741874686300080
+        index = <optimized out>
+        entry = 0x7fe028017080
+        tlb_addr = <optimized out>
+        maybe_resized = false
+        full = <optimized out>
+        flags = <optimized out>
+#7  0x00005576693db31b in mmu_lookup
+    (cpu=0x55766c32c480, addr=18446741874686300080, oi=<optimized out>, ra=0, type=MMU_DATA_LOAD, l=0x7fe048df9f00) at ../accel/tcg/cputlb.c:1803
+        a_bits = <optimized out>
+        flags = <optimized out>
+#8  0x00005576693d3173 in do_ld4_mmu
+    (cpu=0x7fe03c135150, addr=18446603473123421792, oi=2247122315, ra=140601056453952, access_type=MMU_DATA_LOAD) at ../accel/tcg/cputlb.c:2416
+        l = {
+          page = {{
+              full = 0x1c232000,
+              haddr = 0xc0700000000,
+              addr = 18446741874686300080,
+              flags = 88995840,
+              size = 4
+            }, {
+              full = 0x7fe033fff458,
+              haddr = 0xc11d1c12054df800,
+              addr = 18446741874686296064,
+              flags = 88995840,
+              size = 0
+            }},
+          memop = MO_32,
+          mmu_idx = 0
+        }
+        crosspage = <optimized out>
+        ret = <optimized out>
+#9  0x00005576692d44cf in cpu_ldl_mmu
+    (env=0x55766c32ec30, addr=18446741874686300080, oi=2247122315, ra=0)
+    at ../accel/tcg/ldst_common.c.inc:158
+        oi = 2247122315
+        has_error_code = <optimized out>
+        old_eip = 18446744072005078059
+        dt = 0x55766c32edc0
+        ptr = 18446741874686300080
+        e1 = <optimized out>
+        e2 = <optimized out>
+        e3 = <optimized out>
+        type = <optimized out>
+        dpl = <optimized out>
+        cpl = <optimized out>
+        selector = <optimized out>
+        offset = <optimized out>
+        ist = <optimized out>
+        new_stack = <optimized out>
+        esp = <optimized out>
+        ss = <optimized out>
+        count = 0
+        env = 0x55766c32ec30
+#10 cpu_ldl_le_mmuidx_ra
+    (env=0x55766c32ec30, addr=18446741874686300080, mmu_idx=<optimized out>, ra=0) at ../accel/tcg/ldst_common.c.inc:294
+        oi = 2247122315
+        has_error_code = <optimized out>
+        old_eip = 18446744072005078059
+        dt = 0x55766c32edc0
+        ptr = 18446741874686300080
+        e1 = <optimized out>
+        e2 = <optimized out>
+        e3 = <optimized out>
+        type = <optimized out>
+        dpl = <optimized out>
+        cpl = <optimized out>
+        selector = <optimized out>
+        offset = <optimized out>
+        ist = <optimized out>
+        new_stack = <optimized out>
+        esp = <optimized out>
+        ss = <optimized out>
+        count = 0
+        env = 0x55766c32ec30
+#11 do_interrupt64
+    (env=0x55766c32ec30, intno=251, is_int=0, error_code=0, next_eip=<optimized out>, is_hw=<optimized out>) at ../target/i386/tcg/seg_helper.c:889
+        has_error_code = <optimized out>
+        old_eip = 18446744072005078059
+        dt = 0x55766c32edc0
+        ptr = 18446741874686300080
+        e1 = <optimized out>
+        e2 = <optimized out>
+        e3 = <optimized out>
+        type = <optimized out>
+        dpl = <optimized out>
+        cpl = <optimized out>
+        selector = <optimized out>
+        offset = <optimized out>
+        ist = <optimized out>
+        new_stack = <optimized out>
+        esp = <optimized out>
+        ss = <optimized out>
+        count = 0
+        env = 0x55766c32ec30
+#12 do_interrupt_all
+    (cpu=0x55766c32c480, intno=251, is_int=0, error_code=0, next_eip=<optimized out>, is_hw=<optimized out>) at ../target/i386/tcg/seg_helper.c:1130
+        count = 0
+        env = 0x55766c32ec30
+#13 0x000055766924f605 in do_interrupt_x86_hardirq
+    (env=<optimized out>, intno=<optimized out>, is_hw=<optimized out>)
+    at ../target/i386/tcg/seg_helper.c:1162
+        cpu = 0x55766c32c480
+        env = <optimized out>
+        intno = <optimized out>
+#14 0x000055766924f605 in x86_cpu_exec_interrupt ()
+#15 0x00005576693bdc25 in cpu_handle_interrupt
+    (cpu=0x55766c32c480, last_tb=<optimized out>)
+    at ../accel/tcg/cpu-exec.c:865
+        cc = <optimized out>
+        interrupt_request = 2
+        last_tb = <optimized out>
+        tb_exit = <optimized out>
+        ret = <optimized out>
+#16 cpu_exec_loop (cpu=0x55766c32c480, sc=0x7fe048df9fb0)
+    at ../accel/tcg/cpu-exec.c:974
+        last_tb = <optimized out>
+        tb_exit = <optimized out>
+        ret = <optimized out>
+#17 0x00005576693bcee1 in cpu_exec_setjmp
+    (cpu=0x55766c32c480, sc=0x7fe048df9fb0) at ../accel/tcg/cpu-exec.c:1058
+#18 0x00005576693bcd64 in cpu_exec (cpu=0x55766c32c480)
+    at ../accel/tcg/cpu-exec.c:1084
+        sc = {
+          diff_clk = 0,
+          last_cpu_icount = 0,
+          realtime_clock = 0
+        }
+        ret = <optimized out>
+#19 0x00007fe0c5e4011c in tcg_cpus_exec (cpu=0x55766c32c480)
+    at ../accel/tcg/tcg-accel-ops.c:76
+        ret = <optimized out>
+        r = <optimized out>
+        force_rcu = {
+          notifier = {
+            notify = 0x7fe0c5e40250 <mttcg_force_rcu>,
+            node = {
+              le_next = 0x0,
+              le_prev = 0x7fe033fff478
+            }
+          },
+          cpu = 0x55766c32c480
+        }
+#20 mttcg_cpu_thread_fn (arg=0x55766c32c480)
+    at ../accel/tcg/tcg-accel-ops-mttcg.c:95
+        r = <optimized out>
+        force_rcu = {
+          notifier = {
+            notify = 0x7fe0c5e40250 <mttcg_force_rcu>,
+            node = {
+              le_next = 0x0,
+              le_prev = 0x7fe033fff478
+            }
+          },
+          cpu = 0x55766c32c480
+        }
+#21 0x0000557669662ada in qemu_thread_start (args=0x55766c3a1870)
+    at ../util/qemu-thread-posix.c:541
+        __clframe = {
+          __cancel_routine = <optimized out>,
+          __cancel_arg = 0x0,
+          __do_it = 1,
+          __cancel_type = <synthetic pointer>
+        }
+        qemu_thread_args = 0x55766c3a1870
+        start_routine = 0x7fe0c5e40000 <mttcg_cpu_thread_fn>
+        arg = 0x55766c32c480
+        r = <optimized out>
+#22 0x00007fe0c68a1912 in start_thread (arg=<optimized out>)
+    at pthread_create.c:443
+        ret = <optimized out>
+        pd = <optimized out>
+        unwind_buf = {
+          cancel_jmp_buf = {{
+              jmp_buf = {140725889877392, 270352123062618637, 140600921814592, 0, 140603380340288, 0, -288199396121933299, -287677566653593075},
+              mask_was_saved = 0
+            }},
+          priv = {
+            pad = {0x0, 0x0, 0x0, 0x0},
+            data = {
+              prev = 0x0,
+              cleanup = 0x0,
+              canceltype = 0
+            }
+          }
+        }
+        not_first_call = <optimized out>
+#23 0x00007fe0c683f450 in clone3 ()
+    at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+```
+
+Also, a couple runs failed with:
+```
++ /usr/libexec/qemu-kvm -smp 8 -net none -m 768M -nographic -kernel /boot/vmlinuz-5.14.0-427.el9.x86_64 -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.7FKAS9/basic.img -device virtio-rng-pci,max-bytes=1024,period=1000 -cpu Nehalem -initrd /var/tmp/ci-sanity-initramfs-5.14.0-390.el9.x86_64.img -append 'root=LABEL=systemd_boot rw raid=noautodetect rd.luks=0 loglevel=2 init=/usr/lib/systemd/systemd console=ttyS0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-01.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-01.service oops=panic panic=1 softlockup_panic=1 systemd.wants=end.service debug systemd.log_level=debug rd.systemd.log_target=console systemd.default_standard_output=journal+console systemd.unified_cgroup_hierarchy=1 systemd.legacy_systemd_cgroup_controller=0
+'
+Could not access KVM kernel module: No such file or directory
+qemu-kvm: failed to initialize kvm: No such file or directory
+qemu-kvm: falling back to tcg
+qemu-kvm: warning: Machine type 'pc-i440fx-rhel7.6.0' is deprecated: machine types for previous major releases are deprecated
+c[?7lSeaBIOS (version 1.16.3-2.el9)
+Booting from ROM...
+early console in setup codae
+Probing EDD (edd=off to disable)... oc[?7lk
+[    0.000000] Linux version 5.14.0-427.el9.x86_64 (mockbuild@x86-05.stream.rdu2.redhat.com) (gcc (GCC) 11.4.1 20231218 (Red Hat 11.4.1-3), GNU ld version 2.35.2-42.el9) #1 SMP PREEMPT_DYNAMIC Fri Feb 23 04:45:07 UTC 2024
+...
+[    2.152522] pci 0000:00:02.0: reg 0x30: [mem 0xfebe0000-0xfebeffff pref]
+[    2.153914] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
+[    2.156615] pci 0000:00:03.0: [1af4:1005] type 00 class 0x00ff00
+[    2.159388] pci 0000:00:03.0: reg 0x10: [io  0xc000-0xc01f]
+qemu-kvm: ../system/memory.c:2424: void *memory_region_get_ram_ptr(MemoryRegion *): Assertion `mr->ram_block' failed.
+/bin/qemu-system-x86_64: line 4: 137172 Aborted                 (core dumped) "/usr/libexec/qemu-kvm" "$@"
+```
+
+I'm not sure if the two issues are related, or if the assertion is something completely different.
+Steps to reproduce:
+I, unfortunately, don't have any concrete steps to reproduce the issue, it happens randomly throughout CI runs. However, when needed, I can reproduce the issue in some reliable-ish manner by running the integration tests in a loop (the issue manifests itself usually in a couple of hours in this case).
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2302 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2302
new file mode 100644
index 00000000..b77301c2
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2302
@@ -0,0 +1,25 @@
+qemu-x86_64 crashes with "Illegal Instruction" on SPECCPU2017 Benchmarks
+Description of problem:
+I am running qemu-x86_64 with SPEC CPU 2017 benchmarks, and the compiled benchmarks such as Perlbench will crash unexpectedly. I have changed to three other machines to run it and still get crashes on two of them, I don't know what's the problem and want some help.
+Steps to reproduce:
+1. Compile SPEC CPU 2017 basic Perlbench binary. 
+2. Use the above command line to run it.
+Additional information:
+I have added some debugging flags to qemu-x86_64 to test it. The "-d in_asm" flag gives me the instructions before the crash like this:
+```
+----------------
+IN: Perl_lex_start
+0x555555678a79:  48 89 83 a8 00 00 00     movq     %rax, 0xa8(%rbx)
+0x555555678a80:  e9 01 ff ff ff           jmp      0x555555678986
+
+----------------
+IN: Perl_lex_start
+0x555555678986:  48 8b 50 10              movq     0x10(%rax), %rdx
+0x55555567898a:  41 83 e4 16              andl     $0x16, %r12d
+0x55555567898e:  48 89 93 d0 00 00 00     movq     %rdx, 0xd0(%rbx)
+0x555555678995:  48 89 93 c0 00 00 00     movq     %rdx, 0xc0(%rbx)
+0x55555567899c:  62                       .byte    0x62
+
+qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+Illegal instruction (core dumped)
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2380 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2380
new file mode 100644
index 00000000..19639337
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2380
@@ -0,0 +1,105 @@
+Crash on x86_64 vm launch
+Description of problem:
+When I started using QEMU for x86 OS programming about a year or 2 ago it ran fine until about a year ago where it just does not launch for more than a few seconds, it always crashes with no output at all, even when running with debug options enabled, it still outputs normal values before just crashing or exiting, this happens when running with an OS image or not, I have tried everything possible (wiping the whole system of anything including "qemu" including the registry, disabling all AV including windows defender, using SFC and DISM to repair corrupt files, installing the oldest versions of qemu up to the newest, running the program in different compatibility modes, running as admin, changing install directories, disabling overclocking, and many more) the only way it runs is if I use a VM to run qemu or reinstall windows, I am not reinstalling windows and im not running a vm to run another vm, my OS is very stable apart from this one program, I need to use QEMU as it is very important for my OS builds as it allows me to automate many things.
+Steps to reproduce:
+1. launch qemu-system-x86_64
+
+unable to reproduce on other clean OS installs
+Additional information:
+upon clean building QEMU from latest build using MSYS2 and running GDB here is the output
+
+```
+(gdb) run
+Starting program: C:\qemu\build\qemu-system-x86_64.exe
+[New Thread 22292.0x250c]
+[New Thread 22292.0x2004]
+[New Thread 22292.0x1d2c]
+[New Thread 22292.0x5614]
+[New Thread 22292.0x5b3c]
+[New Thread 22292.0x5ae8]
+[New Thread 22292.0x2d04]
+[New Thread 22292.0x5588]
+[New Thread 22292.0x3ce8]
+gdb: unknown target exception 0xc0000409 at 0x7ffac8f83e74
+
+Thread 8 received signal ?, Unknown signal.
+[Switching to Thread 22292.0x2d04]
+0x00007ffac8f83e74 in strerror_s () from C:\Windows\System32\msvcrt.dll
+
+```
+
+the error code leads to STATUS_STACK_BUFFER_OVERRUN
+
+upon back tracing this it leads to this output
+
+```
+(gdb) bt
+#0  0x00007ffac8f83e74 in strerror_s () from C:\Windows\System32\msvcrt.dll
+#1  0x00007ffac8f82c04 in msvcrt!longjmp () from C:\Windows\System32\msvcrt.dll
+#2  0x00007ff670af2b8e in advance_pc (env=0x34d3c60, s=0x4beff8d0, num_bytes=4)
+    at ../target/i386/tcg/translate.c:2131
+#3  0x00007ff670af2d33 in x86_ldl_code (env=0x34d3c60, s=0x4beff8d0)
+    at ../target/i386/tcg/translate.c:2169
+#4  0x00007ff670af3939 in insn_get (env=0x34d3c60, s=0x4beff8d0, ot=MO_32)
+    at ../target/i386/tcg/translate.c:2454
+#5  0x00007ff670b0c4ca in disas_insn (s=0x4beff8d0, cpu=0x34d1450)
+    at ../target/i386/tcg/translate.c:5148
+#6  0x00007ff670b1253f in i386_tr_translate_insn (dcbase=0x4beff8d0, cpu=0x34d1450)
+    at ../target/i386/tcg/translate.c:7023
+#7  0x00007ff670ba30b2 in translator_loop (cpu=0x34d1450, tb=0x3b3a280, max_insns=0x4beffba4,
+    pc=954352, host_pc=0x43de8ff0, ops=0x7ff671a9b480 <i386_tr_ops>, db=0x4beff8d0)
+    at ../accel/tcg/translator.c:164
+#8  0x00007ff670b127ef in gen_intermediate_code (cpu=0x34d1450, tb=0x3b3a280,
+    max_insns=0x4beffba4, pc=954352, host_pc=0x43de8ff0) at ../target/i386/tcg/translate.c:7099
+#9  0x00007ff670ba1abd in setjmp_gen_code (env=0x34d3c60, tb=0x3b3a280, pc=954352,
+    host_pc=0x43de8ff0, max_insns=0x4beffba4, ti=0x4beffbc0) at ../accel/tcg/translate-all.c:278
+#10 0x00007ff670ba1de3 in tb_gen_code (cpu=0x34d1450, pc=954352, cs_base=0, flags=176,
+    cflags=-16646144) at ../accel/tcg/translate-all.c:358
+#11 0x00007ff670b96508 in cpu_exec_loop (cpu=0x34d1450, sc=0x4beffd60)
+    at ../accel/tcg/cpu-exec.c:989
+#12 0x00007ff670b96689 in cpu_exec_setjmp (cpu=0x34d1450, sc=0x4beffd60)
+    at ../accel/tcg/cpu-exec.c:1035
+#13 0x00007ff670b96728 in cpu_exec (cpu=0x34d1450) at ../accel/tcg/cpu-exec.c:1061
+--Type <RET> for more, q to quit, c to continue without paging--
+#14 0x00007ff670bc1fb7 in tcg_cpu_exec (cpu=0x34d1450) at ../accel/tcg/tcg-accel-ops.c:76
+#15 0x00007ff670bc28a2 in mttcg_cpu_thread_fn (arg=0x34d1450)
+    at ../accel/tcg/tcg-accel-ops-mttcg.c:95
+#16 0x00007ff670de8587 in win32_start_routine (arg=0x3537c60) at ../util/qemu-thread-win32.c:411
+#17 0x00007ffac8f8e634 in msvcrt!_beginthreadex () from C:\Windows\System32\msvcrt.dll
+#18 0x00007ffac8f8e70c in msvcrt!_endthreadex () from C:\Windows\System32\msvcrt.dll
+#19 0x00007ffac901257d in KERNEL32!BaseThreadInitThunk () from C:\Windows\System32\kernel32.dll
+#20 0x00007ffacae0aa48 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
+#21 0x0000000000000000 in ?? ()
+
+```
+
+if I am reading the output correctly   qemu/target/i386/tcg/translate.c:2131     is the last file (in source) it accesses before moving to msvcrt.dll,  inside of the advance_pc function
+
+
+this is the function
+
+```
+static uint64_t advance_pc(CPUX86State *env, DisasContext *s, int num_bytes) {
+    uint64_t pc = s->pc;
+
+    if (s->base.num_insns > 1 && !is_same_page(&s->base, s->pc + num_bytes - 1)) {
+        siglongjmp(s->jmpbuf, 2);   <--------------------------------------------------   The line is the last function call
+    }
+
+    s->pc += num_bytes;
+
+    if (unlikely(cur_insn_len(s) > X86_MAX_INSN_LENGTH)) {
+        if (((s->pc - 1) ^ (pc - 1)) & TARGET_PAGE_MASK) {
+            volatile uint8_t unused = cpu_ldub_code(env, (s->pc - 1) & TARGET_PAGE_MASK);
+            (void)unused;
+        }
+        siglongjmp(s->jmpbuf, 1);
+    }
+
+    return pc;
+}
+```
+
+if I had to guess this problem could be caused by some windows configuration, something to do with memory, or maybe some corrupt files, but I am unsure
+
+I am not a c programmer so I don't know much about the code but I can debug more if needed
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2474 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2474
new file mode 100644
index 00000000..24a03590
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2474
@@ -0,0 +1,96 @@
+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/gitlab/issues_text/target_i386/host_missing/accel_TCG/2489 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2489
new file mode 100644
index 00000000..a158b25a
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2489
@@ -0,0 +1,92 @@
+qemu-system-x86_64 TCG coredumps when using qemu_plugin_register_vcpu_mem_cb
+Description of problem:
+QEMU freezes, then exits with `Segmentation fault (core dumped)`.
+Steps to reproduce:
+1. Install Windows 7 SP1 into `disk.qcow2`.
+2. Start the machine, and use `savevm snapshot` at the login screen, then exit.
+3. `./qemu-system-x86_64 -m 1G -M q35 -drive file=disk.qcow2 -nic none -loadvm snapshot -plugin contrib/plugins/libexeclog.so`
+Additional information:
+QEMU runs normally without the plugin.
+
+This bug can also be reproduced with a simpler plugin just calling `qemu_plugin_register_vcpu_mem_cb` once per instruction:
+[minimal_plugin.diff](/uploads/6e6c1af21df90379e726e693a53f7b8f/minimal_plugin.diff).
+
+Log using `-d op,in_asm,out_asm,plugin -D log`: [log.gz](/uploads/ccfd26c4845422d63f72a357f8fc1137/log.gz)
+
+GDB full backtrace:
+```
+(gdb) bt f
+#0  stw_he_p (v=0, ptr=0x2) at /REDACTED/qemu/include/qemu/bswap.h:265
+No locals.
+#1  stw_le_p (v=0, ptr=0x2) at /REDACTED/qemu/include/qemu/bswap.h:319
+No locals.
+#2  access_stw (ac=ac@entry=0x7f1652dfec70, addr=addr@entry=18446735827410705922, val=val@entry=0) at ../target/i386/tcg/access.c:143
+        p = 0x2
+#3  0x000055dfca88534e in do_xsave_fpu (ac=ac@entry=0x7f1652dfec70, ptr=ptr@entry=18446735827410705920) at ../target/i386/tcg/fpu_helper.c:2537
+        env = 0x55dff34fe630
+        fpus = 0
+        fptag = <optimized out>
+        i = <optimized out>
+        addr = <optimized out>
+#4  0x000055dfca88caf8 in do_fxsave (ptr=18446735827410705920, ac=0x7f1652dfec70) at ../target/i386/tcg/fpu_helper.c:2632
+        env = 0x55dff34fe630
+        env = <optimized out>
+#5  helper_fxsave (env=<optimized out>, ptr=18446735827410705920) at ../target/i386/tcg/fpu_helper.c:2656
+        ra = <optimized out>
+        ac = {vaddr = 18446735827410705920, haddr1 = 0x0, haddr2 = 0x0, size = 512, size1 = 512, mmu_idx = 4, env = 0x55dff34fe630, 
+          ra = 139732667533971}
+#6  0x00007f160c030a93 in code_gen_buffer ()
+No locals.
+#7  0x000055dfca979986 in cpu_tb_exec (cpu=cpu@entry=0x55dff34fbe70, itb=itb@entry=0x7f160c030940 <code_gen_buffer+198931>, 
+    tb_exit=tb_exit@entry=0x7f1652dff228) at ../accel/tcg/cpu-exec.c:458
+        ret = <optimized out>
+        last_tb = <optimized out>
+        tb_ptr = 0x7f160c030a00 <code_gen_buffer+199123>
+        __PRETTY_FUNCTION__ = "cpu_tb_exec"
+#8  0x000055dfca979edd in cpu_loop_exec_tb (tb_exit=0x7f1652dff228, last_tb=<synthetic pointer>, pc=<optimized out>, 
+    tb=0x7f160c030940 <code_gen_buffer+198931>, cpu=0x55dff34fbe70) at ../accel/tcg/cpu-exec.c:908
+        insns_left = <optimized out>
+        __PRETTY_FUNCTION__ = "cpu_loop_exec_tb"
+        insns_left = <optimized out>
+        _a15 = <optimized out>
+        _b16 = <optimized out>
+#9  cpu_exec_loop (cpu=cpu@entry=0x55dff34fbe70, sc=sc@entry=0x7f1652dff2c0) at ../accel/tcg/cpu-exec.c:1022
+        tb = 0x7f160c030940 <code_gen_buffer+198931>
+        flags = <optimized out>
+        cflags = 4278321152
+        pc = <optimized out>
+        cs_base = <optimized out>
+        last_tb = <optimized out>
+        tb_exit = 1
+        ret = <optimized out>
+#10 0x000055dfca97a6fd in cpu_exec_setjmp (cpu=cpu@entry=0x55dff34fbe70, sc=sc@entry=0x7f1652dff2c0) at ../accel/tcg/cpu-exec.c:1039
+No locals.
+#11 0x000055dfca97ae79 in cpu_exec (cpu=cpu@entry=0x55dff34fbe70) at ../accel/tcg/cpu-exec.c:1065
+        ret = <optimized out>
+        sc = {diff_clk = 0, last_cpu_icount = 0, realtime_clock = 0}
+        _rcu_read_auto = 0x1
+#12 0x000055dfca9a35af in tcg_cpu_exec (cpu=cpu@entry=0x55dff34fbe70) at ../accel/tcg/tcg-accel-ops.c:78
+--Type <RET> for more, q to quit, c to continue without paging--c
+        ret = <optimized out>
+        __PRETTY_FUNCTION__ = "tcg_cpu_exec"
+#13 0x000055dfca9a3703 in mttcg_cpu_thread_fn (arg=arg@entry=0x55dff34fbe70) at ../accel/tcg/tcg-accel-ops-mttcg.c:95
+        r = <optimized out>
+        force_rcu = {notifier = {notify = 0x55dfca9a37f0 <mttcg_force_rcu>, node = {le_next = 0x0, le_prev = 0x7f1652e00528}}, cpu = 0x55dff34fbe70}
+        cpu = 0x55dff34fbe70
+        __PRETTY_FUNCTION__ = "mttcg_cpu_thread_fn"
+        __func__ = "mttcg_cpu_thread_fn"
+#14 0x000055dfcab7e898 in qemu_thread_start (args=0x55dff355dd80) at ../util/qemu-thread-posix.c:541
+        __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {94420348558720, 3438567870158976394, -1656, 0, 140727865026624, 139734089805824, 
+                8803266606146106762, 3438582454403577226}, __mask_was_saved = 0}}, __pad = {0x7f1652dff430, 0x0, 0x0, 0x0}}
+        __cancel_routine = 0x55dfcab7e8f0 <qemu_thread_atexit_notify>
+        __cancel_arg = <optimized out>
+        __not_first_call = <optimized out>
+        qemu_thread_args = <optimized out>
+        start_routine = 0x55dfca9a3600 <mttcg_cpu_thread_fn>
+        arg = 0x55dff34fbe70
+        r = <optimized out>
+#15 0x00007f165e090272 in start_thread () from /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
+No symbol table info available.
+#16 0x00007f165e10bdec in clone3 () from /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
+No symbol table info available.
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/249 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/249
new file mode 100644
index 00000000..6a6789a2
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/249
@@ -0,0 +1 @@
+guest OS catches a page  fault bug when running dotnet
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2495 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2495
new file mode 100644
index 00000000..4d6c2322
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2495
@@ -0,0 +1,72 @@
+A bug in x86-64 MMX instructions
+Description of problem:
+It seems QEMU emits invalid TCG when lifting MMX instructions with redundant REX prefixes. For example, when lifting `490f7ec0 (movq r8, mm0)`, QEMU generates the following valid TCG.
+
+```
+ ---- 00000000004011f2 0000000000000000
+ call enter_mmx,$0x0,$0,env
+ ld_i64 loc0,env,$0x270
+ mov_i64 r8,loc0
+ mov_i64 rip,$0x4011f6
+ exit_tb $0x0
+ set_label $L0
+ exit_tb $0x7f84f82ec143
+```
+
+However, after changing the value of the rex prefix to `4f` , so the instruction becomes `4f0f7ec0 (rex.WRXB movq r8, mm0)`, the lifted TCG is changed to:
+
+```
+ ---- 00000000004011f2 0000000000000000
+ call enter_mmx,$0x0,$0,env
+ ld_i64 loc0,env,$0x2f0 // The offset to MM0 is changed
+ mov_i64 r8,loc0
+ mov_i64 rip,$0x4011f6
+ exit_tb $0x0
+ set_label $L0
+ exit_tb $0x7f98e82ec143
+```
+
+I have observed this bug in numerous MMX instructions. For example, `410fdaff (rex.B pminub mm7, mm7)` is lifted to the wrong TCGs.
+
+It seems this bug looks similar to #2474.
+Steps to reproduce:
+1. Write `test.c` 
+```
+#include <stdint.h>
+#include <stdio.h>
+#include <string.h>
+
+uint8_t i_R8[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 };
+uint8_t i_MM0[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
+uint8_t o_R8[8];
+
+void __attribute__ ((noinline)) show_state() {
+    printf("R8: ");
+    for (int i = 0; i < 8; i++) {
+        printf("%02x ", o_R8[i]);
+    }
+    printf("\n");
+}
+
+void __attribute__ ((noinline)) run() {
+    __asm__ (
+        ".intel_syntax noprefix\n"
+        "mov r8, qword ptr [rip + i_R8]\n"
+        "movq mm0, qword ptr [rip + i_MM0]\n"
+        ".byte 0x4f, 0x0f, 0x7e, 0xc0\n"
+        "mov qword ptr [rip + o_R8], r8\n"
+        ".att_syntax\n"
+    );
+}
+
+int main(int argc, char **argv) {
+    run();
+    show_state();
+    return 0;
+}
+```    
+2. Compile `test.bin` using this command: `gcc-12 -O2 -no-pie ./test.c -o ./test.bin`
+3. Run QEMU using this command: `qemu-x86_64 ./test.bin` 
+4. The program, runs on top of the buggy QEMU, prints the value of R8 as `00 00 00 00 00 00 00 00`. It should print `ff ff ff ff ff ff ff ff` after the bug is fixed.
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2511 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2511
new file mode 100644
index 00000000..285afaaa
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2511
@@ -0,0 +1,32 @@
+Regression 9.1.0rc2: target/i386/tcg/access.c:18: access_prepare_mmu: Assertion '...' failed.
+Description of problem:
+Executing QEMU command line crashes with 
+   ```
+qemu-system-x86_64: ../target/i386/tcg/access.c:18: access_prepare_mmu: Assertion `size > 0 && size <= TARGET_PAGE_SIZE' failed.
+   ```
+Steps to reproduce:
+1. Download https://www.qemu-advent-calendar.org/2020/download/day07.tar.gz
+2. Execute with QEMU command line
+Additional information:
+git bisect finishes with:
+   ```
+8b131065080af3cf2dda04e4e190c5a74fec2f31 is the first bad commit
+commit 8b131065080af3cf2dda04e4e190c5a74fec2f31
+Author: Paolo Bonzini <pbonzini@redhat.com>
+Date:   Tue Jun 18 09:13:49 2024 +0200
+
+    target/i386/tcg: use X86Access for TSS access
+    
+    This takes care of probing the vaddr range in advance, and is also faster
+    because it avoids repeated TLB lookups.  It also matches the Intel manual
+    better, as it says "Checks that the current (old) TSS, new TSS, and all
+    segment descriptors used in the task switch are paged into system memory";
+    note however that it's not clear how the processor checks for segment
+    descriptors, and this check is not included in the AMD manual.
+    
+    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
+    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+
+ target/i386/tcg/seg_helper.c | 110 +++++++++++++++++++++++--------------------
+ 1 file changed, 58 insertions(+), 52 deletions(-)
+   ```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2567 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2567
new file mode 100644
index 00000000..3f0ceb38
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2567
@@ -0,0 +1,78 @@
+crash in target/i386/tcg/translate.c on loongarch64 Linux debian 6.11.0-rc7
+Description of problem:
+```
+  ERROR:target/i386/tcg/translate.c:748:gen_helper_out_func: code should not be reached 
+  Bail out! ERROR:target/i386/tcg/translate.c:748:gen_helper_out_func: code should not be reached 
+  已中止（核心已转储）
+  ```
+Steps to reproduce:
+1. windows x64 has been installed into win7_x64.qcow2
+2. windows x64 in win7_x64.qcow2 has been run for several times by the same command line
+3. crash occurred when windows was starting up
+Additional information:
+```
+Hint: You are currently not seeing messages from other users and the system.
+      Users in groups 'adm', 'systemd-journal' can see all messages.
+      Pass -q to turn off this notice.
+           PID: 61627 (qemu-system-x86)
+           UID: 1000 (tsingkong)
+           GID: 1001 (tsingkong)
+        Signal: 6 (ABRT)
+     Timestamp: Tue 2024-09-10 15:59:05 CST (18h ago)
+  Command Line: qemu-system-x86_64 -name win7_x64 -hda /SATA/QEMU/win7_x64.qcow2 -boot c -cpu qemu64 -smp sockets=1,cores=4,threads=1 -m 8G -device VGA -netdev user,id=lan -device rtl8139,netdev=lan -usb -device usb-tablet -rtc base=localtime -monitor stdio
+    Executable: /usr/bin/qemu-system-x86_64
+ Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-353cf168c0a84fbe8cdc2b8b72cba71e.scope
+          Unit: user@1000.service
+     User Unit: app-org.kde.konsole-353cf168c0a84fbe8cdc2b8b72cba71e.scope
+         Slice: user-1000.slice
+     Owner UID: 1000 (tsingkong)
+       Boot ID: 49cf5288d7af4b97be341fe599f0c8df
+    Machine ID: 3ab0590011874c2e916d2eeef4585dfb
+      Hostname: debian
+       Storage: /var/lib/systemd/coredump/core.qemu-system-x86.1000.49cf5288d7af4b97be341fe599f0c8df.61627.1725955145000000.zst (present)
+  Size on Disk: 285.9M
+       Message: Process 61627 (qemu-system-x86) of user 1000 dumped core.
+                
+                Module libsystemd.so.0 from deb systemd-256.5-2.loong64
+                Module libgcc_s.so.1 from deb gcc-14-14.2.0-4.loong64
+                Module libstdc++.so.6 from deb gcc-14-14.2.0-4.loong64
+                Module libblkid.so.1 from deb util-linux-2.40.2-8.loong64
+                Module libatomic.so.1 from deb gcc-14-14.2.0-4.loong64
+                Module libmount.so.1 from deb util-linux-2.40.2-8.loong64
+                Module libzstd.so.1 from deb libzstd-1.5.6+dfsg-1.loong64
+                Module libudev.so.1 from deb systemd-256.5-2.loong64
+                Stack trace of thread 61637:
+                #0  0x00007ffff2536968 __pthread_kill_implementation (libc.so.6 + 0x76968)
+                #1  0x00007ffff24f17dc __GI_raise (libc.so.6 + 0x317dc)
+                #2  0x00007ffff24dd238 __GI_abort (libc.so.6 + 0x1d238)
+                #3  0x00007ffff2ccf704 g_assertion_message (libglib-2.0.so.0 + 0x93704)
+                #4  0x00007ffff2ccf768 g_assertion_message_expr (libglib-2.0.so.0 + 0x93768)
+                #5  0x000055555630c440 n/a (qemu-system-x86_64 + 0x830440)
+                #6  0x00005555563286e8 n/a (qemu-system-x86_64 + 0x84c6e8)
+                #7  0x000055555632ef0c n/a (qemu-system-x86_64 + 0x852f0c)
+                #8  0x00005555563f9108 translator_loop (qemu-system-x86_64 + 0x91d108)
+                #9  0x0000555556332474 gen_intermediate_code (qemu-system-x86_64 + 0x856474)
+                #10 0x00005555563f7c08 n/a (qemu-system-x86_64 + 0x91bc08)
+                #11 0x00005555563f8204 tb_gen_code (qemu-system-x86_64 + 0x91c204)
+                #12 0x00005555563ecd54 n/a (qemu-system-x86_64 + 0x910d54)
+                #13 0x00005555563ed288 n/a (qemu-system-x86_64 + 0x911288)
+                #14 0x00005555563edb98 cpu_exec (qemu-system-x86_64 + 0x911b98)
+                #15 0x00007fffdc006c5c tcg_cpu_exec (accel-tcg-x86_64.so + 0x2c5c)
+                #16 0x00007fffdc006df4 n/a (accel-tcg-x86_64.so + 0x2df4)
+                #17 0x0000555556636000 n/a (qemu-system-x86_64 + 0xb5a000)
+                #18 0x00007ffff2534ca4 start_thread (libc.so.6 + 0x74ca4)
+                #19 0x00007ffff259cbcc __thread_start3 (libc.so.6 + 0xdcbcc)
+                
+                Stack trace of thread 61640:
+                #0  0x00005555563fd620 n/a (qemu-system-x86_64 + 0x921620)
+                #1  0x0000555556401b44 get_page_addr_code_hostp (qemu-system-x86_64 + 0x925b44)
+                #2  0x00005555563ebda8 n/a (qemu-system-x86_64 + 0x90fda8)
+                #3  0x00005555563ed5f0 helper_lookup_tb_ptr (qemu-system-x86_64 + 0x9115f0)
+                #4  0x00007fff8d39309c n/a (n/a + 0x0)
+                ELF object binary architecture: LoongArch
+
+```
+
+core.qemu-system-x86.1000.49cf5288d7af4b97be341fe599f0c8df.61627.1725955145000000.zst
+
+https://mega.nz/file/M9ZVzQYS#Z8kw6_cul56nd_p2iwz2SRb4Yb_1K8gqH2YlBBjKk6U
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2578 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2578
new file mode 100644
index 00000000..c193ba1f
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2578
@@ -0,0 +1,14 @@
+x86: exception during hardware interrupt pushes wrong error code
+Description of problem:
+Exceptions during IDT traversal push the wrong error code when triggered by a hardware interrupt.
+The EXT bit in TCG mode is never set.  However, it works fine in KVM mode as hardware is generating the number.
+Steps to reproduce:
+1. load a short IDT e.g. with 64 entries
+2. trigger a self IPI through the LAPIC with a vector 100
+3. the pushed error code is 802 instead of 803.
+Additional information:
+It can be fixed in the lines `raise_exception_err(env, EXCP0D_GPF, intno * 8 + 2);` in `seg_helper.c` 
+which must include the `is_hw` field when calculating the error number. Something like `intno * 8 + 2 + (is_hw != 0)` 
+works here.
+
+Nevertheless, all the other exception cases in the `do_interrupt_*` functions have to set the same bit as well.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2581 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2581
new file mode 100644
index 00000000..7c1f3efe
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2581
@@ -0,0 +1,12 @@
+Assert failure "target/i386/tcg/translate.c:748:gen_helper_out_func" when emulating Windows
+Description of problem:
+qemu crashes with:
+```
+ERROR:../target/i386/tcg/translate.c:748:gen_helper_out_func: code should not be reached
+```
+Steps to reproduce:
+1. Run the command listed above
+2. Wait a random amount of time (anywhere between 30mins to 2hours)
+3. Qemu will crash at some point
+Additional information:
+- Relevant part of the macOS crash log: [qemu-crash.txt](/uploads/5cc296fd0e8c603ba08379749a67071d/qemu-crash.txt)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2599 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2599
new file mode 100644
index 00000000..341068d4
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2599
@@ -0,0 +1 @@
+[x86] RET imm16 not align with native machine
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2605 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2605
new file mode 100644
index 00000000..d4e40126
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2605
@@ -0,0 +1 @@
+amd64/v4 support
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/265 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/265
new file mode 100644
index 00000000..f9a0ab10
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/265
@@ -0,0 +1 @@
+x86: retf or iret pagefault sets wrong error code
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/279 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/279
new file mode 100644
index 00000000..f45f2551
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/279
@@ -0,0 +1 @@
+x86-64 MTTCG Does not update page table entries atomically
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2821 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2821
new file mode 100644
index 00000000..e7cc3c88
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2821
@@ -0,0 +1,23 @@
+Emulated newer x86 chipsets are noticably slower on cpu-bound loads than "-cpu qemu64"
+Description of problem:
+I noticed that "-cpu qemu64" is much faster than "-cpu max" or "-cpu Icelake-Server-noTSX" for cpu bound loads, and with more than one cpu under load.
+Steps to reproduce:
+1. Run a guest as per "qemu-system-x86_64 -cpu max [..]" command from above. Any linux distro should do.
+2. run through the setup questions if you use Fedora-Server-KVM-41-1.4.x86_64.qcow2 from the example command line above
+3. log into the guest via ssh, i.e. "ssh chris@amd64" here
+4. cd /dev/shm; wget http://archive.apache.org/dist/httpd/httpd-2.4.57.tar.bz2; wget https://fluxcoil.net/files/tmp/job_httpd_extract_cpu.sh
+6. bash ./job_httpd_extract_cpu.sh 4 300
+8. cat /tmp/counter
+
+Step 6 is executing a script which simply uses 4 parallel loops, where each loop runs "bzcat httpd-2.4.57.tar.bz2" constantly. After 300sec, the successful uncompressions over all 4 loops are summed up and stored in /tmp/counter.
+
+- result with "-cpu qemu64": 96
+- result with "-cpu max": 84
+- result with "-cpu Icelake-Server-noTSX": 44
+Additional information:
+- For "-cpu Icelake-Server-noTSX" on this Thinkpad T590 I get these warnings, I think they are not relevant:
+  qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
+  qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24]
+  [..]
+- I also looked at Broadwell etc, and all of them seem in the same ballpark.
+  Graph over some emulated architectures: https://fluxcoil.net/files/tmp/gnuplot_cpu-performance-emulated-only.png
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/286 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/286
new file mode 100644
index 00000000..f76a347d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/286
@@ -0,0 +1 @@
+Performance degradation for WinXP boot time after b55f54bc
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2878 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2878
new file mode 100644
index 00000000..b03a49d5
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2878
@@ -0,0 +1 @@
+Support for avx512 in qemu user space  emulation.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/2891 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2891
new file mode 100644
index 00000000..c7bf2e6b
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/2891
@@ -0,0 +1 @@
+qemu-system-x86_64 segfaults when executing ipxe selftests
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/314 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/314
new file mode 100644
index 00000000..3984c145
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/314
@@ -0,0 +1 @@
+qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/318 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/318
new file mode 100644
index 00000000..3450c0bd
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/318
@@ -0,0 +1 @@
+QEMU crash after a QuickBASIC program integer overflow
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/330 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/330
new file mode 100644
index 00000000..7af554a0
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/330
@@ -0,0 +1 @@
+TCG does not support x2APIC emulation
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/380 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/380
new file mode 100644
index 00000000..164de155
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/380
@@ -0,0 +1 @@
+Windows 7 fails to boot
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/382 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/382
new file mode 100644
index 00000000..a9cfa56a
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/382
@@ -0,0 +1 @@
+target/i386/seg_helper.c: 16-bit TSS struct format wrong?
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/394 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/394
new file mode 100644
index 00000000..8cd4fd3d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/394
@@ -0,0 +1 @@
+Windows 7 crashing due to PAGE_FAULT_IN_NONPAGED_AREA
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/404 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/404
new file mode 100644
index 00000000..c78b2af6
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/404
@@ -0,0 +1 @@
+Windows XP takes much longer to boot in TCG mode since 5.0
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/420 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/420
new file mode 100644
index 00000000..3243e66a
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/420
@@ -0,0 +1 @@
+Some x86_64 SSE operations have incorrect/erratic behaviours
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/427 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/427
new file mode 100644
index 00000000..c431467c
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/427
@@ -0,0 +1 @@
+TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/505 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/505
new file mode 100644
index 00000000..7f7e4d02
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/505
@@ -0,0 +1,12 @@
+QEMU crashes when reaching a hardware watchpoint
+Description of problem:
+When using hardware watchpoints, qemu crashes when it hits the watch point.
+See https://github.com/zephyrproject-rtos/zephyr/issues/28613 for the same problem
+Steps to reproduce:
+1. Download https://download.qemu.org/qemu-6.1.0-rc0.tar.xz
+2. Download debian-live-10.10.0-i386-standard.iso from https://cdimage.debian.org/debian-cd/current-live/i386/iso-hybrid/
+3. Build qemu with /configure --target-list=i386-softmmu
+4. Run build/qemu-system-i386 -boot d -cdrom debian-live-10.10.0-i386-standard.iso -m 512 -icount auto -gdb tcp:localhost:1234 -S -display none
+5. Run gdb and inside gdb run "target remote localhost:1234"
+6. In gdb, run "watch *0x0000fff0" and "cont"
+7. qemu will crash with ```qemu: fatal: Raised interrupt while not in I/O function```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/509 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/509
new file mode 100644
index 00000000..174c00e8
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/509
@@ -0,0 +1 @@
+Atomic test-and-set instruction does not work on qemu-user
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/601 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/601
new file mode 100644
index 00000000..f17b0df4
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/601
@@ -0,0 +1,20 @@
+import tensorflow causes qemu: uncaught target signal 6 (Aborted) - core dumped
+Description of problem:
+Crashes when importing tensorflow in Docker container under --platorm linux/amd64 on M1 Mac
+```
+2021-09-06 13:35:24.435613: F tensorflow/core/lib/monitoring/sampler.cc:42] Check failed: bucket_limits_[i] > bucket_limits_[i - 1] (0 vs. 10)
+qemu: uncaught target signal 6 (Aborted) - core dumped
+```
+Steps to reproduce:
+See https://gitlab.com/ryan-feather/docker-tensorflow-qemu-bug/ for Dockerfile and description of steps repeating here.
+1. Using the dockerfile 
+```
+FROM python:3.9-buster
+RUN pip install tensorflow==2.6.0
+
+```
+2. `docker buildx build --iidfile build.id --platform linux/amd64 . --progress=plain`
+3. ``` docker run --platform linux/amd64  `cat build.id` python -c "import tensorflow"```
+Additional information:
+See 
+https://github.com/docker/for-mac/issues/5342 where the Docker team suggests this is a qemu bug. I couldn't find where anyone had opened one of these here, so hopefully this isn't a duplicate.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/619 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/619
new file mode 100644
index 00000000..440e98c4
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/619
@@ -0,0 +1 @@
+Move TCGCPUOps::fake_user_exception() to linux-user/i386/cpu_loop.c
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/661 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/661
new file mode 100644
index 00000000..5b1f1b34
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/661
@@ -0,0 +1,44 @@
+Unable to enable 5 level paging
+Description of problem:
+When attempting to set cr4.LA57, qemu just freezes on that instruction. When I say freeze I mean literally freeze, no exceptions, nothing, it just halts forever on that instruction. When this happened, the first thing I did was
+
+```
+(qemu) info registers 
+EAX=00001000 EBX=00000001 ECX=80224f08 EDX=00000000
+ESI=8034a3a0 EDI=00026520 EBP=000079f8 ESP=000079c8
+EIP=00019648 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0020 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
+CS =0018 00000000 ffffffff 00c09a00 DPL=0 CS32 [-R-]
+SS =0020 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
+DS =0020 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
+FS =0020 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
+GS =0020 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
+LDT=0000 00000000 00000000 00008200 DPL=0 LDT
+TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
+GDT=     0000e120 00000037
+IDT=     00000000 00000000
+CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000000
+...
+```
+
+then using gdb to figure out what instruction it is hanging on, I set a breakpoint at 0x19648 at and ran 
+```
+(gdb) x/1 0x19648
+=> 0x19648:	mov    %rax,%cr4
+(gdb) 
+```
+
+This instruction corresponds to this LOC within limine https://github.com/limine-bootloader/limine/blob/trunk/stage23/protos/stivale.32.c#L33
+Steps to reproduce:
+1. Try to enable 5 level paging
+2. qemu freezes when trying to set cr4.LA57
+3. cry
+Additional information:
+This never happened prior to version 6.1, I test this on multiple different machines and a few of my friends 
+experienced the same issue
+
+I have not tested this on linux, however I assume it will do the same on anything else. 
+Either way, qemu should not be just halting
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/67 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/67
new file mode 100644
index 00000000..eeedac6a
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/67
@@ -0,0 +1 @@
+incomplete emulation of fstenv under TCG
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/676 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/676
new file mode 100644
index 00000000..0ca7eec2
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/676
@@ -0,0 +1,54 @@
+Throws a PF when it should throw a GF/SS
+Description of problem:
+QEMU misreports what should be a #GP as a #PF 
+```
+check_exception old: 0xffffffff new 0xe
+     0: v=0e e=0001 i=0 cpl=0 IP=0028:ffffffffb28fa53b pc=ffffffffb28fa53b SP=0030:ffffffffb2901210 CR2=1fbf7020000772a4
+RAX=1fbf7020000772a4 RBX=0000000000000000 RCX=ffff80000006a0a8 RDX=ffff80000006a038
+RSI=1fbff0200000d26c RDI=0000000000000080 RBP=ffffffffb2901230 RSP=ffffffffb2901210
+R8 =ffffffffb28fb37f R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000
+R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000
+RIP=ffffffffb28fa53b RFL=00000007 [-----PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+CS =0028 0000000000000000 00000000 00209a00 DPL=0 CS64 [-R-]
+SS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+DS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+FS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+GS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT
+TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
+GDT=     000000000000edc0 00000037
+IDT=     000000000002e6a0 000000ff
+CR0=80000013 CR2=1fbf7020000772a4 CR3=0000000000058000 CR4=000006a0
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
+DR6=00000000ffff0ff0 DR7=0000000000000400
+CCS=3f7fe0400001a4d9 CCD=1fbff0200000d26c CCO=SARQ    
+EFER=0000000000000501
+```
+
+Now, `CR2=1fbf7020000772a4` is of course a non-canonical address, and therefore should not generate a #PF, rather it should generate a #GP. I also tried to generate a #SS by dereferencing a non-canonical address through the stack, and that also throws a #PF instead of a #SS
+
+```
+check_exception old: 0xffffffff new 0xe
+     0: v=0e e=0001 i=0 cpl=0 IP=0028:fffffffff4bda92a pc=fffffffff4bda92a SP=0030:1fbf7020000772a4 CR2=1fbf70200007729c
+RAX=0000000000000000 RBX=0000000000000000 RCX=0000000000000000 RDX=fffffffff4bdb998
+RSI=0000000000000000 RDI=fffffffff4bdb998 RBP=fffffffff4bdf290 RSP=1fbf7020000772a4
+R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000
+R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000
+RIP=fffffffff4bda92a RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+CS =0028 0000000000000000 00000000 00209a00 DPL=0 CS64 [-R-]
+SS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+DS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+FS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+GS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT
+TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
+GDT=     000000000000edc0 00000037
+IDT=     000000000002e6a0 000000ff
+CR0=80000011 CR2=1fbf70200007729c CR3=00000000bffa5000 CR4=00000020
+```
+Steps to reproduce:
+1. Dereference a non-canonical address
+2. QEMU gives you a page fault instead of a gpf
+3. reconsider life
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/683 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/683
new file mode 100644
index 00000000..adac15e9
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/683
@@ -0,0 +1 @@
+certain programs make QEMU crash with "tcg fatal error"
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/766 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/766
new file mode 100644
index 00000000..749af1da
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/766
@@ -0,0 +1,27 @@
+qemu-system-x86_64: Reboot loop after Machine->Reset
+Description of problem:
+When using tcg, the virtual machine goes into a reboot loop after the VM
+is rebooted through UI->Machine->Reboot menu, or through outb(0xcf9, 0xf).
+There might be other reboot mechanisms that result in the same loop.
+
+The loop doesn't occur when using kvm:
+qemu-system-x86_64 -M q35 -enable-kvm
+Steps to reproduce:
+1. Run the command. (The one without -enable-kvm.)
+2. From the UI, click on Machine->Reset.
+3. See that the VM locks up, instead of resetting.
+Additional information:
+The reboot loop occurs because a variable defined by Seabios cannot be updated, possibly because the memory is read-only.
+
+The variable in question is [HaveRunPost](https://github.com/coreboot/seabios/blob/2dd4b9b3f84019668719344b40dba79d681be41c/src/fw/shadow.c#L194). If HaveRunPost is non-zero, the BIOS follows the resume path. When the reset is clicked, the BIOS does indeed gain control and follow the resume path because HaveRunPost is 2. The control ends up at qemu_reboot, which should reset HaveRunPost to 0 and trigger another reset, so that this second time around, the BIOS sees HaveRunPost as 0, and follows the initialization path instead.
+
+But, even though the instruction to update HaveRunPost seems to run, the value remains non-zero (2 to be exact).
+
+```
+        // HaveRunPost has value 2 here.
+        barrier();
+        HaveRunPost = 0;
+        barrier();
+        // If a dprintf(1, "%x\n", HaveRunPost); is placed here, the value printed is 2 and not 0!
+        // With kvm-enabled, this dprintf prints 0.
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/824 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/824
new file mode 100644
index 00000000..b3c4740c
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/824
@@ -0,0 +1,12 @@
+x86_64 Translation Block error (cmp eax, 0x6; jnle 0x524)
+Description of problem:
+`Qemu` produces a Translation block of 4 instructions:
+```
+0x0000558a53039ffc: 83f806       (cmp eax, 0x6)
+0x0000558a53039fff: 0f           (nothing)
+0x0000558a53039ffc: 83f806       (cmp eax, 0x6)
+0x0000558a53039fff: 0f8f1e050000 (jnle 0x524)
+```
+This problem occurs several time with different addresses but the same pattern:
+- 1st and 3th instructions are the same (both addresses and opcodes);
+- 2nd is the prefix of the 4th (same addresses).
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/83 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/83
new file mode 100644
index 00000000..7a8b27c6
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/83
@@ -0,0 +1 @@
+QEMU x87 emulation of trig and other complex ops is only at 64-bit precision, not 80-bit
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/844 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/844
new file mode 100644
index 00000000..a1fb8dd2
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/844
@@ -0,0 +1,44 @@
+Close gap for x86_64-v3 ABI in TCG - CPU support for fma, f16c, avx, avx2 features required
+Description of problem:
+There are 3 additional ABIs defined by a collaboration of vendors for the `x86_64` architecture, over the original baseline:
+
+* https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex
+
+This is no problem for KVM assuming suitable host hardware, but TCG is currently unable to support more than the original baseline and the `x86_64-v2` step.  
+
+For `x86_64-v3` there are some gaps in its emulation coverage. This can be seen by taking `Nehalem` which is a good fit for `x86_64-v2`, and requesting the extra v3 features:
+
+```
+$ qemu-system-x86_64 -accel tcg -cpu Nehalem,+avx,+avx2,+bmi1,+bmi2,+f16c,+fma,+abm,+movbe
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5]
+```
+
+IOW, the strict bare minimum TCG needs in order to satisfy `x86_64-v3` is  `fma`, `f16c`, `avx` and `avx2` support
+
+If we want to fully support a named CPU model satisfying v3, then `Haswell` is the closest and that has a few additional gaps
+
+```
+$ qemu-system-x86_64 -accel tcg -cpu Haswell-noTSX
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10]
+
+```
+
+Those additional gaps wouldn't impact ability to execute binaries build for the `x86_64-v3` ABI though, so not as important.
+
+The reason `x86_64-v3` compatibility in TCG matters is because sooner or later some Linux OS are going to set this as the baseline for their compiler toolchain.  There is a proposal to set this in `Fedora ELN`, which is what feeds in to a possible future `RHEL-10`.
+
+I imagine adding these extra features would be non-negligible work in TCG / take some time to complete.
+
+Thus I file this bug for the purpose of suggesting these 4 specific missing features be considered a priority to address, compared to other missing CPU features in TCG that might be considered more of a 'nice to have'.
+
+eg looking further the `x86_64-v4` baseline brings in a requirement for `avx512f`, `avx512bw`, `avx512cd`, `avx512dq`, `avx512vl` which TCG also lacks, but I don't think they really need to be considered important at this point in time.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/870 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/870
new file mode 100644
index 00000000..d6224f82
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/870
@@ -0,0 +1,12 @@
+Throws a #GP when it should throw a #SS
+Description of problem:
+When stacks are switched as part of a 64-bit mode privilege-level change (resulting from an interrupt), IA-32e mode loads only an inner-level RSP from the TSS. If the value of rsp from tss is a non-canonical form. It will trigger #SS. But when I test it in qemu it throws #GP instead of #SS
+Steps to reproduce:
+In order to confirm that it is the #SS triggered by the non-canonical address, We can verify on a real machine.  
+1. Set the value of the current core's `TSS.IST7` to the the non-canonical address.
+2. Set the `ist` field of the interrupt 4 (Overflow Exception) descriptor to 7.
+3. Execute the `INT 4` instruction in Ring 3 and it will be taken over by the #SS handler.
+
+Repeat the above steps in qemu this exception will be taken over by #GP
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/888 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/888
new file mode 100644
index 00000000..0884b136
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/888
@@ -0,0 +1,7 @@
+TCG <--> KVM behavior difference (TCG bug)
+Description of problem:
+This app couldn't start in TCG mode in QEMU 6.2, but with KVM everything is good. Until version 6.0 it also works with TCG.
+As I checked - problem git commit is 5f9529006ea37560c97b05661a84472431d25b91.
+Steps to reproduce:
+1. Install Allplayer
+2. Try to run it in TCG and KVM mode with QEMU 6.2
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/973 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/973
new file mode 100644
index 00000000..e0a67c1d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/973
@@ -0,0 +1,19 @@
+qemu 6.2 memory leak when failed to boot and infinitely reboot
+Description of problem:
+qemu allocates tons of memory (very likely memory leak) in certain (rare) cases.
+
+When I misconfigured qemu so that I have run a bigger linux kernel within insufficient memory (for example 8M bzImage while 16M ram and no hdd), the kernel will obviously fail to boot. In this case qemu will reboot (likely the linux kernel reboots). However reboot does not solve the problem, causing qemu to repeatedly reboot.
+
+Memory usage of qemu raises sharply in the progress.
+Steps to reproduce:
+1. Get any linux kernel (tested with 5.15.33)
+2. Run the kernel on qemu, with memory smaller than necessary
+Additional information:
+A reproducing dockerfile:
+```
+FROM alpine:3.15
+
+RUN apk add qemu-system-x86_64 linux-virt
+
+CMD ["/usr/bin/qemu-system-x86_64", "-kernel", "/boot/vmlinuz-virt", "-nographic", "-net", "none", "-m", "16M"]
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/984 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/984
new file mode 100644
index 00000000..49f54494
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/984
@@ -0,0 +1,23 @@
+QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word
+Description of problem:
+~~The QEMU softfloat float64_to_floatx80 implementation is broken and does not produce correct results.~~ QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word.
+
+```
+IN = 1234.567890 (0x40934a4584f4c6e7)
+OUT = 1234.567871 (0x40099a522c0000000000)
+```
+
+This bug was introduced in the QEMU commit qemu/qemu@8ae5719 as part of the switchover to FloatParts, and is still present in the latest tag (v7.0.0-rc4 as of now).
+
+Prior to the offending commit:
+
+```
+IN = 1234.567890 (0x40934a4584f4c6e7)
+OUT = 1234.567890 (0x40099a522c27a6373800)
+```
+
+This breaks the i386 emulation of `fldl st(0)` (`helper_fldl_ST0`).
+Steps to reproduce:
+Call `float64_to_floatx80` with the input value of `1234.567890 (0x40934a4584f4c6e7)` and see the returned result.
+Additional information:
+See https://github.com/zephyrproject-rtos/sdk-ng/issues/461
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_TCG/993 b/gitlab/issues_text/target_i386/host_missing/accel_TCG/993
new file mode 100644
index 00000000..5509626a
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_TCG/993
@@ -0,0 +1,81 @@
+Invalid opcode  vzeroupper
+Description of problem:
+Got many invalid opcode error with Fedora 36
+See fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=2076410
+
+Crash stack and disassemble. 
+```
+Downloading separate debug info for /lib64/liblzma.so.5...
+Downloading separate debug info for /home/penghuang/Sources/system-supplied DSO at 0x7fff30f55000...
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/lib64/libthread_db.so.1".
+Core was generated by `flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo'.
+Program terminated with signal SIGILL, Illegal instruction.
+#0  0x00007f89783cbe4a in sha512_block_data_order_avx2 () from /lib64/libgnutls.so.30
+[Current thread is 1 (Thread 0x7f8972ada640 (LWP 5083))]
+(gdb) bt
+#0  0x00007f89783cbe4a in sha512_block_data_order_avx2 () from /lib64/libgnutls.so.30
+#1  0x00007f89783bf042 in x86_sha512_update (ctx=0x7f8972ad9090, length=128, data=0x7f8972ad8f90 '\\' <repeats 128 times>, "@\255")
+    at sha-x86-ssse3.c:215
+#2  0x00007f897810879b in nettle_hmac_set_key (outer=<optimized out>, inner=0x7f8972ad9168, state=<optimized out>, 
+    hash=0x7f897848b6c0 <x86_sha384>, key_length=0, key=0x7f89783ff943 "") at /usr/src/debug/nettle-3.7.3-3.fc36.x86_64/hmac.c:83
+#3  0x00007f89783bce3a in wrap_x86_hmac_fast (algo=<optimized out>, nonce=<optimized out>, nonce_size=<optimized out>, key=0x7f89783ff943, 
+    key_size=0, text=0x7f8972ad9430, text_size=48, digest=0x55a79d80b948) at hmac-x86-ssse3.c:294
+#4  0x00007f89782d4b57 in _gnutls_mac_fast (algorithm=GNUTLS_MAC_SHA384, key=0x7f89783ff943, keylen=0, text=0x7f8972ad9430, textlen=48, 
+    digest=0x55a79d80b948) at hash_int.c:167
+#5  0x00007f89782f524d in gnutls_hmac_fast (algorithm=GNUTLS_MAC_SHA384, key=key@entry=0x7f89783ff943, keylen=keylen@entry=0, 
+    ptext=0x7f8972ad9430, ptext_len=ptext_len@entry=48, digest=digest@entry=0x55a79d80b948) at crypto-api.c:640
+#6  0x00007f897830d2ff in _tls13_init_secret2 (prf=0x7f897848f888 <hash_algorithms+168>, psk=<optimized out>, psk@entry=0x0, psk_size=48, 
+    psk_size@entry=0, out=out@entry=0x55a79d80b948) at secrets.c:59
+#7  0x00007f897830d3d0 in _tls13_init_secret (session=session@entry=0x55a79d80a1c0, psk=psk@entry=0x0, psk_size=psk_size@entry=0) at secrets.c:35
+#8  0x00007f89782c66c0 in read_server_hello (datalen=<optimized out>, data=<optimized out>, session=0x55a79d80a1c0) at handshake.c:2097
+#9  _gnutls_recv_handshake (session=session@entry=0x55a79d80a1c0, type=type@entry=GNUTLS_HANDSHAKE_SERVER_HELLO, optional=optional@entry=0, 
+    buf=buf@entry=0x0) at handshake.c:1656
+#10 0x00007f89782c8dbb in handshake_client (session=0x55a79d80a1c0) at handshake.c:3072
+#11 gnutls_handshake (session=0x55a79d80a1c0) at handshake.c:2871
+#12 0x00007f89784a694f in g_tls_connection_gnutls_handshake_thread_handshake (tls=0x55a79d80c250, timeout=<optimized out>, 
+    cancellable=<optimized out>, error=0x7f8972ad9b10) at ../tls/gnutls/gtlsconnection-gnutls.c:968
+#13 0x00007f89784a8942 in handshake_thread (task=0x7f8968007ec0, object=object@entry=0x55a79d80c250, task_data=task_data@entry=0x55a79d766e60, 
+    cancellable=cancellable@entry=0x55a79d748760) at ../tls/base/gtlsconnection-base.c:1564
+#14 0x00007f89784a8c02 in async_handshake_thread (task=<optimized out>, object=0x55a79d80c250, task_data=0x55a79d766e60, 
+    cancellable=0x55a79d748760) at ../tls/base/gtlsconnection-base.c:1848
+#15 0x00007f89882dbaf3 in g_task_thread_pool_thread (thread_data=0x7f8968007ec0, pool_data=<optimized out>) at ../gio/gtask.c:1441
+#16 0x00007f8988111b72 in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/gthreadpool.c:354
+#17 0x00007f898810f172 in g_thread_proxy (data=0x55a79d7e1360) at ../glib/gthread.c:827
+#18 0x00007f8987efdcc7 in start_thread (arg=<optimized out>) at pthread_create.c:442
+#19 0x00007f8987f82e00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+(gdb)
+(gdb) disassemble 
+Dump of assembler code for function sha512_block_data_order_avx2:
+   0x00007f89783cbe00 <+0>:    mov    %rsp,%rax
+   0x00007f89783cbe03 <+3>:    push   %rbx
+   0x00007f89783cbe04 <+4>:    push   %rbp
+   0x00007f89783cbe05 <+5>:    push   %r12
+   0x00007f89783cbe07 <+7>:    push   %r13
+   0x00007f89783cbe09 <+9>:    push   %r14
+   0x00007f89783cbe0b <+11>:    push   %r15
+   0x00007f89783cbe0d <+13>:    sub    $0x520,%rsp
+   0x00007f89783cbe14 <+20>:    shl    $0x4,%rdx
+   0x00007f89783cbe18 <+24>:    and    $0xfffffffffffff800,%rsp
+   0x00007f89783cbe1f <+31>:    lea    (%rsi,%rdx,8),%rdx
+   0x00007f89783cbe23 <+35>:    add    $0x480,%rsp
+   0x00007f89783cbe2a <+42>:    mov    %rdi,0x80(%rsp)
+   0x00007f89783cbe32 <+50>:    mov    %rsi,0x88(%rsp)
+   0x00007f89783cbe3a <+58>:    mov    %rdx,0x90(%rsp)
+   0x00007f89783cbe42 <+66>:    mov    %rax,0x98(%rsp)
+=> 0x00007f89783cbe4a <+74>:    vzeroupper 
+   0x00007f89783cbe4d <+77>:    sub    $0xffffffffffffff80,%rsi
+   0x00007f89783cbe51 <+81>:    mov    (%rdi),%rax
+   0x00007f89783cbe54 <+84>:    mov    %rsi,%r12
+   0x00007f89783cbe57 <+87>:    mov    0x8(%rdi),%rbx
+   0x00007f89783cbe5b <+91>:    cmp    %rdx,%rsi
+   0x00007f89783cbe5e <+94>:    mov    0x10(%rdi),%rcx
+   0x00007f89783cbe62 <+98>:    cmove  %rsp,%r12
+   0x00007f89783cbe66 <+102>:    mov    0x18(%rdi),%rdx
+   0x00007f89783cbe6a <+106>:    mov    0x20(%rdi),%r8
+   0x00007f89783cbe6e <+110>:    mov    0x28(%rdi),%r9
+   0x00007f89783cbe72 <+114>:    mov    0x30(%rdi),%r10
+   0x00007f89783cbe76 <+118>:    mov    0x38(%rdi),%r11
+   0x00007f89783cbe7a <+122>:    jmp    0x7f89783cbe80 <sha512_block_data_order_avx2+128>
+   0x00007f89783cbe7c <+124>:    nopl   0x0(%rax)
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1031 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1031
new file mode 100644
index 00000000..8b2c6e16
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1031
@@ -0,0 +1,42 @@
+Intel 12th Gen CPU not working with QEMU Hyper-V nested virtualization
+Description of problem:
+When booting with Hyper-V + host-passthrough it gets stuck at tianocore, does not change until I reboot which then loops into windows diagnostics which leads nowhere. Done using Windows 10, tried using newest windows version and 1909.
+
+Specs: Manjaro Gnome 5.15 LTS, i5-12600k, z690 gigabyte aorus elite ddr4, rtx 3070ti.
+
+I’ve spent days trying to figure out what was messing with it and it turned out I could boot when messing with my CPU topology, for some reason my 12th gen + Hyper-V + host-passthrough only works with sockets. Cores and threads above 1 causes boot problems, apart from disabling vme which boots, but the hypervisor does not load.
+
+This fails (normal host-passthrough):
+```
+  <cpu mode="host-passthrough" check="none" migratable="on">
+    <topology sockets="1" dies="1" cores="6" threads="2"/>
+  </cpu>
+```
+
+This boots (-can only change sockets):
+```
+  <cpu mode="host-passthrough" check="none" migratable="on">
+    <topology sockets="12" dies="1" cores="1" threads="1"/>
+  </cpu>
+```
+
+This boots (-no hypervisor):
+```
+<cpu mode="host-passthrough" check="partial" migratable="off">
+    <topology sockets="1" dies="1" cores="6" threads="2"/>
+    <feature policy="disable" name="vme"/>
+  </cpu>
+```
+
+No matter what adjustment I do I cannot change the cores or threads or it will result in a boot failure, host-model just does not work once I boot the machine the host model changes to cooperlake.
+
+My current way of bypassing this is I’ve downloaded the QEMU source code, gone through cpu.c and modified the default skylake-client CPU model to match my CPU, then I added in most of my i5-12600k flags manually, this seems to work with a 35-45% performance drop in CPU and in ram. Without Hyper-V enabled and using the normal host-passthrough I get near bare metal performance.
+
+Tried with multiple versions of QEMU, EDK2, and loads of kernel versions (to add to this my i5-12600k gen does not work on kernel version 5.13 and below) even went ahead to try Ubuntu and had the same problem, my other (i7-9700k) PC works fine with Hyper-V. Also disabled my E-cores through bios resulting in the same issue. CPU pinning the P-cores to the guest does not seem to help.
+Steps to reproduce:
+1. Enable hyper-v in windows features
+2. Restart guest
+3. Boot failure
+Additional information:
+Hyper-V host-passthrough XML:
+https://pst.klgrth.io/paste/yc5wk
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1043 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1043
new file mode 100644
index 00000000..cab6db26
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1043
@@ -0,0 +1,10 @@
+QEMU cpu max doesnot work on Windows 11 with ryzen processor and whpx
+Description of problem:
+- System does not boot.
+- WHPX: setting APIC emulation mode in the hypervisor
+- Windows Hypervisor Platform accelerator is operational
+- whpx: injection failed, MSI (0, 0) delivery: 0, dest_mode: 0, trigger mode: 0, vector: 0, lost (c0350005)
+- qemu: WHPX: Unexpected VP exit code 4
+Steps to reproduce:
+1. Windows 11 / Ryzen
+2. qemu-system-x86_64.exe --accel whpx --cpu max
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1137 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1137
new file mode 100644
index 00000000..401e7c5e
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/1137
@@ -0,0 +1,35 @@
+When using qemu-system-x86_64 whpx acceleration, cpu information is set strangely.
+Description of problem:
+When using the guest with whpx acceleration in qemu-system-x86_64, the CPU information of the guest seems to be set strangely.
+
+When the guest is Linux, it seems that individual CPUs are allocated as many as the number of cores when using the -accel whpx option and the -smp option.
+* -smp 4, -smp cores=4, -smp sockes=1, cores=4, threads=1 are all set to have 4 single-core CPUs plugged in
+
+If the guest is Windows, check the information with CPU-Z
+ It is recognized as a Pentium 4 and is displayed as a CPU with 1 core and n threads.
+
+Physically, it seems to be set to have n individual CPUs with 1 core plugged in.
+In Windows 11 Home (which seems to be the case for all versions of Windows Home), you cannot give the -smp value more than 5.
+* When booting with the -smp option value of 5 or more, a BSOD saying multiprocessor configuration not supported appears. -smp n, -smp cores=n, -smp sockes=1,cores=n,threads=1 All same symptoms occur
+Steps to reproduce:
+1. Boot Windows or Linux with -accel whpx -smp 4 option (or with the -accel whpx -smp sockets=1,cores=4,threads=1 option to make it deterministic)
+2. For Linux guest, use cat /proc/cpuinfo to check cpu information, for Windows guest, use cpu-z, device manager, task manager, etc. to check cpu information
+3. In the information of the Linux guest, it is displayed as fixed as core id : 0, cpu cores : 1, 
+   In Windows guest, information is displayed as written in "Description of problem" respectively.
+Additional information:
+**Windows 11 Home Guest set to 4 cores :**
+
+qemu-system-x86_64 -M q35 -smp sockets=1,cores=4,threads=1 -m 8g -device qxl-vga,vgamem_mb=256 -display sdl -drive file="Windows 11.vmdk",id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -rtc base=localtime -usbdevice tablet -accel whpx
+![Windows_Guest](/uploads/7b38889ff4ef20c935f724b0307766c9/Windows_Guest.jpg)
+
+
+**Windows 11 Home Guest set to 5 cores :**
+
+qemu-system-x86_64 -M q35 -smp sockets=1,cores=5,threads=1 -m 8g -device qxl-vga,vgamem_mb=256 -display sdl -drive file="Windows 11.vmdk",id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -rtc base=localtime -usbdevice tablet -accel whpx
+![BSOD](/uploads/910378cc73140831d9db5c58cb575bb8/BSOD.jpg)
+
+
+**Linux (Debian 11) guest set to 4 cores :**
+
+qemu-system-x86_64 -M q35 -smp sockets=1,cores=4,threads=1 -m 4g -device qxl-vga,vgamem_mb=256 -display sdl -drive file="debian.vdi",id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -rtc base=localtime -usbdevice tablet -accel whpx
+![Linux_Guest](/uploads/d1dbb2e38fcba57741c43f0f348297a2/Linux_Guest.jpg)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2063 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2063
new file mode 100644
index 00000000..a2413f2a
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2063
@@ -0,0 +1,55 @@
+Poor performance with -accel whpx on Server 2022 host, windows 10 guest - missing CPUID hypervisor ident data?
+Description of problem:
+**Performance of Windows 10 x64 QEMU virtual machine is essentially unusable, compared to same image running under Hyper-V on the same host system.**
+
+It appears the VM is not being provided the Hyper-V enlightenment hints while running under QEMU.  The hv-XXX cpu options do not appear applicable to -accel WHPX.
+
+Below are dumps of the 0x40000000 cpuid values on the host, QEMU guest, and Hyper-V guest (exact same .VHD file used, nested virtualization not enabled for this VM).
+
+host:
+- 0x40000000 eax=4000000c ebx=7263694d ecx=666f736f edx=76482074
+- 0x40000001 eax=31237648 ebx=0 ecx=0 edx=0
+- 0x40000002 eax=4f7c ebx=a0000 ecx=2 edx=85d
+- 0x40000003 eax=bfff ebx=2bb9ff ecx=22 edx=71fffbf6
+- 0x40000004 eax=50d1c ebx=fff ecx=0 edx=0
+- 0x40000005 eax=400 ebx=400 ecx=ba00 edx=0
+- 0x40000006 eax=1e00be ebx=0 ecx=0 edx=0
+- 0x40000007 eax=80000007 ebx=3 ecx=0 edx=0
+- 0x40000008 eax=100001 ebx=1 ecx=aaaa edx=0
+- 0x40000009 eax=0 ebx=0 ecx=0 edx=0
+- 0x4000000a eax=0 ebx=0 ecx=0 edx=0
+- 0x4000000b eax=0 ebx=0 ecx=0 edx=0
+- 0x4000000c eax=0 ebx=0 ecx=0 edx=0
+
+qemu guest with -accel whpx : 
+- 0x40000000 eax=40000010 ebx=0 ecx=0 edx=0
+- 0x40000001 eax=0 ebx=0 ecx=0 edx=0
+- 0x40000002 eax=0 ebx=0 ecx=0 edx=0
+- 0x40000003 eax=0 ebx=0 ecx=0 edx=0
+- 0x40000004 eax=0 ebx=0 ecx=0 edx=0
+- 0x40000005 eax=0 ebx=0 ecx=0 edx=0
+- 0x40000006 eax=0 ebx=0 ecx=0 edx=0
+- 0x40000007 eax=0 ebx=0 ecx=0 edx=0
+- 0x40000008 eax=0 ebx=0 ecx=0 edx=0
+- 0x40000009 eax=0 ebx=0 ecx=0 edx=0
+- 0x4000000a eax=0 ebx=0 ecx=0 edx=0
+- 0x4000000b eax=0 ebx=0 ecx=0 edx=0
+- 0x4000000c eax=0 ebx=0 ecx=0 edx=0
+- 0x4000000d eax=0 ebx=0 ecx=0 edx=0
+- 0x4000000e eax=0 ebx=0 ecx=0 edx=0
+- 0x4000000f eax=0 ebx=0 ecx=0 edx=0
+- 0x40000010 eax=225519 ebx=30d40 ecx=0 edx=0
+
+hyperv guest VM: (nested virtualization not enabled)
+- 0x40000000 eax=4000000b ebx=7263694d ecx=666f736f edx=76482074
+- 0x40000001 eax=31237648 ebx=0 ecx=0 edx=0
+- 0x40000002 eax=4f7c ebx=a0000 ecx=2 edx=85d
+- 0x40000003 eax=ae7f ebx=388030 ecx=22 edx=e0bed7b2
+- 0x40000004 eax=40c2c ebx=fff ecx=0 edx=0
+- 0x40000005 eax=f0 ebx=400 ecx=ba00 edx=0
+- 0x40000006 eax=e ebx=0 ecx=0 edx=0
+- 0x40000007 eax=0 ebx=0 ecx=0 edx=0
+- 0x40000008 eax=0 ebx=0 ecx=0 edx=0
+- 0x40000009 eax=0 ebx=0 ecx=0 edx=0
+- 0x4000000a eax=0 ebx=0 ecx=0 edx=0
+- 0x4000000b eax=0 ebx=0 ecx=0 edx=0
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2403 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2403
new file mode 100644
index 00000000..1c9951b3
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2403
@@ -0,0 +1,14 @@
+WHPX accelerator fails to boot guest Windows 7
+Description of problem:
+I get Qemu freezed on Starting Windows screen when trying to boot Windows 7 Professional
+Steps to reproduce:
+1. Run qemu with the above command line and until Starting Windows screen appears.
+2. See qemu freezed.
+Additional information:
+tcg accelerator works ok, though (Windows 7 successfully boots as expected on native hardware):
+
+- `qemu-system-x86_64.exe -accel tcg -cpu Westmere,aes=on,avx=on,sse4.1=on,sse4.2=on,ssse3=on,x2apic=on,xsave=on -m 4G -machine q35 -device qxl-vga,vgamem_mb=64 -hda Windows7_Disk.qcow2 -boot d -cdrom Windows7.iso`
+
+  This bug seems to have the same roots: https://gitlab.com/qemu-project/qemu/-/issues/1859
+
+  ![Capture.PNG](/uploads/f934e620a4b3c157fc34e8ff38470a0b/Capture.PNG){width=579 height=477}
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2782 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2782
new file mode 100644
index 00000000..0258cc6d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/2782
@@ -0,0 +1,10 @@
+WHPX won't enable x86_64v3 level instructions
+Description of problem:
+x86_64v3 support is not available inside guest
+Steps to reproduce:
+1. Boot the image
+2. Open terminal
+3. Run `/lib64/ld-linux-x86-64.so.2 --help` and check which levels are available in the output
+4. Or run `/lib64/ld-linux-x86-64.so.2 --list-diagnostics | grep isa` and check `isa_1` value (expected 7 for v3 (3 bits being set))
+Additional information:
+Due to this some Linux distribution, like Centos Stream 10, will not be able to boot with WHPX acceleration enabled.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/346 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/346
new file mode 100644
index 00000000..18661373
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/346
@@ -0,0 +1 @@
+Guest refuses to accept keyboard input when accelerated with WHPX
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/513 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/513
new file mode 100644
index 00000000..f5294499
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/513
@@ -0,0 +1 @@
+Qemu/WHPX fails on applying UEFI firmware with -pflash
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/934 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/934
new file mode 100644
index 00000000..edf23fb0
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/934
@@ -0,0 +1,45 @@
+VM execution fails for tianocore edk2 ovmf uefi based image on windows whpx
+Description of problem:
+Cannot do a UEFI tianocore boot of image with linux installation.
+
+I think the BIOS/UEFI/firmware when run inside a virtual-machine should be oblivious to the type of hypervisor, just probe and enable the emulated hardware. Maybe WHPX is not enabling pflash devices properly. 
+
+My goal is to create a 40Gb fedora linux image with a on-image UEFI boot sequence that I can 
+1. native boot using ventoy (works)
+2. boot using kvm/qemu in linux (works)
+3. boot using whpx/qemu in windows (no success yet)
+
+My original sequence of steps to reproduce was.
+1. Under Linux, in qemu-vm, create a bootable linux image by installing from the fedora livecd installer
+2. Confirm qemu-VM/fedora installation/UEFI boot works fine under Linux/kvm/qemu. One can see tianocore logo booting up.
+3. reboot to windows
+4. attempt to boot with analogous windows qemu command. confirm boot failure and error message
+5. remove ```-accel whpx``` and rerun, confirm boot succeeds with tianocore image, albeit un-accelarated
+
+It turns out the image creation is not required.
+
+The below works under linux
+```
+XDG_RUNTIME_DIR=/run/user/1000 qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot d -drive "index=0,if=pflash,format=raw,readonly=on,file=/usr/share/edk2/ovmf/OVMF_CODE.fd" -drive "index=1,if=pflash,format=raw,file=/vol/15KJ_Images/vstorage/OVMF_VARS.fd" -drive "index=2,format=raw,file=/vol/15KJ_Images/transcend/m02_lnx.raw.img.vtoy"  -device "virtio-vga-gl" -display "gtk,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" -qmp tcp:0:5955,server,nowait
+```
+The below does not work under windows
+```
+qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -smp "sockets=1,cores=8,threads=1" -boot d -drive "index=0,if=pflash,format=raw,readonly=on,file=C:/vol/scoop_01/scoopg/apps/qemu/current/share/edk2-x86_64-code.fd" -drive "index=1,if=pflash,format=raw,file=E:/vstorage/OVMF_VARS.fd" -drive "index=2,if=virtio,media=disk,format=raw,file=H:\m01_lnx.raw.img" -drive "index=3,if=virtio,media=disk,format=raw,file=H:\gkpics01.raw.img"  -drive "index=4,if=virtio,media=disk,format=vhdx,file=E:\test\sgdata.vhdx" -display gtk -vga virtio -rtc base=utc -netdev user,id=vmnic1,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15 -device virtio-net,netdev=vmnic1  -qmp "tcp:127.0.0.1:5955,server,nowait"
+:
+Windows Hypervisor Platform accelerator is operational
+qemu-system-x86_64: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2
+qemu-system-x86_64: WHPX: Failed to exec a virtual processor
+```
+
+The image does boot if one removes the hardware hypervisor argument ```-accel whpx```
+Steps to reproduce:
+The full qemu command with disk images is not required. Just the accel whpx and the pflash devices are sufficient.
+1. Confirm that the VM does not execute with the command
+```
+qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -boot c -drive "index=0,if=pflash,format=raw,readonly=on,file=C:/vol/scoop_01/scoopg/apps/qemu/current/share/edk2-x86_64-code.fd"
+```
+2. Confirm that the VM does execute and tianocore logo shoes up when ```-accel whpx ``` is removed.
+Additional information:
+- In the planned changes of Fedora 37, going forward, fedora installer will no longer support installing fresh to machines with legacy BIOS and will necessarily require UEFI boot. This means that there is urgency in allowing this mode of booting. 
+  - https://fedoraproject.org/wiki/Releases/37/ChangeSet
+  - https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_WHPX/977 b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/977
new file mode 100644
index 00000000..b973d197
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_WHPX/977
@@ -0,0 +1 @@
+QEMU 6.2, windows 98 doesn't shutdown properly
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_Xen/2294 b/gitlab/issues_text/target_i386/host_missing/accel_Xen/2294
new file mode 100644
index 00000000..c9b03fa5
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_Xen/2294
@@ -0,0 +1 @@
+x86 microvm machine stuck under Xen accelerator
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/101 b/gitlab/issues_text/target_i386/host_missing/accel_missing/101
new file mode 100644
index 00000000..f59324b3
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/101
@@ -0,0 +1 @@
+Running a virtual machine on a Haswell system produces machine check events
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1017 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1017
new file mode 100644
index 00000000..f940a63b
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1017
@@ -0,0 +1,13 @@
+Qemu Windows 10 restart bluescreen
+Description of problem:
+after shutting down qemu VM box and open some system programs on Host System, getting Bluescreen
+with following issue - Memory Manangement or shutting down you Host system, getting bluescreen.
+Only after stoppingh using qemu vm reboot system.
+Steps to reproduce:
+1. start qemu vm, ty get some operations
+1. then stop the qemu vm via console comands
+1. rebooting or restarting Host system
+1. by shutting down, you get Bluescreen
+2.
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1035 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1035
new file mode 100644
index 00000000..99ea0ac1
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1035
@@ -0,0 +1,16 @@
+Hyper-V on KVM does not work on AMD CPUs
+Description of problem:
+Can not enable hytper-v on KVM on AMD 3970x
+```
+[ 3743.647780] SVM: kvm [17094]: vcpu0, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+[ 3744.014046] SVM: kvm [17094]: vcpu1, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+[ 3744.016101] SVM: kvm [17094]: vcpu2, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+[ 3744.018011] SVM: kvm [17094]: vcpu3, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+[ 3744.020032] SVM: kvm [17094]: vcpu4, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+[ 3744.021834] SVM: kvm [17094]: vcpu5, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+[ 3744.023644] SVM: kvm [17094]: vcpu6, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+[ 3744.025478] SVM: kvm [17094]: vcpu7, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+```
+Additional information:
+Related issue:
+https://bugzilla.kernel.org/show_bug.cgi?id=203477
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1040 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1040
new file mode 100644
index 00000000..2b5b836e
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1040
@@ -0,0 +1,6 @@
+Windows Server 2016 VM totally freezes spontaneously during the day a couple of times for 1-5 minutes. There is no any logs in it during the freeze
+Description of problem:
+Windows Server 2016 VM totally freezes spontaneously during the day a couple of times for 1-5 minutes. There is no any logs inside VM during the freeze. Timestamp of the last log written into journal is right before the freeze and the pretty next log is right after the freeze is gone. Looks like "black hole". No ping from from the host toward the VM. There is no way to connect to the VM even via spice on virt-manager as well. Seems like the VM is suspending. Htop on the host during the time of the freeze shows 100% load of all eight cores dedicated to the VM. But the host system is available and reachable, the lxc's inside this host is available and reachable as well.
+
+
+![12h_12m_59s_17_Mar_22__1_](/uploads/8874ad0220751fa253f8794c2eb6c2d5/12h_12m_59s_17_Mar_22__1_.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1041 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1041
new file mode 100644
index 00000000..5bfaba61
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1041
@@ -0,0 +1,31 @@
+x86_64 Auxillary vector reports platform as i686 which doesn't match the linux kernel
+Description of problem:
+Based on the kernel source in the auxiliary vector AT_PLATFORM should be `x86_64` (confirmed by running outside qemu). However qemu sets it to `i686`.
+
+This was originally reported with docker-for-mac, but was reduced on `x86_64` which is why it is pointless
+Steps to reproduce:
+1. Compile the following for x86_64 (statically if you don't want have an x86_64 dynamic linker) (code originally from https://stackoverflow.com/questions/26520163/accessing-auxiliary-vectors-c)
+
+```
+#include <stdio.h>
+#include <elf.h>
+
+int main(int argc, char** argv, char* envp[]) {
+  Elf64_auxv_t *auxv;
+  while(*envp++ != NULL);
+
+  /*from stack diagram above: *envp = NULL marks end of envp*/
+  int i = 0 ;
+  for (auxv = (Elf64_auxv_t *)envp; auxv->a_type != AT_NULL; auxv++)
+    /* auxv->a_type = AT_NULL marks the end of auxv */
+  {
+    if( auxv->a_type == AT_PLATFORM)
+      printf("AT_PLATFORM is: %s\n", ((char*)auxv->a_un.a_val));
+  }
+}
+```
+2. Run with `qemu-x86_64-static`
+3. See `AT_PLATFORM is: i686`
+4. Compare to "real" x86_64 bit system which gives `AT_PLATFORM is: x86_64`
+Additional information:
+I think that adding `#define ELF_PLATFORM "x86_64"` [here](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c#L134) should work (but I don't fully understand the code). Otherwise we just end up getting the 32-bit case.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1042 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1042
new file mode 100644
index 00000000..8e340bf0
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1042
@@ -0,0 +1,20 @@
+windows 10 guest freezes the host on shutdown
+Description of problem:
+Windows 10 guest sometimes freezes the QEMU host when shutting down.
+
+There has been a bug reported about this in the past here:
+https://bugs.launchpad.net/qemu/+bug/1580459
+
+I am also using PCI Passthrough with an NVIDIA GPU.
+Some users have claimed to have fixed this issue by enabling Message Signaled-based Interrupts-mode on the PCI Devices the (GPU/HDMI-AUDIO). I have have these enabled and confirmed they are enabled, but the issue still persists.
+
+This bug has been effecting me for over a year, I just never bothered to look deeper into it after I seen the issue still persists after enabling the MSI stuff.
+
+There is something I noticed about this issue. Basically, it appears that I can mostly avoid the issue entirely, by making sure that as the guest is shutting down, that I move the mouse a bit.
+The host almost never freezes if I do this, and only happens very rarely.
+But if I start a shutdown, and just don't move the mouse at all, it is very likely the host will lock up, requiring a complete reboot. I am pretty sure the mouse movement, should be a big clue, because I can consistently reproduce the issue. The issue itself does not (atleast) for me appear to be tied to how long the VM is running or if gaming on it or not, though I have not thoroughly tested this.
+
+I have gone through various kernel/qemu/libvirt updates, the issue occurs in all of them, and has been an issue from the very beginning of my setup.
+Steps to reproduce:
+1. Start Windows 10 guest.
+2. Shutdown Windows 10 guest
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1047 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1047
new file mode 100644
index 00000000..5e5d377c
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1047
@@ -0,0 +1,104 @@
+Single stepping Windows 10 bootloader results in Assertion `ret < cpu->num_ases && ret >= 0' failed.
+Description of problem:
+When I am trying to debug Windows bootloader, I see an assertion error in QEMU when single stepping some instructions in SeaBIOS.
+
+```
+qemu-system-i386: ../hw/core/cpu-sysemu.c:77: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed.                                        
+```
+Steps to reproduce:
+1. Download / construct `w.img`, see above
+2. Start QEMU using `./qemu-system-i386 --drive media=disk,file=w.img,format=raw,index=1 -s -S -enable-kvm`
+3. Start GDB using `gdb --ex 'target remote :::1234' --ex 'hb *0x7c00' --ex c --ex 'si 1000' --ex q`
+4. See error message
+Additional information:
+The GDB script first breaks at 0x7c00, then tries to execute 1000 instructions using single step (`si`). On my machine, after executing around 772 instructions, the assertion error in QEMU happens. 
+Here is an interactive GDB session on my machine. 
+
+```
+(gdb) hb *0x7c00
+Hardware assisted breakpoint 1 at 0x7c00
+(gdb) c
+Continuing.
+
+Breakpoint 1, 0x00007c00 in ?? ()
+(gdb) d
+Delete all breakpoints? (y or n) y
+(gdb) si 770
+0x000f7d7b in ?? ()
+(gdb) x/10i $eip
+=> 0xf7d7b:	mov    $0x7d85,%ebx
+   0xf7d80:	out    %al,$0xb2
+   0xf7d82:	pause  
+   0xf7d84:	hlt    
+   0xf7d85:	mov    %bp,%sp
+   0xf7d88:	jmp    0xf7dd1
+   0xf7d8a:	mov    %cx,%si
+   0xf7d8d:	mov    $0x1,%ax
+   0xf7d91:	add    %al,(%eax)
+   0xf7d93:	callw  0x6b66
+(gdb) si
+0x000f7d80 in ?? ()
+(gdb) info reg
+eax            0xb5                181
+ecx            0x5678              22136
+edx            0x0                 0
+ebx            0x7d85              32133
+esp            0xe96d4             0xe96d4
+ebp            0xfed4              0xfed4
+esi            0xe0346             918342
+edi            0xefd91             982417
+eip            0xf7d80             0xf7d80
+eflags         0x6                 [ IOPL=0 PF ]
+cs             0x8                 8
+ss             0x10                16
+ds             0x10                16
+es             0x10                16
+fs             0x10                16
+gs             0x10                16
+fs_base        0x0                 0
+gs_base        0x0                 0
+k_gs_base      0x0                 0
+cr0            0x11                [ ET PE ]
+cr2            0x0                 0
+cr3            0x0                 [ PDBR=0 PCID=0 ]
+cr4            0x0                 [ ]
+cr8            0x0                 0
+efer           0x0                 [ ]
+...
+mxcsr          0x1f80              [ IM DM ZM OM UM PM ]
+(gdb) si
+0x000f7d82 in ?? ()
+(gdb) info reg
+eax            0xb5                181
+ecx            0x5678              22136
+edx            0x0                 0
+ebx            0x7d85              32133
+esp            0xe96d4             0xe96d4
+ebp            0xfed4              0xfed4
+esi            0xe0346             918342
+edi            0xefd91             982417
+eip            0xf7d82             0xf7d82
+eflags         0x6                 [ IOPL=0 PF ]
+cs             0x8                 8
+ss             0x10                16
+ds             0x10                16
+es             0x10                16
+fs             0x10                16
+gs             0x10                16
+fs_base        0x0                 0
+gs_base        0x0                 0
+k_gs_base      0x0                 0
+cr0            0x11                [ ET PE ]
+cr2            0x0                 0
+cr3            0x0                 [ PDBR=0 PCID=0 ]
+cr4            0x0                 [ ]
+cr8            0x0                 0
+efer           0x0                 [ ]
+...
+mxcsr          0x1f80              [ IM DM ZM OM UM PM ]
+(gdb) si
+Remote connection closed
+(gdb) 
+```
+
+This bug was first incorrectly filed in KVM's bug tracker at <https://bugzilla.kernel.org/show_bug.cgi?id=216003>.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1098 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1098
new file mode 100644
index 00000000..11a08083
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1098
@@ -0,0 +1,11 @@
+make check failed at bios-tables-test
+Description of problem:
+run unit test "make check", failed at
+3/177 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test       ERROR           6.59s   killed by signal 6 SIGABRT
+Steps to reproduce:
+1. ./configure --target-list=x86_64-softmmu --disable-xen --enable-sdl --enable-docs --disable-capstone
+2. make -j check V=1
+Additional information:
+Looks like DSDT construction code has been changed but hasn't updated bios-table-test binaries.
+
+See attached diff file.[make_check_failure_dsdt_asl.diff](/uploads/9ed82fbb081863d8991fb0ea72446365/make_check_failure_dsdt_asl.diff)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1115 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1115
new file mode 100644
index 00000000..1d6a89e9
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1115
@@ -0,0 +1,14 @@
+qemu 7.0.0 stuck at Windows boot logo with SeaBios and MBR disk
+Description of problem:
+When trying to boot an MBR Windows guest with SeaBios, it is stuck at the blue Windows boot logo, before the loading circle.
+Changing the vGPU doesn't help, 0% cpu load just frozen. Even if I boot a WinPE iso, the same happens.
+Even after 30 minutes, the same.
+Rebooted host multiple times.
+Since SeaBios is the default in qemu and virt-manager I imagine many VMs are installed as MBR and thus will be stuck.
+To boot the VM I have to:
+- switch to UEFI (TianoCore)
+- boot WinPE iso
+- use proprietary software to convert the Windows disk from MBR to GPT
+Then it boots just fine but I imagine not many users will be able to do this.
+Steps to reproduce:
+1. boot Windows image / WinPE iso with SeaBios
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1131 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1131
new file mode 100644
index 00000000..20c2a8d8
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1131
@@ -0,0 +1,20 @@
+Multiboot: could not move values from provided mmap to another address directly.
+Description of problem:
+When using `-kernel` to load a Multiboot file which requires a memory map(MULTIBOOT_MEMORY_INFO flag) and trying to move the values in the provided mmap entries to another address directly, QEMU reboots.
+```c
+xxx = mmap->addr;
+```
+
+When moving with volatile, everything works well:
+```c
+volatile unsigned long long addr = mmap->addr;
+xxx = addr;
+```
+Steps to reproduce:
+1. Source code here: [github/xtexChooser/toop/boot/multiboot/src/multiboot.c](https://github.com/xtexChooser/toop/blob/51153319d4f2320ae9a9277ffffad3f67a335fe9/boot/multiboot/src/multiboot.c#L32)
+2. Minimized reproduce: [gist.github.com/xtexChooser/22017d662c8144b7abcb0b18c2afb09c](https://gist.github.com/xtexChooser/22017d662c8144b7abcb0b18c2afb09c)
+3. I am sure that 0x00001210 is writable, it is empty in the memory map and QEMU works correctly when writing a zero value to here.
+4. The reproducer is available without any module, when it works, it should keep running without any output, if QEMU reboots, the screen should flash as it clears and prints the BIOS information again.
+5. If move with volatile(as the `multiboot_works.c` in reproducer), the reproducer works correctly.
+Additional information:
+#
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1135 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1135
new file mode 100644
index 00000000..0f5ea8bf
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1135
@@ -0,0 +1,12 @@
+Multiboot: invalid multiboot information block
+Description of problem:
+Breakpoint at 0x85d4, this is the entrypoint of this Multiboot loader.
+According to the Multiboot specification, the EAX register should be a pointer to the Multiboot information block. When I am testing, it is 0x9500. However, when dumping the memory using `dump binary memory`, nearby memory areas are all zeros.
+
+When dumping some bigger memory aeras, I found that the module hasbeen loaded to the memory successfully, altough MBI was broken.
+Steps to reproduce:
+
+Additional information:
+multiboot: [multiboot](/uploads/55fdfcf30ada0af2d00badf11fcd308c/multiboot)
+
+toop: [toop](/uploads/de3b63ae021303c544105ba1498f3373/toop)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/116 b/gitlab/issues_text/target_i386/host_missing/accel_missing/116
new file mode 100644
index 00000000..a3b03881
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/116
@@ -0,0 +1 @@
+qemu fails under NeXTStep 3.3 when accessing ROM in SCSI-Adapter am53c974
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1164 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1164
new file mode 100644
index 00000000..d79ec648
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1164
@@ -0,0 +1,17 @@
+q35: incorrect values for PCIEXBAR masks
+Description of problem:
+https://lore.kernel.org/all/1fded151ce5ecbf7010427871b908000b2aba9ee.1520867956.git.x1917x@gmail.com/
+
+In function [mch_update_pciexbar](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/pci-host/q35.c#L295)
+
+There are two small issues in PCIEXBAR address mask handling:
+- wrong bit positions for address mask bits (see PCIEXBAR description
+  in Q35 datasheet)
+- incorrect usage of 64ADR_MASK
+
+Due to this, attempting to write a valid PCIEXBAR address may cause it to
+shift to another address, causing memory layout corruption where emulated
+MMIO regions may overlap real (passed through) MMIO ranges. Fix this
+by providing correct values.
+Additional information:
+Q35 datasheet: https://www.intel.com/Assets/PDF/datasheet/316966.pdf  ( 5.1.16 PCIEXBAR—PCI Express* Register Range Base Address )
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1267 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1267
new file mode 100644
index 00000000..d41e9792
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1267
@@ -0,0 +1,93 @@
+qemu-i386 missing VDSO
+Description of problem:
+Qemu crashes with a segmentation fault when running any binary using qemu-i386. Steps to reproduce are trivial, simply run `qemu-user ./test`. The file is here: [test](/uploads/fe0d498713e79d7e39f417e69ad64c2f/test). Basically any binary compiled with `GOARCH=386` using [TinyGo](https://tinygo.org/) should reproduce this issue.
+I also tried some trivial Go compiled binary and they also crash, but this time with an internal Go error that suggests something is terribly broken over there too: `fatal error: mallocgc called without a P or outside bootstrapping`
+
+Interestingly, qemu-x86_64 and qemu-arm appear to work just fine.
+
+Unfortunately I couldn't get a good backtrace on newer versions. It looks like this in the git version, which I doubt is correct:
+
+```
+~/src/qemu/build$ /bin/lldb ./qemu-i386
+(lldb) target create "./qemu-i386"
+Current executable set to '/home/ayke/src/qemu/build/qemu-i386' (aarch64).
+(lldb) run /home/ayke/src/tinygo/tinygo/test
+Process 97986 launched: '/home/ayke/src/qemu/build/qemu-i386' (aarch64)
+Process 97986 stopped
+* thread #1, name = 'qemu-i386', stop reason = unknown crash reason
+    frame #0: 0x0000fffff78fb9fc libc.so.6`__sigsuspend + 92
+libc.so.6`__sigsuspend:
+->  0xfffff78fb9fc <+92>:  svc    #0
+    0xfffff78fba00 <+96>:  cmn    x0, #0x1, lsl #12         ; =0x1000 
+    0xfffff78fba04 <+100>: b.hi   0xfffff78fba3c            ; <+156>
+    0xfffff78fba08 <+104>: mov    w19, w0
+(lldb) bt
+* thread #1, name = 'qemu-i386', stop reason = unknown crash reason
+  * frame #0: 0x0000fffff78fb9fc libc.so.6`__sigsuspend + 92
+    frame #1: 0x0000aaaaaabfcedc qemu-i386`dump_core_and_abort(target_sig=11) at signal.c:745:5
+    frame #2: 0x0000aaaaaabfc128 qemu-i386`handle_pending_signal(cpu_env=0x0000aaaaaae5d2e0, sig=11, k=0x0000aaaaaae68af8) at signal.c:1061:13
+    frame #3: 0x0000aaaaaabfbe48 qemu-i386`process_pending_signals(cpu_env=0x0000aaaaaae5d2e0) at signal.c:1141:13
+    frame #4: 0x0000aaaaaaae5a04 qemu-i386`cpu_loop(env=0x0000aaaaaae5d2e0) at cpu_loop.c:315:9
+    frame #5: 0x0000aaaaaabf5e7c qemu-i386`main(argc=2, argv=0x0000ffffffffecd8, envp=0x0000ffffffffecf0) at main.c:925:5
+    frame #6: 0x0000fffff78e7b80 libc.so.6`___lldb_unnamed_symbol2945 + 112
+    frame #7: 0x0000fffff78e7c60 libc.so.6`__libc_start_main + 160
+    frame #8: 0x0000aaaaaaae0430 qemu-i386`_start at start.S:81
+(lldb) ^D
+```
+
+I got a better (but still not great) backtrace in Qemu 7.0.0:
+
+```
+~/src/tinygo/tinygo$ /bin/lldb qemu-i386
+(lldb) target create "qemu-i386"
+Current executable set to 'qemu-i386' (aarch64).
+(lldb) run test
+Process 98106 launched: '/usr/bin/qemu-i386' (aarch64)
+Process 98106 stopped
+* thread #1, name = 'qemu-i386', stop reason = signal SIGSEGV: address access protected (fault address: 0x8000)
+    frame #0: 0x0000aaaaaac4b564 qemu-i386`cpu_ldub_code + 32
+qemu-i386`cpu_ldub_code:
+->  0xaaaaaac4b564 <+32>: ldrb   w0, [x0, w1, uxtw]
+    0xaaaaaac4b568 <+36>: str    xzr, [x2]
+    0xaaaaaac4b56c <+40>: ret    
+
+qemu-i386`cpu_lduw_code:
+    0xaaaaaac4b570 <+0>:  mrs    x2, TPIDR_EL0
+(lldb) bt
+* thread #1, name = 'qemu-i386', stop reason = signal SIGSEGV: address access protected (fault address: 0x8000)
+  * frame #0: 0x0000aaaaaac4b564 qemu-i386`cpu_ldub_code + 32
+    frame #1: 0x0000aaaaaac4a4a8 qemu-i386`translator_ldub_swap + 72
+    frame #2: 0x0000aaaaaabe6714 qemu-i386`___lldb_unnamed_symbol6310 + 144
+    frame #3: 0x0000aaaaaabed2e8 qemu-i386`___lldb_unnamed_symbol6311 + 24
+    frame #4: 0x0000aaaaaac4a040 qemu-i386`translator_loop + 400
+    frame #5: 0x0000aaaaaabed5a8 qemu-i386`gen_intermediate_code + 72
+    frame #6: 0x0000aaaaaac486ec qemu-i386`tb_gen_code + 364
+    frame #7: 0x0000aaaaaac43068 qemu-i386`cpu_exec + 1480
+    frame #8: 0x0000aaaaaabaa4b0 qemu-i386`cpu_loop + 208
+    frame #9: 0x0000aaaaaab8cb54 qemu-i386`main + 2020
+    frame #10: 0x0000fffff7687b80 libc.so.6`___lldb_unnamed_symbol2945 + 112
+    frame #11: 0x0000fffff7687c60 libc.so.6`__libc_start_main + 160
+    frame #12: 0x0000aaaaaab8d3b0 qemu-i386`_start + 48
+(lldb) ^D
+```
+
+And an even better backtrace for an even older version (5.2.0). Though I should note that this GDB also had an assertion failue, but the backtrace looks reasonable:
+
+```
+#0  0x0000aaaaaaba7804 in cpu_ldub_code (env=env@entry=0x0, ptr=0) at ../../accel/tcg/user-exec.c:1170
+#1  0x0000aaaaaab40d04 in translator_ldub_swap (do_swap=false, pc=<optimized out>, env=<optimized out>) at ./include/exec/translator.h:176
+#2  translator_ldub (pc=<optimized out>, env=<optimized out>) at ./include/exec/translator.h:176
+#3  x86_ldub_code (env=env@entry=0xaaaaaad809f0, s=s@entry=0xffffffffe990) at ../../target/i386/translate.c:1916
+#4  0x0000aaaaaab51670 in disas_insn (s=s@entry=0xffffffffe990, cpu=<optimized out>, cpu=<optimized out>) at ../../target/i386/translate.c:4506
+#5  0x0000aaaaaab5e1c8 in i386_tr_translate_insn (dcbase=0xffffffffe990, cpu=<optimized out>) at ../../target/i386/translate.c:8569
+#6  0x0000aaaaaabbc9f4 in translator_loop (ops=0xaaaaaacd62b0 <i386_tr_ops>, db=0xffffffffe990, cpu=0xaaaaaad786a0, tb=<optimized out>, max_insns=<optimized out>)
+    at ../../accel/tcg/translator.c:103
+#7  0x0000aaaaaab5e470 in gen_intermediate_code (cpu=cpu@entry=0xaaaaaad786a0, tb=tb@entry=0xffffe8007f00, max_insns=max_insns@entry=512)
+    at ../../target/i386/translate.c:8631
+#8  0x0000aaaaaabcd54c in tb_gen_code (cpu=cpu@entry=0xaaaaaad786a0, pc=pc@entry=0, cs_base=cs_base@entry=0, flags=flags@entry=4194483, cflags=-16777216, 
+    cflags@entry=0) at ../../accel/tcg/translate-all.c:1744
+#9  0x0000aaaaaabbe2a8 in tb_find (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0xaaaaaad786a0) at ../../accel/tcg/cpu-exec.c:414
+#10 cpu_exec (cpu=cpu@entry=0xaaaaaad786a0) at ../../accel/tcg/cpu-exec.c:770
+#11 0x0000aaaaaab3a438 in cpu_loop (env=env@entry=0xaaaaaad809f0) at ../../linux-user/i386/cpu_loop.c:207
+#12 0x0000aaaaaab1df00 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../linux-user/main.c:882
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1279 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1279
new file mode 100644
index 00000000..b0e4ebba
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1279
@@ -0,0 +1,8 @@
+please assist resolving windows networking issue
+Description of problem:
+After Installation of Windows, for Intel E1000 , Realtek and VirtIO, Windows shows "Error Code 56: Windows is Still Setting Up the Class Configuration For This Device" in device manager and Network won't work
+Steps to reproduce:
+Install Windows 10 VM on Proxmox 7.2 with virtual hardware Version 6.1
+You get the error code above.  When using virtio  nic , during installation of the kvm-qemu-virtio driver/agent package, the installer get's stuck and finally fails.
+
+If you downgrade to virtual hardware 5.1 , the problem goes away.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1298 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1298
new file mode 100644
index 00000000..05e2204b
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1298
@@ -0,0 +1,15 @@
+virtio-pmem not working on microvm: virtio-pmem missing request data
+Description of problem:
+When using micorvm, qemu does not "connect" the memory backend mem1 with the pmem device. 
+
+When using the first command is executed, qemu shows the following starts message:
+```
+qemu-system-x86_64: virtio-pmem missing request data 
+```
+
+and the kernel outputs following messages:
+```
+[    0.043871] nd_pmem namespace0.0: could not reserve region [mem 0x00000000-0x001fffff]
+[    0.043923] IPI shorthand broadcast: enabled
+[    0.044022] nd_pmem: probe of namespace0.0 failed with error -16
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1323 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1323
new file mode 100644
index 00000000..0c39c619
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1323
@@ -0,0 +1,17 @@
+qemu-system-x86_64: keyboard not available in cd boot menu
+Description of problem:
+While CD boot menu is shown, no keys input affects the CD boot menu
+Steps to reproduce:
+1. Execute qemu-system-x86_64 -m 1536 -cdrom openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso
+2. Wait for boot menu
+3. Try to choose entry
+Additional information:
+Also occurs with other ISOs
+
+   ```
+   qemu-system-x86_64 -m 1536 -cdrom debian-10.8.0-amd64-netinst.iso
+   ```
+
+Does not occur with provided edk2 firmware
+
+Does not occur with QEMU emulator version 7.1.0
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1328 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1328
new file mode 100644
index 00000000..5abaee71
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1328
@@ -0,0 +1,9 @@
+Cannot boot any UEFI systems after upgrade edk2-ovmf
+Description of problem:
+After upgrading edk2-ovmf from version 202208-1 to version 202208-3 none of my virtual machines on UEFI (windows and Arch linuw guest) have successfully started.
+
+I'm using Virtual Manager and virt-viewer with virsh.
+Steps to reproduce:
+1. Update edk2-ovmf to 202208-3
+2. Restart all running VM
+3. Vm with UEFI bios cannot boot
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1348 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1348
new file mode 100644
index 00000000..8d266640
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1348
@@ -0,0 +1 @@
+WIN10 MBR/SeaBIOS/CSM machine hangs at boot (same as  #1115  https://gitlab.com/qemu-project/qemu/-/issues/1115 )
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1368 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1368
new file mode 100644
index 00000000..6cfb54eb
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1368
@@ -0,0 +1,38 @@
+unexpect rax value
+Description of problem:
+- When I execute "mov -0x8(%rbp), %rax" and "movq 0xb8000, (%rax)", the value of rax should be 0x7fedf but it is 0x7fefe. It is 1 less.
+Steps to reproduce:
+- 1. Code currently executed
+<pre>
+(gdb) x/2i $pc
+=> 0x2202 <vga_init+12>:	mov    -0x8(%rbp),%rax
+   0x2206 <vga_init+16>:	movq   $0xb8000,(%rax)
+</pre>
+- 2. Value of memory address -0x8(%rbp)
+<pre>
+(gdb) x /xg $rbp-0x8
+0x7fec8:	0x000000000007fedf
+</pre>
+- 3. Value of rax before execution
+<pre>
+(gdb) p /x $rax
+$1 = 0xfffffffd
+</pre>
+- 4. Value of rax after execution
+<pre>
+(gdb) p /x $rax
+$1 = 0x7fedf
+</pre>
+It's all right so far.
+- 5. View the current execution code again
+<pre>
+(gdb) x/i $pc
+=> 0x2207 <vga_init+17>:	movl   $0xb8000,(%rax)
+</pre>
+the code address changed from 0x2206 to 0x2207 and the code changed from "movq xx, xx" to "movl xx, xx".<br>
+Now rax is 0x7fedf.
+- 6. After execution<br>
+After executing "movl   $0xb8000,(%rax)"<br>
+The rax change to 0x7fede
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1382 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1382
new file mode 100644
index 00000000..3d939e68
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1382
@@ -0,0 +1,40 @@
+x86-64 In long mode the Selector Error Code has an improperly encoded Selector Index when dealing with IDT descriptor indexes
+Description of problem:
+When in long mode an IDT descriptor is 16 bytes in size. When an exception is raised where an index to an IDT descriptor entry needs to be encoded in an error code's selector index field it appears that QEMU's software emulation improperly encodes the IDT descriptor index as if each entry is 8 bytes rather than 16. The effect is that the descriptor index is encoded with a value that is double what it should be.
+  
+As an example if I have a *Segment Not Present* (#NP) exception handler (which has a selector error code pushed on the stack) that is raised when I try to generate a software interrupt 0x97 that is marked not present in its IDT descriptor entry - I expect that QEMU would properly encode the value 0x97 in the Selector Index of the Selector Error Code pushed on the stack. Instead, the value stored is actually 0x12E. 0x12E is double the expected value 0x97.
+
+You can observe this errant value in the output of QEMU when using the `-d int` option. I have cut out the unnecessary state information as I'm focussed on the `v=` and `e=`.
+
+     0: v=97 e=0000 i=1 cpl=0 IP=0008:0000000000008a0a pc=0000000000008a0a SP=0010:0000000000007c00      
+     1: v=0b e=0972 i=0 cpl=0 IP=0008:0000000000008a0a pc=0000000000008a0a SP=0010:0000000000007c00 
+
+When I used `int 0x97` to generate the software interrupt it properly shows that `v=97` had occurred in the output above. Because 0x97 was marked not present exception 0x0b (Not Present) was raised as you can see in the second line. The problem is that `e=0972` is a Selector Error Code where *Bits 3..16* contain the value 0x12E instead of 0x97. **It isn't just the display value in QEMU's debug output that is wrong**, as the **Selector Error Code pushed on the interrupt stack is the same erroneous value**. 
+
+This issue doesn't occur if you run QEMU with the `-enable-kvm` option; in BOCHS; or on real hardware. The value in those environments contains a Selector Error Code of 0x4ba. *Bits 3..16* of 0x4ba contains the descriptor index 0x97 as expected. See additional information for more details.
+Steps to reproduce:
+1. Put processor in long mode. 64-bit mode will suffice.
+2. Load an IDT with:
+   - A valid Segment Not Present (#NP) 0x0B Exception Handler. Handler doesn't really need to do anything.
+   - At least one interrupt handler marked *Not Present* higher than 0x00. Interrupt 0x97 as an example.
+3. Raise the interrupt with something like `int 0x097` for this example.
+Additional information:
+In order to test this problem out in other environments like real hardware and virtual machines I wrote a test program on a floppy disk image that can be run on machines and virtual machines that support legacy boot from floppy media (or emulated floppy media). The test program code can be found [in my Github repository](https://github.com/mpetch/SelectorErrorCodeTest). A pre-built [disk image](https://github.com/mpetch/SelectorErrorCodeTest/blob/main/disk.img) is also available.
+
+When the disk image is executed with QEMU using `qemu-system-x86_64 -fda disk.img` the result (with incorrect encoding) can be seen here:
+
+![image](/uploads/02c99f4915956c02c387ba27df693a62/image.png)
+
+When QEMU is run with `qemu-system-x86_64 -fda disk.img -enable-kvm` the result (with correct encoding) can be seen here:
+
+![image](/uploads/9ce7c10fef355e71ac2fdf0e3cb5c80e/image.png)
+
+Correct results are also obtained in BOCHS and real hardware.
+
+---
+The [Intel Software Development Manual Volume 3A](https://www.intel.ca/content/www/ca/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html) documents the error code as:
+
+![image](/uploads/a469d4b3d649e1e20a4b1993d73df05c/image.png)
+
+---
+#
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1383 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1383
new file mode 100644
index 00000000..878b39f9
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1383
@@ -0,0 +1 @@
+Pentium Pro cpuid capabilities are wrong, resulting in wrong definition of athlon and others
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1396 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1396
new file mode 100644
index 00000000..183da3fe
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1396
@@ -0,0 +1,3 @@
+Is it possible to emulate QEMU 64 Bit on Windows?
+Description of problem:
+Is it possible to emulate 64 Bit OS on Windows QEMU version? I'm trying to emulate ESXi image but the ESXi says it can only start 32 bit VM's. When I try to start a 64 bit VM from the ESXi I get the error `Task failed on server: Module 'CPUID' power on failed. `.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/141 b/gitlab/issues_text/target_i386/host_missing/accel_missing/141
new file mode 100644
index 00000000..eedc308c
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/141
@@ -0,0 +1 @@
+qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1410 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1410
new file mode 100644
index 00000000..c6446b02
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1410
@@ -0,0 +1,14 @@
+system_powerdown only works once
+Description of problem:
+When the guest is configured to sleep on power button events, something in the ACPI states are not restored coming out of resume.  The first call to `system_powerdown` succeeds, but the second after waking the system is rejected in `acpi_pm1_evt_power_down()` since `ar->pm1.evt.en` is zero coming out of the resume path.
+
+There is probably something deeper (or perhaps in seabios?) since removing the test in that handler doesn't cause a second sleep either.
+Steps to reproduce:
+![image](/uploads/60876bde4027c42699f2edf936bd874d/image.png)
+1. Boot a guest configured to sleep when it receives a power button event
+2. `system_powerdown` from the monitor to tell it to sleep
+3. `info status` to verify that it is suspended
+4. Wake the guest, either with `system_wakeup` or moving the mouse or something
+5. `system_powerdown` has no effect
+Additional information:
+This is using qemu-7.2.0 built from source with a Windows 10 guest and IGD GPU+audio passthrough.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1437 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1437
new file mode 100644
index 00000000..c0295927
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1437
@@ -0,0 +1,6 @@
+Nitrux doesn't finish boot process
+Description of problem:
+Boot process doesn't finish
+![imagen](/uploads/787a61359bb79ba644a7d99bf021680e/imagen.png)
+Steps to reproduce:
+1.Load Nitrux ISO
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1472 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1472
new file mode 100644
index 00000000..fe85c013
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1472
@@ -0,0 +1,5 @@
+Parameter 'sgx-epc.0.node' is unexpected
+Description of problem:
+qemu-system-x86_64: Parameter 'sgx-epc.0.node' is unexpected
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1473 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1473
new file mode 100644
index 00000000..709bf9c7
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1473
@@ -0,0 +1 @@
+how to run qemu with sgx feature enabled
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1476 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1476
new file mode 100644
index 00000000..dfcd07ca
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1476
@@ -0,0 +1 @@
+Support for additional CMOS memory banks
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1492 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1492
new file mode 100644
index 00000000..af14064b
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1492
@@ -0,0 +1,292 @@
+[coredump] [git master] qemu-x86_64 segfaults on ppc64le (4K page size) when trying to run android-studio inside chroot
+Description of problem:
+qemu-x86_64 segfaults when trying to run android-studio inside an Arch Linux x86_64 chroot from a Gentoo Linux ppc64le (4K page size) host. Hardware is a Raptor CS Talos 2 Power 9.
+```
+[niko@talos2 ~]$ android-studio 
+/usr/bin/android-studio: line 200: 117922 Segmentation fault      (core dumped) "$JAVA_BIN" -classpath "$CLASS_PATH" ${VM_OPTIONS} "-XX:ErrorFile=$HOME/java_error_in_studio_%p.log" "-XX:HeapDumpPath=$HOME/java_error_in_studio_.hprof" "-Djb.vmOptionsFile=${USER_VM_OPTIONS_FILE:-${VM_OPTIONS_FILE}}" ${IDE_PROPERTIES_PROPERTY} -Djava.system.class.loader=com.intellij.util.lang.PathClassLoader -Didea.strict.classpath=true -Didea.vendor.name=Google -Didea.paths.selector=AndroidStudio2022.1 -Didea.platform.prefix=AndroidStudio -Didea.jre.check=true -Dsplash=true com.intellij.idea.Main "$@"
+```
+Steps to reproduce:
+1. Create an Arch Linux chroot from a bootstrap tarball: https://wiki.archlinux.org/title/Install_Arch_Linux_from_existing_Linux#Method_A:_Using_the_bootstrap_tarball_(recommended)
+2. Chroot into it using the following script:
+```
+#!/bin/bash
+
+basedir="/home/niko/chroots/arch-x86_64"
+cp /etc/resolv.conf ${basedir}/etc/
+cp /usr/bin/qemu-x86_64 ${basedir}/usr/bin/
+sed -i 's!#Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$arch!Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$a>
+mount --make-slave --bind  ${basedir} ${basedir}
+mount -t proc none ${basedir}/proc
+mount -t sysfs none ${basedir}/sys/
+mount --make-rslave --rbind /dev ${basedir}/dev
+mount --make-rslave --rbind /run ${basedir}/run
+chroot ${basedir} /bin/bash
+sleep 3
+umount -R ${basedir}/run
+umount -R ${basedir}/dev
+umount ${basedir}/sys
+umount ${basedir}/proc
+umount ${basedir}
+mount | grep chroots | grep arch-x86_64 | grep -v snap
+```
+3. Initialize pacaman keyring and update system:
+```
+# pacman-key --init
+# pacman-key --populate
+# pacman -Syu
+```
+4. Install android-studio from the AUR (download `PKGBUILD` and run `makepkg -s`, finally install the package with `pacman -U <packagename>`): https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=android-studio
+5. Create an unpriviledged account and run `android-studio`
+6. Wait for the crash.
+Additional information:
+```
+Wed 2023-02-15 12:39:32 CET   117922 1000 1000 SIGSEGV present  /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64                         >
+talos2 ~ # coredumpctl gdb 117922
+           PID: 117922 (java)
+           UID: 1000 (niko)
+           GID: 1000 (niko)
+        Signal: 11 (SEGV)
+     Timestamp: Wed 2023-02-15 12:39:25 CET (1min 47s ago)
+  Command Line: /usr/bin/qemu-x86_64 /opt/android-studio/jbr/bin/java -classpath /opt/android-studio/lib/util.jar:/opt/android-studio/lib/app.jar:/opt/android-studio/lib/3rd-party-rt.jar:/opt/android-studio/lib/jna.jar:/opt/android-studio/lib/platform-statistics-devkit.jar:/opt/android-studio/lib/jps-model.jar:/opt/android-studio/lib/rd-core.jar:/opt/android-studio/lib/rd-framework.jar:/opt/android-studio/lib/stats.jar:/opt/android-studio/lib/protobuf.jar:/opt/android-studio/lib/external-system-rt.jar:/opt/android-studio/lib/forms_rt.jar:/opt/android-studio/lib/intellij-test-discovery.jar:/opt/android-studio/lib/rd-swing.jar:/opt/android-studio/lib/annotations.jar:/opt/android-studio/lib/groovy.jar:/opt/android-studio/lib/annotations-java5.jar:/opt/android-studio/lib/byte-buddy-agent.jar:/opt/android-studio/lib/error-prone-annotations.jar:/opt/android-studio/lib/externalProcess-rt.jar:/opt/android-studio/lib/grpc-netty-shaded.jar:/opt/android-studio/lib/idea_rt.jar:/opt/android-studio/lib/intellij-coverage-agent-1.0.656.jar:/opt/android-studio/lib/junit.jar:/opt/android-studio/lib/junit4.jar:/opt/android-studio/lib/lz4-java.jar:/opt/android-studio/lib/platform-objectSerializer-annotations.jar:/opt/android-studio/lib/pty4j.jar:/opt/android-studio/lib/rd-text.jar:/opt/android-studio/lib/resources.jar:/opt/android-studio/lib/util_rt.jar:/opt/android-studio/lib/winp.jar:/opt/android-studio/lib/ant/lib/ant.jar:/opt/android-studio/lib/dbus-java-3.2.1.jar:/opt/android-studio/lib/java-utils-1.0.6.jar:/opt/android-studio/lib/jnr-unixsocket-0.23.jar:/opt/android-studio/lib/jnr-ffi-2.1.10.jar:/opt/android-studio/lib/jffi-1.2.19.jar:/opt/android-studio/lib/jffi-1.2.19-native.jar:/opt/android-studio/lib/asm-7.1.jar:/opt/android-studio/lib/asm-commons-7.1.jar:/opt/android-studio/lib/asm-analysis-7.1.jar:/opt/android-studio/lib/asm-tree-7.1.jar:/opt/android-studio/lib/asm-util-7.1.jar:/opt/android-studio/lib/jnr-a64asm-1.0.0.jar:/opt/android-studio/lib/jnr-x86asm-1.0.2.jar:/opt/android-studio/lib/jnr-constants-0.9.12.jar:/opt/android-studio/lib/jnr-enxio-0.21.jar:/opt/android-studio/lib/jnr-posix-3.0.50.jar -Xms256m -Xmx1280m -XX:ReservedCodeCacheSize=512m -XX:+IgnoreUnrecognizedVMOptions -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=50 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow -ea -Dsun.io.useCanonCaches=false $'-Djdk.http.auth.tunneling.disabledSchemes=""' -Djdk.attach.allowAttachSelf=true -Djdk.module.illegalAccess.silent=true -Djna.nosys=true -Djna.boot.library.path= -Didea.vendor.name=Google -Dkotlinx.coroutines.debug=off -Dsun.tools.attach.tmp.only=true -XX:ErrorFile=/home/niko/java_error_in_studio_%p.log -XX:HeapDumpPath=/home/niko/java_error_in_studio_.hprof -Djb.vmOptionsFile=/opt/android-studio/bin/studio64.vmoptions -Djava.system.class.loader=com.intellij.util.lang.PathClassLoader -Didea.strict.classpath=true -Didea.vendor.name=Google -Didea.paths.selector=AndroidStudio2022.1 -Didea.platform.prefix=AndroidStudio -Didea.jre.check=true -Dsplash=true com.intellij.idea.Main
+    Executable: /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64
+ Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope
+          Unit: user@1000.service
+     User Unit: vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope
+         Slice: user-1000.slice
+     Owner UID: 1000 (niko)
+       Boot ID: 33cad872d21043ebbe3dd6581bdd28c6
+    Machine ID: b3e834569b8ff461391f5ac061feb773
+      Hostname: talos2
+       Storage: /var/lib/systemd/coredump/core.java.1000.33cad872d21043ebbe3dd6581bdd28c6.117922.1676461165000000.zst (present)
+  Size on Disk: 226.7M
+       Message: Process 117922 (java) of user 1000 dumped core.
+
+GNU gdb (Gentoo 12.1 vanilla) 12.1
+Copyright (C) 2022 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+Type "show copying" and "show warranty" for details.
+This GDB was configured as "powerpc64le-unknown-linux-gnu".
+Type "show configuration" for configuration details.
+For bug reporting instructions, please see:
+<https://bugs.gentoo.org/>.
+Find the GDB manual and other documentation resources online at:
+    <http://www.gnu.org/software/gdb/documentation/>.
+
+For help, type "help".
+Type "apropos word" to search for commands related to "word"...
+Reading symbols from /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64...
+BFD: warning: /var/tmp/coredump-R9M5K3: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002
+BFD: warning: /var/tmp/coredump-R9M5K3: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
+BFD: warning: /var/tmp/coredump-R9M5K3: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
+
+warning: Can't open file /opt/android-studio/jbr/bin/java during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/ld-linux-x86-64.so.2 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libpthread.so.0 during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/jbr/lib/jli/libjli.so during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libdl.so.2 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libc.so.6 during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/jbr/lib/server/libjvm.so during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libm.so.6 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/librt.so.1 during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/jbr/lib/libverify.so during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/jbr/lib/libjava.so during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/jbr/lib/libjimage.so during file-backed mapping note processing
+
+warning: Can't open file /tmp/hsperfdata_niko/117922 during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/jbr/lib/libzip.so during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/jbr/lib/modules during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/jbr/lib/libnio.so during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/jbr/lib/libnet.so during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/util.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/app.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/3rd-party-rt.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/jna.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/platform-statistics-devkit.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/jps-model.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/rd-core.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/rd-framework.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/stats.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/protobuf.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/external-system-rt.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/forms_rt.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/intellij-test-discovery.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/rd-swing.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/annotations.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/groovy.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/annotations-java5.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/byte-buddy-agent.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/error-prone-annotations.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/externalProcess-rt.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/grpc-netty-shaded.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/idea_rt.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/intellij-coverage-agent-1.0.656.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/junit.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/junit4.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/lz4-java.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/platform-objectSerializer-annotations.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/pty4j.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/rd-text.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/resources.jar during file-backed mapping note processing
+
+warning: Can't open file /opt/android-studio/lib/util_rt.jar during file-backed mapping note processing
+
+warning: core file may not match specified executable file.
+[New LWP 117925]
+[New LWP 117924]
+[New LWP 117930]
+[New LWP 117935]
+[New LWP 117933]
+[New LWP 117928]
+[New LWP 117936]
+[New LWP 117922]
+[New LWP 117927]
+[New LWP 117932]
+[New LWP 117929]
+[New LWP 117937]
+[New LWP 117926]
+[New LWP 117934]
+[New LWP 117931]
+[New LWP 117941]
+[New LWP 117939]
+[New LWP 117938]
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/usr/lib64/libthread_db.so.1".
+Core was generated by `/usr/bin/qemu-x86_64 /opt/android-studio/jbr/bin/java -classpath /opt/android-s'.
+Program terminated with signal SIGSEGV, Segmentation fault.
+#0  0x00000000102e1c68 in sigsuspend ()
+[Current thread is 1 (Thread 0x3fffbab18360 (LWP 117925))]
+(gdb) info threads
+  Id   Target Id                          Frame 
+* 1    Thread 0x3fffbab18360 (LWP 117925) 0x00000000102e1c68 in sigsuspend ()
+  2    Thread 0x3fffbb3cf360 (LWP 117924) 0x000000001033afec in syscall ()
+  3    Thread 0x3fffba9d3360 (LWP 117930) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
+  4    Thread 0x3fffba951360 (LWP 117935) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  5    Thread 0x3fffba850360 (LWP 117933) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  6    Thread 0x3fffbaa55360 (LWP 117928) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  7    Thread 0x3fffba910360 (LWP 117936) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
+  8    Thread 0x409e2000 (LWP 117922)     safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  9    Thread 0x3fffbaa96360 (LWP 117927) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  10   Thread 0x3fffba891360 (LWP 117932) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  11   Thread 0x3fffbaa14360 (LWP 117929) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  12   Thread 0x3fffba60e360 (LWP 117937) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
+  13   Thread 0x3fffbaad7360 (LWP 117926) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  14   Thread 0x3fffba992360 (LWP 117934) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  15   Thread 0x3fffbabce360 (LWP 117931) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
+  16   Thread 0x3fffba7ce360 (LWP 117941) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
+  17   Thread 0x3fffba80f360 (LWP 117939) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  18   Thread 0x3fffba5cd360 (LWP 117938) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+(gdb) thread 1
+[Switching to thread 1 (Thread 0x3fffbab18360 (LWP 117925))]
+#0  0x00000000102e1c68 in sigsuspend ()
+(gdb) thread 2
+[Switching to thread 2 (Thread 0x3fffbb3cf360 (LWP 117924))]
+#0  0x000000001033afec in syscall ()
+(gdb) thread 3
+[Switching to thread 3 (Thread 0x3fffba9d3360 (LWP 117930))]
+#0  0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
+(gdb) thread 4
+[Switching to thread 4 (Thread 0x3fffba951360 (LWP 117935))]
+#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+75	../common-user/host/ppc64/safe-syscall.inc.S: No such file or directory.
+(gdb) thread 5
+[Switching to thread 5 (Thread 0x3fffba850360 (LWP 117933))]
+#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+75	in ../common-user/host/ppc64/safe-syscall.inc.S
+(gdb) thread 6
+[Switching to thread 6 (Thread 0x3fffbaa55360 (LWP 117928))]
+#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+75	in ../common-user/host/ppc64/safe-syscall.inc.S
+(gdb) thread 7
+[Switching to thread 7 (Thread 0x3fffba910360 (LWP 117936))]
+#0  0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
+(gdb) thread 8
+[Switching to thread 8 (Thread 0x409e2000 (LWP 117922))]
+#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+75	in ../common-user/host/ppc64/safe-syscall.inc.S
+(gdb) thread 9
+[Switching to thread 9 (Thread 0x3fffbaa96360 (LWP 117927))]
+#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+75	in ../common-user/host/ppc64/safe-syscall.inc.S
+(gdb) thread 10
+[Switching to thread 10 (Thread 0x3fffba891360 (LWP 117932))]
+#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+75	in ../common-user/host/ppc64/safe-syscall.inc.S
+(gdb) thread 11
+[Switching to thread 11 (Thread 0x3fffbaa14360 (LWP 117929))]
+#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+75	in ../common-user/host/ppc64/safe-syscall.inc.S
+(gdb) thread 12
+[Switching to thread 12 (Thread 0x3fffba60e360 (LWP 117937))]
+#0  0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
+(gdb) thread 13
+[Switching to thread 13 (Thread 0x3fffbaad7360 (LWP 117926))]
+#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+75	in ../common-user/host/ppc64/safe-syscall.inc.S
+(gdb) thread 14
+[Switching to thread 14 (Thread 0x3fffba992360 (LWP 117934))]
+#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+75	in ../common-user/host/ppc64/safe-syscall.inc.S
+(gdb) thread 15
+[Switching to thread 15 (Thread 0x3fffbabce360 (LWP 117931))]
+#0  0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
+(gdb) thread 16
+[Switching to thread 16 (Thread 0x3fffba7ce360 (LWP 117941))]
+#0  0x000000001037df88 in __futex_abstimed_wait_cancelable64 ()
+(gdb) thread 17
+[Switching to thread 17 (Thread 0x3fffba80f360 (LWP 117939))]
+#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+75	in ../common-user/host/ppc64/safe-syscall.inc.S
+(gdb) thread 18
+[Switching to thread 18 (Thread 0x3fffba5cd360 (LWP 117938))]
+#0  safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+75	in ../common-user/host/ppc64/safe-syscall.inc.S
+```
+
+Download full coredump: https://drive.google.com/file/d/1t0Tm6-O6THrOFPp8uO-pbHqv8tZ6XWUe/view?usp=share_link
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1524 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1524
new file mode 100644
index 00000000..f5e11d9d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1524
@@ -0,0 +1,37 @@
+error while loading state for instance 0x0 of device 'kvm-tpr-opt',load of migration failed: Operation not permitted
+Description of problem:
+when i save and restore a guest,it report the error: "error while loading state for instance 0x0 of device 'kvm-tpr-opt',load of migration failed: Operation not permitted"
+Steps to reproduce:
+1.virsh save test ccc.img
+
+2.virsh restore ccc.im
+
+
+it report error:
+
+[root@TOS-9772 ~]# virsh save test ccc.img
+
+[root@TOS-9772 ~]# virsh restore ccc.img
+
+error: Failed to restore domain from ccc.img
+
+error: internal error: qemu unexpectedly closed the monitor: qmp_cmd_name: query-hotpluggable-cpus, arguments: {}
+
+qmp_cmd_name: query-cpus-fast, arguments: {}
+
+qmp_cmd_name: query-iothreads, arguments: {}
+
+qmp_cmd_name: expire_password, arguments: {"protocol": "spice", "time": "never"}
+
+qmp_cmd_name: balloon, arguments: {"value": 1073741824}
+
+qmp_cmd_name: migrate-incoming, arguments: {"uri": "fd:29"}
+
+{"timestamp": {"seconds": 1677661413, "microseconds": 275227}, "event": "MIGRATION", "data": {"status": "setup"}}
+
+{"timestamp": {"seconds": 1677661413, "microseconds": 275600}, "event": "MIGRATION", "data": {"status": "active"}}
+
+2023-03-01T09:03:33.316549Z qemu-system-x86_64: error while loading state for instance 0x0 of device 'kvm-tpr-opt'
+
+2023-03-01T09:03:33.317076Z qemu-system-x86_64: load of migration failed: Operation not permitted
+{"timestamp": {"seconds": 1677661413, "microseconds": 317297}, "event": "MIGRATION", "data": {"status": "failed"}}
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1533 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1533
new file mode 100644
index 00000000..5adbd6b3
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1533
@@ -0,0 +1 @@
+qemu-i386 should not enable feature LM with named CPU models.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1534 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1534
new file mode 100644
index 00000000..583990ad
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1534
@@ -0,0 +1 @@
+usermode emulation warns about features that are system-only (x2apic, tsc-deadline, pcid, invpcid)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1570 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1570
new file mode 100644
index 00000000..b020e457
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1570
@@ -0,0 +1,63 @@
+Incorrect memory handling when booting redox
+Description of problem:
+During the boot of redox, I regularly get one of two errors when reading the HPET at base address `0xfed00000`:
+- Incorrect translation from virtual address `0xffff8000fed00108` to random physical addresses, e.g. `0xfec00108`
+- Invalid read at addr 0x0, size 8, region 'hpet', reason: invalid size (min:4 max:4)
+Steps to reproduce:
+1. Build the server version of the redox OS as per [the instructions](https://doc.redox-os.org/book/ch02-05-building-redox.html).
+2. Run the qemu command line with multiple CPUs. The more CPUs the easier it is to reproduce.
+3. The problem will manifest itself as a divide by zero error. See the corresponding [redox bug report](https://gitlab.redox-os.org/redox-os/kernel/-/issues/116).
+Additional information:
+The best evidence I have is a debug line I added to qemu before [the memory_region_dispatch_read line](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/tcg/cputlb.c#L1375):
+
+```
+if ((mr_offset & 0x1ff) == 0x108)  fprintf(stderr, "cputlb io_readx cpu %d addr=%llx mr_offset=%llx mr=%p mr->addr=%llx\n", current_cpu->cpu_index, addr,  mr_offset, mr, mr->addr);
+r = memory_region_dispatch_read(mr, mr_offset, &val, op, full->attrs);
+```
+
+That logs:
+
+```
+cputlb io_readx cpu 0 addr=ffff8000fed00108 mr_offset=108 mr=0x7fefb60d5720 mr->addr=fec00000
+```
+
+The expected physical address is `0xfed00000` instead of `0xfec00000`.
+
+A more extensive log is this one:
+```
+55027@1680283224.671665:memory_region_ops_read cpu 5 mr 0x7f9950890130 addr 0xfed000f0 value 0x949707cc size 4 name 'hpet'      <- ok
+55027@1680283224.671681:memory_region_ops_read cpu 5 mr 0x7f9950890130 addr 0xfed000f4 value 0x0 size 4 name 'hpet'             <- ok
+tlb_set_page_full: vaddr=0000000000474000 paddr=0x000000000536f000 prot=5 idx=1
+...
+tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff
+tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff
+tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff
+tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff
+...
+55027@1680283224.671951:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec00108 value 0x0 size 4 name 'ioapic'           <- wrong
+55027@1680283224.671958:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec0010c value 0x0 size 4 name 'ioapic'
+55027@1680283224.671967:memory_region_ops_write cpu 2 mr 0x7f994d808d30 addr 0xcf8 value 0x8000fa80 size 4 name 'pci-conf-idx'
+55027@1680283224.671986:memory_region_ops_read cpu 2 mr 0x7f994d808e40 addr 0xcfc value 0x80a805 size 4 name 'pci-conf-data'
+55027@1680283224.672001:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec00000 value 0x0 size 4 name 'ioapic'           <- wrong
+55027@1680283224.672010:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec00004 value 0x0 size 4 name 'ioapic'
+```
+
+Some observations
+- ~I seem to be the only one having this issue. Perhaps because I am the only one developing on MacOS. Maybe it's because I'm running an older intel mac.~. I managed to reproduce this on a Asus vivobook running linux
+- The redox OS [reads the HPET](https://gitlab.redox-os.org/redox-os/kernel/-/blob/master/src/arch/x86_64/time.rs#L11) at addresses `0xf4`, `0x108`, `0x00` in that order. If I change the order to `0x00`, `0xf4`, `0x108`, the problem goes away.
+- Even if I work around the problem by changing the order of the reads, the OS still randomly crashes. This could be related, but I can only speculate on that right now.
+- Increasing qemu debug logging tends to push the problem to the 4vs8 size problem instead of the incorrect address one. The more logging, the more difficult it is to reproduce.
+- I tried to bisect the issue and found I could only reproduce it after qemu version 5.2. However, the mac build broke during this process so I could not find the causal commit. Between 5.1 and 5.2 the performance is greatly increased though and I suspect whatever changed there caused the issue.
+- I can't reproduce the problem with -smp 1
+- I have seen qemu segfault occasionally, but I didn't look further into it and I don't know if it's related to this issue.
+- I have attempted to rule out a bug in redox. I am fairly certain nothing strange is going on there, but I can't say for sure.
+- When I trigger the incorrect address bug, I mostly get  a base address of `0xfec00000` which is the IO APIC. However, I do occasionally see other addresses too
+- `info tlb` at the time of the fault shows
+   ```
+   ffff8000fd3e6000: 00000000fd3e6000 X--DA---W
+   ffff8000fd3e7000: 00000000fd3e7000 X--DA---W
+   ffff8000fed00000: 00000000fed00000 X--DAC--W
+   ffff8000fee00000: 00000000fee00000 X--DA---W
+   fffffd8000000000: 0000000001e32000 XG-DA---W
+   fffffd8000001000: 0000000001e36000 XG-DA---W
+   ```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1628 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1628
new file mode 100644
index 00000000..6e1c1f6e
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1628
@@ -0,0 +1,130 @@
+windows 10 display scale will cause an exception
+Description of problem:
+windows dispaly sacle 150% or higher,  windows system will exception
+Steps to reproduce:
+1.  windows dispaly sacle 150%
+Additional information:
+- code in: qemu/hw/display/qxl-render.c
+
+static void qxl_unpack_chunks(void *dest, size_t size, PCIQXLDevice *qxl,
+                              QXLDataChunk *chunk, uint32_t group_id)
+{
+    uint32_t max_chunks = 32;
+    size_t offset = 0;
+    size_t bytes;
+    for (;;) {
+        bytes = MIN(size - offset, chunk->data_size);
+        memcpy(dest + offset, chunk->data, bytes);
+        offset += bytes;
+        if (offset == size) {
+            return;
+        }
+        chunk = qxl_phys2virt(qxl, chunk->next_chunk, group_id,
+                              sizeof(QXLDataChunk) + chunk->data_size);
+         **// get next chunk, but the chunk size use current chunk's data size, not next chunk's data size!!!!**
+         **// if next chunk alloc size < current chunk's data size, there will be exception **
+         
+        if (!chunk) {
+            return;
+        }
+        max_chunks--;
+        if (max_chunks == 0) {
+            return;
+        }
+    }
+}
+
+
+
+- code in: qxl_wddm_dod/QXLDod.cpp exist next chunk alloc size < current chunk's data size 
+
+NTSTATUS  QxlDevice::SetPointerShape(_In_ CONST DXGKARG_SETPOINTERSHAPE* pSetPointerShape)
+{
+.....
+    res = (Resource *)AllocMem(MSPACE_TYPE_VRAM, CURSOR_ALLOC_SIZE, TRUE);  // here we all the first QXLDataChunk , and alloc_size = (CURSOR_ALLOC_SIZE - sizeof(Resource) - sizeof(InternalCursor)) = 8118
+
+.....
+     for (; src != src_end; src += pSetPointerShape->Pitch) {
+        if (!PutBytesAlign(&chunk, &now, &end, src, line_size, PAGE_SIZE - PAGE_SIZE % line_size, NULL)) { // in this function ,we will alloc next QXLDataChunk 
+            ..........
+            break;
+        }
+    }
+}
+
+BOOLEAN QxlDevice::PutBytesAlign(QXLDataChunk **chunk_ptr, UINT8 **now_ptr,
+                            UINT8 **end_ptr, UINT8 *src, int size,
+                            size_t alloc_size, PLIST_ENTRY pDelayed)
+{
+    .....
+    size_t maxAllocSize = BITS_BUF_MAX - BITS_BUF_MAX % size;
+    alloc_size = MIN(alloc_size, maxAllocSize);
+    void *ptr = AllocMem(MSPACE_TYPE_VRAM, alloc_size + sizeof(QXLDataChunk), bForced);  *** //here will  alloc  next  QXLDataChunk  and  alloc_size  = (PAGE_SIZE - PAGE_SIZE % line_size) = 3876 ****
+}
+
+
+eg:
+dispaly sacle 150% ，mouse size will bu change to  57* 55  ，rgba data size = 12540,   we  need three QXLDataChunk  
+
+QXLDataChunk* first;
+first->data_size = 8118;
+first->prev_chunk = 0;
+first->next_chunk=second;
+first->data = [alloc_size(8118), data_size(8118)]
+
+QXLDataChunk* second;
+second->data_size = 3876;
+second->prev_chunk = first;
+second->next_chunk=third;
+second->data = [alloc_size(3876), data_size(3876)]
+
+QXLDataChunk* third;
+third->data_size = 546;
+third->prev_chunk =second;
+third->next_chunk=0;
+third->data = [alloc_size(3876), data_size(546)]
+
+
+chunk = first;
+qxl_phys2virt(qxl, second, group_id, sizeof(QXLDataChunk) + 8118)
+
+
+this size [sizeof(QXLDataChunk) + 8118]  > second  QXLDataChunk's  alloc  size  , will  cause  qxl_get_check_slot_offset check fail
+
+
+for second QXLDataChunk, we actual alloc size  is (sizeof(QXLDataChunk) + 3876),  but we assign (8118 + sizeof(QXLDataChunk))  will cause an exception
+
+
+suggest code :
+
+static void qxl_unpack_chunks(void *dest, size_t size, PCIQXLDevice *qxl,
+                              QXLDataChunk *chunk, uint32_t group_id)
+{
+    uint32_t max_chunks = 32;
+    size_t offset = 0;
+    size_t bytes;
+    QXLPHYSICAL next_chunk_phys = 0; 
+    for (;;) {
+        bytes = MIN(size - offset, chunk->data_size);
+        memcpy(dest + offset, chunk->data, bytes);
+        offset += bytes;
+        if (offset == size) {
+            return;
+        }
+        next_chunk_phys = chunk->next_chunk;
+        chunk = qxl_phys2virt(qxl, next_chunk_phys, group_id,
+                              sizeof(QXLDataChunk));  // fist time, only get the next chunk's data size;
+        if (!chunk) {
+            return;
+        }
+        chunk = qxl_phys2virt(qxl, next_chunk_phys, group_id,
+                              sizeof(QXLDataChunk) + chunk->data_size); // second time, check data size and get data;
+        if (!chunk) {
+            return;
+        }
+        max_chunks--;
+        if (max_chunks == 0) {
+            return;
+        }
+    }
+}
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1648 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1648
new file mode 100644
index 00000000..65370057
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1648
@@ -0,0 +1,58 @@
+linux-user: incorrect alignment of sigframe::pretcode & rt_sigframe::pretcode cause crash
+Description of problem:
+Corrent Print Result:
+
+sp: cdd3b4e8
+
+SUCCEEDED!
+
+qemu-x86_64 Print Result:
+
+sp: 2804170
+
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+
+Segmentation fault
+
+Reason of Bug:
+
+sigframe::pretcode & rt_sigframe::pretcode must align of 16n-sizeof(void*) instead of 16n, Because rsp align of 16n before instruction "call" in caller, After "call", push address of "call" in caller. sp of begin in callee is 16n-sizeof(void*)
+
+For example on x86_64:
+
+reference to "qemu/linux-user/i386/signal.c"
+
+```
+# define TARGET_FPSTATE_FXSAVE_OFFSET 0
+
+struct rt_sigframe {
+    abi_ulong pretcode;
+    struct target_ucontext uc;
+    struct target_siginfo info;
+    struct target_fpstate fpstate QEMU_ALIGNED(16);
+};
+#define TARGET_RT_SIGFRAME_FXSAVE_OFFSET (                                 \
+    offsetof(struct rt_sigframe, fpstate) + TARGET_FPSTATE_FXSAVE_OFFSET)
+```
+
+offsetof(struct rt_sigframe, fpstate) align of 16
+
+TARGET_FPSTATE_FXSAVE_OFFSET is 0
+
+TARGET_RT_SIGFRAME_FXSAVE_OFFSET is 16n, also alignment of fxsave is 64
+
+so address of rt_sigframe::pretcode is 16n instead of 16n - sizeof(void*), It is incorect!
+
+Fix the bug:
+
+```
+struct rt_sigframe {
+    abi_ulong pretcode;
+    struct target_ucontext uc;
+    struct target_siginfo info;
+    abi_ulong unused QEMU_ALIGNED(16);
+    struct target_fpstate fpstate;
+};
+```
+
+offsetof(struct rt_sigframe, fpstate) is 16n+8, so address of rt_sigframe::pretcode is 16n-8 on x86_64.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1762 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1762
new file mode 100644
index 00000000..b51374e5
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1762
@@ -0,0 +1,83 @@
+Linux RTC issues possibly with RTC_UIE_ON, RTC_UIE_OFF
+Description of problem:
+Running:
+
+```
+hwclock --hctosys
+```
+
+as root, under the running VM using a UEFI bios image, I get:
+
+```
+hwclock: select() to /dev/rtc0 to wait for clock tick timed out
+```
+
+When running the same command on the same disk image but without UEFI,
+that is, just using the SeaBIOS bios, everything works fine.
+
+Running
+
+```
+hwclock --hctosys --directisa
+```
+
+works fine, too.
+
+Running the (compiled) kernel test utility:
+
+
+```
+/usr/src/linux/tools/testing/selftests/rtc/rtctest.c
+
+```
+
+
+```
+TAP version 13
+1..8
+# Starting 8 tests from 2 test cases.
+#  RUN           rtc.date_read ...
+# rtctest.c:49:date_read:Current RTC date/time is 10/07/2023 14:02:11.
+#            OK  rtc.date_read
+ok 1 rtc.date_read
+#  RUN           rtc.date_read_loop ...
+# rtctest.c:88:date_read_loop:Continuously reading RTC time for 30s (with 11ms breaks after every read).
+# rtctest.c:115:date_read_loop:Performed 2752 RTC time reads.
+#            OK  rtc.date_read_loop
+ok 2 rtc.date_read_loop
+#  RUN           rtc.uie_read ...
+# uie_read: Test terminated by timeout
+#          FAIL  rtc.uie_read
+not ok 3 rtc.uie_read
+#  RUN           rtc.uie_select ...
+# rtctest.c:164:uie_select:Expected 0 (0) != rc (0)
+# uie_select: Test terminated by assertion
+#          FAIL  rtc.uie_select
+not ok 4 rtc.uie_select
+#  RUN           rtc.alarm_alm_set ...
+# rtctest.c:202:alarm_alm_set:Alarm time now set to 14:02:52.
+# rtctest.c:214:alarm_alm_set:Expected 0 (0) != rc (0)
+# alarm_alm_set: Test terminated by assertion
+#          FAIL  rtc.alarm_alm_set
+not ok 5 rtc.alarm_alm_set
+#  RUN           rtc.alarm_wkalm_set ...
+# rtctest.c:258:alarm_wkalm_set:Alarm time now set to 10/07/2023 14:02:57.
+# rtctest.c:268:alarm_wkalm_set:Expected 0 (0) != rc (0)
+# alarm_wkalm_set: Test terminated by assertion
+#          FAIL  rtc.alarm_wkalm_set
+not ok 6 rtc.alarm_wkalm_set
+#  RUN           rtc.alarm_alm_set_minute ...
+# rtctest.c:304:alarm_alm_set_minute:Alarm time now set to 14:03:00.
+# rtctest.c:316:alarm_alm_set_minute:Expected 0 (0) != rc (0)
+# alarm_alm_set_minute: Test terminated by assertion
+#          FAIL  rtc.alarm_alm_set_minute
+not ok 7 rtc.alarm_alm_set_minute
+#  RUN           rtc.alarm_wkalm_set_minute ...
+# rtctest.c:360:alarm_wkalm_set_minute:Alarm time now set to 10/07/2023 14:05:00.
+# rtctest.c:370:alarm_wkalm_set_minute:Expected 0 (0) != rc (0)
+# alarm_wkalm_set_minute: Test terminated by assertion
+#          FAIL  rtc.alarm_wkalm_set_minute
+not ok 8 rtc.alarm_wkalm_set_minute
+# FAILED: 2 / 8 tests passed.
+# Totals: pass:2 fail:6 xfail:0 xpass:0 skip:0 error:0
+#
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/189 b/gitlab/issues_text/target_i386/host_missing/accel_missing/189
new file mode 100644
index 00000000..b6d2b0ff
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/189
@@ -0,0 +1 @@
+Intel GVT-g works in X11, segfaults in wayland
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/191 b/gitlab/issues_text/target_i386/host_missing/accel_missing/191
new file mode 100644
index 00000000..833d496c
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/191
@@ -0,0 +1 @@
+qemu64 CPU model is incorrect
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1919 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1919
new file mode 100644
index 00000000..bd1d4a61
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1919
@@ -0,0 +1,20 @@
+UEFI SecureCode hangs on MacOs - 8.1.1 / MacOS Ventura
+Description of problem:
+Unable to load edk2 secure boot UEFI code. Non-secure edk2 bios works fine, but secure one hangs during load.
+Steps to reproduce:
+1. Run mentioned command - it should display OVMF logo - but it hangs
+Additional information:
+* edk2-x86_64-code.fd works fine, edk2-x86_64-secure-code.fd not
+* Tested with swtpm and without - doesn't matter
+* TPM access has been observed (when swtpm enabled) - sounds like secure-code validation partially works
+
+To enable TPM:
+```
+   -chardev socket,id=chrtpm,path=mytpm0/swtpm-sock \
+   -tpmdev emulator,id=tpm0,chardev=chrtpm \
+   -device tpm-tis,tpmdev=tpm0 \
+```
+and run swtpm
+```
+swtpm socket --tpm2 --tpmstate dir=mytpm0 --ctrl type=unixio,path=mytpm0/swtpm-sock
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/192 b/gitlab/issues_text/target_i386/host_missing/accel_missing/192
new file mode 100644
index 00000000..0b8e43d1
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/192
@@ -0,0 +1 @@
+xv6 Bootloop
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1932 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1932
new file mode 100644
index 00000000..ca2a573e
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1932
@@ -0,0 +1,12 @@
+Broken grab on hover setting
+Description of problem:
+It seems that now qemu implements "static" grab on hover, i.e., it can only be disabled by
+
+1. setting `vmport=off` in `-M` (btw, `pc` or `q35`, doesn't matter)
+2. emulating a usb mouse *and* blacklist/unload the `psmouse` driver on the guest side
+
+while grab on hover setting in the gtk display backend (or frontend?) is seemingly bogus now either way.
+
+Can this be fixed (again?) so that the setting (which can be toggled in the menu "dynamically") can be used to tell this "vmport" thing whether or not it should grab on hover?
+Additional information:
+NIL
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1947 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1947
new file mode 100644
index 00000000..f66af1b6
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1947
@@ -0,0 +1,20 @@
+ACPI (Stop code 0x000000A5) BSOD During Windows XP Professional x64 Edition Setup
+Description of problem:
+When attempting to launch Windows XP Professional x64 Edition setup, the setup crashes with BSOD stop code 0x000000A5 and the following message:
+```
+A problem has been detected and Windows has been shut down to prevent damage to your computer.
+
+If this is the first time you've seen this Stop error screen, restart your computer. If this screen appears again, follow these steps:
+
+The BIOS in this system is not fully ACPI compliant. Please contact your system vendor for an updated BIOS. If you are unable to obtain an updated BIOS or the latest BIOS supplied by your vendor is not ACPI compliant, you can turn off ACPI mode during textmode setup. To do this, press the F7 key when you are prompted to install storage drivers. The system will not notify you that the F7 key was pressed - it will silently disable ACPI and allow you to continue your installation.
+
+Technical information:
+
+*** STOP: 0x000000A5 (0x0000000000000014, 0xFFFFFA80000CBFC6, 0x000000000000008A, 0xFFFFFADFC8E31A90)
+```
+Steps to reproduce:
+1. Obtain a copy of Windows XP Professional x64 Edition SP2.
+2. Run QEMU using the provided command line (with the name & location of your ISO in place of "Windows XP Professional x64 Edition.iso")
+Additional information:
+It appears the bug may be dependent on KVM, I've seen some conflicting results, but with the provided command line removing "accel=kvm" or replacing it with "accel=tcg" changes the BSOD to one about lack of disk space.
+Also, a similar bug occurs with Windows 2000 SP4, but the setup will hang instead of crash. (The hang can be avoided by pressing F5 and selecting "Standard PC" instead of either ACPI option during setup.)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1952 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1952
new file mode 100644
index 00000000..03db2989
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1952
@@ -0,0 +1,96 @@
+elf-linux-user: segfault caused by invalid loaddr extracted by the ELF loader
+Description of problem:
+Emulating ELF binaries as emitted by Zig may lead to segfault in QEMU, which typically looks like this
+
+```
+$ qemu-x86_64 simple
+fish: Job 1, 'qemu-x86_64 simple' terminated by signal SIGSEGV (Address boundary error)
+```
+Steps to reproduce:
+1. Obtain latest Zig nightly
+2. Compile simple static C program using Zig's ELF linker:
+
+```
+$ echo "int main() { return 0 };" > simple.c
+$ zig build-exe simple.c -lc -target x86_64-linux-musl -fno-lld --image-base 0x1000000
+$ qemu-x86_64 simple
+fish: Job 1, 'qemu-x86_64 simple' terminated by signal SIGSEGV (Address boundary error)
+```
+Additional information:
+Note that running `simple` directly it's correctly mmaped and executed by the kernel:
+
+```
+$ ./simple
+$ echo $status
+0
+``` 
+
+The reason this happens is because of an assumption QEMU's ELF loader makes on the virtual addresses and offsets of `PT_LOAD` segments, namely:
+
+```
+vaddr2 - vaddr1 >= off2 - off1
+```
+
+Typically, to the best of my knowledge, this is conformed to by the linkers in the large, but it is not required at all. Here's a one-line tweak to QEMU's loader that fixes the segfault:
+
+```diff
+diff --git a/linux-user/elfload.c b/linux-user/elfload.c
+index f21e2e0c3d..eabb4fed03 100644
+--- a/linux-user/elfload.c
++++ b/linux-user/elfload.c
+@@ -3211,7 +3211,7 @@ static void load_elf_image(const char *image_name, int image_fd,
+     for (i = 0; i < ehdr->e_phnum; ++i) {
+         struct elf_phdr *eppnt = phdr + i;
+         if (eppnt->p_type == PT_LOAD) {
+-            abi_ulong a = eppnt->p_vaddr - eppnt->p_offset;
++            abi_ulong a = eppnt->p_vaddr & ~(eppnt->p_align - 1);
+             if (a < loaddr) {
+                 loaddr = a;
+             }
+```
+
+The reason why this breaks for ELF binaries emitted by Zig is that while virtual addresses are allocated sequentially or pre-allocated, file offsets are allocated on a best-effort basis wherever there is enough space in the file to fit a given section/segment so that we can move the contents in file while preserving the allocated virtual addresses on a whim. To provide a more concrete example, here's the load segment layout for `simple` as emitted by Zig:
+
+```
+$ readelf -l simple
+
+Elf file type is EXEC (Executable file)
+Entry point 0x1002000
+There are 7 program headers, starting at offset 64
+
+Program Headers:
+  Type           Offset             VirtAddr           PhysAddr
+                 FileSiz            MemSiz              Flags  Align
+  PHDR           0x0000000000000040 0x0000000001000040 0x0000000001000040
+                 0x0000000000000188 0x0000000000000188  R      0x8
+  LOAD           0x0000000000000000 0x0000000001000000 0x0000000001000000
+                 0x00000000000001c8 0x00000000000001c8  R      0x1000
+  LOAD           0x0000000000021000 0x0000000001001000 0x0000000001001000
+                 0x0000000000000078 0x0000000000000078  R      0x1000
+  LOAD           0x0000000000022000 0x0000000001002000 0x0000000001002000
+                 0x000000000000065a 0x000000000000065a  R E    0x1000
+  LOAD           0x0000000000023000 0x0000000001003000 0x0000000001003000
+                 0x0000000000000060 0x0000000000000278  RW     0x1000
+  GNU_EH_FRAME   0x0000000000021064 0x0000000001001064 0x0000000001001064
+                 0x0000000000000014 0x0000000000000014  R      0x4
+  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
+                 0x0000000000000000 0x0000000000000000  RW     0x1
+
+ Section to Segment mapping:
+  Segment Sections...
+   00
+   01
+   02     .rodata.str1.1 .rodata .eh_frame .eh_frame_hdr
+   03     .text .init .fini
+   04     .data .got .bss
+   05     .eh_frame_hdr
+   06
+```
+
+As you can see, initially `loaddr := 0x1000000 - 0x0 = 0x1000000`. However, upon iterating over the second load segment, we already get
+
+```
+a := 0x1001000 - 0x21000 = 0xfe000
+```
+
+and since `a < loaddr`, we incorrectly set `loaddr := 0xfe000`.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1956 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1956
new file mode 100644
index 00000000..4bea7ec6
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1956
@@ -0,0 +1 @@
+[x86,microvm] Update microvm documentation with ACPI option
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1986 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1986
new file mode 100644
index 00000000..71738b53
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1986
@@ -0,0 +1,14 @@
+windows install fails with error 0x80070001
+Description of problem:
+I have a windows vm executed via libvirt, I run it on a physical drive passing it into the guest. when I pass it via sata pt and try to install windows 11 on it, the install fails with error 0x80070001. I had an installation there which resulted with periodic bosd when sata pt was used.
+if I pass the /dev node, I don't get the errors but the performance is horrible due to high hdd usage
+I've tested the same setup with ubuntu, doing read and write to the device of multiple GB (200GB~), no issue at all.
+I've opened an issue at virtio-win and it was closed claiming it is a sata pt issue after trying latest virtio-win.
+Steps to reproduce:
+1. define a sata virtio controller
+2. pass a physical sata drive to the guest attached to the sata controller define in step 1
+3. define a windows iso as cdrom
+4. try to install windows on the device
+Additional information:
+[save.xml.txt](/uploads/0b7eb56d5fe00ff11341483d3d47ebed/save.xml.txt)
+[qemu.cmd.txt](/uploads/b948eee1a95321d11136b96352caace0/qemu.cmd.txt)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/1998 b/gitlab/issues_text/target_i386/host_missing/accel_missing/1998
new file mode 100644
index 00000000..a2cb4ce8
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/1998
@@ -0,0 +1,27 @@
+acpihp does not work with some common guest kernels
+Description of problem:
+for pc-q35 6.1, 7.2, any guest kernel with `ACPI: Core revision` < 20230331, can not hot plug the nvidia GPUs.
+So basically only guest kernel >= 6.5 can make it work so far.
+But majority of server kernels are still at 4.18, 5.x. I wonder if it possible to be fixed?
+I also don't know is this qemu bug? bios bug? or actually ACPIA's bug?
+
+journal -k report error like following:
+```
+Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 0: no space for [mem size 0x01000000]
+Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 0: failed to assign [mem size 0x01000000]
+Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 6: assigned [mem 0x81800000-0x8187ffff pref]
+Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 5: assigned [io  0xa000-0xa07f]
+Nov 11 17:53:00 VMTEST kernel: nvidia 0000:08:00.0: enabling device (0000 -> 0003)
+Nov 11 17:53:00 VMTEST kernel: NVRM: This PCI I/O region assigned to your NVIDIA device is invalid:
+                                                NVRM: BAR0 is 0M @ 0x0 (PCI:0000:08:00.0)
+Nov 11 17:53:00 VMTEST kernel: nvidia: probe of 0000:08:00.0 failed with error -1
+```
+Steps to reproduce:
+1. run the instance as I described above
+2. in qemu monitor: device_add vfio-pci,host=0000:06:00.0,id=gpu0,bus=pci.8
+3. login to the vm console then nvidia-smi to see the failure
+
+workaround:
+`ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off` to disable the acpihp then pciehp can make it work.
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2008 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2008
new file mode 100644
index 00000000..c5f340b4
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2008
@@ -0,0 +1,12 @@
+querying smbios type=1 UUID in Windows not possible when using SMBIOS 64 bit entry
+Description of problem:
+Querying the UUID in Powershell with
+`get-wmiobject win32_computersystemproduct | Select-Object -expandProperty UUID`
+will return no value. When using `-machine 'pc-i440fx-8.1,smbios-entry-point-type=32'` or `-machine 'pc-i440fx-8.0'` the command works as expected. When using `-machine 'pc-i440fx-8.0,smbios-entry-point-type=64'` the issue is also present.
+
+Commit bf376f3020dfd7bcb2c4158b4ffa85c04d44f56d changed the default for machine version 8.1, so that explains that part.
+
+It's not clear to me if this is a bug in QEMU or a bug/limitation of the guest OS when 64 bit entry is used by SMBIOS.
+Additional information:
+Originally reported for Windows 10 in the Proxmox VE community forum (AFAIK the downstream build in Proxmox VE does not patch the relevant code paths):
+https://forum.proxmox.com/threads/136942/
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2020 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2020
new file mode 100644
index 00000000..f2ae8554
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2020
@@ -0,0 +1,11 @@
+qemu-system-x86_64: ../../hw/rtc/mc146818rtc.c:203: periodic_timer_update: Assertion `lost_clock >= 0' failed.
+Description of problem:
+VM just crashed, likely because of a time / NTP change
+```
+qemu-system-x86_64: ../../hw/rtc/mc146818rtc.c:203: periodic_timer_update: Assertion `lost_clock >= 0' failed.
+2023-12-04 15:51:40.571+0000: shutting down, reason=crashed
+```
+Steps to reproduce:
+1. N/A
+
+/label ~"kind::Bug"
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2064 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2064
new file mode 100644
index 00000000..d452e067
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2064
@@ -0,0 +1,12 @@
+QEMU v8.2.0-rc4 and above will not take SMI
+Description of problem:
+Starting from v8.2.0-rc4, the x86 QEMU system will take SMI from an incorrect starting address. Without any firmware relocation, sending an SMI will move the RIP to 0x8000, instead of the traditional 0x38000. This caused the existing UEFI drivers not functional during SMI relocation step.
+
+After some investigation, the issue was caused by this commit: https://github.com/qemu/qemu/commit/b5e0d5d22fbffc3d8f7d3e86d7a2d05a1a974e27. There seems to be 2 issues with this change:
+
+1. This code section https://github.com/qemu/qemu/blob/7425b6277f12e82952cede1f531bfc689bf77fb1/target/i386/tcg/translate.c#L568C1-L572C6 was updated from calculating `cpu_eip` based on `s->pc` to `s->base.pc_next`. This will cause undetermined behavior.
+2. This code section https://github.com/qemu/qemu/blob/7425b6277f12e82952cede1f531bfc689bf77fb1/target/i386/tcg/translate.c#L2848C1-L2869C67 added the routine of updating `new_pc`, which is later used `tcg_gen_addi_tl`. This will cause the `new_pc` to be populated with undesirable value and thus cause faulting behaviors.
+Steps to reproduce:
+1. Launch once booting UEFI firmware, and the system will get stuck at the SMM base relocation logic.
+Additional information:
+I verified that after fixing the 2 issues mentioned above, the SMI can be correctly invoked at desired location.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2070 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2070
new file mode 100644
index 00000000..c8b51588
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2070
@@ -0,0 +1,9 @@
+TCG acceleration + EDK2  + Secure Boot hangs on boot since qemu 8.2
+Description of problem:
+Since qemu 8.2, using TCG acceleration in combination with EDK2-OVMF UEFI Secure Boot firmware hangs on boot. qemu freezes and keeps a full CPU core busy at 100% while it hangs. The issue does not occur when using KVM acceleration. It also does not occur when not using EDK2-OVMF UEFI firmware. It also does not occur when using the non secure boot EDK2-OVMF UEFI firmware.
+Steps to reproduce:
+1. `git clone https://github.com/systemd/mkosi`
+2. `cd mkosi`
+3. `bin/mkosi --tools-tree=default --tools-tree-distribution=arch --qemu-kvm=no --qemu-firmware=uefi --debug -f qemu`
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2079 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2079
new file mode 100644
index 00000000..26da6f1d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2079
@@ -0,0 +1 @@
+flaky test: tcg tests, cross-i686-tci runner, "run-memory" test
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2218 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2218
new file mode 100644
index 00000000..f639aa31
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2218
@@ -0,0 +1,12 @@
+MIDI playback issue on Windows 98 / 2000 / XP guest
+Description of problem:
+In Windows 98 / 2000 / XP guest, playback MIDI using Windows Media Player will cause audio slow.
+
+In Windows 98 / 2000 / XP guest, playback MP3 or WMA or WAV using Windows Media Player is works OK.
+Steps to reproduce:
+1. In Windows XP guest, open C:\WINDOWS\Media\Flourish.mid using Windows Media Player.
+2. In Windows XP guest, open C:\WINDOWS\System32\OOBE\images\title.wma using Windows Media Player.
+3. In Windows 98 guest, open C:\WINDOWS\Media\Passport.mid using Windows Media Player.
+4. In Windows 98 guest, open C:\WINDOWS\Application Data\Microsoft\WELCOME\WELCOM98.WAV using Windows Media Player.
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/223 b/gitlab/issues_text/target_i386/host_missing/accel_missing/223
new file mode 100644
index 00000000..a33379a9
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/223
@@ -0,0 +1 @@
+guest migration 100% cpu freeze bug
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2244 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2244
new file mode 100644
index 00000000..81061109
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2244
@@ -0,0 +1,46 @@
+Regression in 8.2.90: cpu_physical_memory_snapshot_get_dirty: assertion failed
+Description of problem:
+On executing the image from QEMU advent calendar 2014, door 12 the following error is shown and QEMU exists.
+
+On Debian (built on git-repo)
+```
+$ qemu-system-i386 oberon/oberon.qcow2
+qemu-system-i386: ../system/physmem.c:948: cpu_physical_memory_snapshot_get_dirty: Zusicherung »start + length <= snap->end« nicht erfüllt.
+Abgebrochen
+```
+On Windows (built on qemu-9.0.0-rc0.tar.xz)
+```
+$ qemu-system-i386 oberon/oberon.qcow2
+ERROR:../qemu-9.0.0-rc0/system/physmem.c:946:cpu_physical_memory_snapshot_get_dirty: assertion failed: (start + length <= snap->end)
+Bail out! ERROR:../qemu-9.0.0-rc0/system/physmem.c:946:cpu_physical_memory_snapshot_get_dirty: assertion failed: (start + length <= snap->end)
+```
+Steps to reproduce:
+1. Retrieve oberon.tar.xz with `wget http://qemu-advent-calendar.org/2014/download/oberon.tar.xz`
+2. Extract with `tar -xf oberon.tar.xz`
+3. Execute with `qemu-system-i386 oberon/oberon.qcow2`
+Additional information:
+The same error is shown for QEMU advent calendar 2014, door 15 (Plan 9 from Bell Labs) soon after switch to graphical mode.
+
+git bisect result:
+```
+973a724eb006f674301a0c45f34b3c08dee0fe49 is the first bad commit
+commit 973a724eb006f674301a0c45f34b3c08dee0fe49
+Author: Paolo Bonzini <pbonzini@redhat.com>
+Date:   Mon Dec 29 14:48:14 2014 +0100
+
+    vga: implement horizontal pel panning in graphics modes
+    
+    This implements smooth scrolling, as used for example by Commander Keen
+    and Second Reality.
+    
+    Unfortunately, this is not enough to avoid tearing in Commander Keen,
+    because sometimes the wrong start address is used for a frame.
+    On real EGA, the panning register is sampled on every line, while
+    the display start is latched for the next frame at the start of the
+    vertical retrace.  On real VGA, the panning register is also latched,
+    but at the end of the vertical retrace.  It looks like Keen exploits
+    this by only waiting for horizontal retrace when setting the display
+    start, but implementing it breaks the 256-color Keen games...
+    
+    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2263 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2263
new file mode 100644
index 00000000..b0d53834
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2263
@@ -0,0 +1,28 @@
+guest panics when attempting to perform loadvm operation on x86_64 platform with kvm_intel ept=0
+Description of problem:
+The guest experiences a panic when attempting to perform the `loadvm` operation after it has been running for a while on the x86_64 platform with `kvm_intel ept=0`. I'm unsure if this operation is permitted or not, but it functions properly when using `kvm_intel ept=1`.
+Steps to reproduce:
+1. Load the `kvm-intel` module with the parameter `ept=0`.
+2. savevm  
+Boot the first guest using the previous command line and switch to the QEMU console to execute the `savevm` operation. After that, proceed to shutting down the guest.
+3. loadvm  
+Boot the second guest using the same command line and switch to the QEMU console to execute the `loadevm` operation. After that, the guest panics.
+Additional information:
+I have performed some debugging and it seems that the issue lies in the fact that the VMM modifies the guest memory without informing the KVM module. Upon further investigation, I noticed that the `loadvm` operation only restores the memory and does not execute any ioctl to modify the user memory region recorded in the KVM module.
+
+The KVM module calls `kvm_mmu_reset_context()` to unload the current EPT or SPT page table when guest system registers (CR0/CR3/CR4) are restored. However, for EPT, the EPT page table is released directly and can be reconstructed at a later stage. In contrast, for SPT, the KVM only decreases the reference count and retains the outdated SPT page table in the active list that is maintained by the KVM. As a result, this outdated SPT page table is reused later, leading to incorrect mapping.
+
+To address this, I attempted to call `kvm_arch_flush_shadow_all()` to zap all the page tables in `kvm_mmu_reset_context()`, which allowed the guest to function properly with SPT after the `loadvm` operation.
+
+Therefore, I believe that QEMU should notify the KVM to clear all the page tables if the KVM is using shadow paging. However, it appears that there is no appropriate ioctl available for the VMM to achieve this.
+
+guest panic output:
+![image](/uploads/f7f3ad03c9bc5633105788f784b0544a/image.png)
+
+Trace the `kvm_mmu_get_page()` event and observe that only one record indicates that the outdated page table is reused instead of being recreated.
+
+
+```shell
+perf record -a -e kvmmmu:kvm_mmu_get_page
+```
+![image](/uploads/1393aefb585ad80050f8cc5ba7939fc3/image.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2266 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2266
new file mode 100644
index 00000000..cca7971a
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2266
@@ -0,0 +1,69 @@
+qemu-system-x86_64: stuck on watchpoint hit
+Description of problem:
+
+Steps to reproduce:
+1. `gcc -O0 -g watch-bug.c -o watch-bug`
+2. `gdb watch-bug`
+3. gdb commands:
+```
+b main
+r
+watch l1
+next  [ correct stop on the next line ]
+next  [ qemu is stuck as watchpoint should be hit ]
+```
+Additional information:
+* NOTE: it works correctly, if 'continue' command is used instead of 'next'
+
+
+`watch-bug.c`
+```c
+int i0;
+long l1;
+
+
+int main(int argc, char* argv[])
+{
+    i0 = argc;
+	l1 = i0 * 7;
+
+    return 0;
+}
+
+```
+
+Log:
+```c
+Log:
+root@qemux86-64:~# gdb watch-bug
+GNU gdb (GDB) 13.2
+Copyright (C) 2023 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+Type "show copying" and "show warranty" for details.
+This GDB was configured as "x86_64-poky-linux".
+Type "show configuration" for configuration details.
+For bug reporting instructions, please see:
+<https://www.gnu.org/software/gdb/bugs/>.
+Find the GDB manual and other documentation resources online at:
+    <http://www.gnu.org/software/gdb/documentation/>.
+
+For help, type "help".
+Type "apropos word" to search for commands related to "word"...
+Reading symbols from watch-bug...
+(gdb) b main
+Breakpoint 1 at 0x1134: file watch-bug.c, line 8.
+(gdb) r
+Starting program: /home/root/watch-bug 
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/lib/libthread_db.so.1".
+
+Breakpoint 1, main (argc=1, argv=0x7fffffffecd8) at watch-bug.c:8
+8           i0 = argc;
+(gdb) watch l1
+Hardware watchpoint 2: l1
+(gdb) next
+9           l1 = i0 * 7;
+(gdb) next
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2270 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2270
new file mode 100644
index 00000000..de76911e
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2270
@@ -0,0 +1 @@
+CPU topology recognition for Ryzen 9 7950X3D
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2320 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2320
new file mode 100644
index 00000000..70132252
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2320
@@ -0,0 +1 @@
+-Wchar-subscripts warnings in target/i386/tcg/decode-new.c.inc
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2330 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2330
new file mode 100644
index 00000000..af4d247f
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2330
@@ -0,0 +1,73 @@
+acpi-erst: divide by zero in make_erst_storage_header()
+Description of problem:
+When we gives `0` to `record_size` for `acpi-erst` device, below code may triggers divide-by-zero.
+
+```c
+static void make_erst_storage_header(ERSTDeviceState *s)
+    ...
+    header->magic = cpu_to_le64(ERST_STORE_MAGIC);
+    header->record_size = cpu_to_le32(s->default_record_size);
+    header->version = cpu_to_le16(0x0100);
+    header->reserved = cpu_to_le16(0x0000);
+
+    /* Compute mapsize */
+    mapsz = s->storage_size / s->default_record_size; // devide-by-zero occurs
+```
+
+`acpi-erst` device refuses invalid value for `record_size` and does appropriate condition check in `check_erst_backend_storage()`, but this check is placed before the function triggering the error when `header->magic` is 0.
+
+```c
+static void check_erst_backend_storage(ERSTDeviceState *s, Error **errp)
+    ...
+    /*
+     * Check if header is uninitialized; HostMemoryBackend inits to 0
+     */
+    if (le64_to_cpu(header->magic) == 0UL) {
+        make_erst_storage_header(s);
+    }
+
+    /* Validity check record_size */
+    record_size = le32_to_cpu(header->record_size);
+    if (!(
+        (record_size) && /* non zero */
+        (record_size >= UEFI_CPER_RECORD_MIN_SIZE) &&
+        (((record_size - 1) & record_size) == 0) && /* is power of 2 */
+        (record_size >= 4096) /* PAGE_SIZE */
+        )) {
+        error_setg(errp, "ERST record_size %u is invalid", record_size);
+        return;
+    }
+```
+Steps to reproduce:
+1. make sure `acpi-erst.backing` doesn't exist in current folder.
+2. run qemu command.
+```bash
+./build/qemu-system-i386 -object memory-backend-file,id=erstnvram,mem-path=acpi-erst.backing,size=0x10000,share=on -device acpi-erst,memdev=erstnvram,record_size=0
+```
+Additional information:
+I built qemu from source code with `--enable-sanitizers`, and backtrace is as follows:
+```bash
+AddressSanitizer:DEADLYSIGNAL
+=================================================================
+==401519==ERROR: AddressSanitizer: FPE on unknown address 0x55bd0616fd53 (pc 0x55bd0616fd53 bp 0x61f000000e80 sp 0x7fffd16e5d90 T0)
+    #0 0x55bd0616fd53 in make_erst_storage_header /home/xxx/qemu/build/../hw/acpi/erst.c:401
+    #1 0x55bd0616fd53 in check_erst_backend_storage /home/xxx/qemu/build/../hw/acpi/erst.c:431
+    #2 0x55bd0616fd53 in erst_realizefn /home/xxx/qemu/build/../hw/acpi/erst.c:973
+    #3 0x55bd06268426 in pci_qdev_realize /home/xxx/qemu/build/../hw/pci/pci.c:2093
+    #4 0x55bd06557629 in device_set_realized /home/xxx/qemu/build/../hw/core/qdev.c:510
+    #5 0x55bd0655ecc8 in property_set_bool /home/xxx/qemu/build/../qom/object.c:2362
+    #6 0x55bd0655cec4 in object_property_set /home/xxx/qemu/build/../qom/object.c:1471
+    #7 0x55bd06560dec in object_property_set_qobject /home/xxx/qemu/build/../qom/qom-qobject.c:28
+    #8 0x55bd0655d30a in object_property_set_bool /home/xxx/qemu/build/../qom/object.c:1541
+    #9 0x55bd0632f8cf in qdev_device_add_from_qdict /home/xxx/qemu/build/../system/qdev-monitor.c:719
+    #10 0x55bd0632fc91 in qdev_device_add /home/xxx/qemu/build/../system/qdev-monitor.c:738
+    #11 0x55bd0633ae7e in device_init_func /home/xxx/qemu/build/../system/vl.c:1203
+    #12 0x55bd066e7a50 in qemu_opts_foreach /home/xxx/qemu/build/../util/qemu-option.c:1135
+    #13 0x55bd06335421 in qemu_create_cli_devices /home/xxx/qemu/build/../system/vl.c:2640
+    #14 0x55bd06335421 in qmp_x_exit_preconfig /home/xxx/qemu/build/../system/vl.c:2709
+    #15 0x55bd06338f42 in qemu_init /home/xxx/qemu/build/../system/vl.c:3742
+    #16 0x55bd06553e35 in main /home/xxx/qemu/build/../system/main.c:47
+    #17 0x7efcdb919d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
+    #18 0x7efcdb919e3f in __libc_start_main_impl ../csu/libc-start.c:392
+    #19 0x55bd060ecb24 in _start (/home/xxx/qemu/build/qemu-system-i386+0x32db24)
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2334 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2334
new file mode 100644
index 00000000..324a1885
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2334
@@ -0,0 +1,252 @@
+[9.0.0] qemu breaks mac os vm
+Description of problem:
+Mac OS Monterey vm not able to boot after upgrading qemu to v. 9.0.0; no issue with qemu 8.2.2.
+This vm is booted with opencore latest version.
+The vm is not able to boot, apple logo is displayed on the screen for a bit, then the vm shutdowns, this is quite strange.
+I can't see anything useful in the logs.
+Changing machine type from q35-9.0 back to 8.2 doesn't solve the issue.
+The vm is booted via libvirt (latest version) and it's not a quite "base" vm, it has multiple passthroughs and other things.
+Before testing into details and starting to run base vms to see if it boots,maybe someone can see something wrong or maybe someone has the same issue.
+Reverting back to qemu 8.2.2 fixes all the issues and the vm is able to boot again.
+No issues with a windows 11 vm and with a kali vm.
+I can say that it's not a DSDT issue (a problem I was having in the past was related with DSTD), because injecting the DSDT of the vm started from v 8.2.2 doesn't boot it.
+
+This is the xml of the vm:
+
+```
+<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
+  <name>Monterey</name>
+  <memory unit='KiB'>33554432</memory>
+  <currentMemory unit='KiB'>33554432</currentMemory>
+  <memoryBacking>
+    <nosharepages/>
+  </memoryBacking>
+  <vcpu placement='static' current='28'>32</vcpu>
+  <vcpus>
+    <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/>
+    <vcpu id='1' enabled='yes' hotpluggable='yes' order='2'/>
+    <vcpu id='2' enabled='yes' hotpluggable='yes' order='3'/>
+    <vcpu id='3' enabled='yes' hotpluggable='yes' order='4'/>
+    <vcpu id='4' enabled='yes' hotpluggable='yes' order='5'/>
+    <vcpu id='5' enabled='yes' hotpluggable='yes' order='6'/>
+    <vcpu id='6' enabled='yes' hotpluggable='yes' order='7'/>
+    <vcpu id='7' enabled='yes' hotpluggable='yes' order='8'/>
+    <vcpu id='8' enabled='yes' hotpluggable='yes' order='9'/>
+    <vcpu id='9' enabled='yes' hotpluggable='yes' order='10'/>
+    <vcpu id='10' enabled='yes' hotpluggable='yes' order='11'/>
+    <vcpu id='11' enabled='yes' hotpluggable='yes' order='12'/>
+    <vcpu id='12' enabled='yes' hotpluggable='yes' order='13'/>
+    <vcpu id='13' enabled='yes' hotpluggable='yes' order='14'/>
+    <vcpu id='14' enabled='yes' hotpluggable='yes' order='15'/>
+    <vcpu id='15' enabled='yes' hotpluggable='yes' order='16'/>
+    <vcpu id='16' enabled='yes' hotpluggable='yes' order='17'/>
+    <vcpu id='17' enabled='yes' hotpluggable='yes' order='18'/>
+    <vcpu id='18' enabled='yes' hotpluggable='yes' order='19'/>
+    <vcpu id='19' enabled='yes' hotpluggable='yes' order='20'/>
+    <vcpu id='20' enabled='yes' hotpluggable='yes' order='21'/>
+    <vcpu id='21' enabled='yes' hotpluggable='yes' order='22'/>
+    <vcpu id='22' enabled='yes' hotpluggable='yes' order='23'/>
+    <vcpu id='23' enabled='yes' hotpluggable='yes' order='24'/>
+    <vcpu id='24' enabled='yes' hotpluggable='yes' order='25'/>
+    <vcpu id='25' enabled='yes' hotpluggable='yes' order='26'/>
+    <vcpu id='26' enabled='yes' hotpluggable='yes' order='27'/>
+    <vcpu id='27' enabled='yes' hotpluggable='yes' order='28'/>
+    <vcpu id='28' enabled='no' hotpluggable='yes'/>
+    <vcpu id='29' enabled='no' hotpluggable='yes'/>
+    <vcpu id='30' enabled='no' hotpluggable='yes'/>
+    <vcpu id='31' enabled='no' hotpluggable='yes'/>
+  </vcpus>
+  <iothreads>2</iothreads>
+  <iothreadids>
+    <iothread id='1'/>
+    <iothread id='2'/>
+  </iothreadids>
+  <cputune>
+    <vcpupin vcpu='0' cpuset='1'/>
+    <vcpupin vcpu='1' cpuset='2'/>
+    <vcpupin vcpu='2' cpuset='3'/>
+    <vcpupin vcpu='3' cpuset='4'/>
+    <vcpupin vcpu='4' cpuset='5'/>
+    <vcpupin vcpu='5' cpuset='6'/>
+    <vcpupin vcpu='6' cpuset='7'/>
+    <vcpupin vcpu='7' cpuset='9'/>
+    <vcpupin vcpu='8' cpuset='10'/>
+    <vcpupin vcpu='9' cpuset='11'/>
+    <vcpupin vcpu='10' cpuset='12'/>
+    <vcpupin vcpu='11' cpuset='13'/>
+    <vcpupin vcpu='12' cpuset='14'/>
+    <vcpupin vcpu='13' cpuset='15'/>
+    <vcpupin vcpu='14' cpuset='17'/>
+    <vcpupin vcpu='15' cpuset='18'/>
+    <vcpupin vcpu='16' cpuset='19'/>
+    <vcpupin vcpu='17' cpuset='20'/>
+    <vcpupin vcpu='18' cpuset='21'/>
+    <vcpupin vcpu='19' cpuset='22'/>
+    <vcpupin vcpu='20' cpuset='23'/>
+    <vcpupin vcpu='21' cpuset='25'/>
+    <vcpupin vcpu='22' cpuset='26'/>
+    <vcpupin vcpu='23' cpuset='27'/>
+    <vcpupin vcpu='24' cpuset='28'/>
+    <vcpupin vcpu='25' cpuset='29'/>
+    <vcpupin vcpu='26' cpuset='30'/>
+    <vcpupin vcpu='27' cpuset='31'/>
+    <emulatorpin cpuset='0,8,16,24'/>
+  </cputune>
+  <os>
+    <type arch='x86_64' machine='pc-q35-8.2'>hvm</type>
+    <loader readonly='yes' type='pflash'>/opt/macos/AUDK_CODE.fd</loader>
+    <nvram>/opt/macos/AUDK_VARS.fd</nvram>
+    <boot dev='hd'/>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+  </features>
+  <cpu mode='host-passthrough' check='none' migratable='on'>
+    <topology sockets='2' dies='1' clusters='1' cores='8' threads='2'/>
+  </cpu>
+  <clock offset='utc'>
+    <timer name='rtc' tickpolicy='catchup'/>
+    <timer name='pit' tickpolicy='delay'/>
+    <timer name='hpet' present='no'/>
+  </clock>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>restart</on_crash>
+  <devices>
+    <emulator>/usr/bin/qemu-system-x86_64</emulator>
+    <controller type='pci' index='0' model='pcie-root'/>
+    <controller type='pci' index='1' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='1' port='0x8' hotplug='off'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/>
+    </controller>
+    <controller type='pci' index='2' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='2' port='0x9' hotplug='off'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
+    </controller>
+    <controller type='pci' index='3' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='3' port='0xc' hotplug='off'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
+    </controller>
+    <controller type='pci' index='4' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='4' port='0x13' hotplug='off'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/>
+    </controller>
+    <controller type='virtio-serial' index='0'>
+      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-ehci1'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-uhci1'>
+      <master startport='0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/>
+    </controller>
+    <controller type='sata' index='0'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
+    </controller>
+    <interface type='bridge'>
+      <mac address='c8:2a:14:66:2c:a1'/>
+      <source bridge='br0'/>
+      <model type='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
+    </interface>
+    <interface type='bridge'>
+      <mac address='c8:2a:14:31:32:e2'/>
+      <source bridge='br1'/>
+      <model type='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+    </interface>
+    <serial type='pty'>
+      <target type='isa-serial' port='0'>
+        <model name='isa-serial'/>
+      </target>
+    </serial>
+    <console type='pty'>
+      <target type='serial' port='0'/>
+    </console>
+    <channel type='unix'>
+      <target type='virtio' name='org.qemu.guest_agent.0'/>
+      <address type='virtio-serial' controller='0' bus='0' port='1'/>
+    </channel>
+    <input type='keyboard' bus='ps2'/>
+    <input type='mouse' bus='ps2'/>
+    <audio id='1' type='none'/>
+    <hostdev mode='subsystem' type='pci' managed='yes'>
+      <driver name='vfio'/>
+      <source>
+        <address domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
+      </source>
+      <rom file='/opt/gpu-bios/6900xt.rom'/>
+      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0' multifunction='on'/>
+    </hostdev>
+    <hostdev mode='subsystem' type='pci' managed='yes'>
+      <driver name='vfio'/>
+      <source>
+        <address domain='0x0000' bus='0x06' slot='0x00' function='0x1'/>
+      </source>
+      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x1'/>
+    </hostdev>
+    <hostdev mode='subsystem' type='pci' managed='yes'>
+      <driver name='vfio'/>
+      <source>
+        <address domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
+      </source>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+    </hostdev>
+    <hostdev mode='subsystem' type='pci' managed='yes'>
+      <driver name='vfio'/>
+      <source>
+        <address domain='0x0000' bus='0x0c' slot='0x00' function='0x0'/>
+      </source>
+      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
+    </hostdev>
+    <hostdev mode='subsystem' type='pci' managed='yes'>
+      <driver name='vfio'/>
+      <source>
+        <address domain='0x0000' bus='0x84' slot='0x00' function='0x0'/>
+      </source>
+      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
+    </hostdev>
+    <hostdev mode='subsystem' type='usb' managed='no'>
+      <source>
+        <vendor id='0x046d'/>
+        <product id='0x0892'/>
+      </source>
+      <address type='usb' bus='0' port='2'/>
+    </hostdev>
+    <hostdev mode='subsystem' type='usb' managed='no'>
+      <source>
+        <vendor id='0x148f'/>
+        <product id='0x3070'/>
+      </source>
+      <address type='usb' bus='0' port='1'/>
+    </hostdev>
+    <watchdog model='itco' action='reset'/>
+    <memballoon model='none'/>
+  </devices>
+  <qemu:commandline>
+    <qemu:arg value='-smbios'/>
+    <qemu:arg value='type=2'/>
+    <qemu:arg value='-global'/>
+    <qemu:arg value='ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off'/>
+    <qemu:arg value='-global'/>
+    <qemu:arg value='pcie-root-port.x-speed=8'/>
+    <qemu:arg value='-global'/>
+    <qemu:arg value='pcie-root-port.x-width=16'/>
+    <qemu:arg value='-cpu'/>
+    <qemu:arg value='host,+hypervisor,migratable=no,-erms,kvm=on,+invtsc,+topoext,+avx,+aes,+xsave,+xsaveopt,+ssse3,+sse4_2,+popcnt,+arat,+pclmuldq,+pdpe1gb,+rdtscp,+vme,+umip,check'/>
+  </qemu:commandline>
+</domain>
+```
+
+06:00.0/1 --> gpu
+00:1b.0 --> audio
+0c:00.0 --> sata controller
+84:00.0 --> usb controller
+0x046d 0x0892 --> usb webcam
+0x148f 0x3070 --> usb wifi
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/237 b/gitlab/issues_text/target_i386/host_missing/accel_missing/237
new file mode 100644
index 00000000..8051f1ca
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/237
@@ -0,0 +1 @@
+[Feature request] x86: dump MSR features in human form
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2381 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2381
new file mode 100644
index 00000000..cc1178bf
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2381
@@ -0,0 +1,3 @@
+Modern x86 TSC features under TCG
+Additional information:
+I may be able to find a volunteer to implement this. If this feature does not appear to be a good first task, please let me know.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2383 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2383
new file mode 100644
index 00000000..7f9eb028
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2383
@@ -0,0 +1,3 @@
+Support SMRR for x86 emulation
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2393 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2393
new file mode 100644
index 00000000..4e53ee99
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2393
@@ -0,0 +1,20 @@
+qemu: seabios hangs for 10~15 sec at boot with `-machine q35`
+Description of problem:
+Whenever i'm starting a virtual machine i'm having the issue that seabios (or at least that's what i see) hangs for about 10~15 seconds. In that time on of the cpu cores runs at 100%.
+This issue isn't new actually. I'm having this already for quite some time and a i think for at least the last 2 major versions. I haven't looked into it since it isn't a big issue, just annoying.
+Today i've looked into it and as far as i can see, this issue is always present with the flag `-machine q35`, which is the default for my vm's. If i set it to `-machine pc`, booting works as expected. However i also found a "workaround" where the vm's starting immediately (with `-machine q35` enabled), which is by simply adding a iso image to the command line (via -cdrom) - even though it's not used.
+
+This means:
+- 15 sec delay: qemu-system-x86_64 -machine q35
+- works immediately: qemu-system-x86_64 -machine q35 -cdrom /mnt/data/vm/isos/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20230303-Media.iso
+
+Please note that most of my vm's usually start booting from a kernel image directly (-kernel /mnt/data/vm/kernel/gentoo-latest -initrd /mnt/data/vm/kernel/initrd-v5.cpio.gz) - but even in that case settings a cdrom (image) would fix the issue.
+Also, the image needs to be a valid one, if i set an empty file or /dev/null the issue would remain.
+Further more, i have the same issue on a second computer. This also runs on Gentoo Linux and is also a AMD Ryzen. (in case this is relevant)
+Steps to reproduce:
+1. qemu-system-x86_64 -machine q35
+2. wait about 10-15sec before boot continues
+Additional information:
+I was thinking to add an Screenshot of the hanging boot process, but the only text written there is:
+SeaBIOS (version 1.16.0-20220807_005459-localhost)
+with a blinking cursor below
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2420 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2420
new file mode 100644
index 00000000..0bf284e0
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2420
@@ -0,0 +1,44 @@
+Error: Deprecated CPU topology (considered invalid): Unsupported cluster parameter musn't be specified as 1
+Description of problem:
+warning: Deprecated CPU topology (considered invalid): Unsupported clusters parameter mustn't be specified as 1
+VM does not start
+
+What I've tried so far to fix:
+
+- Removed the offending `clusters="1"` parameter in the XML, both via virsh edit and virt-manager but the sucker comes back every time!
+
+- Creating a completely new VM from scratch, just keeping the qcow2 for Windows. What happens then is funny: The initial setup goes well. Machine type automatically gets set to q35 version 9.0. After setting up my cores (pinning) for the VM (7C/14T for the VM 1C/2T for host), there is no "clusters" parameter anymore. So the first start went well. After a RESTART of the whole host machine and subsequent launch of the VM guess what happened? The "clusters" thing is back in full swing.
+Steps to reproduce:
+1. Create Windows 11 VM with virt-manager
+2. Try to do core pinning and setting up the following in virt manager before
+- Copy CPU configuration from host (host-passthrough)
+- Manually set CPU structure via GUI to 1 Socket, 7 Cores, 2 Threads on an 8 Core (in my case 11900k)
+3. Observe result in XML being: 
+ `<topology sockets="1" dies="1" clusters="1" cores="7" threads="2"/>`
+
+Again, the "clusters" entry leads to the VM not starting. Removing it doesn't work, it comes back straight away. I tried in virt-manager as well as with virsh edit.
+Additional information:
+My core pinning for reference:
+
+```
+<vcpu placement="static">14</vcpu>
+  <iothreads>1</iothreads>
+  <cputune>
+    <vcpupin vcpu="0" cpuset="0"/>
+    <vcpupin vcpu="1" cpuset="8"/>
+    <vcpupin vcpu="2" cpuset="1"/>
+    <vcpupin vcpu="3" cpuset="9"/>
+    <vcpupin vcpu="4" cpuset="2"/>
+    <vcpupin vcpu="5" cpuset="10"/>
+    <vcpupin vcpu="6" cpuset="3"/>
+    <vcpupin vcpu="7" cpuset="11"/>
+    <vcpupin vcpu="8" cpuset="4"/>
+    <vcpupin vcpu="9" cpuset="12"/>
+    <vcpupin vcpu="10" cpuset="5"/>
+    <vcpupin vcpu="11" cpuset="13"/>
+    <vcpupin vcpu="12" cpuset="6"/>
+    <vcpupin vcpu="13" cpuset="14"/>
+    <emulatorpin cpuset="7,15"/>
+    <iothreadpin iothread="1" cpuset="7,15"/>
+  </cputune>
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2426 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2426
new file mode 100644
index 00000000..878f3517
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2426
@@ -0,0 +1 @@
+How to determine which cpu microarchitecture is suitable for use on Windows 11?
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/243 b/gitlab/issues_text/target_i386/host_missing/accel_missing/243
new file mode 100644
index 00000000..9cf1fa68
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/243
@@ -0,0 +1 @@
+Qemu refuses to multiboot Elf64 kernels
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2452 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2452
new file mode 100644
index 00000000..185f5d0e
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2452
@@ -0,0 +1 @@
+memory allocation for AMDVIIOTLBEntry in amdvi_update_iotlb()
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2509 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2509
new file mode 100644
index 00000000..11eafe55
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2509
@@ -0,0 +1,26 @@
+With qemu-system-i386 certain iso images cause looping crashes
+Description of problem:
+Soon after start seabios tries to boot, a crash followed by a loop occurs. Last line seen before crash and loop:
+   ```
+Booting from DVD/CD...
+   ```
+Steps to reproduce:
+1. Download https://www.qemu-advent-calendar.org/2018/download/day10.tar.xz
+2. Execute QEMU command line
+Additional information:
+Starting VM with qemu-system-x86_64 works
+   ```
+   qemu-system-x86_64 -cdrom gamebro.iso
+   ```
+Starting VM with qemu-system-i386 using KVM causes looping
+   ```
+   qemu-system-i386 -accel kvm -cdrom gamebro.iso
+   ```
+Starting VM with qemu-system-i386 on Windows using WHPX works
+   ```
+   qemu-system-i386.exe -accel whpx -cdrom gamebro.iso
+   ```
+Starting other iso images works, e.g. https://cdimage.debian.org/mirror/cdimage/archive/10.8.0/i386/iso-cd/debian-10.8.0-i386-netinst.iso
+   ```
+   qemu-system-i386 -cdrom debian-10.8.0-i386-netinst.iso
+   ```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2520 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2520
new file mode 100644
index 00000000..6c81af7c
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2520
@@ -0,0 +1,11 @@
+qemu-system-x86_64 : No Display when system wakeup from suspend
+Description of problem:
+Qemu display window is blank with message `Display output is not active.`
+Steps to reproduce:
+1. Use https://gitlab.com/berrange/tiny-vm-tools/-/blob/master/make-tiny-image.py to generate tiny-initrd.img
+2. Run qemu and drop into shell
+3. Put machine into S3 (echo mem > /sys/power/state)
+4. Use socat to connect to QEMU monitor and wake up the machine (system_wakeup)
+5. System resumes in shell, but no output in display
+Additional information:
+Same behavior, if I try standard ubuntu22.04.qcow2 image. Before suspend GUI is there and after wakeup from suspend  blank display with message `Display output is not active.`
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2530 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2530
new file mode 100644
index 00000000..6379633d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2530
@@ -0,0 +1,17 @@
+Duplicate ACPI _SUN
+Description of problem:
+ACPI _SUN is `the slot-unique ID number for a slot`, but qemu uses `PCI_SLOT()` which is definitely not unique
+https://gitlab.com/qemu-project/qemu/-/blob/407f9a4b121eb65166375c410e14d7b704bc1106/hw/i386/acpi-build.c#L524
+Steps to reproduce:
+1. Create a linux VM with 2 virtio NICs
+2. Look at the ACPI _SUN of the virtio-pci devices (firmware_node/sun)
+
+Both virtio-pci devices have _SUN == 0
+```
+#
+Additional information:
+In systemd we recently introduced code to use firmware_node/sun information for NIC naming
+https://github.com/systemd/systemd/commit/0a4ecc54cb9f2d3418b970c51bfadb69c34ae9eb
+
+but having duplicate _SUN is of course problematic
+https://github.com/systemd/systemd/issues/34082
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2555 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2555
new file mode 100644
index 00000000..07812020
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2555
@@ -0,0 +1,20 @@
+Can't start a guest with 2 IOAPICs
+Description of problem:
+For a host with multiple IOAPICs, I want to start a guest with 2 IOAPICs. I saw this commit about this function: **[x86: add support for second ioapic]**:
+     https://gitlab.com/qemu-project/qemu/-/commit/94c5a606379ddd04beecdb11fb34b51b4b28c7f2
+
+But after I started a guest in a host with multiple IOAPICs, there was still only one IOAPIC in guest. How should I enable this feature?
+Additional information:
+Host IOAPICs Info:
+   ```
+[    1.268280] IOAPIC[0]: apic_id 0, version 33, address 0xfec00000, GSI 0-23
+[    1.268286] IOAPIC[1]: apic_id 1, version 33, address 0xfec20000, GSI 24-55
+[    1.268291] IOAPIC[2]: apic_id 2, version 33, address 0xd9000000, GSI 56-87
+[    4.415313] ACPI: Using IOAPIC for interrupt routing
+   ```
+
+Guest IOAPIC Info:
+   ```
+[    0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23
+[    0.255045] ACPI: Using IOAPIC for interrupt routing
+   ```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2556 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2556
new file mode 100644
index 00000000..675938d4
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2556
@@ -0,0 +1,12 @@
+memory balloon massively slows Windows shutdown (almost feels like it crashed for minutes)
+Description of problem:
+When reducing the memory using ballooning, the shutdown takes very long. One may even assume it crashed, but it will eventually power off.
+Steps to reproduce:
+1. wait until Windows has booted
+2. reduce the balloon by multiple GB via monitor: `balloon 8192` _(8 GB balloon, memory size is 24 GB)_
+3. Shut down (or reboot) Windows
+
+The system shows the boot screen at shutdown for a long time.
+
+It's about 10 seconds extra time per reduced balloon size. So when resizing the balloon from 24 GB to 8 GB, that's 16 GB.  
+So the shutdown needs: 16 * 10 = 160 seconds = **about 3 minutes**
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2562 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2562
new file mode 100644
index 00000000..7e59dcbc
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2562
@@ -0,0 +1,52 @@
+Booting EFI shell from GRUB using "chainloader" in Qemu with UEFI boot shows video artifacts if we have all_video, gfxterm
+Steps to reproduce:
+- Start Qemu in UEFI mode, i. e. `qemu-system-x86_64 -bios OVMF.fd ...`
+- Qemu should load GRUB from the disk as the first thing after firmware
+- GRUB should run commands `loadfont unicode; insmod all_video; terminal_output gfxterm` (note: this is perfectly ordinary sequence executed by Debian's default configuration)
+- Then GRUB should execute EFI shell using `chainloader` command
+
+If we do all this, then instead of EFI shell we will see broken image. I. e. video output will be completely broken/mangled/damaged. But EFI shell will still respond to commands. If we type "exit", then we will exit from EFI shell back to GRUB.
+
+I will repeat: my configuration is not special at all. `loadfont unicode; insmod all_video; terminal_output gfxterm` are absolutely ordinary commands executed by Debian's GRUB default setup. So, essentially this bug means this: if I add EFI shell to GRUB menu in Debian, then this new menu entry will not work properly if I try to boot in Qemu in UEFI mode.
+
+Okay, now let me give you more detailed steps to reproduce.
+
+- Execute the following script on Linux x86_64 host:
+```bash
+#!/bin/bash
+# This script was tested on Debian trixie (as on 2024-09-07) with the following packages installed:
+# dosfstools grub-efi-amd64-bin qemu-system-x86 ovmf efi-shell-x64
+set -e
+DIR="$(mktemp -d /tmp/qemu-bug-XXXXXX)"
+truncate --size=100M "$DIR/disk"
+echo ',+,' | sfdisk --label gpt "$DIR/disk"
+LOOP="$(losetup --find --show --partscan --nooverlap "$DIR/disk")"
+sleep 1
+mkfs.vfat "${LOOP}p1"
+mkdir "$DIR/root"
+mount "${LOOP}p1" "$DIR/root"
+losetup --detach "$LOOP"
+mkdir -p "$DIR/root/EFI/boot" "$DIR/root/boot/grub/fonts"
+grub-mkimage --format=x86_64-efi --output="$DIR/root/EFI/boot/bootx64.efi" --prefix=/boot/grub part_gpt fat
+cp -r /usr/lib/grub/x86_64-efi "$DIR/root/boot/grub"
+cp /usr/share/efi-shell-x64/shellx64.efi "$DIR/root/boot"
+cp /usr/share/grub/unicode.pf2 "$DIR/root/boot/grub/fonts"
+cat << "EOF" > "$DIR/root/boot/grub/grub.cfg"
+loadfont unicode
+insmod all_video
+terminal_output gfxterm
+menuentry "EFI shell" {
+  chainloader /boot/shellx64.efi
+}
+EOF
+umount "$DIR/root"
+qemu-system-x86_64 -m 2048 -bios OVMF.fd -drive file="$DIR/disk",format=raw
+```
+- When you see Qemu window, choose "EFI shell" menu entry in GRUB menu
+- You will immediately see damaged video output instead of proper EFI shell
+
+This bug doesn't reproduce on real hardware, i. e. without Qemu!!! I. e. this is Qemu bug. Qemu task is to duplicate real hardware behaviour. On real hardware there is no this bug, so Qemu should not have it, either.
+
+Note: if I remove `loadfont unicode; insmod all_video; terminal_output gfxterm`, then the bug disappears.
+
+Also note: if I replace `all_video` with `efi_gop`, then the bug disappears, too. So, workaround is to use `efi_gop` instead of `all_video` in UEFI mode. But I still believe the bug is in Qemu, because `all_video` doesn't cause any problems on real hardware, so Qemu should work, too.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2583 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2583
new file mode 100644
index 00000000..0cb5722f
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2583
@@ -0,0 +1,25 @@
+libvfio-user.so.0 missing in /lib/x86_64-linux-gnu/  in fresh install of 9.1.50
+Description of problem:
+Library libvfio-user.so.0  is missing from /lib/x86_64-linux-gnu. qemu-system-x86_64 does not start due to missing library.
+
+````
+root@jpbdeb:~# ls -al /usr/local/bin/qemu-system-x86_64 
+-rwxr-xr-x 1 root root 81734576 Sep 21 21:48 /usr/local/bin/qemu-system-x86_64
+root@jpbdeb:~# ldd /usr/local/bin/qemu-system-x86_64 
+	linux-vdso.so.1 (0x00007fff511de000)
+	libvfio-user.so.0 => not found
+	libslirp.so.0 => /lib/x86_64-linux-gnu/libslirp.so.0 (0x00007f73eba33000)
+	libxenctrl.so.4.17 => /lib/x86_64-linux-gnu/libxenctrl.so.4.17 (0x00007f73eba09000)
+	libxenstore.so.4 => /lib/x86_64-linux-gnu/libxenstore.so.4 (0x00007f73eb9fe000)
+	libxenforeignmemory.so.1 => /lib/x86_64-linux-gnu/libxenforeignmemory.so.1 (0x00007f73eb9f9000)
+        ...
+````
+Steps to reproduce:
+1. Fresh OS install, including all packages necessary to build from source.
+2. Download source from gitlab and proceed with documented build instructions.
+3. make install
+4. Attempt to run /usr/local/bin/qemu-system-x86_64  fails, due to missing library.
+Additional information:
+Adding the link to the library that exists in /usr/lib/x86_64-linux-gnu  resolves the issue:
+
+(as root) ln -s /usr/local/lib/x86_64-linux-gnu/libvfio-user.so.0  /lib/x86_64-linux-gnu/libvfio-user.so.0
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2586 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2586
new file mode 100644
index 00000000..d6120a48
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2586
@@ -0,0 +1,3 @@
+qemu-system-x86_64: IGD "legacy mode" support with Q35?
+Additional information:
+Detailed discussion on https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12103
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2590 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2590
new file mode 100644
index 00000000..9e751ec7
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2590
@@ -0,0 +1,23 @@
+qemu-x86_64: gdb doesn't read symbols from dynamically linked shared libraries.
+Description of problem:
+GDB fails to load dynamically linked shared libraries when connecting to qemu-x86_64, causing it to not recognize symbols from the shared libraries. As a result, breakpoints in shared library functions (e.g, `break printf`) do not work.
+Steps to reproduce:
+1. Start the debug server: `./qemu-x86_64 -g PORT ./x86_64-binary`
+2. Connect GDB to the debug server:
+```
+$ gdb-multiarch ./x86_64-binary
+(gdb) set verbose on
+(gdb) target remote :PORT
+```
+3. GDB displays a warning and fails to load shared libraries:
+```
+(gdb) target remote :PORT
+Remote debugging using :PORT
+warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
+(gdb) info sharedlibrary
+No shared libraries loaded at this time.
+```
+Additional information:
+This issue does not occur when using gdbserver on a native x86_64 machine and connecting to it from gdb-multiarch on an ARM64 machine, indicating the issue is likely related to QEMU rather than GDB. 
+
+GDB correctly recognizes symbols from the target binary (e.g., the `main` function), and breakpoints at these symbols function as expected.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2593 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2593
new file mode 100644
index 00000000..4f541842
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2593
@@ -0,0 +1,57 @@
+-netdev user,smb=/path doesn't work with old Windows versions anymore
+Description of problem:
+I'm running Windows 98 in qemu and wasn't able to access the share. After finding `/tmp/qemu-smb.*/` and increasing the log level (setting `log level = 10` in the temporary smb.conf) it became clear, that the smbd server didn't support any of the protocols offered by Win98:
+
+<details>
+
+```
+[2024/09/25 23:04:25.871072, 10, pid=40892, effective(1000, 1000), real(1000, 1000)] ../../lib/util/util.c:580(dump_data)
+  [0000] 02 50 43 20 4E 45 54 57   4F 52 4B 20 50 52 4F 47   .PC NETW ORK PROG
+  [0010] 52 41 4D 20 31 2E 30 00   02 4D 49 43 52 4F 53 4F   RAM 1.0. .MICROSO
+  [0020] 46 54 20 4E 45 54 57 4F   52 4B 53 20 33 2E 30 00   FT NETWO RKS 3.0.
+  [0030] 02 44 4F 53 20 4C 4D 31   2E 32 58 30 30 32 00 02   .DOS LM1 .2X002..
+  [0040] 44 4F 53 20 4C 41 4E 4D   41 4E 32 2E 31 00 02 57   DOS LANM AN2.1..W
+  [0050] 69 6E 64 6F 77 73 20 66   6F 72 20 57 6F 72 6B 67   indows f or Workg
+  [0060] 72 6F 75 70 73 20 33 2E   31 61 00 02 4E 54 20 4C   roups 3. 1a..NT L
+  [0070] 4D 20 30 2E 31 32 00                                M 0.12.
+[2024/09/25 23:04:25.871241,  3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot)
+  Requested protocol [PC NETWORK PROGRAM 1.0]
+[2024/09/25 23:04:25.871247,  3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot)
+  Requested protocol [MICROSOFT NETWORKS 3.0]
+[2024/09/25 23:04:25.871252,  3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot)
+  Requested protocol [DOS LM1.2X002]
+[2024/09/25 23:04:25.871256,  3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot)
+  Requested protocol [DOS LANMAN2.1]
+[2024/09/25 23:04:25.871260,  3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot)
+  Requested protocol [Windows for Workgroups 3.1a]
+[2024/09/25 23:04:25.871264,  3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot)
+  Requested protocol [NT LM 0.12]
+...
+[2024/09/25 23:04:25.871315,  6, pid=40892, effective(1000, 1000), real(1000, 1000)] ../../source3/param/loadparm.c:2442(lp_file_list_changed)
+  lp_file_list_changed()
+  file /tmp/qemu-smb.TU2YU2/smb.conf -> /tmp/qemu-smb.TU2YU2/smb.conf  last mod_time: 2024-09-25 23:04:20.374500597
+[2024/09/25 23:04:25.871325,  3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1201(smb2_multi_protocol_reply_negprot)
+  smb2_multi_protocol_reply_negprot: No protocol supported !
+
+```
+
+</details>
+
+(`smb2_multi_protocol_reply_negprot: No protocol supported !`).
+
+Manually adding the line `server min protocol = LANMAN1` under `[global]` in the temporary `smb.conf` fixed the issue.
+I think qemu should add that line by default.
+
+The behavior was the same with smbd 4.15.13-Ubuntu from Ubuntu 22.04 and 4.21.0 from current Arch Linux.
+Steps to reproduce:
+1. Set up qemu VM with Win98 (or presumably any Windows version up to XP)
+   * at least on my machine I had to use `tcg`, with `kvm` Win98 is very unstable on Ryzen CPUs
+   * I roughly followed this tutorial: https://computernewb.com/wiki/QEMU/Guests/Windows_98 incl. using that Windows 98 QuickInstall ISO and the softgpu driver
+   * enable user-mode networking with smb share (`-netdev user,id=lan,smb=/path/to/share -device pcnet,netdev=lan`)
+2. Edit `C:\Windows\LMHOSTS` as described in the qemu documentation (add line `10.0.2.4 smbserver`)
+3. Probably reboot the Windows VM
+   * Actually, rebooting Win98 doesn't work for me, it then hangs while booting. Shutting down and starting the VM again works though.
+4. Open the Windows Explorer and enter `\\smbserver` in the address bar - it will fail with some unhelpful error.
+5. Edit `/tmp/qemu-smb.*/smb.conf` and add the line `server min protocol = LANMAN1` under `[global]`
+   - `server min protocol = NT1` also works for Win98, but with `LANMAN1` even older operating systems like Win3.11 should also work
+6. Retry step 4 - it should work now.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2594 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2594
new file mode 100644
index 00000000..5907a251
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2594
@@ -0,0 +1,35 @@
+Migration fails with 'get_pci_config_device: Bad config data: i=0x9a read: 2 device: 3 cmask: ff wmask: 0 w1cmask:0' after hotplugging a CPU
+Description of problem:
+After hotplugging a CPU and finishing a migration from node 1 to node 2, the instance on node 2 crashes when virtio block devices are used:
+```
+qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x9a read: 2 device: 3 cmask: ff wmask: 0 w1cmask:0
+qemu-system-x86_64: Failed to load PCIDevice:config
+qemu-system-x86_64: Failed to load virtio-blk:virtio
+qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:04.0/virtio-blk'
+qemu-system-x86_64: load of migration failed: Invalid argument
+```
+
+I found the problem also exhibits when using `scsi-hd` in combination with `virtio-scsi`, but not when using IDE hard disks or SCSI disks with an LSI controller. VMs with network cards aren't affected either, as are VMs without virtio disks.
+
+
+Interestingly, the latest QEMU version shipped with Ubuntu 20.04 (4.2.1-Debian 1:4.2-3ubuntu6.29) is able to migrate this VM just fine.
+Steps to reproduce:
+1. Start a VM using the first command line
+2. Start another VM using the second command line
+3. Hotplug a CPU in QMP:
+   ```
+   {"execute":"device_add","arguments":{"node-id":0,"socket-id":0,"core-id":2,"thread-id":0,"id":{},"driver":"qemu64-x86_64-cpu"}}
+   ```
+4. Start a migration by executing the following QMP command (again substituting `<ip:port>` with the IP:port combination of node 2
+   ```
+   {"execute":"migrate","arguments":{"uri":"tcp:127.0.0.1:1234"}}
+   ```
+
+(For steps 3 and 4 I used this):
+```
+echo '{"execute":"qmp_capabilities"}
+{"execute":"device_add","arguments":{"node-id":0,"socket-id":0,"core-id":2,"thread-id":0,"id":{},"driver":"qemu64-x86_64-cpu"},"id":1}
+{"execute":"migrate","arguments":{"uri":"tcp:127.0.0.1:1234"},"id":2}' | nc -U /tmp/vm1.sock
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2597 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2597
new file mode 100644
index 00000000..c7dcf7f0
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2597
@@ -0,0 +1 @@
+qemu-i386 crashes on ppc64el
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2616 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2616
new file mode 100644
index 00000000..dc51a261
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2616
@@ -0,0 +1,11 @@
+crashout on any storage operation on SCO OpenServer 6
+Description of problem:
+it's hard to exactly pinpoint what's wrong, but apparently it's a known issue. whenever i attempt to install or boot the OS, i get one of the two outcomes: with KVM it's a halt-and-catch-fire, getting stuck in an eternal loop of I/O errors and failed interrupts, with TCG at the very least the drivers get loaded and the installation disk is mounted, contrary to the emulated hard drive. connecting either drive to SCSI made HBA act like it's not there at all, and using the standard AHCI/IDE controllers leads to the result presented in the picture in one of the sections below, and, as mentioned earlier, this stage only happens with TCG. there's a 9:1 shot (on Q35, on PIIX3/PIIX4 it'll always either throw this exception or fail to initialise the CD-ROM) of it either screaming about a power failure right as it's ready to format the drive or it just installing.
+Steps to reproduce:
+1. download the old OpenServer 6 VM image/ISO from the SCO/Xinuos server.
+2. attach it in your config.
+3. go through initial setup stages (eg. entering a licence or deferring from such).
+4. wait for the disk initialisation to begin.
+Additional information:
+![example on the prebuilt image for VMware with a 1:1 compatible config](/uploads/995fab2ebccecba2e9d90f73519ac118/Screenshot_from_2024-10-10_21-34-39.png)
+![example of installing with PIIX3/PIIX4](/uploads/2b8685dcdb998acd0cfc2121f9951290/Screenshot_from_2024-10-11_18-26-05.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2626 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2626
new file mode 100644
index 00000000..b0dc6d97
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2626
@@ -0,0 +1,8 @@
+QEMU crashes after host time moves backwards
+Description of problem:
+QEMU process crashes after time synchronized and moved backwards on the host.
+Steps to reproduce:
+As detailed in the [thread](https://bugzilla.redhat.com/show_bug.cgi?id=2228406)
+
+1. create a virtual machine and change tick period in the guest
+2. executing `while [ 1 ];do hwclock --systohc; hwclock --hctosys;done` on the host
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2631 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2631
new file mode 100644
index 00000000..cce15ebc
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2631
@@ -0,0 +1,81 @@
+qemu-system-i386: void msix_vector_use(PCIDevice *, unsigned int): Assertion `vector < dev->msix_entries_nr' failed.
+Description of problem:
+While fuzzing, we observed a assertion failures in several virtio devices supporting msi-x functionality.
+Steps to reproduce:
+Here is qtest reproducer:
+```bash
+cat << EOF | qemu-system-i386 -display none -machine accel=qtest, -m 512M -machine pc -nodefaults \
+-device virtio-mouse-pci,vectors=19923041 -qtest stdio
+outl 0xcf8 0x80001020
+outl 0xcfc 0xe0800000
+outl 0xcf8 0x80001004
+outw 0xcfc 0x02
+write 0xe0800010 0x4 0x6100
+EOF
+```
+
+and execution log:
+```
+cat << EOF | qemu-system-i386 -display none -machine accel=qtest, -m 512M -machine pc -nodefaults \
+-device virtio-mouse-pci,vectors=19923041 -qtest stdio
+outl 0xcf8 0x80001020
+outl 0xcfc 0xe0800000
+outl 0xcf8 0x80001004
+outw 0xcfc 0x02
+write 0xe0800010 0x4 0x6100
+EOF
+[I 0.000001] OPENED
+[R +0.067760] outl 0xcf8 0x80001020
+[S +0.067795] OK
+OK
+[R +0.067821] outl 0xcfc 0xe0800000
+[S +0.067959] OK
+OK
+[R +0.067993] outl 0xcf8 0x80001004
+[S +0.068005] OK
+OK
+[R +0.068020] outw 0xcfc 0x02
+[S +0.068520] OK
+OK
+[R +0.068554] write 0xe0800010 0x4 0x6100
+qemu-system-i386: ../hw/pci/msix.c:569: void msix_vector_use(PCIDevice *, unsigned int): Assertion `vector < dev->msix_entries_nr' failed.
+Aborted
+```
+
+If you need more information, let me know so I can discuss more about this issue.
+Additional information:
+```c
+int msix_init(PCIDevice *dev, unsigned short nentries,
+              MemoryRegion *table_bar, uint8_t table_bar_nr,
+              unsigned table_offset, MemoryRegion *pba_bar,
+              uint8_t pba_bar_nr, unsigned pba_offset, uint8_t cap_pos,
+              Error **errp);
+int msix_init_exclusive_bar(PCIDevice *dev, unsigned short nentries,
+                            uint8_t bar_nr, Error **errp);
+```
+
+`msix_init` accepts `nentries` as `unsigned short` type. 
+
+```c
+static void virtio_pci_device_plugged(DeviceState *d, Error **errp):
+
+    ...
+
+    if (proxy->nvectors) {
+        int err = msix_init_exclusive_bar(&proxy->pci_dev, proxy->nvectors,
+                                          proxy->msix_bar_idx, NULL);
+        if (err) {
+            /* Notice when a system that supports MSIx can't initialize it */
+            if (err != -ENOTSUP) {
+                warn_report("unable to init msix vectors to %" PRIu32,
+                            proxy->nvectors);
+            }
+            proxy->nvectors = 0;
+        }
+    }
+```
+
+When virtio-pci device is initialized, `proxy->nvectors` (`uint32_t` here) is casted into `unsigned short`.
+This causes inconsistency between `msix_entries_nr` and `nvectors` and triggers the above crash.
+
+While this is due to setting invalid value to `nvectors`, we need proper handling of the wrong value in the configuration.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2654 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2654
new file mode 100644
index 00000000..c904c35a
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2654
@@ -0,0 +1,14 @@
+qemu-system-i386 no longer boots NetBSD
+Description of problem:
+Since qemu commit b56617bbcb473c25815d1bf475e326f84563b1de, qemu-system-i386 can no longer boot NetBSD.
+Steps to reproduce:
+```
+wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.0/images/NetBSD-10.0-i386.iso
+qemu-system-i386 -cdrom NetBSD-10.0-i386.iso
+```
+
+Expected behavior: Boots into the NetBSD installer
+
+Observed incorrect behavior: Boot hangs with a black screen
+Additional information:
+This regression is a critical issue to the NetBSD project as its automated testing infrastructure is heavily dependent on qemu-system-i386.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2657 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2657
new file mode 100644
index 00000000..c95f9129
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2657
@@ -0,0 +1,11 @@
+Kernel crashed when installing OpenServer 6 D2M2a
+Description of problem:
+The kernel crashed when finishing installation.
+Steps to reproduce:
+1. Download OpenServer6D2M2a-DVD.iso for free from Xinuos website(a free account is needed, but the registation is easy to be done)
+2. Create new virtual hard drive
+3. Boot the installation ISO
+4. Install with all default settings and all packages, evaluate license is okay.
+5. Boom!
+Additional information:
+![QQ20241106-110404](/uploads/b42d5d6fef34606b4a6c672e33f06b97/QQ20241106-110404.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2666 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2666
new file mode 100644
index 00000000..db1b9be0
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2666
@@ -0,0 +1,22 @@
+OPENSTEP 4.2 for Intel does not boot from SCSI cd connected to am53c974
+Description of problem:
+Get OPENSTEP 4.2 installation media from 
+https://fsck.technology/software/NeXT/OpenStep%20Installation%20Media/
+
+Boot qemu like command line above
+
+Follow on-screen instruction, do not forgot to "change floppy0 path_to_driver_disk.img" in qemu monitor
+Additional information:
+![os42-qemu-amd](/uploads/88eddae2f9ec6acd83274a98ab11f2e4/os42-qemu-amd.png)
+
+driver select screen
+
+![os42-qemu-amd-1](/uploads/37d96d04d7f40f6c80aa3f9f6e03f4ff/os42-qemu-amd-1.png)
+
+it boots ..
+
+![os42-qemu-amd-2](/uploads/d3640682a1af90218885ecee31f45ec6/os42-qemu-amd-2.png)
+
+find a bit too much LUNs and eventually give up after scanning them all
+
+Note there is 0-sized disk "detected" in there somewhere
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/267 b/gitlab/issues_text/target_i386/host_missing/accel_missing/267
new file mode 100644
index 00000000..dbb71c14
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/267
@@ -0,0 +1 @@
+qemu-x86_64 segment prefixes error
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2739 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2739
new file mode 100644
index 00000000..49b88bcc
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2739
@@ -0,0 +1,3 @@
+Feature: Emulate GRUB2's initrd16 newc: feature for dynamic initrd generation
+Additional information:
+This feature is used in boot environments like WINPE, where GRUB2 leverages `initrd16` with `newc:` to load `wimboot` and then dynamically create an initrd containing necessary files for booting a Windows PE environment from a WIM image. Emulating this in QEMU would greatly improve the ability to test and debug such setups.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2769 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2769
new file mode 100644
index 00000000..6abccb2a
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2769
@@ -0,0 +1,3 @@
+Ability to set smbios type 3 field "Type"
+Additional information:
+That's all :)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2779 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2779
new file mode 100644
index 00000000..d6367bed
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2779
@@ -0,0 +1,41 @@
+Segmentation fault when introspecting machine properties
+Description of problem:
+QEMU currrently crashes when trying to list the properties of the q35 machine type while QEMU has been started with the i440fx machine type. Introspecting QOM objects for their properties should always be possible, but apparently there is currently something causing a crash in this case.
+Steps to reproduce:
+1. Start QEMU with: qemu-system-x86_64 -M pc -qmp stdio
+2. Enter these commands in the QMP monitor:
+
+```
+ { "execute": "qmp_capabilities" }
+ { "execute": "qom-list-properties","arguments": { "typename": "pc-q35-10.0-machine"}}
+```
+Additional information:
+Backtrace looks like this:
+```
+mc146818rtc_set_cmos_data (s=0x0, addr=95, val=-1) at ../../devel/qemu/hw/rtc/mc146818rtc.c:738
+738	        s->cmos_data[addr] = val;
+--Type <RET> for more, q to quit, c to continue without paging--#0  mc146818rtc_set_cmos_data (s=0x0, addr=95, val=-1) at ../../devel/qemu/hw/rtc/mc146818rtc.c:738
+#1  0x0000555555bf15d2 in pc_machine_done (notifier=0x555557f40750, data=<optimized out>) at ../../devel/qemu/hw/i386/pc.c:632
+#2  0x0000555555d4f7a2 in object_init_with_type (obj=obj@entry=0x555557f40320, ti=ti@entry=0x5555579c3c60)
+    at ../../devel/qemu/qom/object.c:424
+#3  0x0000555555d49c7e in object_initialize_with_type (obj=0x555557f40320, size=<optimized out>, type=type@entry=0x5555579c3c60)
+    at ../../devel/qemu/qom/object.c:570
+#4  0x0000555555d4a660 in object_new_with_type (type=0x5555579c3c60) at ../../devel/qemu/qom/object.c:774
+#5  object_new (typename=typename@entry=0x555558672b30 "pc-q35-10.0-machine") at ../../devel/qemu/qom/object.c:789
+#6  0x0000555555e825c5 in qmp_qom_list_properties (typename=0x555558672b30 "pc-q35-10.0-machine", errp=errp@entry=0x7fffffffd988)
+    at ../../devel/qemu/qom/qom-qmp-cmds.c:205
+#7  0x0000555555ef0525 in qmp_marshal_qom_list_properties (args=<optimized out>, ret=0x7fffeda9af00, errp=0x7fffeda9af08)
+    at qapi/qapi-commands-qom.c:288
+#8  0x0000555555f1edc1 in do_qmp_dispatch_bh (opaque=0x7fffeda9aed0) at ../../devel/qemu/qapi/qmp-dispatch.c:128
+#9  0x0000555555f40e28 in aio_bh_poll (ctx=ctx@entry=0x5555579f2930) at ../../devel/qemu/util/async.c:219
+#10 0x0000555555f2886f in aio_dispatch (ctx=0x5555579f2930) at ../../devel/qemu/util/aio-posix.c:424
+#11 0x0000555555f41cbb in aio_ctx_dispatch (source=0x0, callback=0x5f, user_data=<optimized out>) at ../../devel/qemu/util/async.c:361
+#12 0x00007ffff6d98e8c in g_main_context_dispatch_unlocked.lto_priv () at /lib64/libglib-2.0.so.0
+#13 0x00007ffff6d99155 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
+#14 0x0000555555f42540 in glib_pollfds_poll () at ../../devel/qemu/util/main-loop.c:287
+#15 os_host_main_loop_wait (timeout=<optimized out>) at ../../devel/qemu/util/main-loop.c:310
+#16 main_loop_wait (nonblocking=nonblocking@entry=0) at ../../devel/qemu/util/main-loop.c:589
+#17 0x0000555555ae1207 in qemu_main_loop () at ../../devel/qemu/system/runstate.c:835
+#18 0x0000555555e85d57 in qemu_default_main (opaque=<optimized out>) at ../../devel/qemu/system/main.c:48
+#19 0x0000555555e85d2f in main (argc=<optimized out>, argv=<optimized out>) at ../../devel/qemu/system/main.c:76
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2783 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2783
new file mode 100644
index 00000000..b9bebd68
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2783
@@ -0,0 +1,17 @@
+Cannot install a fresh Windows 7 32-bit guest with Q35 machine type (mouse and keyboard do not function, so cannot continue install)
+Description of problem:
+When trying to install Windows 7 32-bit via the official SP1 installation ISO, the machine boots the installer, but both keyboard and mouse do not function, so the installation cannot proceed.
+Steps to reproduce:
+1. Using virt-manager, create a new VM using the x86 version of the Windows 7 SP1 install ISO found here: https://archive.org/details/windows-7-professional-with-sp1-x64-dvd-iso
+2. Select `Microsoft Windows 7` as the Operating System type, which uses Q35 as the machine type
+3. Click Begin Installation
+4. See the Windows 7 installer screen show up
+5. Keyboard and mouse inputs don't work at all, mouse cursor also doesn't appear
+Additional information:
+I've tried using `Microsoft Windows XP` as the Operating System in virt-manager, which switches to i440FX as the machine type, and the issue doesn't appear: keyboard and mouse both work perfectly. But of course, it would be nice to use Q35 instead to get USB 3.0, PCI-E, etc.
+
+![image](/uploads/41f7e9b5f1293f6a153582cf066d114f/image.png)
+Notice the lack of cursor in the screenshot above on Q35.
+
+When using a i440FX machine, the white Windows cursor will appear:
+![image](/uploads/bbafdd23b06e60fe862f1cd6262483f2/image.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2813 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2813
new file mode 100644
index 00000000..c2a15045
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2813
@@ -0,0 +1,9 @@
+Cannot emulate Windows 95 / 98
+Description of problem:
+If install Windows 95 / 98 on that configuration, Windows 95 / 98 crashed on "While initializing device NDIS: Windows protection error." message, or QEMU crashed. With this command line Windows 95 / 98 can worked on previous QEMU 7.<br>And please don't allow IME input on CJK (Chinese / Japanese / Korean) host system (that relied IME to input some text). Such input process is done by the IME in CJK operating system guest.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2816 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2816
new file mode 100644
index 00000000..9edd84ed
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2816
@@ -0,0 +1,14 @@
+qemu-9.2.1 windows can not load files if kernel is linux-6.13.x
+Description of problem:
+qemu-9.2 and 9.2.1 emulating windows-10 both gave this
+bug "externe exception 80000004." emulating windows-10
+when a program tries to load a file. 
+qemu emulating windows-10 runs without this bug when using
+kernel linux-6.12.14 and older.
+Steps to reproduce:
+1.start a prog, in my case sprint-layout-6.0, try to open/load a file.
+2.
+3.
+Additional information:
+Im not shure if the bug is with qemu or kernel.
+You can decide better what causes this bug.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2817 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2817
new file mode 100644
index 00000000..0f00a05f
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2817
@@ -0,0 +1,51 @@
+Strange floating-point behaviour under Windows with some CPU models
+Description of problem:
+I'm encountering a very weird bug with some floating-point maths code, but only under very specific configurations. First I thought it was a Clang bug, but then further digging eventually showed it to only occur under Windows VMs with specific QEMU CPU options, I'm not certain whether it is a QEMU/KVM bug or a Windows bug, but thought starting here would be easiest.
+
+When compiled under MSVC Clang with modern CPU instructions disabled (e.g. `-march=pentium3` or `-march=pentium-mmx`), the `floorf()` call in the following program always returns 0.0, while the truncation works correctly:
+
+```
+#include <math.h>
+#include <stdio.h>
+#include <stdlib.h>
+
+int main(int argc, char **argv)
+{
+	float n = atof(argv[1]);
+	printf("n = %f\n", n);
+	
+	float f = floorf(n);
+	printf("f = %f\n", f);
+	
+	float c = (int)(n);
+	printf("c = %f\n", c);
+	
+	return 0;
+}
+```
+
+Example output on an affected VM:
+
+```
+C:\Users\Administrator> floorf-p3.exe 10
+n = 10.000000
+f = 0.000000
+c = 10.000000
+
+C:\Users\Administrator> floorf-p4.exe 10
+n = 10.000000
+f = 10.000000
+c = 10.000000
+```
+
+(`floorf-p3.exe` was compiled with `-march=pentium3` and `floorf-p4.exe` with `-march=pentium4` above)
+
+I've tried a few QEMU CPU models on a variety of Intel/AMD VM hosts and two different Windows versions (10 and Server 2022), and observed the following:
+
+* `host-passthrough` - works (on AMD and Intel hosts)
+* `qemu64` - broken
+* `EPYC-Milan` - works
+* `Westmere` - works
+* `Penryn` - broken
+
+(I also reported this via the mailing list, but I think it might've swallowed my post)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2832 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2832
new file mode 100644
index 00000000..dcb18385
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2832
@@ -0,0 +1,99 @@
+Random kernel panic (2/3) in github macOS runner: IO-APIC + timer doesn't work!
+Description of problem:
+Random kernel panic (2/3 runs average) with this traceback:
+
+```
+[    0.020000] Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with apic=debug and send a report.  Then try booting with the 'noapic' option.
+[    0.020000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-14-generic #15-Ubuntu
+[    0.020000] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-stable202408-prebuilt.qemu.org 08/13/2024
+[    0.020000] Call Trace:
+[    0.020000]  <TASK>
+[    0.020000]  show_stack+0x49/0x60
+[    0.020000]  dump_stack_lvl+0x5f/0x90
+[    0.020000]  dump_stack+0x10/0x18
+[    0.020000]  panic+0x16a/0x328
+[    0.020000]  check_timer+0x4d1/0x570
+[    0.020000]  setup_IO_APIC+0x1e5/0x210
+[    0.020000]  apic_intr_mode_init+0xd0/0xf0
+[    0.020000]  x86_late_time_init+0x24/0x40
+[    0.020000]  start_kernel+0x3f9/0x4a0
+[    0.020000]  x86_64_start_reservations+0x24/0x30
+[    0.020000]  x86_64_start_kernel+0xf2/0x100
+[    0.020000]  common_startup_64+0x13e/0x141
+[    0.020000]  </TASK>
+[    0.020000] ---[ end Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with apic=debug and send a report.  Then try booting with the 'noapic' option. ]---
+```
+Steps to reproduce:
+1. Start qemu in macos-13 github runner
+Additional information:
+Example failed build:
+https://github.com/nirs/vmnet-helper/actions/runs/13477646025/job/37658748139
+
+serial.log:
+```
+3h3hBdsDxe: failed to load Boot0001 "UEFI QEMU QEMU CD-ROM " from PciRoot(0x0)/Pci(0x1,0x0)/Scsi(0x0,0x0): Not Found
+BdsDxe: loading Boot0002 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x3,0x0)
+BdsDxe: starting Boot0002 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x3,0x0)
+EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
+[    0.000000] Linux version 6.11.0-14-generic (buildd@lcy02-amd64-032) (x86_64-linux-gnu-gcc-14 (Ubuntu 14.2.0-4ubuntu2) 14.2.0, GNU ld (GNU Binutils for Ubuntu) 2.43.1) #15-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 10 23:48:25 UTC 2025 (Ubuntu 6.11.0-14.15-generic 6.11.0)
+[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.11.0-14-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0
+[    0.000000] KERNEL supported cpus:
+[    0.000000]   Intel GenuineIntel
+[    0.000000]   AMD AuthenticAMD
+[    0.000000]   Hygon HygonGenuine
+[    0.000000]   Centaur CentaurHauls
+[    0.000000]   zhaoxin   Shanghai  
+[    0.000000] BIOS-provided physical RAM map:
+[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080afff] usable
+[    0.000000] BIOS-e820: [mem 0x000000000080b000-0x000000000080bfff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x000000000080c000-0x0000000000810fff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000811000-0x00000000008fffff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000003ee41fff] usable
+[    0.000000] BIOS-e820: [mem 0x000000003ee42000-0x000000003ef02fff] reserved
+[    0.000000] BIOS-e820: [mem 0x000000003ef03000-0x000000003f8ecfff] usable
+[    0.000000] RCU Tasks: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1.
+[    0.000000] RCU Tasks Rude: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1.
+[    0.000000] RCU Tasks Trace: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1.
+[    0.000000] NR_IRQS: 524544, nr_irqs: 256, preallocated irqs: 16
+[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
+[    0.000000] Console: colour dummy device 80x25
+[    0.000000] printk: legacy console [tty1] enabled
+[    0.000000] printk: legacy console [ttyS0] enabled
+[    0.000000] ACPI: Core revision 20240322
+[    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
+[    0.001000] APIC: Switch to symmetric I/O mode setup
+[    0.003000] x2apic: IRQ remapping doesn't support X2APIC mode
+[    0.011000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
+[    0.013000] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
+[    0.013000] ...trying to set up timer (IRQ0) through the 8259A ...
+[    0.013000] ..... (found apic 0 pin 2) ...
+[    0.014000] ....... failed.
+[    0.014000] ...trying to set up timer as Virtual Wire IRQ...
+[    0.018000] ..... failed.
+[    0.018000] ...trying to set up timer as ExtINT IRQ...
+[    0.020000] ..... failed :(.
+[    0.020000] Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with apic=debug and send a report.  Then try booting with the 'noapic' option.
+[    0.020000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-14-generic #15-Ubuntu
+[    0.020000] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-stable202408-prebuilt.qemu.org 08/13/2024
+[    0.020000] Call Trace:
+[    0.020000]  <TASK>
+[    0.020000]  show_stack+0x49/0x60
+[    0.020000]  dump_stack_lvl+0x5f/0x90
+[    0.020000]  dump_stack+0x10/0x18
+[    0.020000]  panic+0x16a/0x328
+[    0.020000]  check_timer+0x4d1/0x570
+[    0.020000]  setup_IO_APIC+0x1e5/0x210
+[    0.020000]  apic_intr_mode_init+0xd0/0xf0
+[    0.020000]  x86_late_time_init+0x24/0x40
+[    0.020000]  start_kernel+0x3f9/0x4a0
+[    0.020000]  x86_64_start_reservations+0x24/0x30
+[    0.020000]  x86_64_start_kernel+0xf2/0x100
+[    0.020000]  common_startup_64+0x13e/0x141
+[    0.020000]  </TASK>
+[    0.020000] ---[ end Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with apic=debug and send a report.  Then try booting with the 'noapic' option. ]---
+```
+
+Same Ubuntu image never fail with vfkit vm on the same macos-13 github runners.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2833 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2833
new file mode 100644
index 00000000..8767f8b2
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2833
@@ -0,0 +1,19 @@
+Inconsistent `Tn_INT_ROUTE_CAP` and `Tn_INT_ROUTE_CNF` in HPET
+Description of problem:
+In the [HPET specification](http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/software-developers-hpet-spec-1-0a.pdf) it says:
+>  Timer n Interrupt Routing Capability: (where n is the timer number: 00 to 31) This 32-bit read-only field indicates to which interrupts in the I/O (x) APIC this timer’s interrupt can be routed. This is used in conjunction with the Tn_INT_ROUTE_CNF field.
+> 
+> Each bit in this field corresponds to a particular interrupt. For example, if this timer’s interrupt can be mapped to interrupts 16, 18, 20, 22, or 24, then bits 16, 18, 20, 22, and 24 in this field will be set to 1. All other bits will be 0.
+
+
+> Timer n Interrupt Route: (where n is the timer number: 00 to 31). This 5-bit read/write field indicates the routing for the interrupt to the I/O APIC. A maximum value of 32 interrupts are supported. Default is 00h Software writes to this field to select which interrupt in the I/O (x) will be used for this timer’s interrupt. If the value is not supported by this prarticular timer, then the value read back will not match what is written. The software must only write valid values.
+
+In QEMU, the HPET timers indicate that the only I/O APIC IRQ they support is IRQ 2 (based only bit 2 being 1). But actually the HPET interrupt works even if I set it to IRQ 20, which is inconsistent with the `Tn_INT_ROUTE_CAP` that the timer shows.
+
+The HPET should show that it works with more than just IRQ 2.
+Steps to reproduce:
+1. Git checkout https://github.com/ChocolateLoverRaj/code-runner/tree/fd368f53c1c99885a3b149a59f2959f383f42859
+2. `nix develop`
+3. `cargo r -- -s -serial mon:stdio --no-reboot -nographic -d int`
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2834 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2834
new file mode 100644
index 00000000..18e2f8b5
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2834
@@ -0,0 +1,19 @@
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]
+Description of problem:
+when run `./qemu-system-x86_64  -cpu host,intel_pt  -m 8192M -smp 4 -hda  ubuntu.qcow2  --enable-kvm --nographic` warning `qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]`.
+Tried adding level/min-level=0x14, but still received a warning.
+Steps to reproduce:
+run command 
+```
+./qemu-system-x86_64  -cpu host,intel_pt  -m 8192M -smp 4 -hda  ubuntu.qcow2  --enable-kvm --nographic
+```
+Additional information:
+- CPU i5-13600kf
+```
+~$ sudo rdmsr 0x485 -f 14:14 # MSR_IA32_VMX_MISC_INTEL_PT
+1
+~$ sudo rdmsr 0x48B -f 56:56 # SECONDARY_EXEC_PT_USE_GPA
+1
+~$ sudo rdmsr 0x484 -f 50:50 # VM_ENTRY_LOAD_IA32_RTIT_CTL
+1
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2848 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2848
new file mode 100644
index 00000000..3168b864
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2848
@@ -0,0 +1,13 @@
+i386 max_cpus off by one
+Description of problem:
+X86 VMs are currently limited to 255 vCPUs (`mc->max_cpus = 255;` in `pc.c`).
+The first occurrence i can find of this limit is in d3e9db933f416c9f1c04df4834d36e2315952e42 from 2005 where both `MAX_APICS` and `MAX_CPUS` was set to 255. This is becoming relevant for some people as servers with 256 cores become more available. 
+
+**Can we increase the limit to 256 vCPUs?** 
+I think so. 
+
+Today, the APIC id limit (see `apic_id_limit` in `x86-common.c`) is based on the CPU id limit. 
+According to the a comment for `typdef uint32_t apic_id_t;` (see `topology.h`), we can have 256 APICs, but more APICs require x2APIC support. 
+APIC seems to be no hindrance to increase max_cpus to 256. 
+
+**Can we increase the limit to 512?** Maybe not? We need x2APIC support of which i have no clue. Also there is always a performance risk of exceeding the size at which current data structures work efficiently.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2868 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2868
new file mode 100644
index 00000000..0936a658
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2868
@@ -0,0 +1,3 @@
+amd iommu pte is only 32bits not 64bits.
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2869 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2869
new file mode 100644
index 00000000..9235c4bd
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2869
@@ -0,0 +1,3 @@
+enable guest mode at amd iommu
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2874 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2874
new file mode 100644
index 00000000..6071c384
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2874
@@ -0,0 +1,9 @@
+AMD Ryzen 9950x with -smp option yields "warning: This family of AMD CPU doesn't support hyperthreading"
+Description of problem:
+When using the above -smp option (`-smp 32,sockets=1,dies=1,clusters=1,cores=16,threads=2`), which should be valid for the Ryzen 9950X 16 cores / 32 threads CPU, QEMU prints:
+```
+qemu-system-x86_64: warning: This family of AMD CPU doesn't support hyperthreading(2). Please configure -smp options properly or try enabling topoext feature.
+```
+This is unexpected.  This CPU should support hyperthreading out of the box, it seems.
+Steps to reproduce:
+1. Run command above on Ryzen 9950X or similar CPU.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2882 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2882
new file mode 100644
index 00000000..ee5f2288
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2882
@@ -0,0 +1,90 @@
+Reading ACPI info via fw_cfg in SVSM causes Linux to panic
+Description of problem:
+We could use some help from a Qemu expert with an Qemu/ACPI/Linux related problem,
+working on Coconut SVSM.
+
+**See https://github.com/coconut-svsm/svsm/issues/646**
+
+Coconut has code to read ACPI information via fw_cfg, and extract the number of guest CPUs from that.
+That code has been used in the past, but since igvm became the default launch method for SVSM, it
+was only used in corner-cases, while the information were obtained in some other way (igmv parameter).
+Now a commit switches back to the fw_cfg+ACPI method. The information returned by it is correct, but
+strangely Linux (guest) is spitting out ACPI related errors and crashes in some cases before reaching user-space. We do not have any clue how this can be related other than through Qemu behavior. 
+There is no direct way how SVSM can influence the ACPI related behavior of the Linux
+guest kernel.
+
+The problem seems to be caused by simply reading the ACPI data.
+
+Reverting the bad commit and simply calling the original fw_cfg acpi function causes problems for Linux.
+Steps to reproduce:
+Boot SVSM bases CVM. SVSM and OVMF boot OK, then Linux prints these errors in some scenarios panics:
+```
+[...]
+[    1.857709] ACPI: Added _OSI(Processor Aggregator Device)
+[    1.859436] ACPI: 1 ACPI AML tables successfully acquired and loaded
+[    1.860867] ACPI Error: AE_BAD_ADDRESS, Unable to initialize fixed events (20240827/evevent-53)
+[    1.862709] ACPI: Unable to start the ACPI Interpreter
+[    1.863708] ACPI Error: Could not remove SCI handler (20240827/evmisc-251)
+[    1.864942] ACPI Error: AE_BAD_PARAMETER, Thread 2176690624 could not acquire Mutex [ACPI_MT
+X_Namespace] (0x1) (20240827/utmutex-252)
+[    1.866715] ACPI Error: AE_BAD_PARAMETER, Thread 2176690624 could not acquire Mutex [ACPI_MTX_Tables] (0x2) (20240827/utmutex-252)
+[    1.869722] ACPI Error: Mutex [ACPI_MTX_Tables] (0x2) is not acquired, cannot release (20240
+827/utmutex-289)
+[    1.870826] iommu: Default domain type: Translated
+[    1.871710] iommu: DMA domain TLB invalidation policy: lazy mod
+[...]
+[    2.672635] io scheduler bfq registered
+[    2.675679] atomic64_test: passed for x86-64 platform with CX8 and with SSE
+[    2.677596] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
+[    2.679264] ------------[ cut here ]------------
+[    2.680284] refcount_t: addition on 0; use-after-free.
+[    2.681477] WARNING: CPU: 3 PID: 1 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110
+[    2.683261] Modules linked in:
+[    2.683929] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.13.6-200.fc41.x86_64 #1
+[    2.685608] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-stable202502-39-gb
+483f751 02/02/2022
+[    2.687729] RIP: 0010:refcount_warn_saturate+0xe5/0x110
+[    2.688853] Code: e3 7f ff 0f 0b e9 fb 0a 8a 00 80 3d 15 9f 23 02 00 0f 85 5e ff ff ff 48 c7 c7 30 7b e7 8c c6 05 01 9f 23 02 01 e8 fb e2 7f ff <0f> 0b e9 d4 0a 8a 00 48 c7 c7 88 7b e7 8c
+ c6 05 e5 9e 23 02 01 e8
+[    2.692768] RSP: 0018:ffffb2ed0001fd90 EFLAGS: 00010282
+[    2.693894] RAX: 0000000000000000 RBX: ffff975b81060a80 RCX: ffffffff8d967448
+[    2.695410] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000001
+[    2.696923] RBP: ffffb2ed0001fe38 R08: 0000000000000000 R09: 0720072007200720
+[    2.698439] R10: 0720072007200720 R11: 0720072007200720 R12: ffff975b81060a80
+[    2.699955] R13: ffffb2ed0001fe78 R14: 00000000000000dc R15: 00000000000001df
+[    2.701461] FS:  0000000000000000(0000) GS:ffff975cf7d80000(0000) knlGS:0000000000000000
+[    2.703179] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[    2.704400] CR2: 00007f1c1658a3c8 CR3: 000800006082c000 CR4: 00000000003506f0
+[    2.705910] Call Trace:
+[    2.706451]  <TASK>
+[    2.706922]  ? srso_return_thunk+0x5/0x5f
+[    2.707820]  ? show_trace_log_lvl+0x255/0x2f0
+[    2.708783]  ? show_trace_log_lvl+0x255/0x2f0
+[    2.709712]  ? kobject_get+0x68/0x70
+[    2.710492]  ? refcount_warn_saturate+0xe5/0x110
+[    2.711480]  ? __warn.cold+0x93/0xfa
+[    2.712268]  ? refcount_warn_saturate+0xe5/0x110
+[    2.713262]  ? report_bug+0xff/0x140
+[    2.714036]  ? handle_bug+0x58/0x90
+[    2.714779]  ? exc_invalid_op+0x17/0x70
+[    2.715617]  ? asm_exc_invalid_op+0x1a/0x20
+[    2.716526]  ? refcount_warn_saturate+0xe5/0x110
+[    2.717507]  kobject_get+0x68/0x70
+[    2.718266]  kobject_add_internal+0x32/0x250
+[    2.719196]  kobject_add+0x96/0xc0
+[    2.719923]  kobject_create_and_add+0xa3/0xc0
+[    2.720851]  bgrt_init+0x77/0xc0
+[    2.721578]  ? __pfx_bgrt_init+0x10/0x10
+[    2.722418]  do_one_initcall+0x5b/0x310
+[    2.723272]  do_initcalls+0x147/0x170
+[    2.724086]  ? __pfx_kernel_init+0x10/0x10
+[    2.725174]  kernel_init_freeable+0xfb/0x130
+[    2.726114]  kernel_init+0x1a/0x140
+[    2.726883]  ret_from_fork+0x34/0x50
+[    2.727679]  ? __pfx_kernel_init+0x10/0x10
+[    2.728580]  ret_from_fork_asm+0x1a/0x30
+[    2.729429]  </TASK>
+[    2.729926] ---[ end trace 0000000000000000 ]---
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2892 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2892
new file mode 100644
index 00000000..464f7b77
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2892
@@ -0,0 +1 @@
+Outdated documentation about MicroVMs
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2894 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2894
new file mode 100644
index 00000000..7c87f475
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2894
@@ -0,0 +1,25 @@
+There is a bug in versions 2025-02-10 and later that causes virtual machines to be created with incorrect SMP settings with warnings about TCG features when setting more than 2 cores with the smp option in the default TCG acceleration (see main text).
+Description of problem:
+When using qemu-system-x86_64 in versions 9.2.50 and later, if you create a virtual machine with 2 or more cores using the smp option,
+
+```
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:EDX.ht [bit 28]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.cmp-legacy [bit 1]
+```
+The log will be displayed as many as the number of cores you have enabled, and the created virtual machine will be displayed as having a 1-core CPU with the number of cores you have enabled.
+* I have not tested whether the same symptom occurs on versions 9.2.50 and later for other environments (Linux and the WoA version released on March 26th).
+Steps to reproduce:
+1. Create a virtual machine with more than two cores using TCG acceleration, which is the default acceleration, by using options such as 'qemu-system-x86_64 -smp 2' or 'qemu-system-x86_64 -smp sockets=1,cores=2,threads=1'.
+2. 'qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:EDX.ht [bit 28]' and
+'qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.cmp-legacy [bit 1]'
+The log is generated as many as the number of cores set and the virtual machine is created.
+3. When checking the CPU information of the booted virtual machine, it does not show that there is one CPU with the specified number of cores, but rather that there is a single core CPU with the specified number of cores.
+Additional information:
+```
+>qemu-system-x86_64 -M q35 -smp 2 -m 4g -display sdl -usb -device usb-tablet -drive file=MasterOS.vdi,id=disk,if=none -drive file="C:\Program Files\qemu\share\edk2-x86_64-code.fd",id=efi,readonly=on,format=raw,if=pflash -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.1 -rtc base=localtime
+```
+![스크린샷_2025-03-31_164120](/uploads/4ddc95e8f90532e9c22d4f7c5c181c1a/스크린샷_2025-03-31_164120.png)
+```
+>qemu-system-x86_64 -M q35 -smp 4 -m 4g -display sdl -usb -device usb-tablet -drive file=MasterOS.vdi,id=disk,if=none -drive file="C:\Program Files\qemu\share\edk2-x86_64-code.fd",id=efi,readonly=on,format=raw,if=pflash -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.1 -rtc base=localtime
+```
+![스크린샷_2025-03-31_164917](/uploads/978d86c5f1b1d81230a0e96cd1bd10b9/스크린샷_2025-03-31_164917.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2897 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2897
new file mode 100644
index 00000000..14133376
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2897
@@ -0,0 +1,14 @@
+Can't boot SeaBIOS based VM when using -display gtk, works fine with vnc or sdl
+Description of problem:
+When using -display gtk, SeaBIOS hangs nondeterministicly. Changing to -display sdl or -display vnc lets it boot.
+Steps to reproduce:
+1. Run `qemu-system-x86_64 -display gtk` and the VM will not complete BIOS POST.
+2. Run `qemu-system-x86_64 -display sdl` and the VM will complete BIOS POST.
+Additional information:
+This ONLY happens with SeaBIOS. Using a UEFI BIOS to boot the VM does not cause this issue. 
+
+I realise this is a crazy bug. I suspect that the only way it could have slipped through testing is because it *requires* human interaction.
+
+There is no difference with using --accel kvm or not, but I have provided the smallest possible command line to duplicate the issue, which is literally just `qemu-system-x86_64 -display gtk`
+
+#
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2922 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2922
new file mode 100644
index 00000000..213030e4
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2922
@@ -0,0 +1,7 @@
+x86 reverse-debugging test is unreliable
+Description of problem:
+The reverse-debugging test for the x86 target is not working reliably. If the host system is under load, the test simply hangs and finally times out.
+Steps to reproduce:
+1. ``make check-venv``
+2. Run something in the background that keeps all CPUs busy
+3. ``for ((x=0;x<10;x++)); do QEMU_TEST_FLAKY_TESTS=1 pyvenv/bin/avocado run tests/avocado/reverse_debugging.py:ReverseDebugging_X86_64.test_x86_64_pc  ; done``
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2954 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2954
new file mode 100644
index 00000000..83239864
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2954
@@ -0,0 +1,19 @@
+SD card is not visible by UEFI
+Description of problem:
+SD card is not visible by OVMF UEFI, so it's not possible to boot from it:
+```
+UEFI Interactive Shell v2.2
+EDK II
+UEFI v2.70 (EDK II, 0x00010000)
+Mapping table
+     BLK0: Alias(s):
+          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
+Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
+Shell>
+```
+It is visible by SeaBIOS though, if we remove the OVMF part from the commandline:
+```
+qemu-system-x86_64 -device sdhci-pci -drive if=none,file=Fedora-IoT-ostree-41-20241027.0.x86_64.iso,format=raw,id=MMC1 -device sd-card,drive=MMC1
+```
+
+@philmd
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2961 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2961
new file mode 100644
index 00000000..254966cb
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2961
@@ -0,0 +1,31 @@
+isapc: RTC refactor caused regression in qemu>=8.2 (broke Xenix, maybe others)
+Description of problem:
+I've been playing a bit with retro UNIXes and wanted to try a Xenix install.
+
+There are several webpages giving hints for installing Xenix under old versions of QEMU.  The good news: most of the workarounds and tweaks they mention seem to be no longer needed.  Starting with a Homebrew-supplied qemu 10.0.0 on my laptop I was able to do a basic install _without_ having to tweak the floppy geometry or anything like that.
+
+The bad news: once the install was complete and I tried to reboot from the harddrive it hangs at the...
+```
+Boot
+:
+```
+...prompt.  It doesn't respond to any keystrokes at this point.  This prompt is printed by the second-stage loader (called `/boot` on the Xenix filesystem) which is a real-mode 8086 binary.
+
+To debug this further I moved to a more familiar Linux developer environment and found that the qemu that is stock with Debian 12.10 (7.2.15) did *not* exhibit the same problem!
+
+I manually bisected through the released versions and found that it definitely broke some time in the 8.2 release cycle: 8.1.5 worked, 8.2.0rc0 did not.  I then did a git checkout and started building qemu, using `git bisect` to find the guilty commit.
+
+Soon I came across 56b1f50e3c101bfe5f52bac73de0e88438de11bd from @shentey -- a change which moved connecting the RTC's ISA interrupt from `pc_basic_device_init()` down into `*_realize()` when a Southbridge is configured.  I was able to confirm that before this commit I could boot, but after it I could not.
+
+I verified using gdb that `pc_basic_device_init()` is being called but the functions that the initialization had moved to were not (or at least weren't called *yet*). So after this change this RTC irq wasn't being wired up, which apparently broke the second-stage Xenix loader.
+
+I then went back to git tip and found that reverting the 56b1f50e3c1 commit was enough to fix the problem there as well.
+
+I don't know enough about the qemu internals to judge whether the original change made sense.  Therefore, I won't claim that reverting it is the correct approach to fix the bug.  However, it did work for me.
+
+The Southbridge code has been reorged a little since 8.2 but the functional revert is still pretty straightfoward.  Here is the diff I used:
+[revert-56b1f50e3c1.patch](/uploads/573754b8af3d7ddb97d5f973cb0003db/revert-56b1f50e3c1.patch)
+Steps to reproduce:
+1. Install Xenix 2.3.4 from https://archive.org/details/sco-xenix-386-and-extras
+2. After some enjoyable floppy juggling, be amazed at how smoothly the install went
+3. Try to boot from the harddrive afterwards and weep
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/2987 b/gitlab/issues_text/target_i386/host_missing/accel_missing/2987
new file mode 100644
index 00000000..9efe925f
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/2987
@@ -0,0 +1,7 @@
+QEMU TCG failed to boot Windows 98 Second Edition
+Description of problem:
+QEMU TCG failed at booting Windows 98 Second Edition 4.10.2222B.
+
+Bisected to commit e54ef98c8a80d16158bab4341d9a898701270528
+Additional information:
+![Screenshot_2025-05-29_at_5.15.14_PM](/uploads/1cf0cf2435c1227df895f37496239c66/Screenshot_2025-05-29_at_5.15.14_PM.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/320 b/gitlab/issues_text/target_i386/host_missing/accel_missing/320
new file mode 100644
index 00000000..f20b75a5
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/320
@@ -0,0 +1 @@
+Corsair iCUE Install Fails, qemu VM Reboots
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/331 b/gitlab/issues_text/target_i386/host_missing/accel_missing/331
new file mode 100644
index 00000000..a5c9389c
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/331
@@ -0,0 +1 @@
+Incorrect feature negotiation for vhost-vdpa netdevice
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/368 b/gitlab/issues_text/target_i386/host_missing/accel_missing/368
new file mode 100644
index 00000000..edc13885
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/368
@@ -0,0 +1 @@
+virtiofsd: doesn't garant write access at users allowed by group permission
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/375 b/gitlab/issues_text/target_i386/host_missing/accel_missing/375
new file mode 100644
index 00000000..82565828
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/375
@@ -0,0 +1 @@
+MacOS 11.4 (x86_64) Host - USB passthrough appears to be broken
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/387 b/gitlab/issues_text/target_i386/host_missing/accel_missing/387
new file mode 100644
index 00000000..7cdf7e5c
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/387
@@ -0,0 +1 @@
+SD-Card not working anymore on x86 targets
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/389 b/gitlab/issues_text/target_i386/host_missing/accel_missing/389
new file mode 100644
index 00000000..450a47ca
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/389
@@ -0,0 +1 @@
+Add multiboot2 support
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/475 b/gitlab/issues_text/target_i386/host_missing/accel_missing/475
new file mode 100644
index 00000000..abc0972d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/475
@@ -0,0 +1 @@
+4.2 regression: ReactOS crashes on boot
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/508 b/gitlab/issues_text/target_i386/host_missing/accel_missing/508
new file mode 100644
index 00000000..e8456c5f
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/508
@@ -0,0 +1 @@
+x86_64 cmpxchg behavior in qemu tcg does not match the real CPU
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/510 b/gitlab/issues_text/target_i386/host_missing/accel_missing/510
new file mode 100644
index 00000000..593bdae2
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/510
@@ -0,0 +1 @@
+QEMU registers support on x64
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/512 b/gitlab/issues_text/target_i386/host_missing/accel_missing/512
new file mode 100644
index 00000000..4edb0505
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/512
@@ -0,0 +1 @@
+6.1.0-rc1 New regression (not in 6.1.0-rc0): Freezes using UEFI firmware without acceleration
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/525 b/gitlab/issues_text/target_i386/host_missing/accel_missing/525
new file mode 100644
index 00000000..83948de3
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/525
@@ -0,0 +1,14 @@
+missing features with CPU `qemu64`
+Description of problem:
+The live migration complains about a missing feature when using the CPU qemu64, which is _guaranteed to work_.
+Steps to reproduce:
+1. start the VM with qemu64 on the CPU: Intel(R) Xeon(R) CPU E5-2620 v4 
+2. live-migrate the VM to a CPU: Intel(R) Xeon(R) CPU E5-2670 0
+Additional information:
+The migration fails:
+```
+root@covid21:~# virsh migrate --verbose --live --persistent --undefinesource myvm.local qemu+ssh://covid24/system
+error: operation failed: guest CPU doesn't match specification: missing features: abm
+```
+
+This should not happen on a generic CPU, which should always work. Note, that the migration succeeds when using `-cpu qemu64,abm=off …`
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/536 b/gitlab/issues_text/target_i386/host_missing/accel_missing/536
new file mode 100644
index 00000000..098024c1
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/536
@@ -0,0 +1 @@
+Null-ptr dereference in ich9_apm_ctrl_changed
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/538 b/gitlab/issues_text/target_i386/host_missing/accel_missing/538
new file mode 100644
index 00000000..f3daca2d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/538
@@ -0,0 +1 @@
+Memory Leak in hpet_timer results in unusable machine
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/554 b/gitlab/issues_text/target_i386/host_missing/accel_missing/554
new file mode 100644
index 00000000..9c04a08d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/554
@@ -0,0 +1 @@
+q35 machine type cdrom device not discovered by freedos
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/561 b/gitlab/issues_text/target_i386/host_missing/accel_missing/561
new file mode 100644
index 00000000..a11709d0
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/561
@@ -0,0 +1 @@
+Q35 - ACPI PCI hot-plug issue with Windows guest
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/627 b/gitlab/issues_text/target_i386/host_missing/accel_missing/627
new file mode 100644
index 00000000..ead59b0c
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/627
@@ -0,0 +1,7 @@
+VI.EXE crashes on start under QEMU; works under BOCHS
+Description of problem:
+vi.exe hangs on startup; can be verified to work in bochs
+Steps to reproduce:
+1. Run vi.exe from DOS prompt; hang is evident immediately as ~ ~ ~ ~ doesn't show up
+Additional information:
+Actual [vi.exe](/uploads/d77076b8187489253c6ad8f1ab3ec247/vi.exe) attached; it's ridiculously old; the kind of thing that belongs on archive.org; I think I actually own this copy program by inheritance; but if the copyright holder objects we'll have to take it down again. :(
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/629 b/gitlab/issues_text/target_i386/host_missing/accel_missing/629
new file mode 100644
index 00000000..041d5c0d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/629
@@ -0,0 +1,10 @@
+Trying to use EGA or VGA functions from QBASIC doesn't work
+Description of problem:
+QBASIC can't start any graphics mode beyond CGA
+
+Some other programs that default to EGA crash trying to start graphics; none that I've tried can start EGA at all; believe to be the same bug; will file separately if it turns out to not be
+Steps to reproduce:
+1. Boot
+2. Start QBASIC
+3. Run a program consisting of only "SCREEN 12" for VGA or "SCREEN 9" for EGA
+4. Get error message "Illegal Function Call"
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/641 b/gitlab/issues_text/target_i386/host_missing/accel_missing/641
new file mode 100644
index 00000000..ac1b8154
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/641
@@ -0,0 +1 @@
+6.1.0 introduces regression in q35, unable to add more than 15 pcie-root-ports
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/673 b/gitlab/issues_text/target_i386/host_missing/accel_missing/673
new file mode 100644
index 00000000..a217a279
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/673
@@ -0,0 +1,10 @@
+I can no longer boot with -kernel and -initrd
+Description of problem:
+The kernel refuses to mount the initramfs and proceeds to kernel panic. i didnt have this problem until qemu updated
+Steps to reproduce:
+I have put it all in the git repo of my project
+1. git clone https://github.com/oknowaen/ltl-initramfs.git
+2. cd ltl-initramfs
+3. make (will start automatically)!
+Additional information:
+[Screenshot_20211016_182355](/uploads/c04094f5bcccadc3f8473f2ea6fc864d/Screenshot_20211016_182355.png)
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/705 b/gitlab/issues_text/target_i386/host_missing/accel_missing/705
new file mode 100644
index 00000000..fb2d0f25
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/705
@@ -0,0 +1,27 @@
+Failed to acpi hotplug on pcie root ports in case of q35+ovmf+machine type 6.1
+Description of problem:
+Hotplug on multifunction bridges use ACPI hotplug instead of Native since machine type 6.1
+In this case, Hotplug works well on q35 with bios fireware, But doesn't work on q35 with ovmf firmware.
+E.g:
+/usr/bin/qemu-system-x86_64 \
+-machine pc-q35-6.1,accel=kvm,pflash0=...... \
+-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 \
+-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 \
+-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 \
+......
+
+(qemu) netdev_add bridge,br=br0,id=hostnet1
+(qemu) device_add virtio-net-pci,netdev=hostnet1,id=net1,bus=pci.3
+
+Error message in guest kernel:
+kernel: pci 0000:03:00.0: [1af4:1041] type 00 class 0x020000
+kernel: pci 0000:03:00.0: reg 0x14: [mem 0x00000000-0x00000fff]
+kernel: pci 0000:03:00.0: reg 0x20: [mem 0x00000000-0x00003fff 64bit pref]
+kernel: pci 0000:03:00.0: reg 0x30: [mem 0x00000000-0x0003ffff pref]
+kernel: pci 0000:03:00.0: BAR 6: no space for [mem size 0x00040000 pref]
+kernel: pci 0000:03:00.0: BAR 6: failed to assign [mem size 0x00040000 pref]
+kernel: pci 0000:03:00.0: BAR 4: no space for [mem size 0x00004000 64bit pref]
+kernel: pci 0000:03:00.0: BAR 4: failed to assign [mem size 0x00004000 64bit pref]
+kernel: pci 0000:03:00.0: BAR 1: no space for [mem size 0x00001000]
+kernel: pci 0000:03:00.0: BAR 1: failed to assign [mem size 0x00001000]
+kernel: virtio-pci 0000:03:00.0: virtio_pci: leaving for legacy driver
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/745 b/gitlab/issues_text/target_i386/host_missing/accel_missing/745
new file mode 100644
index 00000000..1a76fb51
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/745
@@ -0,0 +1,36 @@
+NVRAM is not persistent across coldboots without attached r/w FAT32 hard drive
+Description of problem:
+NVRAM variables are not persistent across coldboots without an attached readable / writable FAT32 hard drive.
+Steps to reproduce:
+Without hard drive:
+1. Start VM as above ("without hard drive attached"), and enter EFI shell.
+2. Dump the contents of a NVRAM variable, e.g. Lang. Note the contents.
+3. Edit the contents of that variable.
+4. Shutdown and restart the VM (cold reboot), and enter the EFI shell.
+5. Dump the contents of the same NVRAM variable. The contents have reverted to what they were in Step 2.
+
+With hard drive:
+1. Start VM as above ("with hard drive attached"), and enter EFI shell.
+2. Navigate to the hard drive filesystem, e.g. FS0.
+3. List the files in the filesystem. If NvVars exists, note the modification time.
+4. Edit the contents of a NVRAM variable, e.g. Lang.
+5. List the files of the filesystem. The NvVars file either now exists, or has notably been modified since Step 3.
+Additional information:
+OVMF blobs used: Those found in the Debian Sid package "ovmf_2021.11_rc1-1_all.deb" (https://packages.debian.org/sid/ovmf)
+
+Note that, without a hard drive attached, edited NVRAM variables persist across warm reboots, e.g. via the EFI shell command `reset`.
+
+I have not tested filesystem formats other than FAT32 with the attached hard drive, though I assume that would be futile due to the UEFI specification stating that EFI only supports FAT-based filesystems by default.
+
+Without HDD attached, before cold reboot:
+![no_hdd_pre-coldboot](/uploads/cb1da3e72a852ff1e7fd1b47afc9ba6e/no_hdd_pre-coldboot.png)
+
+Without HDD attached, after cold reboot:
+![no_hdd_post-coldboot](/uploads/d9622d4571ad8c046f51a00b26e8354e/no_hdd_post-coldboot.png)
+
+With HDD attached (note modification date / time of NvVars):
+![hdd_attached](/uploads/30135dd688f8c7e7ec2feccd69007258/hdd_attached.png)
+
+This issue leads to modern macOS's installation process failing, as it relies on being able to modify NVRAM variables to know how far along in the installation process it is. Without these variables, the installation process will loop indefinitely, as it can't know when to move on to the next part of the overall process.
+
+Let me know if more information is needed, or if this is an issue better suited for the OVMF bug tracker (which I do not know the location of).
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/752 b/gitlab/issues_text/target_i386/host_missing/accel_missing/752
new file mode 100644
index 00000000..a9b99b34
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/752
@@ -0,0 +1,13 @@
+vmmouse device gets attached twice, one without i8042 associated
+Description of problem:
+I'm developing [a driver for the VMware mouse device](https://github.com/NattyNarwhal/vmwmouse). I know this works properly on VMware, but I'm trying it in QEMU too.
+
+[My full notes](https://github.com/NattyNarwhal/vmwmouse/issues/1), but most relevant is:
+
+* a vmmouse instance gets initialized twice (confirmed in qtree), one with i8042 the first time, one without the second time
+* the second vmmouse instance is the one receiving the events, passing them to the i8042 device's fake event handler
+* obviously, a crash because ISAKBDDevice should never be null
+Steps to reproduce:
+1. Load VMware mouse driver
+2. Move cursor (I recommend waiting until Windows loads before doing so, it is very easy to corrupt the guest filesystem if you do it while Windows is loading)
+3. Crash
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/77 b/gitlab/issues_text/target_i386/host_missing/accel_missing/77
new file mode 100644
index 00000000..f341e297
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/77
@@ -0,0 +1 @@
+msmouse not recognized in guest
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/770 b/gitlab/issues_text/target_i386/host_missing/accel_missing/770
new file mode 100644
index 00000000..37ff5d19
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/770
@@ -0,0 +1 @@
+READ memory access in /hw/acpi/pcihp.c
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/771 b/gitlab/issues_text/target_i386/host_missing/accel_missing/771
new file mode 100644
index 00000000..9a8fb211
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/771
@@ -0,0 +1,14 @@
+No interrupts are delivered to the guest after rebooting Windows 98
+Description of problem:
+After Windows 98 is rebooted in QEMU, the guest freezes: the system is unresponsive to key presses and the boot splash animation halts.  The guest performs fine before the reboot.
+
+Closer examination reveals that no hardware interrupts are delivered to the guest.  BIOS Data Area variables like the keyboard buffer and the system clock are not updated.  Even non-maskable interrupts fail to be delivered, as witnessed by installing an option ROM that hooks interrupt vector 2 and issuing the `nmi` command in the monitor.
+
+The only remedy seems to be to exit the QEMU process entirely and launch it again.
+Steps to reproduce:
+0. Install Windows 98 into the guest.  (Since the normal installation process already involves a couple of reboots, it is possible to hit the issue already at step zero.)
+1. Boot it; it may be into Safe Mode, but the protected-mode graphical environment must at least attempt to load.  (I managed sometimes to reproduce the bug without the system having loaded fully.)
+2. Reboot. This may be a clean reboot, or it may be a hard reboot (`system_reset` or equivalent)
+3. Observe the system freeze.
+Additional information:
+None
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/78 b/gitlab/issues_text/target_i386/host_missing/accel_missing/78
new file mode 100644
index 00000000..8b624dce
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/78
@@ -0,0 +1 @@
+msmouse serial mouse emulation broken? No id byte sent on reset
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/780 b/gitlab/issues_text/target_i386/host_missing/accel_missing/780
new file mode 100644
index 00000000..dfbcc9a6
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/780
@@ -0,0 +1,54 @@
+qemu-system-x86_64: qemu dead-lock when mirror job exit and vm stop in a race
+Description of problem:
+machine under continuous pressure, at the end of the migration phase.
+Libvirtd construction exception at the same time.
+In mirror_run, mirror_write_complete set s->ret to negative value and exit mirror_run; Job_co_entry throws the bh of job_exit into the main thread;
+
+While the live_migration thread gets the qemu_global_mutex, and set to main thread by blk_set_aio_context; when it just polles the bh of job_exit, and run to bdrv_flush. So there need the main thread to process bdrv_flush_co_entry, then we can exit bdrv_flush.
+If the main thread is waiting the qemu_mutex_lock_iothread_impl, bdrv_flush_co_entry cannot be executed, and the Live_migration thread cannot exit to release qemu_global_mutex, resulting in deadlock
+Steps to reproduce:
+1.migrate the machine and let machine under continuous pressure;
+2.gdb to qemu and make break point to virtio_blk_data_plane_stop;
+3.when hit virtio_blk_data_plane_stop, kill libvirtd;
+4.let live_migration thread to poll job_exit
+Additional information:
+```
+#0  0x00007f8f662d12f2 in aio_bh_poll (ctx=ctx@entry=0x5580c53a5c60) at /usr/src/qemu/util/async.c:112
+#1  0x00007f8f662d58ae in aio_poll (ctx=0x5580c53a5c60, blocking=blocking@entry=true) at /usr/src/qemu/util/aio-posix.c:736
+#2  0x00007f8f6530bcca in bdrv_flush (bs=bs@entry=0x5580c5857b30) at /usr/src/qemu/block/io.c:2778
+#3  0x00007f8f65345143 in bdrv_close (bs=bs@entry=0x5580c5857b30) at /usr/src/qemu/block.c:4073
+#4  0x00007f8f65345373 in bdrv_delete (bs=0x5580c5857b30) at /usr/src/qemu/block.c:4335
+#5  0x00007f8f65345405 in bdrv_unref (bs=<optimized out>) at /usr/src/qemu/block.c:5676
+#6  0x00007f8f65344d95 in bdrv_root_unref_child (child=<optimized out>) at /usr/src/qemu/block.c:2516
+#7  0x00007f8f65353f56 in block_job_remove_all_bdrv (job=job@entry=0x5580c6d55cc0) at /usr/src/qemu/blockjob.c:203
+#8  0x00007f8f65317b87 in mirror_exit_common (job=0x5580c6d55cc0) at /usr/src/qemu/block/mirror.c:776
+#9  0x00007f8f65317cc8 in mirror_abort (job=<optimized out>) at /usr/src/qemu/block/mirror.c:804
+#10 0x00007f8f6632737b in job_finalize_single (job=job@entry=0x5580c6d55cc0) at /usr/src/qemu/job.c:680
+#11 0x00007f8f66327d70 in job_completed_txn_abort (job=<optimized out>) at /usr/src/qemu/job.c:758
+#12 0x00007f8f66328018 in job_exit (opaque=0x5580c6d55cc0) at /usr/src/qemu/job.c:873
+#13 0x00007f8f662d130f in aio_bh_poll (ctx=ctx@entry=0x5580c53a5c60) at /usr/src/qemu/util/async.c:118
+#14 0x00007f8f662d5716 in aio_poll (ctx=ctx@entry=0x5580c53a5c60, blocking=blocking@entry=true) at /usr/src/qemu/util/aio-posix.c:736
+#15 0x00007f8f662e6b4d in aio_wait_bh_oneshot (ctx=0x5580c53a5c60, cb=<optimized out>, opaque=<optimized out>) at /usr/src/qemu/util/aio-wait.c:71
+#16 0x00007f8f65340978 in bdrv_attach_aio_context (bs=bs@entry=0x5580c5a07ef0, new_context=new_context@entry=0x5580c53a5c60) at /usr/src/qemu/block.c:5985
+#17 0x00007f8f65345fd5 in bdrv_set_aio_context_ignore (bs=0x5580c5a07ef0, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6050
+#18 0x00007f8f6534609e in bdrv_set_aio_context_ignore (bs=0x5580c5857b30, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6032
+#19 0x00007f8f65353bd4 in child_job_set_aio_ctx (c=<optimized out>, ctx=0x5580c53a5c60, ignore=0x7f8eb8ff8c20) at /usr/src/qemu/blockjob.c:172
+#20 0x00007f8f6534604b in bdrv_set_aio_context_ignore (bs=0x5580c53c46c0, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6040
+#21 0x00007f8f6534609e in bdrv_set_aio_context_ignore (bs=bs@entry=0x5580c5978290, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6032
+#22 0x00007f8f653462b8 in bdrv_child_try_set_aio_context (bs=bs@entry=0x5580c5978290, ctx=ctx@entry=0x5580c53a5c60, ignore_child=<optimized out>, errp=errp@entry=0x0) at /usr/src/qemu/block.c:6145
+#23 0x00007f8f653029aa in blk_do_set_aio_context (blk=0x5580c53c42b0, new_context=0x5580c53a5c60, update_root_node=update_root_node@entry=true, errp=errp@entry=0x0) at /usr/src/qemu/block/block-backend.c:1948
+#24 0x00007f8f65304b0d in blk_set_aio_context (blk=<optimized out>, new_context=<optimized out>, errp=errp@entry=0x0) at /usr/src/qemu/block/block-backend.c:1980
+#25 0x00007f8f64f07976 in virtio_blk_data_plane_stop (vdev=0x5580c6d8a510) at /usr/src/qemu/hw/block/dataplane/virtio-blk.c:305
+#26 0x00007f8f64f7be83 in virtio_bus_stop_ioeventfd (bus=0x5580c6d8a498) at /usr/src/qemu/hw/virtio/virtio-bus.c:247
+#27 0x00007f8f64f77e8b in virtio_vmstate_change (opaque=0x5580c6d8a510, running=0, state=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/hw/virtio/virtio.c:2423
+#28 0x00007f8f663563f5 in vm_state_notify (running=running@entry=0, state=state@entry=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/huawei/microvm/microvm-platform.c:196
+#29 0x00007f8f66335af9 in do_vm_stop (state=RUN_STATE_FINISH_MIGRATE, send_stop=send_stop@entry=true) at /usr/src/qemu/cpus.c:1130
+#30 0x00007f8f66335dd1 in vm_stop (state=<optimized out>) at /usr/src/qemu/cpus.c:2207
+#31 0x00007f8f66335f7e in vm_stop_force_state (state=state@entry=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/cpus.c:2267
+#32 0x00007f8f65197cfc in migration_try_vm_stop_and_save_concurrent (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:2976
+#33 0x00007f8f6519c627 in migration_completion (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3039
+#34 0x00007f8f6519cc8b in migration_iteration_run (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3571
+#35 0x00007f8f6519d190 in migration_thread (opaque=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3801
+#36 0x00007f8f662d82e0 in qemu_thread_start (args=0x5580c57d0300) at /usr/src/qemu/util/qemu-thread-posix.c:519
+#37 0x00007f8f6648bf3b in start_thread (arg=0x7f8eb8ff9700) at pthread_create.c:486
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/786 b/gitlab/issues_text/target_i386/host_missing/accel_missing/786
new file mode 100644
index 00000000..f20ed6fd
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/786
@@ -0,0 +1,17 @@
+assert in qemu-6.2.0/hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: (len <= maxlen)
+Description of problem:
+assert and crash when -acpitable argument is used. Specifically, the argument was "-acpitable file=my_file.bin" which causes the assert and crash. 
+
+The other arguments, I hope, are not critical. In brief, I'm using secure boot (with ovmf_code.secboot.fd), and a sw tpm as well. But hopefully these are not relevant.
+
+The assert with -acpitable is a regression since it worked with version 6.1.0
+
+The actual error message in qemu 6.2.0 is
+
+qemu-6.2.0/hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: (len <= maxlen)
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/791 b/gitlab/issues_text/target_i386/host_missing/accel_missing/791
new file mode 100644
index 00000000..8630f010
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/791
@@ -0,0 +1 @@
+unable to execute QEMU command - SGX VM using libvirtd
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/810 b/gitlab/issues_text/target_i386/host_missing/accel_missing/810
new file mode 100644
index 00000000..12bb57b3
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/810
@@ -0,0 +1,71 @@
+i386/sev: Crash in pc_system_parse_ovmf_flash caused by bad firmware file
+Description of problem:
+A specially-crafted flash file can cause the `memcpy()` call in
+`pc_system_parse_ovmf_flash` (`hw/i386/pc_sysfw_ovmf.c`) to READ out-of-bounds
+memory, because there's no check on the `tot_len` field which is read
+from the flash file.  In such case, `ptr - tot_len` will point to a
+memory location *below* `flash_ptr` (hence the out-of-bounds read).
+
+This path is only taken when SEV is enabled (which requires 
+KVM and x86_64).
+Steps to reproduce:
+1. Create `bad_ovmf.fd` using the following python script:
+   ```
+   from uuid import UUID
+   OVMF_TABLE_FOOTER_GUID = "96b582de-1fb2-45f7-baea-a366c55a082d"
+   b = bytearray(4096)
+   b[4046:4048] = b'\xff\xff'   # tot_len field
+   b[4048:4064] = UUID("{" + OVMF_TABLE_FOOTER_GUID + "}").bytes_le
+   with open("bad_ovmf.fd", "wb") as f:
+       f.write(b)
+   ```
+2. Build QEMU with `--enable-sanitizers`
+3. Start QEMU with SEV and the bad flash file:
+   ```
+   qemu-system-x86_64 -enable-kvm -cpu host -machine q35 \
+                      -drive if=pflash,format=raw,unit=0,file=bad_ovmf.fd,readonly=on \
+                      -machine confidential-guest-support=sev0 \
+                      -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x0
+   ```
+4. QEMU crashes with: `SUMMARY: AddressSanitizer: stack-buffer-underflow`
+Additional information:
+Crash example:
+
+```
+$ sudo build/qemu-system-x86_64 -enable-kvm -cpu host -machine q35 \
+                                -drive if=pflash,format=raw,unit=0,file=bad_ovmf.fd,readonly=on \
+                                -machine confidential-guest-support=sev0 \
+                                -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x0
+==523314==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+=================================================================
+==523314==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7f05305fb180 at pc 0x7f0548d89480 bp 0x7ffed44a1980 sp 0x7ffed44a1128
+READ of size 65517 at 0x7f05305fb180 thread T0
+    #0 0x7f0548d8947f  (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x9b47f)
+    #1 0x556127c3331e in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
+    #2 0x556127c3331e in pc_system_parse_ovmf_flash ../hw/i386/pc_sysfw_ovmf.c:82
+    #3 0x556127c21a0c in pc_system_flash_map ../hw/i386/pc_sysfw.c:203
+    #4 0x556127c21a0c in pc_system_firmware_init ../hw/i386/pc_sysfw.c:258
+    #5 0x556127c1ddd9 in pc_memory_init ../hw/i386/pc.c:902
+    #6 0x556127bdc387 in pc_q35_init ../hw/i386/pc_q35.c:207
+    #7 0x5561273bfdd6 in machine_run_board_init ../hw/core/machine.c:1181
+    #8 0x556127f77de1 in qemu_init_board ../softmmu/vl.c:2652
+    #9 0x556127f77de1 in qmp_x_exit_preconfig ../softmmu/vl.c:2740
+    #10 0x556127f7f24d in qemu_init ../softmmu/vl.c:3775
+    #11 0x556126f947ac in main ../softmmu/main.c:49
+    #12 0x7f05470e80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
+    #13 0x556126fa639d in _start (/home/dmurik/git/qemu/build/qemu-system-x86_64+0x2a5739d)
+
+Address 0x7f05305fb180 is located in stack of thread T3 at offset 0 in frame
+    #0 0x556128a96f1f in qemu_sem_timedwait ../util/qemu-thread-posix.c:293
+
+
+  This frame has 1 object(s):
+    [32, 48) 'ts' (line 295) <== Memory access at offset 0 partially underflows this variable
+HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
+      (longjmp and C++ exceptions *are* supported)
+Thread T3 created by T0 here:
+    #0 0x7f0548d28805 in pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3a805)
+    #1 0x556128a97ecf in qemu_thread_create ../util/qemu-thread-posix.c:596
+
+SUMMARY: AddressSanitizer: stack-buffer-underflow (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x9b47f)
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/837 b/gitlab/issues_text/target_i386/host_missing/accel_missing/837
new file mode 100644
index 00000000..b2412695
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/837
@@ -0,0 +1,30 @@
+x86 user: icebp/int1 raises wrong signal
+Description of problem:
+This is a relatively minor inaccuracy. When `icebp` (`F1`) is executed, it raises `SIGILL` in QEMU, where the behavior on baremetal Linux (on an old Intel Core i5-430m) is to raise `SIGTRAP`.
+
+Specifically, on the architectural level, `icebp` raises `#DB` without affecting `dr6`.
+
+This also happens on an AArch64 host.
+```
+$ ./icebp
+Trace/breakpoint trap
+$ qemu-x86_64 ./icebp
+qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+Illegal instruction
+```
+Steps to reproduce:
+1. Compile this file using `gcc -nostdlib -static icebp.S -o icebp`, optionally with `-m32` to test i386
+```
+    .globl _start
+_start:
+    .byte  0xF1 // gas doesn't assemble this instruction opcode but it disassembles it
+#ifdef __x86_64__
+    mov    $60, %eax
+    syscall
+#else
+    mov    $1, %eax
+    int    $0x80
+#endif 
+```
+2. Run on baremetal. Notice how it raises `SIGTRAP` according to the shell job control message
+3. Run on qemu-user. Notice how it raises `SIGILL`.
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/855 b/gitlab/issues_text/target_i386/host_missing/accel_missing/855
new file mode 100644
index 00000000..27b5bbfd
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/855
@@ -0,0 +1,17 @@
+Prebuilt seabios vgabios-stdvga binary causes onboot kernel panics for freebsd 10.0
+Description of problem:
+FreeBSD 10.0 panics on boot since commit: `0221d73ce6a8e075adaa0a35a6ef853d2652b855`, see my attached screenshot of the panic. 
+I digged a bit into what specifically causes the issue, it seems to be caused by the precompiled `vgabios-stdvga.bin`. 
+I don't see this issue come up when I compile the binary myself via the `roms/` folder with different versions of gcc via gcc docker containers. 
+But once I compile the `vgabios-stdvga` from the `roms/` folder with a more modern Ubuntu version (21.10) using gcc 11.2, I also get panics on my `vgabios-stdvga`. 
+At first I thought it was caused by a different gcc version, but since the buster gcc docker container images create correctly functioning `vgabios-stdvga.bin` binaries, I think this is caused by a newer version of the linker coming from the `binutils` package.
+
+My local Ubuntu version has version 2.37 of the binutils package, the `gcc:11.2` container which compiles a correct `vgabios-stdvga.bin` has version `2.35.2` of the binutils package.
+
+![Screenshot_from_2022-02-03_17-35-59](/uploads/5bafeca625ebe8b38acd5a0d6c358392/Screenshot_from_2022-02-03_17-35-59.png)
+Steps to reproduce:
+1. Compile any version after the mentioned commit using the precompiled seabios binaries
+2. Try to boot freebsd 10.0-RELEASE
+3. Kernel panic because of a page vault during the vesa module load.
+Additional information:
+https://mfsbsd.vx.sk/files/iso/10/amd64/mfsbsd-10.0-RELEASE-amd64.iso
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/871 b/gitlab/issues_text/target_i386/host_missing/accel_missing/871
new file mode 100644
index 00000000..1b81a90e
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/871
@@ -0,0 +1,14 @@
+qemu-x86_64 don't support unshare(CLONE_NEWUSER)
+Description of problem:
+Why qemu-x86_64 call unshare(CLONE_NEWUSER) fail?
+```
+    fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ qemu-x86_64 /bin/unshare --user /bin/bash
+    unshare: unshare failed: Invalid argument
+    fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ /bin/unshare --user /bin/bash
+    nobody@ubuntu:~/Desktop/afl/AFLplusplus$
+```
+Steps to reproduce:
+1.execute `qemu-x86_64 /bin/unshare --user /bin/bash` ,it will fail <br/>
+2.execute `/bin/unshare --user /bin/bash` ,it will ok
+
+How i fix that?
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/877 b/gitlab/issues_text/target_i386/host_missing/accel_missing/877
new file mode 100644
index 00000000..9699197d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/877
@@ -0,0 +1,106 @@
+qemu-system-x86_64: Linux kernel warning when CONFIG_NUMA_EMU is enabled
+Description of problem:
+When Linux kernel is run on qemu 6.2, it prints a warning when `NUMA_EMU` is used. When the same kernel is run on qemu 6.1.1 (`54e1f5be86dd11744e45da8be6afad01d01d59e7`) or earlier, no such warning is printed.
+
+```
+[    0.341924] smpboot: CPU0: Intel QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1)
+[    0.342371] Performance Events: unsupported Netburst CPU model 107 no PMU driver, software events only.
+[    0.343302] rcu: Hierarchical SRCU implementation.
+[    0.344470] smp: Bringing up secondary CPUs ...
+[    0.345349] x86: Booting SMP configuration:
+[    0.345945] .... node  #1, CPUs:      #1
+[    0.014099] ------------[ cut here ]------------
+[    0.014099] sched: CPU #1's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
+[    0.014099] WARNING: CPU: 1 PID: 0 at arch/x86/kernel/smpboot.c:423 topology_sane.isra.0+0x62/0x70
+[    0.014099] Modules linked in:
+[    0.014099] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.16.9 #6
+[    0.014099] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
+[    0.014099] RIP: 0010:topology_sane.isra.0+0x62/0x70
+[    0.014099] Code: 80 3d e1 72 a1 01 00 75 f6 48 83 ec 08 4c 89 da 44 89 d6 48 c7 c7 c0 cd f4 8b 88 44 24 07 c6 05 c3 72 a1 01 01 e8 3c 16 b7 00 <0f> 0b 0f b6 44 24 07 48 83 c4 08 c3 66 90 48 8b 0d 21 95 a3 01 0f
+[    0.014099] RSP: 0000:ffffa8c3006a3ed8 EFLAGS: 00010086
+[    0.014099] RAX: 0000000000000000 RBX: ffffa335fdc15480 RCX: 0000000000000000
+[    0.014099] RDX: 0000000000000002 RSI: 00000000ffffffea RDI: 00000000ffffffff
+[    0.014099] RBP: ffffa3353dc15480 R08: ffffffff8c335ac8 R09: 00000000ffffdfff
+[    0.014099] R10: ffffffff8c255ae0 R11: ffffffff8c255ae0 R12: 0000000000000001
+[    0.014099] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
+[    0.014099] FS:  0000000000000000(0000) GS:ffffa335fdc00000(0000) knlGS:0000000000000000
+[    0.014099] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[    0.014099] CR2: 0000000000000000 CR3: 0000000112a0c000 CR4: 00000000000006e0
+[    0.014099] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[    0.014099] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[    0.014099] Call Trace:
+[    0.014099]  <TASK>
+[    0.014099]  set_cpu_sibling_map+0x16a/0x560
+[    0.014099]  start_secondary+0x42/0xf0
+[    0.014099]  secondary_startup_64_no_verify+0xc2/0xcb
+[    0.014099]  </TASK>
+[    0.014099] Kernel panic - not syncing: panic_on_warn set ...
+[    0.014099] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.16.9 #6
+[    0.014099] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
+[    0.014099] Call Trace:
+[    0.014099]  <TASK>
+[    0.014099]  dump_stack_lvl+0x34/0x44
+[    0.014099]  panic+0xef/0x2a6
+[    0.014099]  ? topology_sane.isra.0+0x62/0x70
+[    0.014099]  __warn.cold+0x26/0x30
+[    0.014099]  ? topology_sane.isra.0+0x62/0x70
+[    0.014099]  report_bug+0x9a/0xc0
+[    0.014099]  handle_bug+0x3c/0x60
+[    0.014099]  exc_invalid_op+0x14/0x70
+[    0.014099]  asm_exc_invalid_op+0x12/0x20
+[    0.014099] RIP: 0010:topology_sane.isra.0+0x62/0x70
+[    0.014099] Code: 80 3d e1 72 a1 01 00 75 f6 48 83 ec 08 4c 89 da 44 89 d6 48 c7 c7 c0 cd f4 8b 88 44 24 07 c6 05 c3 72 a1 01 01 e8 3c 16 b7 00 <0f> 0b 0f b6 44 24 07 48 83 c4 08 c3 66 90 48 8b 0d 21 95 a3 01 0f
+[    0.014099] RSP: 0000:ffffa8c3006a3ed8 EFLAGS: 00010086
+[    0.014099] RAX: 0000000000000000 RBX: ffffa335fdc15480 RCX: 0000000000000000
+[    0.014099] RDX: 0000000000000002 RSI: 00000000ffffffea RDI: 00000000ffffffff
+[    0.014099] RBP: ffffa3353dc15480 R08: ffffffff8c335ac8 R09: 00000000ffffdfff
+[    0.014099] R10: ffffffff8c255ae0 R11: ffffffff8c255ae0 R12: 0000000000000001
+[    0.014099] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
+[    0.014099]  ? topology_sane.isra.0+0x62/0x70
+[    0.014099]  set_cpu_sibling_map+0x16a/0x560
+[    0.014099]  start_secondary+0x42/0xf0
+[    0.014099]  secondary_startup_64_no_verify+0xc2/0xcb
+[    0.014099]  </TASK>
+[    0.014099] ---[ end Kernel panic - not syncing: panic_on_warn set ... ]---
+```
+Steps to reproduce:
+1. Check out the Linux kernel:
+```
+git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+cd linux-stable
+git checkout v5.16.9
+```
+2. Generate the configuration file:
+```
+make defconfig
+./scripts/config -e NUMA_EMU -e CMDLINE_BOOL --set-str CMDLINE "numa=fake=2 panic_on_warn=1" -d CONFIG_CMDLINE_OVERRIDE
+```
+3. Build the kernel
+```
+make -j32
+```
+4. Run qemu and wait for a couple of seconds:
+```
+./qemu-system-x86_64 -m 4G -smp 2 -kernel ~/linux-stable/arch/x86/boot/bzImage -append "console=ttyS0 root=/dev/sda earlyprintk=serial" -enable-kvm -nographic -snapshot
+```
+Additional information:
+With explicit NUMA configuration, it boots fine:
+```
+./qemu-system-x86_64 -m 4G -smp 2 -object memory-backend-ram,size=8G,id=m0 -numa node,cpus=0-1,nodeid=0,memdev=m0 -kernel ~/linux-stable/arch/x86/boot/bzImage -append "console=ttyS0 root=/dev/sda earlyprintk=serial" -enable-kvm -nographic -snapshot
+```
+
+On the host machine:
+```
+$ numactl -H
+available: 2 nodes (0-1)
+node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53
+node 0 size: 95259 MB
+node 0 free: 1767 MB
+node 1 cpus: 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71
+node 1 size: 96757 MB
+node 1 free: 2407 MB
+node distances:
+node   0   1 
+  0:  10  21 
+  1:  21  10 
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/91 b/gitlab/issues_text/target_i386/host_missing/accel_missing/91
new file mode 100644
index 00000000..5ed4aefe
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/91
@@ -0,0 +1 @@
+RFE: Implement support for SMBIOS Type 41 structures
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/921 b/gitlab/issues_text/target_i386/host_missing/accel_missing/921
new file mode 100644
index 00000000..60636e04
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/921
@@ -0,0 +1,623 @@
+qemu 7.0-rc0 warning: cannot get sys attribute capabilities 0
+Description of problem:
+The guest fp not working properly
+Steps to reproduce:
+1. Start the docker
+```
+docker run -it --name qemu --rm \
+    --privileged \
+    --ipc=host \
+    -v /dev/log:/dev/log \
+    -v /dev/vhost-net:/dev/vhost-net \
+    -v /sys/kernel/debug:/sys/kernel/debug \
+    -v $ROOT:$ROOT \
+    -p 2222:22 \
+    -p 1234:1234 \
+    -p 1235:1235 \
+    -e ROOT=$ROOT \
+    -e XDG_RUNTIME_DIR=/tmp \
+    -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \
+    -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY \
+    qemu
+```
+2.This is in the docker
+```
++ build/docker/qemu-system-x86_64 -enable-kvm -M q35 -smp 1 -m 4G -cpu host -net nic,model=virtio -net user,hostfwd=tcp::22-:22,hostfwd=tcp::1234-:1234 -hda /data/xemu-opengl/image/ubuntu.qcow2 -initrd /data/xemu-opengl/image/rootfs.cpio.gz -kernel /data/xemu-opengl/kernel/arch/x86_64/boot/bzImage -append 'root=/dev/sda3 nokaslr' -usb -device usb-tablet -object memory-backend-memfd,id=mem1,size=4G -machine memory-backend=mem1 -device virtio-vga-gl,context_init=true,blob=true,hostmem=1G -vga none -display sdl,gl=on,show-cursor=on -d guest_errors
+qemu-system-x86_64: warning: cannot get sys attribute capabilities 0
+qemu-system-x86_64: warning: cannot get sys attribute capabilities 0
+qemu-system-x86_64: warning: cannot get sys attribute capabilities 0
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 1]
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 2]
+qemu-system-x86_64: warning: cannot get sys attribute capabilities 0
+```
+
+3. In geust
+```
+dmesg
+[    0.000000] Linux version 5.16.14 (root@5bc45822eca9) (gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.37) #3 SMP PREEMPT Sun Mar 13 23:24:16 UTC 2022
+[    0.000000] Command line: root=/dev/sda3 nokaslr
+[    0.000000] x86/fpu: FP/SSE not present amongst the CPU's xstate features: 0x1.
+[    0.000000] signal: max sigframe size: 1440
+[    0.000000] BIOS-provided physical RAM map:
+[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
+[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
+[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
+[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ffddfff] usable
+[    0.000000] BIOS-e820: [mem 0x000000007ffde000-0x000000007fffffff] reserved
+[    0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
+[    0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
+[    0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
+[    0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
+[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000017fffffff] usable
+[    0.000000] NX (Execute Disable) protection: active
+[    0.000000] SMBIOS 2.8 present.
+[    0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
+[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
+[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
+[    0.000000] last_pfn = 0x180000 max_arch_pfn = 0x400000000
+[    0.000000] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
+[    0.000000] last_pfn = 0x7ffde max_arch_pfn = 0x400000000
+[    0.000000] found SMP MP-table at [mem 0x000f5b70-0x000f5b7f]
+[    0.000000] Using GB pages for direct mapping
+[    0.000000] RAMDISK: [mem 0x7ffcf000-0x7ffcffff]
+[    0.000000] ACPI: Early table checksum verification disabled
+[    0.000000] ACPI: RSDP 0x00000000000F5980 000014 (v00 BOCHS )
+[    0.000000] ACPI: RSDT 0x000000007FFE22CB 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: FACP 0x000000007FFE20C3 0000F4 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: DSDT 0x000000007FFE0040 002083 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: FACS 0x000000007FFE0000 000040
+[    0.000000] ACPI: APIC 0x000000007FFE21B7 000078 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: HPET 0x000000007FFE222F 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: MCFG 0x000000007FFE2267 00003C (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: WAET 0x000000007FFE22A3 000028 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: Reserving FACP table memory at [mem 0x7ffe20c3-0x7ffe21b6]
+[    0.000000] ACPI: Reserving DSDT table memory at [mem 0x7ffe0040-0x7ffe20c2]
+[    0.000000] ACPI: Reserving FACS table memory at [mem 0x7ffe0000-0x7ffe003f]
+[    0.000000] ACPI: Reserving APIC table memory at [mem 0x7ffe21b7-0x7ffe222e]
+[    0.000000] ACPI: Reserving HPET table memory at [mem 0x7ffe222f-0x7ffe2266]
+[    0.000000] ACPI: Reserving MCFG table memory at [mem 0x7ffe2267-0x7ffe22a2]
+[    0.000000] ACPI: Reserving WAET table memory at [mem 0x7ffe22a3-0x7ffe22ca]
+[    0.000000] No NUMA configuration found
+[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000017fffffff]
+[    0.000000] NODE_DATA(0) allocated [mem 0x17fffa000-0x17fffdfff]
+[    0.000000] Zone ranges:
+[    0.000000]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
+[    0.000000]   DMA32    [mem 0x0000000001000000-0x00000000ffffffff]
+[    0.000000]   Normal   [mem 0x0000000100000000-0x000000017fffffff]
+[    0.000000] Movable zone start for each node
+[    0.000000] Early memory node ranges
+[    0.000000]   node   0: [mem 0x0000000000001000-0x000000000009efff]
+[    0.000000]   node   0: [mem 0x0000000000100000-0x000000007ffddfff]
+[    0.000000]   node   0: [mem 0x0000000100000000-0x000000017fffffff]
+[    0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000017fffffff]
+[    0.000000] On node 0, zone DMA: 1 pages in unavailable ranges
+[    0.000000] On node 0, zone DMA: 97 pages in unavailable ranges
+[    0.000000] On node 0, zone Normal: 34 pages in unavailable ranges
+[    0.000000] ACPI: PM-Timer IO Port: 0x608
+[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
+[    0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23
+[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
+[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
+[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
+[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
+[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
+[    0.000000] ACPI: Using ACPI (MADT) for SMP configuration information
+[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
+[    0.000000] TSC deadline timer available
+[    0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
+[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff]
+[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x0009f000-0x0009ffff]
+[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x000a0000-0x000effff]
+[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x000f0000-0x000fffff]
+[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x7ffde000-0x7fffffff]
+[    0.000000] PM: hibernation: Registered nosave memory: [mem 0x80000000-0xafffffff]
+[    0.000000] PM: hibernation: Registered nosave memory: [mem 0xb0000000-0xbfffffff]
+[    0.000000] PM: hibernation: Registered nosave memory: [mem 0xc0000000-0xfed1bfff]
+[    0.000000] PM: hibernation: Registered nosave memory: [mem 0xfed1c000-0xfed1ffff]
+[    0.000000] PM: hibernation: Registered nosave memory: [mem 0xfed20000-0xfeffbfff]
+[    0.000000] PM: hibernation: Registered nosave memory: [mem 0xfeffc000-0xfeffffff]
+[    0.000000] PM: hibernation: Registered nosave memory: [mem 0xff000000-0xfffbffff]
+[    0.000000] PM: hibernation: Registered nosave memory: [mem 0xfffc0000-0xffffffff]
+[    0.000000] [mem 0xc0000000-0xfed1bfff] available for PCI devices
+[    0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
+[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:1 nr_node_ids:1
+[    0.000000] percpu: Embedded 52 pages/cpu s174744 r8192 d30056 u2097152
+[    0.000000] pcpu-alloc: s174744 r8192 d30056 u2097152 alloc=1*2097152
+[    0.000000] pcpu-alloc: [0] 0 
+[    0.000000] Fallback order for Node 0: 0 
+[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 1031902
+[    0.000000] Policy zone: Normal
+[    0.000000] Kernel command line: root=/dev/sda3 nokaslr
+[    0.000000] Unknown kernel command line parameters "nokaslr", will be passed to user space.
+[    0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
+[    0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
+[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
+[    0.000000] Memory: 4019736K/4193776K available (16398K kernel code, 2621K rwdata, 5052K rodata, 1252K init, 1332K bss, 173784K reserved, 0K cma-reserved)
+[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
+[    0.000000] Dynamic Preempt: full
+[    0.000000] rcu: Preemptible hierarchical RCU implementation.
+[    0.000000] rcu:     RCU event tracing is enabled.
+[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=1.
+[    0.000000]  Trampoline variant of Tasks RCU enabled.
+[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
+[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
+[    0.000000] NR_IRQS: 4352, nr_irqs: 256, preallocated irqs: 16
+[    0.000000] random: get_random_bytes called from start_kernel+0x492/0x65f with crng_init=0
+[    0.000000] Console: colour VGA+ 80x25
+[    0.000000] printk: console [tty0] enabled
+[    0.000000] ACPI: Core revision 20210930
+[    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
+[    0.001000] APIC: Switch to symmetric I/O mode setup
+[    0.002000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
+[    0.010000] tsc: Unable to calibrate against PIT
+[    0.011000] tsc: using HPET reference calibration
+[    0.012000] tsc: Detected 3699.687 MHz processor
+[    0.000260] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x6aa85c29371, max_idle_ns: 881590506582 ns
+[    0.001636] Calibrating delay loop (skipped), value calculated using timer frequency.. 7399.37 BogoMIPS (lpj=3699687)
+[    0.002617] pid_max: default: 32768 minimum: 301
+[    0.003888] LSM: Security Framework initializing
+[    0.004744] SELinux:  Initializing.
+[    0.006672] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
+[    0.007869] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
+[    0.014682] x86/cpu: User Mode Instruction Prevention (UMIP) activated
+[    0.016974] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127
+[    0.017603] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0
+[    0.018602] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
+[    0.018623] Spectre V2 : Mitigation: Retpolines
+[    0.019603] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
+[    0.020637] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
+[    0.021603] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
+[    0.083192] Freeing SMP alternatives memory: 44K
+[    0.086287] smpboot: CPU0: AMD Ryzen Threadripper 3970X 32-Core Processor (family: 0x17, model: 0x31, stepping: 0x0)
+[    0.088185] Performance Events: Fam17h+ core perfctr, AMD PMU driver.
+[    0.088635] ... version:                0
+[    0.089365] ... bit width:              48
+[    0.089610] ... generic registers:      6
+[    0.090332] ... value mask:             0000ffffffffffff
+[    0.090611] ... max period:             00007fffffffffff
+[    0.091424] ... fixed-purpose events:   0
+[    0.091614] ... event mask:             000000000000003f
+[    0.092889] rcu: Hierarchical SRCU implementation.
+[    0.095245] smp: Bringing up secondary CPUs ...
+[    0.095612] smp: Brought up 1 node, 1 CPU
+[    0.096340] smpboot: Max logical packages: 1
+[    0.096609] smpboot: Total of 1 processors activated (7399.37 BogoMIPS)
+[    0.169912] devtmpfs: initialized
+[    0.175284] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
+[    0.175676] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
+[    0.177611] PM: RTC time: 10:29:46, date: 2022-03-20
+[    0.183040] NET: Registered PF_NETLINK/PF_ROUTE protocol family
+[    0.187536] audit: initializing netlink subsys (disabled)
+[    0.191857] thermal_sys: Registered thermal governor 'step_wise'
+[    0.191877] thermal_sys: Registered thermal governor 'user_space'
+[    0.192675] audit: type=2000 audit(1647772186.201:1): state=initialized audit_enabled=0 res=1
+[    0.194185] cpuidle: using governor menu
+[    0.198008] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000)
+[    0.198662] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820
+[    0.200081] PCI: Using configuration type 1 for base access
+[    0.204517] kprobes: kprobe jump-optimization is enabled. All kprobes are optimized if possible.
+[    0.205408] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
+[    0.206698] ACPI: Added _OSI(Module Device)
+[    0.207453] ACPI: Added _OSI(Processor Device)
+[    0.207610] ACPI: Added _OSI(3.0 _SCP Extensions)
+[    0.208402] ACPI: Added _OSI(Processor Aggregator Device)
+[    0.208611] ACPI: Added _OSI(Linux-Dell-Video)
+[    0.209375] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
+[    0.209614] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
+[    0.212597] ACPI: 1 ACPI AML tables successfully acquired and loaded
+[    0.215363] ACPI: Interpreter enabled
+[    0.215779] ACPI: PM: (supports S0 S3 S4 S5)
+[    0.216543] ACPI: Using IOAPIC for interrupt routing
+[    0.216649] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
+[    0.217739] ACPI: Enabled 2 GPEs in block 00 to 3F
+[    0.221429] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
+[    0.221679] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
+[    0.222638] acpi PNP0A08:00: _OSC: platform does not support [LTR]
+[    0.223563] acpi PNP0A08:00: _OSC: OS now controls [PME PCIeCapability]
+[    0.223907] PCI host bridge to bus 0000:00
+[    0.224612] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
+[    0.225562] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
+[    0.225610] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
+[    0.226616] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window]
+[    0.227610] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window]
+[    0.228611] pci_bus 0000:00: root bus resource [mem 0x180000000-0x97fffffff window]
+[    0.229611] pci_bus 0000:00: root bus resource [bus 00-ff]
+[    0.230749] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000
+[    0.233477] pci 0000:00:01.0: [1af4:1000] type 00 class 0x020000
+[    0.234636] pci 0000:00:01.0: reg 0x10: [io  0xc040-0xc05f]
+[    0.236087] pci 0000:00:01.0: reg 0x14: [mem 0xfebd0000-0xfebd0fff]
+[    0.239084] pci 0000:00:01.0: reg 0x20: [mem 0x1c0000000-0x1c0003fff 64bit pref]
+[    0.240327] pci 0000:00:01.0: reg 0x30: [mem 0xfeb80000-0xfebbffff pref]
+[    0.242540] pci 0000:00:02.0: [1af4:1050] type 00 class 0x030000
+[    0.245344] pci 0000:00:02.0: reg 0x10: [mem 0xfe000000-0xfe7fffff pref]
+[    0.247587] pci 0000:00:02.0: reg 0x14: [mem 0xfebd1000-0xfebd1fff]
+[    0.250649] pci 0000:00:02.0: reg 0x18: [mem 0x1c0004000-0x1c0007fff 64bit pref]
+[    0.253628] pci 0000:00:02.0: reg 0x20: [mem 0x180000000-0x1bfffffff 64bit pref]
+[    0.256753] pci 0000:00:02.0: reg 0x30: [mem 0xfebc0000-0xfebcffff pref]
+[    0.258570] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
+[    0.263325] pci 0000:00:1d.0: [8086:2934] type 00 class 0x0c0300
+[    0.265363] pci 0000:00:1d.0: reg 0x20: [io  0xc060-0xc07f]
+[    0.266765] pci 0000:00:1d.1: [8086:2935] type 00 class 0x0c0300
+[    0.269437] pci 0000:00:1d.1: reg 0x20: [io  0xc080-0xc09f]
+[    0.270732] pci 0000:00:1d.2: [8086:2936] type 00 class 0x0c0300
+[    0.273371] pci 0000:00:1d.2: reg 0x20: [io  0xc0a0-0xc0bf]
+[    0.274696] pci 0000:00:1d.7: [8086:293a] type 00 class 0x0c0320
+[    0.276035] pci 0000:00:1d.7: reg 0x10: [mem 0xfebd2000-0xfebd2fff]
+[    0.279317] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100
+[    0.280866] pci 0000:00:1f.0: quirk: [io  0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO
+[    0.282331] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601
+[    0.284903] pci 0000:00:1f.2: reg 0x20: [io  0xc0c0-0xc0df]
+[    0.286143] pci 0000:00:1f.2: reg 0x24: [mem 0xfebd3000-0xfebd3fff]
+[    0.287991] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500
+[    0.290370] pci 0000:00:1f.3: reg 0x20: [io  0x0700-0x073f]
+[    0.293435] ACPI: PCI: Interrupt link LNKA configured for IRQ 10
+[    0.293726] ACPI: PCI: Interrupt link LNKB configured for IRQ 10
+[    0.294744] ACPI: PCI: Interrupt link LNKC configured for IRQ 11
+[    0.295723] ACPI: PCI: Interrupt link LNKD configured for IRQ 11
+[    0.296740] ACPI: PCI: Interrupt link LNKE configured for IRQ 10
+[    0.297763] ACPI: PCI: Interrupt link LNKF configured for IRQ 10
+[    0.298722] ACPI: PCI: Interrupt link LNKG configured for IRQ 11
+[    0.299743] ACPI: PCI: Interrupt link LNKH configured for IRQ 11
+[    0.300662] ACPI: PCI: Interrupt link GSIA configured for IRQ 16
+[    0.301579] ACPI: PCI: Interrupt link GSIB configured for IRQ 17
+[    0.301618] ACPI: PCI: Interrupt link GSIC configured for IRQ 18
+[    0.302625] ACPI: PCI: Interrupt link GSID configured for IRQ 19
+[    0.303570] ACPI: PCI: Interrupt link GSIE configured for IRQ 20
+[    0.303617] ACPI: PCI: Interrupt link GSIF configured for IRQ 21
+[    0.304524] ACPI: PCI: Interrupt link GSIG configured for IRQ 22
+[    0.304617] ACPI: PCI: Interrupt link GSIH configured for IRQ 23
+[    0.307401] iommu: Default domain type: Translated 
+[    0.307611] iommu: DMA domain TLB invalidation policy: lazy mode 
+[    0.309801] pci 0000:00:02.0: vgaarb: setting as boot VGA device
+[    0.310602] pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
+[    0.310612] pci 0000:00:02.0: vgaarb: bridge control possible
+[    0.311469] vgaarb: loaded
+[    0.312823] SCSI subsystem initialized
+[    0.314995] libata version 3.00 loaded.
+[    0.315348] ACPI: bus type USB registered
+[    0.315984] usbcore: registered new interface driver usbfs
+[    0.316671] usbcore: registered new interface driver hub
+[    0.317497] usbcore: registered new device driver usb
+[    0.317760] pps_core: LinuxPPS API ver. 1 registered
+[    0.318568] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
+[    0.318672] PTP clock support registered
+[    0.320169] Advanced Linux Sound Architecture Driver Initialized.
+[    0.322001] NetLabel: Initializing
+[    0.322614] NetLabel:  domain hash size = 128
+[    0.323353] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
+[    0.323799] NetLabel:  unlabeled traffic allowed by default
+[    0.324864] PCI: Using ACPI for IRQ routing
+[    0.486511] PCI: pci_cache_line_size set to 64 bytes
+[    0.487017] e820: reserve RAM buffer [mem 0x0009fc00-0x0009ffff]
+[    0.487056] e820: reserve RAM buffer [mem 0x7ffde000-0x7fffffff]
+[    0.488868] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
+[    0.489610] hpet0: 3 comparators, 64-bit 100.000000 MHz counter
+[    0.493993] clocksource: Switched to clocksource tsc-early
+[    0.595279] VFS: Disk quotas dquot_6.6.0
+[    0.604747] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
+[    0.606192] pnp: PnP ACPI init
+[    0.607564] system 00:05: [mem 0xb0000000-0xbfffffff window] has been reserved
+[    0.612917] pnp: PnP ACPI: found 6 devices
+[    0.630876] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
+[    0.635819] NET: Registered PF_INET protocol family
+[    0.639137] IP idents hash table entries: 65536 (order: 7, 524288 bytes, linear)
+[    0.648315] tcp_listen_portaddr_hash hash table entries: 2048 (order: 3, 32768 bytes, linear)
+[    0.649938] TCP established hash table entries: 32768 (order: 6, 262144 bytes, linear)
+[    0.656731] TCP bind hash table entries: 32768 (order: 7, 524288 bytes, linear)
+[    0.668799] TCP: Hash tables configured (established 32768 bind 32768)
+[    0.670725] UDP hash table entries: 2048 (order: 4, 65536 bytes, linear)
+[    0.675922] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes, linear)
+[    0.677641] NET: Registered PF_UNIX/PF_LOCAL protocol family
+[    0.683489] RPC: Registered named UNIX socket transport module.
+[    0.684419] RPC: Registered udp transport module.
+[    0.685233] RPC: Registered tcp transport module.
+[    0.686051] RPC: Registered tcp NFSv4.1 backchannel transport module.
+[    0.690218] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
+[    0.691147] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
+[    0.692046] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
+[    0.695623] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window]
+[    0.702621] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window]
+[    0.703550] pci_bus 0000:00: resource 9 [mem 0x180000000-0x97fffffff window]
+[    0.709679] ACPI: \_SB_.GSIA: Enabled at IRQ 16
+[    0.711527] ACPI: \_SB_.GSIB: Enabled at IRQ 17
+[    0.717245] ACPI: \_SB_.GSIC: Enabled at IRQ 18
+[    0.718745] ACPI: \_SB_.GSID: Enabled at IRQ 19
+[    0.720153] PCI: CLS 0 bytes, default 64
+[    0.725883] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
+[    0.726841] software IO TLB: mapped [mem 0x000000007bfcf000-0x000000007ffcf000] (64MB)
+[    0.728264] Unpacking initramfs...
+[    0.744075] Freeing initrd memory: 4K
+[    0.756363] Initialise system trusted keyrings
+[    0.758663] workingset: timestamp_bits=56 max_order=20 bucket_order=0
+[    0.764972] NFS: Registering the id_resolver key type
+[    0.767942] Key type id_resolver registered
+[    0.768863] Key type id_legacy registered
+[    0.770030] 9p: Installing v9fs 9p2000 file system support
+[    0.775964] Key type asymmetric registered
+[    0.776761] Asymmetric key parser 'x509' registered
+[    0.777862] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
+[    0.779862] io scheduler mq-deadline registered
+[    0.780675] io scheduler kyber registered
+[    0.782859] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
+[    0.787721] ACPI: button: Power Button [PWRF]
+[    0.791799] ACPI: \_SB_.GSIF: Enabled at IRQ 21
+[    0.795895] ACPI: \_SB_.GSIG: Enabled at IRQ 22
+[    0.802029] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
+[    0.803727] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
+[    0.806289] Non-volatile memory driver v1.3
+[    0.807110] Linux agpgart interface v0.103
+[    0.808280] ACPI: bus type drm_connector registered
+[    0.810106] [drm] pci: virtio-vga detected at 0000:00:02.0
+[    0.811033] virtio-pci 0000:00:02.0: vgaarb: deactivate vga console
+[    0.812950] Console: switching to colour dummy device 80x25
+[    0.814010] [drm] Host memory window: 0x180000000 +0x40000000
+[    0.814014] [drm] features: +virgl +edid +resource_blob +host_visible
+[    0.814015] [drm] features: +context_init
+[    0.815749] [drm] number of scanouts: 1
+[    0.815764] [drm] number of cap sets: 1
+[    0.822421] [drm] cap set 0: id 4, max-version 0, max-size 20
+[    0.823816] [drm] Initialized virtio_gpu 0.1.0 0 for virtio1 on minor 0
+[    0.835655] loop: module loaded
+[    0.836198] ahci 0000:00:1f.2: version 3.0
+[    0.838738] ahci 0000:00:1f.2: AHCI 0001.0000 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode
+[    0.838743] ahci 0000:00:1f.2: flags: 64bit ncq only 
+[    0.844268] scsi host0: ahci
+[    0.845062] scsi host1: ahci
+[    0.845675] scsi host2: ahci
+[    0.846482] scsi host3: ahci
+[    0.847257] scsi host4: ahci
+[    0.847860] scsi host5: ahci
+[    0.848240] ata1: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3100 irq 27
+[    0.848266] ata2: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3180 irq 27
+[    0.848281] ata3: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3200 irq 27
+[    0.848295] ata4: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3280 irq 27
+[    0.848310] ata5: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3300 irq 27
+[    0.848324] ata6: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3380 irq 27
+[    0.854343] e100: Intel(R) PRO/100 Network Driver
+[    0.854365] e100: Copyright(c) 1999-2006 Intel Corporation
+[    0.854401] e1000: Intel(R) PRO/1000 Network Driver
+[    0.854403] e1000: Copyright (c) 1999-2006 Intel Corporation.
+[    0.854505] e1000e: Intel(R) PRO/1000 Network Driver
+[    0.854506] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
+[    0.854562] sky2: driver version 1.30
+[    0.855224] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
+[    0.855227] ehci-pci: EHCI PCI platform driver
+[    0.856209] ehci-pci 0000:00:1d.7: EHCI Host Controller
+[    0.856447] ehci-pci 0000:00:1d.7: new USB bus registered, assigned bus number 1
+[    0.857195] ehci-pci 0000:00:1d.7: irq 19, io mem 0xfebd2000
+[    0.863684] ehci-pci 0000:00:1d.7: USB 2.0 started, EHCI 1.00
+[    0.863941] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.16
+[    0.863946] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
+[    0.863948] usb usb1: Product: EHCI Host Controller
+[    0.863950] usb usb1: Manufacturer: Linux 5.16.14 ehci_hcd
+[    0.863952] usb usb1: SerialNumber: 0000:00:1d.7
+[    0.864286] hub 1-0:1.0: USB hub found
+[    0.864294] hub 1-0:1.0: 6 ports detected
+[    0.864919] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
+[    0.864953] ohci-pci: OHCI PCI platform driver
+[    0.865050] uhci_hcd: USB Universal Host Controller Interface driver
+[    0.865658] uhci_hcd 0000:00:1d.0: UHCI Host Controller
+[    0.865792] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
+[    0.866072] uhci_hcd 0000:00:1d.0: irq 16, io port 0x0000c060
+[    0.866256] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.16
+[    0.866259] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
+[    0.866262] usb usb2: Product: UHCI Host Controller
+[    0.866263] usb usb2: Manufacturer: Linux 5.16.14 uhci_hcd
+[    0.866265] usb usb2: SerialNumber: 0000:00:1d.0
+[    0.866537] hub 2-0:1.0: USB hub found
+[    0.866542] hub 2-0:1.0: 2 ports detected
+[    0.867382] uhci_hcd 0000:00:1d.1: UHCI Host Controller
+[    0.867567] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
+[    0.867827] uhci_hcd 0000:00:1d.1: irq 17, io port 0x0000c080
+[    0.868033] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.16
+[    0.868037] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
+[    0.868039] usb usb3: Product: UHCI Host Controller
+[    0.868040] usb usb3: Manufacturer: Linux 5.16.14 uhci_hcd
+[    0.868042] usb usb3: SerialNumber: 0000:00:1d.1
+[    0.868240] hub 3-0:1.0: USB hub found
+[    0.868245] hub 3-0:1.0: 2 ports detected
+[    0.869174] uhci_hcd 0000:00:1d.2: UHCI Host Controller
+[    0.869321] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
+[    0.869553] uhci_hcd 0000:00:1d.2: irq 18, io port 0x0000c0a0
+[    0.869959] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.16
+[    0.869963] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
+[    0.869965] usb usb4: Product: UHCI Host Controller
+[    0.870002] usb usb4: Manufacturer: Linux 5.16.14 uhci_hcd
+[    0.870003] usb usb4: SerialNumber: 0000:00:1d.2
+[    0.870149] hub 4-0:1.0: USB hub found
+[    0.870153] hub 4-0:1.0: 2 ports detected
+[    0.870910] usbcore: registered new interface driver usblp
+[    0.870991] usbcore: registered new interface driver usb-storage
+[    0.871112] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
+[    0.873033] serio: i8042 KBD port at 0x60,0x64 irq 1
+[    0.873240] serio: i8042 AUX port at 0x60,0x64 irq 12
+[    0.874086] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1
+[    0.878739] rtc_cmos 00:04: RTC can wake from S4
+[    0.880210] rtc_cmos 00:04: registered as rtc0
+[    0.880321] rtc_cmos 00:04: alarms up to one day, y3k, 242 bytes nvram, hpet irqs
+[    0.880886] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt
+[    0.881236] i2c i2c-0: 1/1 memory slots populated (from DMI)
+[    0.881239] i2c i2c-0: Memory type 0x07 not supported yet, not instantiating SPD
+[    0.881737] device-mapper: ioctl: 4.45.0-ioctl (2021-03-22) initialised: dm-devel@redhat.com
+[    0.882038] hid: raw HID events driver (C) Jiri Kosina
+[    0.882495] usbcore: registered new interface driver usbhid
+[    0.882498] usbhid: USB HID core driver
+[    0.890838] Initializing XFRM netlink socket
+[    0.891351] NET: Registered PF_INET6 protocol family
+[    0.893594] Segment Routing with IPv6
+[    0.893647] In-situ OAM (IOAM) with IPv6
+[    0.893870] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
+[    0.894342] NET: Registered PF_PACKET protocol family
+[    0.894821] 9pnet: Installing 9P2000 support
+[    0.894914] Key type dns_resolver registered
+[    0.895481] IPI shorthand broadcast: enabled
+[    0.895672] sched_clock: Marking stable (908022380, -12397814)->(1044483817, -148859251)
+[    0.895978] registered taskstats version 1
+[    0.895980] Loading compiled-in X.509 certificates
+[    0.897126] cryptomgr_test (53) used greatest stack depth: 15480 bytes left
+[    0.897149] cryptomgr_test (54) used greatest stack depth: 15448 bytes left
+[    0.898086] cryptomgr_test (69) used greatest stack depth: 15392 bytes left
+[    0.900491] PM:   Magic number: 14:469:477
+[    0.901051] printk: console [netcon0] enabled
+[    0.901053] netconsole: network logging started
+[    0.901456] cfg80211: Loading compiled-in X.509 certificates for regulatory database
+[    0.903159] kworker/u2:6 (76) used greatest stack depth: 14656 bytes left
+[    0.903680] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
+[    0.903771] ALSA device list:
+[    0.903773]   No soundcards found.
+[    0.904412] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
+[    0.904450] cfg80211: failed to load regulatory.db
+[    1.094640] usb 1-1: new high-speed USB device number 2 using ehci-pci
+[    1.146521] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
+[    1.146780] ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100
+[    1.146785] ata1.00: 33554432 sectors, multi 16: LBA48 NCQ (depth 32)
+[    1.146810] ata1.00: applying bridge limits
+[    1.147076] ata1.00: configured for UDMA/100
+[    1.147318] ata2: SATA link down (SStatus 0 SControl 300)
+[    1.154178] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
+[    1.154371] ata3.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100
+[    1.154375] ata3.00: applying bridge limits
+[    1.154673] ata3.00: configured for UDMA/100
+[    1.155258] ata4: SATA link down (SStatus 0 SControl 300)
+[    1.155530] ata5: SATA link down (SStatus 0 SControl 300)
+[    1.155833] ata6: SATA link down (SStatus 0 SControl 300)
+[    1.157704] scsi 0:0:0:0: Direct-Access     ATA      QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
+[    1.158268] sd 0:0:0:0: [sda] 33554432 512-byte logical blocks: (17.2 GB/16.0 GiB)
+[    1.158307] sd 0:0:0:0: [sda] Write Protect is off
+[    1.158309] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+[    1.158316] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+[    1.158993] sd 0:0:0:0: Attached scsi generic sg0 type 0
+[    1.165858] scsi 2:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM     2.5+ PQ: 0 ANSI: 5
+[    1.175815]  sda: sda1 sda2 sda3
+[    1.176475] sd 0:0:0:0: [sda] Attached SCSI disk
+[    1.181093] sr 2:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
+[    1.181149] cdrom: Uniform CD-ROM driver Revision: 3.20
+[    1.197445] sr 2:0:0:0: Attached scsi CD-ROM sr0
+[    1.197689] sr 2:0:0:0: Attached scsi generic sg1 type 5
+[    1.224877] usb 1-1: New USB device found, idVendor=0627, idProduct=0001, bcdDevice= 0.00
+[    1.224885] usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=10
+[    1.224887] usb 1-1: Product: QEMU USB Tablet
+[    1.224889] usb 1-1: Manufacturer: QEMU
+[    1.224891] usb 1-1: SerialNumber: 28754-0000:00:1d.7-1
+[    1.231334] input: QEMU QEMU USB Tablet as /devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input4
+[    1.231474] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:1d.7-1/input0
+[    1.484028] random: fast init done
+[    1.486085] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3
+[    1.486277] md: Waiting for all devices to be available before autodetect
+[    1.486280] md: If you don't use raid, use raid=noautodetect
+[    1.486308] md: Autodetecting RAID arrays.
+[    1.486310] md: autorun ...
+[    1.486311] md: ... autorun DONE.
+[    1.489760] EXT4-fs (sda3): INFO: recovery required on readonly filesystem
+[    1.489764] EXT4-fs (sda3): write access will be enabled during recovery
+[    1.549515] EXT4-fs (sda3): recovery complete
+[    1.551218] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
+[    1.551395] VFS: Mounted root (ext4 filesystem) readonly on device 8:3.
+[    1.552185] devtmpfs: mounted
+[    1.564828] Freeing unused kernel image (initmem) memory: 1252K
+[    1.565429] Write protecting the kernel read-only data: 24576k
+[    1.588472] Freeing unused kernel image (text/rodata gap) memory: 2032K
+[    1.599305] Freeing unused kernel image (rodata/data gap) memory: 1092K
+[    1.600131] Run /sbin/init as init process
+[    1.600145]   with arguments:
+[    1.600145]     /sbin/init
+[    1.600145]     nokaslr
+[    1.600146]   with environment:
+[    1.600146]     HOME=/
+[    1.600146]     TERM=linux
+[    1.719163] systemd[1]: systemd 248.3-1ubuntu8.2 running in system mode. (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
+[    1.719924] systemd[1]: Detected virtualization kvm.
+[    1.719999] systemd[1]: Detected architecture x86-64.
+[    1.721691] systemd[1]: Hostname set to <lygstate-Standard-PC-Q35-ICH9-2009>.
+[    1.742316] (sd-executor) (84) used greatest stack depth: 13744 bytes left
+[    1.747792] tsc: Refined TSC clocksource calibration: 3699.944 MHz
+[    1.747936] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x6aaa423949d, max_idle_ns: 881591081251 ns
+[    1.748220] clocksource: Switched to clocksource tsc
+[    1.804055] friendly-recove (87) used greatest stack depth: 13736 bytes left
+[    1.857049] openvpn-generat (89) used greatest stack depth: 13672 bytes left
+[    1.857104] ls (104) used greatest stack depth: 13616 bytes left
+[    2.049195] systemd[1]: Queued start job for default target Graphical Interface.
+[    2.053399] systemd[1]: Created slice system-modprobe.slice.
+[    2.055075] systemd[1]: Created slice system-systemd\x2dfsck.slice.
+[    2.055330] systemd[1]: Created slice User and Session Slice.
+[    2.055443] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
+[    2.057210] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
+[    2.057325] systemd[1]: Reached target User and Group Name Lookups.
+[    2.057352] systemd[1]: Reached target Remote File Systems.
+[    2.057371] systemd[1]: Reached target Slices.
+[    2.057397] systemd[1]: Reached target Local Verity Integrity Protected Volumes.
+[    2.058182] systemd[1]: Listening on Syslog Socket.
+[    2.058530] systemd[1]: Listening on fsck to fsckd communication Socket.
+[    2.058768] systemd[1]: Listening on initctl Compatibility Named Pipe.
+[    2.059725] systemd[1]: Listening on Journal Audit Socket.
+[    2.059946] systemd[1]: Listening on Journal Socket (/dev/log).
+[    2.060156] systemd[1]: Listening on Journal Socket.
+[    2.060815] systemd[1]: Listening on udev Control Socket.
+[    2.060970] systemd[1]: Listening on udev Kernel Socket.
+[    2.065155] systemd[1]: Mounting Huge Pages File System...
+[    2.069417] systemd[1]: Mounting POSIX Message Queue File System...
+[    2.079658] systemd[1]: Mounting Kernel Debug File System...
+[    2.082741] systemd[1]: Mounting Kernel Trace File System...
+[    2.083848] systemd[1]: systemd-journald.service: unit configures an IP firewall, but the local system does not support BPF/cgroup firewalling.
+[    2.083853] systemd[1]: (This warning is only shown for the first unit using IP firewalling.)
+[    2.089029] systemd[1]: Starting Journal Service...
+[    2.275345] systemd[1]: Starting Set the console keyboard layout...
+[    2.331794] systemd[1]: Condition check resulted in Create list of static device nodes for the current kernel being skipped.
+[    2.373032] systemd[1]: Starting Load Kernel Module configfs...
+[    2.390012] systemd[1]: Starting Load Kernel Module drm...
+[    2.401425] systemd[1]: Starting Load Kernel Module fuse...
+[    2.418703] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped.
+[    2.420064] systemd[1]: Starting File System Check on Root Device...
+[    2.432087] systemd[1]: Starting Load Kernel Modules...
+[    2.452273] systemd[1]: Starting Coldplug All udev Devices...
+[    2.468269] systemd[1]: Starting Uncomplicated firewall...
+[    2.518424] systemd[1]: Mounted Huge Pages File System.
+[    2.518764] systemd[1]: Mounted POSIX Message Queue File System.
+[    2.518974] systemd[1]: Mounted Kernel Debug File System.
+[    2.519140] systemd[1]: Mounted Kernel Trace File System.
+[    2.530711] systemd[1]: modprobe@configfs.service: Deactivated successfully.
+[    2.531730] systemd[1]: Finished Load Kernel Module configfs.
+[    2.538860] systemd[1]: modprobe@drm.service: Deactivated successfully.
+[    2.544760] systemd[1]: Finished Load Kernel Module drm.
+[    2.545030] systemd[1]: modprobe@fuse.service: Deactivated successfully.
+[    2.546685] systemd[1]: Finished Load Kernel Module fuse.
+[    2.546931] systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
+[    2.546980] systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
+[    2.549652] systemd[1]: Failed to start Load Kernel Modules.
+[    2.552638] systemd[1]: Finished Uncomplicated firewall.
+[    2.553148] systemd[1]: Condition check resulted in FUSE Control File System being skipped.
+[    2.553189] systemd[1]: Condition check resulted in Kernel Configuration File System being skipped.
+[    2.557719] systemd[1]: Started File System Check Daemon to report status.
+[    2.566265] systemd[1]: Starting Apply Kernel Variables...
+[    2.579756] systemd[1]: Started Journal Service.
+[    2.641573] random: crng init done
+[    2.718179] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro. Quota mode: none.
+[    2.732681] Adding 752916k swap on /swapfile.  Priority:-2 extents:3 across:769300k 
+[    2.733844] swapon (132) used greatest stack depth: 13568 bytes left
+[    2.735312] systemd-journald[110]: Received client request to flush runtime journal.
+[    2.743169] systemd-journald[110]: File /var/log/journal/6baf11e8245c4ca98eface85b84be32f/system.journal corrupted or uncleanly shut down, renaming and replacing.
+[    2.811309] loop0: detected capacity change from 0 to 203424
+[    2.815025] loop1: detected capacity change from 0 to 126632
+[    2.815152] loop2: detected capacity change from 0 to 8
+[    2.827343] loop3: detected capacity change from 0 to 307976
+[    2.841748] loop0: detected capacity change from 0 to 133552
+[    2.843903] loop4: detected capacity change from 0 to 496320
+[    2.847378] loop1: detected capacity change from 0 to 111048
+[    2.914163] journal-offline (149) used greatest stack depth: 13344 bytes left
+[    3.788267] virtio_net virtio0 enp0s1: renamed from eth0
+[    9.114766] language-option (340) used greatest stack depth: 12992 bytes left
+[   12.965077] loop0: detected capacity change from 0 to 8
+[   15.602770] systemd-journald[110]: File /var/log/journal/6baf11e8245c4ca98eface85b84be32f/user-1000.journal corrupted or uncleanly shut down, renaming and replacing.
+[   19.878209] virtio_gpu virtio1: [drm] drm_plane_enable_fb_damage_clips() not called
+[  313.191235] loop0: detected capacity change from 0 to 8
+[  334.252458] loop0: detected capacity change from 0 to 126760
+[  336.575589] loop0: detected capacity change from 0 to 226664
+[  613.230337] loop0: detected capacity change from 0 to 8
+[  660.444496] kworker/dying (50) used greatest stack depth: 12400 bytes left
+[  809.013491] clocksource: timekeeping watchdog on CPU0: hpet wd-wd read-back delay of 65260ns
+[  809.013577] clocksource: wd-tsc-wd read-back delay of 1983150ns, clock-skew test skipped!
+[  913.163318] loop0: detected capacity change from 0 to 8
+[ 1213.159179] loop0: detected capacity change from 0 to 8
+[ 1513.151818] loop0: detected capacity change from 0 to 8
+[ 1813.150457] loop0: detected capacity change from 0 to 8
+```
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/928 b/gitlab/issues_text/target_i386/host_missing/accel_missing/928
new file mode 100644
index 00000000..650fa3fa
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/928
@@ -0,0 +1,84 @@
+QEMU/TCG generates #GP instead #SS for RBP/RSP based faults
+Description of problem:
+Setting RSP/RBP to a non-canonical address and trying to access a memory location based on RSP/RBP generates a #GP under QEMU/TCG while it should generate an #SS exception instead. This difference in behavior triggers a [Xen selftest](https://github.com/xen-project/xen/blob/1145d94c738e/xen/arch/x86/extable.c#L142-L144) violation as can be seen below.
+
+- A successful run should look like this, e.g. when run under KVM:
+
+```
+(XEN) Running stub recovery selftests...
+(XEN) Fixup #UD[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7
+(XEN) Fixup #GP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7
+(XEN) Fixup #SS[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7
+(XEN) Fixup #BP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7
+```
+
+- Under QEMU/TCG it triggers this scary warning:
+
+```
+(XEN) Running stub recovery selftests...
+(XEN) Fixup #UD[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7
+(XEN) Fixup #GP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7
+(XEN) Fixup #GP[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7
+(XEN) Selftest 2 failed: Opc 02 04 04 c3 expected 12[0000], got 13[0000]
+(XEN) Fixup #BP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7
+[...]
+(XEN) ***************************************************
+(XEN) SELFTEST FAILURE: CORRECT BEHAVIOR CANNOT BE GUARANTEED
+(XEN) ***************************************************
+(XEN) 3... 2... 1...
+```
+Steps to reproduce:
+The attached program ([noncanon.c](/uploads/34599a2fe23c6bbf1e9efd8cb8704537/noncanon.c)) generates the following output when run on native hardware or under KVM:
+
+```shell-session
+minipli@bell:~$ for i in "" -sp -bp; do ./noncanon $i; done
+Non-canonical acces via RAX: SIGSEGV, signo 11, error 0, code 128, addr (nil)
+Non-canonical acces via RSP: SIGBUS, signo 7, error 0, code 128, addr (nil)
+Non-canonical acces via RBP: SIGBUS, signo 7, error 0, code 128, addr (nil)
+```
+
+However, when run under QEMU using TCG, I get the following output:
+
+```shell-session
+root@box:~# for i in "" -sp -bp; do ./noncanon $i; done
+Non-canonical acces via RAX: SIGSEGV, signo 11, error 0, code 128, addr (nil)
+Non-canonical acces via RSP: SIGSEGV, signo 11, error 0, code 128, addr (nil)
+Non-canonical acces via RBP: SIGSEGV, signo 11, error 0, code 128, addr (nil)
+```
+
+Please note how RSP/RBP based access generates SIGSEGV instead of the expected SIGBUS.
+Additional information:
+The problem seems to be that QEMU always generates a #GP for non-canonical addresses, while it should differentiate, based on the register that led to the non-canonical address: #SS if RSP/RBP is involved, #GP otherwise. However, short of an instruction decoder, I don't see how this can easily be told apart.
+
+```diff
+diff --git a/target/i386/tcg/sysemu/excp_helper.c b/target/i386/tcg/sysemu/excp_helper.c
+index e1b6d8868338..ac4a6351a49d 100644
+--- a/target/i386/tcg/sysemu/excp_helper.c
++++ b/target/i386/tcg/sysemu/excp_helper.c
+@@ -386,6 +386,7 @@ static int handle_mmu_fault(CPUState *cs, vaddr addr, int size,
+             sext = (int64_t)addr >> (pg_mode & PG_MODE_LA57 ? 56 : 47);
+             if (sext != 0 && sext != -1) {
+                 env->error_code = 0;
++                // XXX: or EXCP0C_STACK for SP/BP bassed error
+                 cs->exception_index = EXCP0D_GPF;
+                 return 1;
+             }
+```
+
+Relevant excerpt from the Intel SDM:
+
+> **6.15 EXCEPTION AND INTERRUPT REFERENCE**  
+> [...]  
+> **Interrupt 12—Stack Fault Exception (#SS)**  
+> [...] 
+> - A canonical violation is detected in 64-bit mode during an operation that reference memory using the stack pointer register containing a non-canonical memory address.
+
+Please note the lack of mentioning the base pointer register, but tests on real hardware show it's subject to this as well.
+
+The AMD manual is more precise about that:
+> **8.2.13 #SS—Stack Exception (Vector 12)**  
+> An #SS exception can occur in the following situations:  
+> - Implied stack references in which the stack address is not in canonical form. Implied stack references include all push and pop instructions, and any instruction using RSP or RBP as a base register  
+> [...]
+
+It explicitly mentions "any instruction using RSP or RBP as a base register".
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/930 b/gitlab/issues_text/target_i386/host_missing/accel_missing/930
new file mode 100644
index 00000000..c1a37495
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/930
@@ -0,0 +1 @@
+Impossible to make windows 98 work on Qemu ver. 5.2
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/975 b/gitlab/issues_text/target_i386/host_missing/accel_missing/975
new file mode 100644
index 00000000..a4fb042b
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/975
@@ -0,0 +1,38 @@
+LXD with QEMU 6.2.0 (and 7.0.0-rc3) breaks during stateful migration
+Description of problem:
+
+Steps to reproduce:
+```
+sudo snap install --lxd
+sudo lxd init --auto
+lxc init images:ubuntu/20.04/cloud v1 --vm
+Creating v1
+lxc config device override v1 root size.state=2GiB
+Device root overridden for v1
+lxc config set v1 migration.stateful=true
+lxc start v1
+sleep 10
+lxc exec v1 -- uptime
+ 22:05:54 up 0 min,  0 users,  load average: 0.07, 0.02, 0.00
+lxc snapshot v1 --stateful
+Error: Migration call failed
+lxc snapshot v1 --stateful
+Error: Monitor is disconnected
+```
+
+The first attempt at `lxc snapshot v1 --stateful` caused this in the `lxc info v1 --show-log` log output:
+
+```
+qemu-system-x86_64: qemu_savevm_state_complete_precopy_non_iterable: bdrv_inactivate_all() failed (-1)
+```
+
+The second attempt caused this:
+
+```
+qemu-system-x86_64: ../block.c:6757: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed.
+```
+
+Which crashed QEMU completely and caused the VM to die.
+Nothing relevant showed up in dmesg, so this wasn't caused by an obvious seccomp or apparmor policy issue.
+Additional information:
+Originally reported by Stephane Graber at https://github.com/lxc/lxd/issues/9875
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/990 b/gitlab/issues_text/target_i386/host_missing/accel_missing/990
new file mode 100644
index 00000000..a98d340a
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_missing/accel_missing/990
@@ -0,0 +1 @@
+support for vIOMMU and vSR-IOV together in L1 as virtual machine
diff --git a/gitlab/issues_text/target_i386/host_ppc/accel_TCG/2487 b/gitlab/issues_text/target_i386/host_ppc/accel_TCG/2487
new file mode 100644
index 00000000..cf5f0c72
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_ppc/accel_TCG/2487
@@ -0,0 +1,68 @@
+qemu-x86_64: qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached
+Description of problem:
+Using this basic test file:
+
+```c
+int
+main (void)
+{
+    return 0;
+}
+```
+
+compiled into a static executable using an x86_64 toolchain (glibc or musl both tested),
+
+```
+gwyn ~/qemu-bug # file test1
+test1: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, with debug_info, not stripped
+
+gwyn ~/qemu-bug # file test2
+test2: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=276dc49ee7cbd3b760e24761bf9fb9e1cc4b4349, for GNU/Linux 3.2.0, not stripped
+```
+
+Using QEMU from 15957eb9efe2da67c796612cead95cba28ba9bda or newer:
+
+```
+gwyn ~/qemu-bug # ../emus-ppc64/bin/qemu-x86_64 --version
+qemu-x86_64 version 9.0.50 (v9.0.0-521-g15957eb9ef-dirty)
+Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers
+```
+
+QEMU crashes:
+
+```
+gwyn ~/qemu-bug # ../emus-ppc64/bin/qemu-x86_64 ./test2
+**
+ERROR:/root/qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached
+Bail out! ERROR:/root/qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached
+Aborted
+```
+Steps to reproduce:
+1. Build QEMU user for ppc64 (may affect other hosts) using commit 15957eb9efe2da67c796612cead95cba28ba9bda or newer.
+2. Run any simple x86_64 executable.
+3. Observe the crash.
+Additional information:
+Bisected to here:
+
+```
+commit 15957eb9efe2da67c796612cead95cba28ba9bda
+Author: Paolo Bonzini <pbonzini@redhat.com>
+Date:   Fri Oct 27 05:57:31 2023 +0200
+
+    target/i386: use TSTEQ/TSTNE to test low bits
+    
+    When testing the sign bit or equality to zero of a partial register, it
+    is useful to use a single TSTEQ or TSTNE operation.  It can also be used
+    to test the parity flag, using bit 0 of the population count.
+    
+    Do not do this for target_ulong-sized values however; the optimizer would
+    produce a comparison against zero anyway, and it avoids shifts by 64
+    which are undefined behavior.
+    
+    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
+    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+
+ target/i386/tcg/emit.c.inc  |  5 ++---
+ target/i386/tcg/translate.c | 28 ++++++++++++++++++++--------
+ 2 files changed, 22 insertions(+), 11 deletions(-)
+```
diff --git a/gitlab/issues_text/target_i386/host_ppc/accel_TCG/391 b/gitlab/issues_text/target_i386/host_ppc/accel_TCG/391
new file mode 100644
index 00000000..af9b7b5d
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_ppc/accel_TCG/391
@@ -0,0 +1 @@
+Unable to pass-through PCIe devices from a ppc64le host to an x86_64 guest
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_KVM/1151 b/gitlab/issues_text/target_i386/host_x86/accel_KVM/1151
new file mode 100644
index 00000000..a3d6ecba
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_x86/accel_KVM/1151
@@ -0,0 +1,49 @@
+when guest unexpect shutdown,can't enter system,the terminal has a black screen
+Description of problem:
+
+Steps to reproduce:
+1.guest unexpect shutdown 
+
+2.when start again,cpu usage is high and can't enter the guest system
+
+3.restart guest can recovery
+
+**libvirt print：**
+
+`2022-08-11 14:39:58.080+0000: 1942: warning : qemuDomainObjTaint:6079 : Domain id=117 name='GDT99d2578e-f06e-4fbe-88dd-7d9dd56fd02d' uuid=99d2578e-f06e-4fbe-88dd-7d9dd56fd02d is tainted: high-privileges
+
+2022-08-11 14:39:58.080+0000: 1942: warning : qemuDomainObjTaint:6079 : Domain id=117 name='GDT99d2578e-f06e-4fbe-88dd-7d9dd56fd02d' uuid=99d2578e-f06e-4fbe-88dd-7d9dd56fd02d is tainted: custom-argv
+
+2022-08-11 14:40:28.792+0000: 741037: warning : qemuDomainObjBeginJobInternal:946 : Cannot start job (modify, none, none) for domain GDT99d2578e-f06e-4fbe-88dd-7d9dd56fd02d; current job is (none, none, migration in) owned by (0 <null>, 0 <null>, 0 remoteDispatchDomainMigratePrepare3Params (flags=0x203)) for (0s, 0s, 30s)
+
+2022-08-11 14:40:28.792+0000: 741037: error : qemuDomainObjBeginJobInternal:968 : Timed out during operation: cannot acquire state change lock (held by monitor=remoteDispatchDomainMigratePrepare3Params)
+`
+
+
+**user perf to analyse:**
+
+\#top -d 3 -Hp 1311519
+
+![image](/uploads/2ec511a049b43f827368eb84c46ee2ed/image.png)
+
+\#perf record -a -g -p 1311519 sleep 20
+
+\#report -n --header --stdio
+
+![image](/uploads/b8c66c590e4b1d444d102923f6247dce/image.png)
+
+
+**query kvm stat:**
+
+ \# perf stat -e 'kvm:*' -a -p 1311519 sleep 20
+
+![image](/uploads/6d50e1b48d795fe68bfebb05b7382a24/image.png)
+
+
+kvm vmexit stat:
+
+\#perf kvm stat record -a -p 1311519 sleep 10
+
+\#perf kvm stat report --event=vmexit
+
+![image](/uploads/3f7f0c35f8734ccebcdf883cb059f12c/image.png)
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_KVM/1152 b/gitlab/issues_text/target_i386/host_x86/accel_KVM/1152
new file mode 100644
index 00000000..122f86d6
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_x86/accel_KVM/1152
@@ -0,0 +1,28 @@
+Windows crashes on resuming from sleep if hv-tlbflush is enabled
+Description of problem:
+The above steps cause my Windows VM to BSOD immediately upon waking up (even before restarting the display driver in my case).
+Steps to reproduce:
+1. Boot Windows
+2. Tell Windows to go to sleep (observe that qemu's state switches to suspended)
+3. Cause windows to wake up (e.g. using the `system_wakeup` HMP command)
+Additional information:
+Looking at the crash dumps always shows the "ATTEMPTED WRITE TO READONLY MEMORY" error, and always with this stack trace:
+
+```
+nt!KeBugCheckEx
+nt!MiRaisedIrqlFault+0x1413a6
+nt!MmAccessFault+0x4ef
+nt!KiPageFault+0x35e
+nt!MiIncreaseUsedPtesCount+0x12
+nt!MiBuildForkPte+0xc6
+nt!MiCloneVads+0x4ab
+nt!MiCloneProcessAddressSpace+0x261
+nt!MmInitializeProcessAddressSpace+0x1cb631
+nt!PspAllocateProcess+0x1d13
+nt!PspCreateProcess+0x242
+nt!NtCreateProcessEx+0x85
+nt!KiSystemServiceCopyEnd+0x25
+ntdll!NtCreateProcessEx+0x14
+```
+
+However, the process that is being created here is always `WerFault.exe`, i.e. the crash reporter. The crashing process is seemingly random. Removing `hv-tlbflush` from the command line resolves the problem. Hence, my hypothesis is that due to improper TLB flushing during wakeup, a random application on the core will crash, which spawns `WerFault.exe` which then immediately crashes again inside the kernel (also because of bad/stale TLB contents) and causes the BSOD. Perhaps one core wakes up first, requests a TLB flush, which is then *not* propagated to sleeping cores due to hv-tlbflush. Then one of those cores wakes up without the TLB flush?
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_KVM/2574 b/gitlab/issues_text/target_i386/host_x86/accel_KVM/2574
new file mode 100644
index 00000000..af824e23
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_x86/accel_KVM/2574
@@ -0,0 +1,49 @@
+VM hang: 'error: kvm run failed Bad address' with some AMD GPUs since kernel 6.7
+Description of problem:
+The Debian ROCm Team runs GPU-utilizing test workloads in QEMU VMs into which we pass through AMD GPUs attached to PCIe x16 slots on the host. We do this to quickly test various Debian distributions/kernels/firmwares on a single physical host per GPU, and to isolate the host as much as possible from potentially hostile code.
+
+Starting with kernel 6.7 in the **guest**, with Navi 31 GPUs (eg: RX 7900 XT), as soon as anything triggers access to the GPU's memory, the VM hangs with `error: kvm run failed Bad address` and dumps its state.
+
+I gather that [this](https://gitlab.com/qemu-project/qemu/-/blob/ea9cdbcf3a0b8d5497cddf87990f1b39d8f3bb0a/accel/kvm/kvm-all.c#L3046-L3048) is where this message originates from. It would seem that the preceding [ioctl](https://gitlab.com/qemu-project/qemu/-/blob/ea9cdbcf3a0b8d5497cddf87990f1b39d8f3bb0a/accel/kvm/kvm-all.c#L3025) runs into `EFAULT` which eventually leads to a break out of the surrounding loop.
+
+Since we can reliably reproduce this starting with 6.7, our assumption is that this is caused by a change in the kernel and/or the `amdgpu` driver. However, as the error originates from kvm *on the host*, we could not rule out that this might also be a emulation issue. In particular, it was only 9.1 [c15e568](c15e568) where the handling of the `EFAULT` and `KVM_EXIT_MEMORY_FAULT` case was added, so perhaps we ran into something that is still incomplete.
+
+I'd appreciate any advice you could give us for further debugging. We will bisect 6.7 to see what could have triggered this on the guest side, but is there something that we can do on the host to further track this down, in particular which `-trace`s might be helpful?
+
+Other notes:
+- The VM boots and runs fine, GPU initializes fine according to `dmesg`. The issue is only triggered on GPU utilization
+- The problematic GPU in question worked fine with kernels 6.3 - 6.6
+- All other GPU architectures that we test this way (eg: Navi 2x) do not experience this issue, they work fine with all kernels we tested
+- We have checked with more than one GPU, to rule out a physical defect
+Steps to reproduce:
+Reproducing the issue requires
+1. A suitable image
+2. Access to a Navi 3x card. Remote access can be arranged, if necessary.
+
+Building a suitable image can be rather complicated and requires a Debian host. If needed, it would be easier for me to just share a pre-built image.
+Additional information:
+This is dumped just before the VM hangs:
+```
+ROCk module is loaded
+error: kvm run failed Bad address
+RAX=00000000000035c8 RBX=00000000000006ba RCX=0003000108b08073 RDX=00000000000006b9
+RSI=ffff9994b00035c8 RDI=ffff899403c80000 RBP=ffff899408b285e0 RSP=ffff9994816ab620
+R8 =0003000000000073 R9 =ffff9994b0000000 R10=ffff899403c8fb18 R11=ffff899408b065b8
+R12=ffff899403c80000 R13=0003000000000073 R14=ffff9994b0000000 R15=00000000000006ba
+RIP=ffffffffc11d8f93 RFL=00000282 [--S----] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0000 0000000000000000 00000000 00000000
+CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA]
+SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
+DS =0000 0000000000000000 00000000 00000000
+FS =0000 00007faa76aea780 00000000 00000000
+GS =0000 ffff899f0dd80000 00000000 00000000
+LDT=0000 0000000000000000 00000000 00000000
+TR =0040 fffffe41c66fc000 00004087 00008b00 DPL=0 TSS64-busy
+GDT=     fffffe41c66fa000 0000007f
+IDT=     fffffe0000000000 00000fff
+CR0=80050033 CR2=000055bd5a5d8598 CR3=000000010342c000 CR4=00750ef0
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000d01
+Code=ff ff 00 00 48 21 c1 8d 04 d5 00 00 00 00 4c 09 c1 48 01 c6 <48> 89 0e 31 c0 e9 6e b1 92 d2 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66
+```
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_KVM/2609 b/gitlab/issues_text/target_i386/host_x86/accel_KVM/2609
new file mode 100644
index 00000000..77634055
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_x86/accel_KVM/2609
@@ -0,0 +1,11 @@
+Blue screen in Windows XP
+Description of problem:
+When starting the installation of Windows XP  when using a virtioblk device you immediately get a bluescreen: `STOP: 0x000000A5 (0x00000002, 0x8A1A6008, 0xE1018808, 0x8A1B7F00)`. I think this happens even before it loads the SATA drivers that are slipstreamed in the ISO.
+
+After a lot of Googling about this error 0x000000A5 I found some posts suggesting that changing the machine type from `q35` to `pc-q35-2.10` solves the issue. And it worked. Anything above 2.10 (for example 2.11) and the bluescreens return.
+
+So I always used this solution, but in QEMU 9.1.0 it warns that `pc-q35-2.10` will be removed soon. This would mean there is no way anymore to install XP to a SATA disk unattendly.
+Steps to reproduce:
+1. Use a virtioblk disk and SATA drivers
+2. Start the Windows XP installer
+3. Bluescreen will appear
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_TCG/1846 b/gitlab/issues_text/target_i386/host_x86/accel_TCG/1846
new file mode 100644
index 00000000..7ef87d6c
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_x86/accel_TCG/1846
@@ -0,0 +1,25 @@
+Regression in q35 avocado tests due to fix for misaligned IO access
+Description of problem:
+Generally I'm seeing intermittent hangs, somewhere after the clock initialisation.
+
+```
+[    4.137020] ALSA device list:                                                                                                                                             
+[    4.137861]   No soundcards found.                                                                                                                                        
+[    4.634128] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3                                                                         
+[   24.085574] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
+[   24.085712] rcu:     0-...!: (0 ticks this GP) idle=4d18/0/0x0 softirq=54/54 fqs=0 (false positive?)
+[   24.085712]  (detected by 1, t=21004 jiffies, g=-1003, q=2151 ncpus=2)
+[   24.085712] Sending NMI from CPU 1 to CPUs 0:                                                                                                                             
+[    4.647507] NMI backtrace for cpu 0                                                                                                                                       
+[    4.647507] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.0.11 #5                                                                                                           
+[    4.647507] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014                                              
+[    4.647507] RIP: 0010:amd_e400_idle+0x39/0x40                                                                                                                             
+[    4.647507] Code: 00 e8 fb ab 0d 00 eb 07 0f 00 2d c2 7d 1d 01 fb f4 fa 31 ff e8 e8 ab 0d 00 fb c3 cc cc cc cc eb 07 0f 00 2d a9 7d 1d 01 fb f4 <c3> cc cc cc cc 66 90 bf 
+01 00 00 00 e8 a6 e4 06 00 65 48 8b 04 25
+```
+
+In avocado the hang generally times out and the test fails.
+Steps to reproduce:
+See above command line. It's racy.
+Additional information:
+
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_TCG/2159 b/gitlab/issues_text/target_i386/host_x86/accel_TCG/2159
new file mode 100644
index 00000000..8bc3d3f0
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_x86/accel_TCG/2159
@@ -0,0 +1,177 @@
+qemu-system-x86_64 crashes in temp_load (tcg) on i686 host
+Description of problem:
+qemu crashes early
+Steps to reproduce:
+1. compile qemu git (commit commit 5d1fc614413b10dd94858b07a1b2e26b1aa0296c (origin/master, origin/HEAD)
+) with line
+../configure --prefix=/usr  --enable-virglrenderer --libdir=lib --audio-drv-list=alsa,oss --enable-opengl --extra-cflags="-I/usr/X11R7/include -O2 -march=i686 -mtune=native -m32 -Wno-maybe-uninitialized -Wno-nested-externs -Wno-implicit-function-declaration" --disable-werror        
+
+2. setarch i686 ninja (kernel is x86_64 on host)
+3. try to boot 64-bit x86 Salix/Slackel (Slackware live images)
+Additional information:
+```
+ gdb  x86_64-softmmu/qemu-system-x86_64
+GNU gdb (GDB) 11.2
+Copyright (C) 2022 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+Type "show copying" and "show warranty" for details.
+This GDB was configured as "i586-slackware-linux".
+Type "show configuration" for configuration details.
+For bug reporting instructions, please see:
+<https://www.gnu.org/software/gdb/bugs/>.
+Find the GDB manual and other documentation resources online at:
+    <http://www.gnu.org/software/gdb/documentation/>.
+
+For help, type "help".
+Type "apropos word" to search for commands related to "word"...
+Reading symbols from x86_64-softmmu/qemu-system-x86_64...
+warning: File "/dev/shm/qemu/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
+To enable execution of this file add
+        add-auto-load-safe-path /dev/shm/qemu/.gdbinit
+line to your configuration file "/root/.config/gdb/gdbinit".
+To completely disable this security protection add
+        set auto-load safe-path /
+line to your configuration file "/root/.config/gdb/gdbinit".
+For more information about this security protection see the
+--Type <RET> for more, q to quit, c to continue without paging--
+"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
+        info "(gdb)Auto-loading safe path"
+(gdb) r  -m 1000 -cdrom /home/guest/ISO/sla
+slackellive64-openbox-7.7.1.iso  slackware-8.0-install-d1.iso
+(gdb) r  -m 1000 -cdrom /home/guest/ISO/slackellive64-openbox-7.7.1.iso
+Starting program: /dev/shm/qemu/build/x86_64-softmmu/qemu-system-x86_64 -m 1000 -cdrom /home/guest/ISO/slackellive64-openbox-7.7.1.iso
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/lib/libthread_db.so.1".
+[New Thread 0xf3e79b00 (LWP 27354)]
+[New Thread 0xf2f09b00 (LWP 27355)]
+[New Thread 0xb1917b00 (LWP 27356)]
+[New Thread 0xaf60cb00 (LWP 27357)]
+[Thread 0xaf60cb00 (LWP 27357) exited]
+[New Thread 0xaf60cb00 (LWP 27358)]
+[New Thread 0xaec86b00 (LWP 27359)]
+[Thread 0xaf60cb00 (LWP 27358) exited]
+[Thread 0xaec86b00 (LWP 27359) exited]
+[New Thread 0xaec86b00 (LWP 27360)]
+[New Thread 0xaf60cb00 (LWP 27361)]
+[Thread 0xaec86b00 (LWP 27360) exited]
+[Thread 0xaf60cb00 (LWP 27361) exited]
+[Thread 0xf2f09b00 (LWP 27355) exited]
+
+Thread 4 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
+[Switching to Thread 0xb1917b00 (LWP 27356)]
+0x56d08a95 in temp_load (s=0xb1000610, ts=ts@entry=0xb1001f40, desired_regs=<optimized out>, allocated_regs=2097200, preferred_regs=0) at ../tcg/tcg.c:4441
+4441            tcg_out_ld(s, ts->type, reg, ts->mem_base->reg, ts->mem_offset);
+(gdb) bt full
+#0  0x56d08a95 in temp_load
+    (s=0xb1000610, ts=ts@entry=0xb1001f40, desired_regs=<optimized out>, allocated_regs=2097200, preferred_regs=0) at ../tcg/tcg.c:4441
+        reg = TCG_REG_ECX
+        __func__ = "temp_load"
+#1  0x56d0fe23 in tcg_reg_alloc_op (op=<optimized out>, s=<optimized out>)
+    at ../tcg/tcg.c:4881
+        i_required_regs = <optimized out>
+        copyto_new_reg = false
+        ts2 = <optimized out>
+        i1 = <optimized out>
+        i_preferred_regs = <optimized out>
+        allocate_new_reg = <optimized out>
+        i2 = <optimized out>
+        i = 0
+        new_args =
+          {1, 5, 2852, 0, 64, 0, 0, 1467284236, 4149882880, 2829350448, 1, 1456305553, 4149882880, 2969568784, 2969568920, 2969568944}
+        arg_life = <optimized out>
+        i_allocated_regs = <optimized out>
+        nb_oargs = <optimized out>
+        arg = <optimized out>
+        const_args =
+--Type <RET> for more, q to quit, c to continue without paging--
+          {0, 0, 0, 0, 1, 1, 1467284236, -1315870200, 1487331864, -1069806704, 0, 1467284236, 1456520351, 1489883472, 2, -1325347776}
+        k = <optimized out>
+        arg_ct = <optimized out>
+        o_allocated_regs = <optimized out>
+        nb_iargs = <optimized out>
+        reg = <optimized out>
+        ts = 0xb1001f40
+        op_cond = <optimized out>
+        opc = <optimized out>
+        i = <optimized out>
+        start_words = <optimized out>
+        num_insns = <optimized out>
+        op = <optimized out>
+        __PRETTY_FUNCTION__ = "tcg_gen_code"
+#2  tcg_gen_code
+    (s=<optimized out>, tb=<optimized out>, pc_start=<optimized out>)
+    at ../tcg/tcg.c:6216
+        opc = <optimized out>
+        i = <optimized out>
+        start_words = <optimized out>
+        num_insns = <optimized out>
+        op = <optimized out>
+--Type <RET> for more, q to quit, c to continue without paging--
+        __PRETTY_FUNCTION__ = "tcg_gen_code"
+#3  0x56af0118 in setjmp_gen_code
+    (env=env@entry=0x57afab90, tb=tb@entry=0xf0b7d580 <code_gen_buffer+8389982>, pc=18446744072243800976, host_pc=0xc03c0b90, max_insns=0xb1916acc, ti=<optimized out>) at ../accel/tcg/translate-all.c:284
+        ret = <optimized out>
+        __PRETTY_FUNCTION__ = "setjmp_gen_code"
+#4  0x56af06e2 in tb_gen_code
+    (cpu=0x57af8860, pc=18446744072243800976, cs_base=0, flags=4244144, cflags=<optimized out>) at ../accel/tcg/translate-all.c:359
+        env = 0x57afab90
+        tb = 0xf0b7d580 <code_gen_buffer+8389982>
+        existing_tb = <optimized out>
+        phys_pc = 245525392
+        phys_p2 = <optimized out>
+        gen_code_buf = 0xf0b7d600 <code_gen_buffer+8390110> "‹]ш…Ы\017Њр"
+        gen_code_size = <optimized out>
+        search_size = <optimized out>
+        max_insns = 64
+        host_pc = 0xc03c0b90
+        __PRETTY_FUNCTION__ = "tb_gen_code"
+        __func__ = "tb_gen_code"
+#5  0x56ae75bd in cpu_exec_loop
+--Type <RET> for more, q to quit, c to continue without paging--
+    (cpu=cpu@entry=0x57af8860, sc=sc@entry=0xb1916c24)
+    at ../accel/tcg/cpu-exec.c:982
+        jc = <optimized out>
+        h = <optimized out>
+        tb = 0x0
+        flags = <optimized out>
+        cflags = 4278321152
+        pc = <optimized out>
+        cs_base = <optimized out>
+        last_tb = <optimized out>
+        tb_exit = 0
+        ret = <optimized out>
+#6  0x56ae7a70 in cpu_exec_setjmp
+    (cpu=cpu@entry=0x57af8860, sc=sc@entry=0xb1916c24)
+    at ../accel/tcg/cpu-exec.c:1028
+#7  0x56ae83a8 in cpu_exec (cpu=<optimized out>)
+    at ../accel/tcg/cpu-exec.c:1054
+        ret = <optimized out>
+        sc = {diff_clk = 0, last_cpu_icount = 0, realtime_clock = 0}
+        _rcu_read_auto = 0x1
+#8  0x56b0ff5e in tcg_cpu_exec (cpu=0x57af8860)
+    at ../accel/tcg/tcg-accel-ops.c:76
+        ret = <optimized out>
+--Type <RET> for more, q to quit, c to continue without paging--
+        __PRETTY_FUNCTION__ = "tcg_cpu_exec"
+#9  0x56b10a47 in rr_cpu_thread_fn (arg=<optimized out>)
+    at ../accel/tcg/tcg-accel-ops-rr.c:261
+        r = <optimized out>
+        cpu_budget = <optimized out>
+        force_rcu =
+            {notify = 0x56b106e0 <rr_force_rcu>, node = {le_next = 0x0, le_prev = 0xb19179b0}}
+        cpu = 0x57af8860
+        __PRETTY_FUNCTION__ = "rr_cpu_thread_fn"
+#10 0x56cc77e5 in qemu_thread_start (args=0x57b51ce0)
+    at ../util/qemu-thread-posix.c:541
+        __cancel_buf =
+            {__cancel_jmp_buf = {{__cancel_jmp_buf = {1467284236, 1471487200, 1471152128, -1315869272, 1617656260, -631423478}, __mask_was_saved = 0}}, __pad = {0xb1916d64, 0x0, 0x0, 0x0}}
+        __cancel_routine = 0x56cc7840 <qemu_thread_atexit_notify>
+        __not_first_call = <optimized out>
+        start_routine = 0x56b10818 <rr_cpu_thread_fn>
+        arg = 0x57af8860
+        r = <optimized out>
+#11 0xf63d5328 in start_thread () at /lib/libpthread.so.0
+#12 0xf604ef06 in clone () at /lib/libc.so.6
+```
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_TCG/2413 b/gitlab/issues_text/target_i386/host_x86/accel_TCG/2413
new file mode 100644
index 00000000..4f645b21
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_x86/accel_TCG/2413
@@ -0,0 +1,33 @@
+Use of TSTEQ/TSTNE has regressed the cdrom test when running a 32 bit build of qemu-system-x86_64 using TCG
+Description of problem:
+The test freezes, eventually timing out. The bisect was confused by other SEV related things so I had to whittle down the config to --disable-kvm.
+Steps to reproduce:
+1. '../../configure' '--disable-docs' '--disable-user' '--cross-prefix=i686-linux-gnu-' '--target-list=x86_64-softmmu' '--enable-debug' '--disable-kvm'
+2. ninja
+3. meson test -t 0.05 qtest-x86_64/cdrom-test V=1
+Additional information:
+Bisect run pointed at:
+
+```
+commit 15957eb9efe2da67c796612cead95cba28ba9bda
+Author: Paolo Bonzini <pbonzini@redhat.com>
+Date:   Fri Oct 27 05:57:31 2023 +0200
+
+    target/i386: use TSTEQ/TSTNE to test low bits
+    
+    When testing the sign bit or equality to zero of a partial register, it
+    is useful to use a single TSTEQ or TSTNE operation.  It can also be used
+    to test the parity flag, using bit 0 of the population count.
+    
+    Do not do this for target_ulong-sized values however; the optimizer would
+    produce a comparison against zero anyway, and it avoids shifts by 64
+    which are undefined behavior.
+    
+    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
+    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+
+ target/i386/tcg/translate.c | 28 ++++++++++++++++++++--------
+ target/i386/tcg/emit.c.inc  |  5 ++---
+ 2 files changed, 22 insertions(+), 11 deletions(-)
+bisect found first bad commit⏎                                                          
+```
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_TCG/2784 b/gitlab/issues_text/target_i386/host_x86/accel_TCG/2784
new file mode 100644
index 00000000..685b1a74
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_x86/accel_TCG/2784
@@ -0,0 +1,217 @@
+SIGILL during DPDK e1000e device initialization - VMOVD instruction fails in QEMU
+Description of problem:
+I think it's a QEMU issue, but it could be rather a DPDK issue.
+When using DPDK with QEMU's e1000e device, the initialization fails with SIGILL (Illegal Instruction) during the LED initialization phase. The issue occurs specifically with the e1000e device and not with other network devices.
+
+Output from GDB:
+```
+Starting DPDK initialization...
+EAL: Detected CPU lcores: 4
+EAL: Detected NUMA nodes: 1
+EAL: Auto-detected process type: PRIMARY
+EAL: Detected shared linkage of DPDK
+EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
+EAL: Selected IOVA mode 'PA'
+EAL: VFIO support initialized
+EAL: Using IOMMU type 1 (Type 1)
+EAL: Ignore mapping IO port bar(2)
+EAL: Probe PCI driver: net_e1000_em (8086:10d3) device: 0000:01:00.0 (socket -1)
+
+Thread 1 "hello" received signal SIGILL, Illegal instruction.
+0x00007ffff1d4f63e in e1000_id_led_init_generic ()
+   from /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.0/librte_net_e1000.so.24.0
+
+1: x/i $pc
+=> 0x7ffff1d4f63e <e1000_id_led_init_generic+94>:	vmovd  0xe00(%rax),%xmm0
+```
+
+PCI device information:
+```
+01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
+    Subsystem: Intel Corporation 82574L Gigabit Network Connection
+    Physical Slot: 0
+    Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
+    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
+    Interrupt: pin A routed to IRQ 22
+    IOMMU group: 6
+    Region 0: Memory at fe840000 (32-bit, non-prefetchable) [size=128K]
+    Region 1: Memory at fe860000 (32-bit, non-prefetchable) [size=128K]
+    Region 2: I/O ports at c000 [size=32]
+    Region 3: Memory at fe880000 (32-bit, non-prefetchable) [size=16K]
+    Expansion ROM at fe800000 [disabled] [size=256K]
+```
+
+GDB Analysis:
+The crash occurs during LED initialization when attempting to execute a VMOVD instruction. The register RAX contains value 0x1 at the time of crash, which appears incorrect as it should contain the base address of the device's memory-mapped region (around 0xfe840000 based on PCI info).
+
+Both host and guest have AVX/AVX2 support
+- The issue appears to be related to memory mapping or address translation
+- The SIGILL occurs consistently at the same point during device initialization
+- This issue only occurs with e1000e device; other network devices work correctly
+
+Please let me know if you need any additional information.
+Additional information:
+Test program:
+```c
+#include <rte_eal.h>
+#include <rte_debug.h>
+#include <rte_lcore.h>
+#include <rte_memory.h>
+#include <rte_log.h>
+#include <rte_dev.h>
+#include <rte_bus.h>
+#include <rte_ethdev.h>
+#include <rte_kvargs.h>
+
+// Callback function for memory segment walking
+static int dump_memseg(const struct rte_memseg_list *msl, 
+                      const struct rte_memseg *ms, void *arg) {
+    size_t *total_mem = arg;
+    *total_mem += ms->len;
+    return 0;
+}
+
+static void print_device_info(uint16_t port_id) {
+    struct rte_eth_dev_info dev_info;
+    int ret = rte_eth_dev_info_get(port_id, &dev_info);
+    if (ret != 0) {
+        printf("Error getting device info for port %u: %s\n", 
+               port_id, rte_strerror(-ret));
+        return;
+    }
+
+    printf("\nDevice Info for Port %u:\n", port_id);
+    printf("  Driver name: %s\n", dev_info.driver_name);
+    
+    // Get device capabilities
+    printf("  Capabilities:\n");
+    printf("    Maximum RX queues: %u\n", dev_info.max_rx_queues);
+    printf("    Maximum TX queues: %u\n", dev_info.max_tx_queues);
+    printf("    Maximum MTU: %u\n", dev_info.max_mtu);
+    printf("    Minimum RX buffers: %u\n", dev_info.min_rx_bufsize);
+    printf("    Maximum RX descriptors: %u\n", dev_info.rx_desc_lim.nb_max);
+    printf("    Maximum TX descriptors: %u\n", dev_info.tx_desc_lim.nb_max);
+
+    // Get and print link status
+    struct rte_eth_link link;
+    ret = rte_eth_link_get_nowait(port_id, &link);
+    if (ret < 0) {
+        printf("  Link status: unknown\n");
+    } else {
+        printf("  Link status: %s\n", link.link_status ? "up" : "down");
+        if (link.link_status) {
+            printf("    Speed: %u Mbps\n", link.link_speed);
+            printf("    Duplex: %s\n", 
+                   link.link_duplex == RTE_ETH_LINK_FULL_DUPLEX ? 
+                   "full" : "half");
+        }
+    }
+    
+    // Get and print MAC address
+    struct rte_ether_addr mac_addr;
+    ret = rte_eth_macaddr_get(port_id, &mac_addr);
+    if (ret < 0) {
+        printf("  MAC address: unknown\n");
+    } else {
+        printf("  MAC address: %02X:%02X:%02X:%02X:%02X:%02X\n",
+               mac_addr.addr_bytes[0], mac_addr.addr_bytes[1],
+               mac_addr.addr_bytes[2], mac_addr.addr_bytes[3],
+               mac_addr.addr_bytes[4], mac_addr.addr_bytes[5]);
+    }
+
+    // Get statistics
+    struct rte_eth_stats stats;
+    ret = rte_eth_stats_get(port_id, &stats);
+    if (ret == 0) {
+        printf("  Statistics:\n");
+        printf("    RX packets: %" PRIu64 "\n", stats.ipackets);
+        printf("    TX packets: %" PRIu64 "\n", stats.opackets);
+        printf("    RX bytes: %" PRIu64 "\n", stats.ibytes);
+        printf("    TX bytes: %" PRIu64 "\n", stats.obytes);
+        printf("    RX errors: %" PRIu64 "\n", stats.ierrors);
+        printf("    TX errors: %" PRIu64 "\n", stats.oerrors);
+    }
+}
+
+// Print runtime configurations
+void print_runtime_config(void) {
+    // Core and NUMA information
+    printf("\n=== CPU and Memory Configuration ===\n");
+    printf("Main lcore ID: %u\n", rte_get_main_lcore());
+    printf("Number of available lcores: %u\n", rte_lcore_count());
+    
+    // Print available lcores and their status
+    printf("\nLcore status:\n");
+    unsigned int lcore_id;
+    RTE_LCORE_FOREACH(lcore_id) {
+        printf("  Lcore %u - Role: %s, Socket: %d\n", 
+               lcore_id,
+               lcore_id == rte_get_main_lcore() ? "Main" : "Worker",
+               rte_lcore_to_socket_id(lcore_id));
+    }
+    
+    // Memory and NUMA information
+    printf("\n=== Memory Configuration ===\n");
+    printf("Number of NUMA nodes: %u\n", rte_socket_count());
+    printf("IOVA mode: %s\n", rte_eal_iova_mode() == RTE_IOVA_PA ? "PA" : "VA");
+    
+    // Service and Process information
+    printf("\n=== Process Information ===\n");
+    printf("Process type: %s\n", 
+           rte_eal_process_type() == RTE_PROC_PRIMARY ? "Primary" :
+           rte_eal_process_type() == RTE_PROC_SECONDARY ? "Secondary" : "Invalid");
+    
+    // Runtime options
+    printf("\n=== Runtime Options ===\n");
+    printf("Current log level: %d\n", rte_log_get_global_level());
+    
+    // Memory allocation policy
+    printf("Hugepage info: %s\n", 
+           rte_eal_has_hugepages() ? "Using hugepages" : "Not using hugepages");
+    
+    // Memory segments info
+    printf("\n=== Memory Segments ===\n");
+    size_t total_memory = 0;
+    
+    // Walk through all memory segments
+    int ret = rte_memseg_walk(dump_memseg, &total_memory);
+    if (ret < 0) {
+        printf("Failed to walk memory segments\n");
+    } else {
+        printf("Total memory: %zu MB\n", total_memory >> 20);
+    }
+}
+
+int main(int argc, char **argv) {
+    printf("Starting DPDK initialization...\n");
+
+    // Set log level to debug
+    rte_log_set_global_level(RTE_LOG_DEBUG);
+
+    int ret = rte_eal_init(argc, argv);
+    if (ret < 0) {
+        rte_panic("Cannot init EAL: %s\n", rte_strerror(-ret));
+    }
+    printf("EAL initialization successful\n");
+
+    // Get number of available ports
+    uint16_t nb_ports = rte_eth_dev_count_avail();
+    printf("\nNumber of available ethernet ports: %u\n", nb_ports);
+
+    // Print info for each port
+    uint16_t port_id;
+    RTE_ETH_FOREACH_DEV(port_id) {
+        print_device_info(port_id);
+    }
+
+    printf("\nProceeding with runtime configuration...\n");
+    print_runtime_config();
+
+    printf("\nCleaning up...\n");
+    rte_eal_cleanup();
+    return 0;
+}
+```
+Compile command: `gcc -o hello hello.c $(pkg-config --cflags libdpdk) $(pkg-config --libs libdpdk) -DRTE_LOG_LEVEL=RTE_LOG_DEBUG`
+
+Launch command: `sudo gdb --args ./hello -l 0 -n 1 --proc-type=auto -m 256 --iova-mode=pa --log-level=8 --match-allocations -a 0000:01:00.0`
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_WHPX/2287 b/gitlab/issues_text/target_i386/host_x86/accel_WHPX/2287
new file mode 100644
index 00000000..e1b22958
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_x86/accel_WHPX/2287
@@ -0,0 +1,29 @@
+whpx, on booting win98, qemu crashes with Failed to emulate PortIO access with EmulatorReturnStatus: 2
+Description of problem:
+Q) What is the correct command line arguments to boot win98se with ```accel whpx```
+
+The above given command line crashes partway through the win98se boot process before the desktop shows up
+```
+Windows Hypervisor Platform accelerator is operational
+C:\vol\scoop_01\SCOOPG\apps\qemu\current\qemu-system-x86_64.exe: warning: GLib-GIO: Failed to open application manifest `C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AppxManifest.xml' for package #34 (`Microsoft.MicrosoftEdge_44.19041.1266.0_neutral__8wekyb3d8bbwe'): error code 0x2
+C:\vol\scoop_01\SCOOPG\apps\qemu\current\qemu-system-x86_64.exe: WHPX: Failed to emulate PortIO access with EmulatorReturnStatus: 2
+C:\vol\scoop_01\SCOOPG\apps\qemu\current\qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor
+```
+Steps to reproduce:
+1. Finish a complete win98 install using ```-machine type=pc,accel=tcg -cpu qemu64```  
+   ```qemu-system-x86_64 -machine type=pc,accel=tcg -cpu qemu64 -smp "sockets=1,cores=1,threads=1" -m 512 -nodefaults -bios bios-256k.bin -rtc base=localtime -display sdl,gl=on -device VGA,vgamem_mb=128 -audiodev dsound,id=snd1 -device adlib,audiodev=snd1 -audiodev dsound,id=snd2 -device ac97,audiodev=snd2  -boot c -drive index=0,if=ide,media=disk,format=vhdx,file="F:\Win98m40_sys.vhdx" -drive index=1,if=ide,media=disk,format=vhdx,file="F:\Win98m40_data_01.vhdx" -drive index=3,if=ide,media=disk,format=vhdx,file="F:\Win98m40_data_02.vhdx"```  
+   With all guestos-win98-drivers installed the win98 seems to work satisfactorily.  
+   Using vga driver from https://github.com/JHRobotics/vmdisp9x/releases   
+2. now change processor to ```-cpu core2duo```, it boots . This does not seem to matter, bug exists even with qemu64
+3. now change accel to ```-machine type=pc,accel=whpx ```, qemu crashes partway into boot before bringing up desktop.   
+   with or without ```kernel-irqchip=off``` does not matter   
+   with or without cpu arguments ```,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-time``` also does not matter
+4. Setting back to ```-machine type=pc,accel=tcg -cpu core2duo``` restores bootable win98se.
+Additional information:
+- [target/i386/whpx/whpx-all.c#L920](https://gitlab.com/qemu-project/qemu/-/blob/a12214d1c4204d2f51d8724993b8dfcf50dd7d94/target/i386/whpx/whpx-all.c#L920)
+- The part of the OS bootsequence, which includes the Win98/DOS boot menu, scandisk, etc. works fine. Its possible to boot to DOS mode and run DOS commands. The crash happens when into the win.com Win98SE boot sequence just before it can bring up the GUI desktop.  
+- qemu crashes even if in the win98/DOS bootmenu, selection is made to boot into ```safe-mode```, which is supposed to boot a vanilla 16-color VGA desktop loading minimal drivers. As before, crash happens before GUI desktop is loaded.
+- 20220623 Learn.Microsoft WHvEmulatorTryIoEmulation and WHvEmulatorTryMmioEmulation   
+  https://learn.microsoft.com/en-us/virtualization/api/hypervisor-instruction-emulator/funcs/whvemulatortryemulation
+- 20220426 Learn.Microsoft WHV_EMULATOR_STATUS  
+  https://learn.microsoft.com/en-us/virtualization/api/hypervisor-instruction-emulator/funcs/whvemulatorstatus
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_WHPX/2887 b/gitlab/issues_text/target_i386/host_x86/accel_WHPX/2887
new file mode 100644
index 00000000..8c69e715
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_x86/accel_WHPX/2887
@@ -0,0 +1 @@
+Qemu VM WHPX Startup Error with OVMF Code and VARS UEFI Files
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_missing/1910 b/gitlab/issues_text/target_i386/host_x86/accel_missing/1910
new file mode 100644
index 00000000..6181dcd7
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_x86/accel_missing/1910
@@ -0,0 +1,62 @@
+Signal handlers in x86_64 userspace have wrongly aligned stack
+Description of problem:
+Various applications crash in signal handlers due to `movaps` getting a misaligned stack address. For some reason this is reported as a NULL deref, but `gdb` clearly shows the true cause.
+
+```plaintext
+> qemu-x86_64 /usr/bin/ruby -e '`true`'
+-e:1: [BUG] Segmentation fault at 0x0000000000000000
+ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux-gnu]
+
+-- Control frame information -----------------------------------------------
+c:0003 p:---- s:0011 e:000010 CFUNC  :`
+c:0002 p:0005 s:0006 e:000005 EVAL   -e:1 [FINISH]
+c:0001 p:0000 s:0003 E:0015b0 DUMMY  [FINISH]
+
+-- Ruby level backtrace information ----------------------------------------
+-e:1:in `<main>'
+-e:1:in ``'
+
+-- Machine register context ------------------------------------------------
+ RIP: 0x00002aaaab50f98a RBP: 0x00002aaaabb136b8 RSP: 0x00002aaaab2a9c98
+ RAX: 0x0000000000000000 RBX: 0x0000000000004946 RCX: 0x0000000000000000
+ RDX: 0x00002aaaab2a9c98 RDI: 0x000000000caf0000 RSI: 0x0000000000000000
+  R8: 0x00002aaaab2aaa50  R9: 0x0000000000000050 R10: 0x0000000000000008
+ R11: 0x0000000000000000 R12: 0x0000000000000002 R13: 0x0000000000007310
+ R14: 0x0000000000005e10 R15: 0x00002aaab0537f20 EFL: 0x0000000000000246
+
+-- C level backtrace information -------------------------------------------
+```
+
+```plaintext
+(gdb) x/i $pc
+=> 0x2aaaab50f98a:      movaps %xmm0,(%rsp)
+(gdb) p/x $rsp
+$3 = 0x2aaaab2a9998
+```
+Steps to reproduce:
+1. ```qemu-x86_64 /usr/bin/ruby -e '`true`'```
+Additional information:
+The x86_64 psABI says:
+
+> the value (%rsp − 8) is always a multiple of 16 when control is transferred to the function entry point.
+
+However, when QEMU jumps to the signal handler, $rsp is aligned to 16B, i.e. ends in `0x..0`.
+
+The relevant kernel code:
+
+https://elixir.bootlin.com/linux/v6.5.5/source/arch/x86/kernel/signal.c#L123
+
+```plaintext
+	sp -= frame_size;
+
+	if (ia32_frame)
+		/*
+		 * Align the stack pointer according to the i386 ABI,
+		 * i.e. so that on function entry ((sp + 4) & 15) == 0.
+		 */
+		sp = ((sp + 4) & -FRAME_ALIGNMENT) - 4;
+	else
+		sp = round_down(sp, FRAME_ALIGNMENT) - 8;
+```
+
+CC @lvivier @bonzini @rth7680
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_missing/1926 b/gitlab/issues_text/target_i386/host_x86/accel_missing/1926
new file mode 100644
index 00000000..58cf4847
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_x86/accel_missing/1926
@@ -0,0 +1,24 @@
+Spice: handle_dev_destroy_surface_wait: condition `msg->surface_id == 0' failed (DoS via assert failure)
+Description of problem:
+Assert failure in libspice-server was found during fuzzing qxl-vga device.
+
+```plaintext
+qemu-system-x86_64: Spice: ../server/red-worker.cpp:367:handle_dev_destroy_surface_wait: condition `msg->surface_id == 0' failed
+Аварийный останов
+```
+Steps to reproduce:
+1. This bug can be reroduced with 
+
+   ```plaintext
+   cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -M \
+   pc -nodefaults -vga qxl -qtest stdio
+   outl 0xcf8 0x8000101c
+   outl 0xcfc 0xc000
+   outl 0xcf8 0x80001004
+   outw 0xcfc 0x01
+   outl 0xc00b 0x01000000
+   EOF
+   ```
+2. This bug is in another place from https://gitlab.com/qemu-project/qemu/-/issues/1829, please pay attention to it. It has to be solved, because it interferes with further fuzzing process
+Additional information:
+As I mentioned, I really need this bug to be solved, because fuzzing qxl-vga device gets less efficient. I suggested to report it here, not in spice-server, because this bug can be on the QEMU side.
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_missing/1946 b/gitlab/issues_text/target_i386/host_x86/accel_missing/1946
new file mode 100644
index 00000000..0c912f0b
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_x86/accel_missing/1946
@@ -0,0 +1,28 @@
+High CPU Load after QEMU 8.1.1
+Description of problem:
+Since the update there is a massive CPU load and this affects the CPU load of the router.
+The VMs are partially for about 3min sporadically not accessible.
+The VMs themselves were not adjusted and I have in the console.
+
+Using the VMM, I was able to see the message recorded below.
+
+`watchdog:_ BUG: soft lockup - CPU#0 stuck for 21s! [swapper/0:0]`
+
+I will also add some data like a XML file of a VM.
+Additional information:
+![webproxy](/uploads/5df86f9adfdd257ca2f43697603567c3/webproxy.PNG)
+[webproxy.log](/uploads/1d428f4c59b2397b9343a62dd8c4bce2/webproxy.log)
+
+[webproxy.xml](/uploads/04221c88956c49d76b4896dd8f6fd1f0/webproxy.xml)
+[Host_Kernel.log](/uploads/f145bf599bf2003b89c17daaabb07143/Host_Kernel.log)
+
+Unfortunately I can't revert to the old QEMU version in the router OS but in the current state all my VM are not really 100% usable anymore.
+
+I would be very grateful if you could take a look at my case.
+
+many thanks in advance.
+
+
+
+
+Paul
diff --git a/gitlab/issues_text/target_i386/host_x86/accel_missing/2608 b/gitlab/issues_text/target_i386/host_x86/accel_missing/2608
new file mode 100644
index 00000000..4850dc58
--- /dev/null
+++ b/gitlab/issues_text/target_i386/host_x86/accel_missing/2608
@@ -0,0 +1,9 @@
+Black screen in Windows XP
+Description of problem:
+When starting the installation of Windows XP (or Windows 2003) the screen in VNC stays black while the installer is in text-mode. During the second half of the installation, where it switches to graphical GUI, the display becomes visible again.
+
+This problem never happened on 9.0.1 and below, so is a regression in 9.1.0
+Steps to reproduce:
+1. Start the Windows XP installer
+2. Connect to VNC
+3. Screen stays black
diff --git a/gitlab/issues_text/target_loongarch/host_loongarch64/accel_missing/2136 b/gitlab/issues_text/target_loongarch/host_loongarch64/accel_missing/2136
new file mode 100644
index 00000000..144928f5
--- /dev/null
+++ b/gitlab/issues_text/target_loongarch/host_loongarch64/accel_missing/2136
@@ -0,0 +1,35 @@
+on loongarch host,  LSX vec get wrong result
+Description of problem:
+on loongarch host,  the lsx insns get wrong result.
+Steps to reproduce:
+1. build linux-user on loongarch host  with '--configure --target-list ='loongarch64-linux-user''
+2. build test code  'gcc --static test.c -o test'
+3. run './build/qemu-loongarch64 test'
+Additional information:
+run 'qemu-loongarch64 test' 
+the result is 
+
+`0: 2f2f2f2f
+1: 0
+2: 2f2f2f2f
+3: 0
+4: ffffffff
+5: 0
+6: ffffffff
+7: ffffffff`
+
+and the 6 or 7  may be ffffff or 0.
+
+run 'test' on loongarch host  or run qemu-loongarch64 on x86_64 host.
+the result is 
+
+`0: 2f2f2f2f
+1: 0
+2: 2f2f2f2f
+3: 0
+4: 0
+5: 0
+6: 0
+7: 0`
+
+for more infomation see log.txt
diff --git a/gitlab/issues_text/target_loongarch/host_missing/accel_KVM/2819 b/gitlab/issues_text/target_loongarch/host_missing/accel_KVM/2819
new file mode 100644
index 00000000..267d3d8c
--- /dev/null
+++ b/gitlab/issues_text/target_loongarch/host_missing/accel_KVM/2819
@@ -0,0 +1,117 @@
+QEMU 9.2.0 hangs with 100% CPU when using `-vnc` on Loongarch (3A6000 and 3C6000)
+Description of problem:
+When launching VMs with the `-vnc` parameter (generated by `<graphics type='vnc'>`) on a Loongarch (Loongson 3A6000 or Loongson 3C6000) machine. QEMU process hangs indefinitely with 100% CPU usage, no VNC output.
+Steps to reproduce:
+1. Create a VM using libvirt (Cockpit-Machines or virt-manager).
+2. Configure VNC graphics as follows in libvirt XML, which is provided by Cockpit-Machines by default.
+```xml
+<graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'>
+  <listen type='address' address='127.0.0.1'/>
+</graphics>
+```
+3. Start the VM: QEMU process hangs indefinitely with 100% CPU usage, no VNC output.
+Additional information:
+- Removing the `-vnc` parameter from the QEMU command line (via removing <graphics ... In libvirt XML) resolves the issue.
+- The issue appears to stem from changes introduced after QEMU 9.0.1, as downgrading resolves the problem.
+- Libvirtd log: https://aosc.io/paste/detail?id=da60d57c-5040-4326-a622-6a692eab488a
+- QEMU command line: https://aosc.io/paste/detail?id=30c97bd5-e666-4578-adfd-236cc1fe02ef
+- Full Libvirt VM XML: https://aosc.io/paste/detail?id=6bff0fed-d805-4c36-afb7-d14f29d6313b
+- No activity in `strace` during the hang.
+- GDB backtrace shows the process stuck in `ppoll` (full trace below):
+```
+(gdb) bt
+ #0  0x00007ffff189cad0 in __GI_ppoll (fds=0x7fffa4068d00, nfds=10, timeout=<optimized out>, sigmask=0x0)
+     at ../sysdeps/unix/sysv/linux/ppoll.c:42
+ #1  0x0000555557e67320 in qemu_poll_ns ()
+ #2  0x0000555557e636a4 in main_loop_wait ()
+ #3  0x0000555557a0c4d4 in qemu_main_loop ()
+ #4  0x0000555557d79cc8 in qemu_default_main ()
+ #5  0x00007ffff17c8f30 in __libc_start_call_main
+     (main=main@entry=0x5555577969c0 <main>, argc=argc@entry=119, argv=argv@entry=0x7ffffbad5508)
+     at ../sysdeps/nptl/libc_start_call_main.h:58
+ #6  0x00007ffff17c9020 in __libc_start_main_impl
+     (main=0x5555577969c0 <main>, argc=119, argv=0x7ffffbad5508,  init=<optimized out>, fini=<optimized out>,  rtld_fini=<optimized out>, stack_end=<optimized out>) at  ../csu/libc-start.c:360
+ #7  0x0000555557797b70 in _start ()
+```
+- Qemu full command line:
+```
+LC_ALL=C \
+PATH=/usr/local/bin:/usr/bin \
+USER=root \
+HOME=/var/lib/libvirt/qemu/domain-5-buildbot-new \
+XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-5-buildbot-new/.local/share \
+XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-5-buildbot-new/.cache \
+XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-5-buildbot-new/.config \
+/usr/bin/qemu-system-loongarch64 \
+-name guest=buildbot-new,debug-threads=on \
+-S \
+-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-5-buildbot-new/master-key.aes"}' \
+-blockdev '{"driver":"file","filename":"/usr/share/qemu/edk2-loongarch64-code.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \
+-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/buildbot-new_VARS.fd","node-name":"libvirt-pflash1-storage","read-only":false}' \
+-machine virt,usb=off,dump-guest-core=off,memory-backend=loongarch.ram,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-storage,acpi=on \
+-accel kvm \
+-cpu la464 \
+-m size=1048576k \
+-object '{"qom-type":"memory-backend-ram","id":"loongarch.ram","size":1073741824}' \
+-overcommit mem-lock=off \
+-smp 1,sockets=1,dies=1,clusters=1,cores=1,threads=1 \
+-uuid c56a24b5-c539-4240-9c72-39fd0d0de860 \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=33,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot strict=on \
+-device '{"driver":"pcie-root-port","port":8,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x1"}' \
+-device '{"driver":"pcie-root-port","port":9,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x1.0x1"}' \
+-device '{"driver":"pcie-root-port","port":10,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x1.0x2"}' \
+-device '{"driver":"pcie-root-port","port":11,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x1.0x3"}' \
+-device '{"driver":"pcie-root-port","port":12,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x1.0x4"}' \
+-device '{"driver":"pcie-root-port","port":13,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x1.0x5"}' \
+-device '{"driver":"pcie-root-port","port":14,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x1.0x6"}' \
+-device '{"driver":"pcie-root-port","port":15,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x1.0x7"}' \
+-device '{"driver":"pcie-root-port","port":16,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \
+-device '{"driver":"pcie-root-port","port":17,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x2.0x1"}' \
+-device '{"driver":"pcie-root-port","port":18,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x2.0x2"}' \
+-device '{"driver":"pcie-root-port","port":19,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x2.0x3"}' \
+-device '{"driver":"pcie-root-port","port":20,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x2.0x4"}' \
+-device '{"driver":"pcie-root-port","port":21,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x2.0x5"}' \
+-device '{"driver":"pcie-root-port","port":22,"chassis":15,"id":"pci.15","bus":"pcie.0","addr":"0x2.0x6"}' \
+-device '{"driver":"pcie-pci-bridge","id":"pci.16","bus":"pci.1","addr":"0x0"}' \
+-device '{"driver":"qemu-xhci","p2":15,"p3":15,"id":"usb","bus":"pci.3","addr":"0x0"}' \
+-device '{"driver":"virtio-scsi-pci","id":"scsi0","bus":"pci.8","addr":"0x0"}' \
+-device '{"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.4","addr":"0x0"}' \
+-blockdev '{"driver":"file","filename":"/mnt/data/aosc-os_installer_20241122_loongarch64.iso","node-name":"libvirt-1-storage","read-only":true}' \
+-device '{"driver":"scsi-cd","bus":"scsi0.0","channel":0,"scsi-id":0,"lun":0,"device_id":"drive-scsi0-0-0-0","drive":"libvirt-1-storage","id":"scsi0-0-0-0"}' \
+-chardev pty,id=charserial0 \
+-serial chardev:charserial0 \
+-chardev socket,id=charchannel0,fd=32,server=on,wait=off \
+-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \
+-chardev spicevmc,id=charchannel1,name=vdagent \
+-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":2,"chardev":"charchannel1","id":"channel1","name":"com.redhat.spice.0"}' \
+-device '{"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"}' \
+-device '{"driver":"usb-kbd","id":"input1","bus":"usb.0","port":"2"}' \
+-audiodev '{"id":"audio1","driver":"spice"}' \
+-vnc 127.0.0.1:0,audiodev=audio1 \
+-spice port=5901,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on \
+-device '{"driver":"virtio-gpu-pci","id":"video0","max_outputs":1,"bus":"pci.7","addr":"0x0"}' \
+-device '{"driver":"ich9-intel-hda","id":"sound0","bus":"pci.16","addr":"0x1"}' \
+-device '{"driver":"hda-duplex","id":"sound0-codec0","bus":"sound0.0","cad":0,"audiodev":"audio1"}' \
+-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.5","addr":"0x0"}' \
+-object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \
+-device '{"driver":"virtio-rng-pci","rng":"objrng0","id":"rng0","bus":"pci.6","addr":"0x0"}' \
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
+```
+- I tried to reproduce the bug with a simple command but failed, not sure what is the real cause. Following commands works fine.
+```
+qemu-system-loongarch64 -m 2G \
+  -cpu la464 \
+  -machine virt \
+  -smp 2 \
+  -bios /usr/share/qemu/edk2-loongarch64-code.fd \
+  -vnc 127.0.0.1:0 \
+  -device virtio-gpu-pci
+```
diff --git a/gitlab/issues_text/target_loongarch/host_missing/accel_missing/1261 b/gitlab/issues_text/target_loongarch/host_missing/accel_missing/1261
new file mode 100644
index 00000000..e31d9acc
--- /dev/null
+++ b/gitlab/issues_text/target_loongarch/host_missing/accel_missing/1261
@@ -0,0 +1,25 @@
+qemu-user syscall 439 (faccessat2) not implemented - loongarch64
+Description of problem:
+On LoongArch64 architecture faccessat syscall is missing and only faccessat2 is present, but it is not handled in  linux-user/syscall
+Steps to reproduce:
+1. Launch a simple bash test script (call it test.sh): if [[ -r test.sh ]] ; then echo OK ; else echo ERROR ; fi
+2. The result is "ERROR" even if the file "test.sh" exists and it is readeable
+3. The correct result should be "OK"
+Additional information:
+test.sh:
+   ```
+   if [[ -r test.sh ]] ; then echo OK ; else echo ERROR ; fi
+   ```
+qemu-loongarch -strace log:
+   ```
+[...]
+12579 statx(255,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x0000004000802a50) = 0
+12579 lseek(255,0,SEEK_CUR) = 0
+12579 read(255,0x2016d490,56) = 56
+12579 Unknown syscall 439
+12579 write(1,0x20172010,6) = 6
+12579 read(255,0x2016d490,56) = 0
+12579 rt_sigprocmask(SIG_BLOCK,0x0000004000802b60,0x0000004000802be0) = 0
+12579 rt_sigprocmask(SIG_SETMASK,0x0000004000802be0,NULL) = 0
+12579 exit_group(0)
+   ```
diff --git a/gitlab/issues_text/target_loongarch/host_missing/accel_missing/2491 b/gitlab/issues_text/target_loongarch/host_missing/accel_missing/2491
new file mode 100644
index 00000000..eb0bb6ea
--- /dev/null
+++ b/gitlab/issues_text/target_loongarch/host_missing/accel_missing/2491
@@ -0,0 +1,15 @@
+Performance Regression in QEMU (amd64 Emulating LoongArch64) from 8.0.4 to 9.0.2
+Description of problem:
+Previous Performance: In May 2023, we were using QEMU 8.0.4 for qemu-user emulation, and the performance was satisfactory. The setup did not include LSX (Loongson SIMD Extensions) support in either the system or QEMU. Performance results are shown in Figure A.
+
+Current Performance: Recently, we upgraded to QEMU 9.0.2. Both the system and QEMU now support vectorized instruction sets. However, we observed a performance decline to less than 60% of the previous benchmarks.
+
+We found that the slowdown is not caused by LSX. Disabling LSX compilation in the new version results in even worse performance. However, there are indeed significant differences between the two systems in terms of LSX support.
+Additional information:
+We use systemd-nspawn and qemu-binfmt for containerized operations. You can get a clean chroot from lcpu release [here](https://github.com/lcpu-club/loongarchlinux-dockerfile/releases/download/20240806/base-devel-loong64-20240806.tar.zst)
+
+Figure A, performance in May 2023
+![Figure A](/uploads/037647ca85b0fe4fd9d77a3c91b29e7d/微信图片_20240808124226.jpg)
+
+Figure B, performance nowadays
+![Figure B](/uploads/d5837ea77ca5a998fa1ca45070862331/微信图片_20240808124233.jpg)
diff --git a/gitlab/issues_text/target_loongarch/host_missing/accel_missing/2538 b/gitlab/issues_text/target_loongarch/host_missing/accel_missing/2538
new file mode 100644
index 00000000..d1c0fe8a
--- /dev/null
+++ b/gitlab/issues_text/target_loongarch/host_missing/accel_missing/2538
@@ -0,0 +1,26 @@
+qemu-system-loongarch64: ../hw/loongarch/virt.c:118: virt_flash_map1: Assertion `QEMU_IS_ALIGNED(real_size, VIRT_FLASH_SECTOR_SIZE)' failed.
+Description of problem:
+Cannot enter the loongarch64 UEFI shell due to the error below:
+qemu-system-loongarch64: ../hw/loongarch/virt.c:118: virt_flash_map1: Assertion `QEMU_IS_ALIGNED(real_size, VIRT_FLASH_SECTOR_SIZE)' failed.
+Steps to reproduce:
+1.follow the steps to create an empty loongarch64 uefi bare metal.
+2.Click start the installation
+3.Then the error occurs.
+Additional information:
+```
+qemu-system-loongarch64: ../hw/loongarch/virt.c:118: virt_flash_map1: Assertion `QEMU_IS_ALIGNED(real_size, VIRT_FLASH_SECTOR_SIZE)' failed.'
+
+Traceback (most recent call last):
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper
+    callback(asyncjob, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/createvm.py", line 2008, in _do_async_install
+    installer.start_install(guest, meter=meter)
+  File "/usr/share/virt-manager/virtinst/install/installer.py", line 695, in start_install
+    domain = self._create_guest(
+             ^^^^^^^^^^^^^^^^^^^
+  File "/usr/share/virt-manager/virtinst/install/installer.py", line 637, in _create_guest
+    domain = self.conn.createXML(initial_xml or final_xml, 0)
+             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/usr/lib64/python3.12/site-packages/libvirt.py", line 4545, in createXML
+    raise libvirtError('virDomainCreateXML() failed')
+```
diff --git a/gitlab/issues_text/target_loongarch/host_missing/accel_missing/2738 b/gitlab/issues_text/target_loongarch/host_missing/accel_missing/2738
new file mode 100644
index 00000000..652643e9
--- /dev/null
+++ b/gitlab/issues_text/target_loongarch/host_missing/accel_missing/2738
@@ -0,0 +1,10 @@
+golang 1.23 build hangs when running under qemu-user on x86_64 host
+Description of problem:
+Forwarded from https://github.com/golang/go/issues/70329.
+
+#
+Steps to reproduce:
+1. Setup qemu-user binfmt for a foreign ISA, for example, installs qemu-user-static-aarch64 on Fedora.
+2. Build the Dockerfile for specified arch: `podman build --arch aarch64 .`
+Additional information:
+
diff --git a/gitlab/issues_text/target_loongarch/host_missing/accel_missing/2754 b/gitlab/issues_text/target_loongarch/host_missing/accel_missing/2754
new file mode 100644
index 00000000..5c6f9bf6
--- /dev/null
+++ b/gitlab/issues_text/target_loongarch/host_missing/accel_missing/2754
@@ -0,0 +1,26 @@
+Virt-manager using QEMU exit in flash and return an I/O Error when attempting to create an loongarch64 QEMU virtual machine
+Description of problem:
+Cannot complete the installation:'Enter the end of the file when reading data:I/O Error'
+
+Traceback (most recent call last):
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 71, in cb_wrapper
+    callback(asyncjob, *args, **kwargs)
+    ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/usr/share/virt-manager/virtManager/createvm.py", line 2008, in _do_async_install
+    installer.start_install(guest, meter=meter)
+    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
+  File "/usr/share/virt-manager/virtinst/install/installer.py", line 726, in start_install
+    domain = self._create_guest(
+            guest, meter, initial_xml, final_xml,
+            doboot, transient)
+  File "/usr/share/virt-manager/virtinst/install/installer.py", line 667, in _create_guest
+    domain = self.conn.createXML(initial_xml or final_xml, 0)
+  File "/usr/lib64/python3.13/site-packages/libvirt.py", line 4545, in createXML
+    raise libvirtError('virDomainCreateXML() failed')
+libvirt.libvirtError: 'Enter the end of the file when reading data:I/O Error'
+Steps to reproduce:
+1.Click to create loongarch64 virtual machine using virt-manager
+2.Configure all arguments of virtual machine
+3.Then click start installation,then the error occurs.
+Additional information:
+
diff --git a/gitlab/issues_text/target_loongarch/host_missing/accel_missing/2865 b/gitlab/issues_text/target_loongarch/host_missing/accel_missing/2865
new file mode 100644
index 00000000..082c0b5c
--- /dev/null
+++ b/gitlab/issues_text/target_loongarch/host_missing/accel_missing/2865
@@ -0,0 +1,52 @@
+loongarch64: wrong implementation of `xvldi` instruction
+Description of problem:
+Consider this sample program.
+
+```c++
+#include <cstdio>
+#include <cstdint>
+#include <lsxintrin.h>
+#include <lasxintrin.h>
+
+void dump_u32(__m256i x) {
+    uint32_t tmp[32/4];
+    __lasx_xvst(x, tmp, 0);
+    putchar('[');
+    for (int i=0; i < 32/4; i++) {
+        if (i > 0) {
+            putchar(' ');
+        }
+
+        printf("%08x", tmp[i]);
+    }
+    puts("]");
+}
+
+int main() {
+    __m256i const1 = __lasx_xvldi(-3832);
+    dump_u32(const1);
+}
+```
+
+The magic constants here means: replicate in 32-bit words a byte (0x4) shifted left by 8. We should have a vector of words 0x800, and indeed, the program run on a real hardware prints expected:
+
+```
+[00000800 00000800 00000800 00000800 00000800 00000800 00000800 00000800]
+```
+
+The same program run under Qemu prints:
+
+```
+[08000800 00000000 08000800 00000000 08000800 00000000 08000800 00000000]
+```
+Additional information:
+I grabbed the latest sources, it seems there's bug in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`, in function `vldi_get_value`.
+
+```c
+    case 1:
+        /* data: {2{16'0, imm[7:0], 8'0}} */
+        data = (t << 24) | (t << 8);
+        break;
+```
+
+There should be `(t << (8+32)) | t << 8`.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_TCG/1206 b/gitlab/issues_text/target_m68k/host_missing/accel_TCG/1206
new file mode 100644
index 00000000..93927846
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_TCG/1206
@@ -0,0 +1,96 @@
+68k: movew %sp@+,%sr does not restore USP if switching from Supervisor to User mode
+Description of problem:
+Debugging issues with MacOS under qemu-system-m68k shows that the `movew %sp@+,%sr` instruction does not restore USP if switching from Supervisor to User mode. I've created a reproducer at https://gitlab.com/mcayland/qemu/-/commits/68k-move-to-sr-bug ([diff from git master](https://gitlab.com/mcayland/qemu/-/commit/fbcd078946c0e582bf8f1ac9a5a3a31cda2e6c38.diff)) which uses the following code snippet:
+
+```
+0x40800000 in MYROM ()
+warning: shared library handler failed to enable breakpoint
+(gdb) disas $pc $pc+0x20
+Dump of assembler code from 0x40800000 to 0x40800020:
+0x40800000 <MYROM+0>:   lea 0x6000,%a0
+0x40800006 <MYROM+6>:   movel %a0,%usp
+0x40800008 <MYROM+8>:   movew %sr,%d0
+0x4080000a <MYROM+10>:  andiw #8191,%d0
+0x4080000e <MYROM+14>:  movew %d0,%sp@-
+0x40800010 <MYROM+16>:  movew %sp@+,%sr
+0x40800012 <MYROM+18>:  bras 0x40800012 <MYROM+18>
+```
+
+Initially the ISP is set to 0x1000 in supervisor mode: the code above loads 0x6000 into %usp, moves the SR register into d0, clears the supervisor bit, and pushes the new SR value onto the stack. Finally the `movew %sp@+,%sr` instruction is executed which switches from supervisor mode to user mode but the resulting %sp is still the ISP value and not the USP:
+
+```
+0x40800000 in MYROM ()
+warning: shared library handler failed to enable breakpoint
+(gdb) stepi
+0x40800006 in MYROM ()
+(gdb) 
+0x40800008 in MYROM ()
+(gdb) 
+0x4080000a in MYROM ()
+(gdb) 
+0x4080000e in MYROM ()
+(gdb)
+0x40800010 in MYROM ()
+(gdb)
+0x40800010 in MYROM ()
+(gdb) i r $ps $sp
+ps             0x2700   9984
+sp             0xffe    0xffe
+(gdb) stepi      
+0x40800012 in MYROM ()
+(gdb) i r $ps $sp
+ps             0x700    1792
+sp             0x1000   0x1000    <-- should be 0x6000
+```
+
+Analysis with gdb shows that the `set_sr` helper is calling `m68k_switch_sp()` correctly but the resulting value is not seen in the guest:
+
+```
+Thread 3 "qemu-system-m68" hit Breakpoint 1, m68k_switch_sp (env=0x62d000030ae0) at ../target/m68k/helper.c:462
+462         env->sp[env->current_sp] = env->aregs[7];
+(gdb) p/x env->aregs[7]
+$1 = 0xffe
+(gdb) n
+463         if (m68k_feature(env, M68K_FEATURE_M68000)) {
+(gdb) 
+464             if (env->sr & SR_S) {
+(gdb) 
+472                 new_sp = M68K_USP;
+(gdb) 
+478         env->aregs[7] = env->sp[new_sp];
+(gdb) 
+479         env->current_sp = new_sp;
+(gdb) 
+480     }
+(gdb) p/x env->aregs[7]
+$2 = 0x6000
+```
+
+The bug seems to be caused by the post-increment operator clobbering the stack pointer with the ISP after the instruction has been translated:
+
+```
+IN: 
+0x40800010:  movew %sp@+,%sr
+
+OP:
+ ld_i32 tmp0,env,$0xfffffffffffffff0
+ brcond_i32 tmp0,$0x0,lt,$L0
+
+ ---- 40800010 00000000
+ mov_i32 tmp0,$0x1
+ st_i32 tmp0,env,$0xfffffffffffffc18
+ qemu_ld_i32 tmp0,A7,leuw,0
+ bswap16_i32 tmp0,tmp0,iz,oz
+ add_i32 tmp3,A7,$0x2
+ call set_sr,$0x0,$0,env,tmp0
+ mov_i32 CC_OP,$0x1
+ mov_i32 PC,$0x40800012
+ mov_i32 A7,tmp3
+ exit_tb $0x0
+ set_label $L0
+ exit_tb $0x7fe118f30043
+```
+
+Here tmp3 which is generated from the ISP is written back to A7 **after** `set_sr` has switched the stack pointer. This appears to be part of the `delay_set_areg` mechanism which was introduced in 8a1e52b69d ("target-m68k: Delay autoinc writeback").
+
+From what I can see it isn't possible to easily change the order of the `set_sr` helper and applying the post-increment since the post-increment is handled automatically after the instruction is translated as part of `do_writebacks()`.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_TCG/2078 b/gitlab/issues_text/target_m68k/host_missing/accel_TCG/2078
new file mode 100644
index 00000000..bcd790e2
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_TCG/2078
@@ -0,0 +1,34 @@
+Qemu crashes with SIGFPE on certain trapping arithmetic operations on m68k target
+Description of problem:
+I recently ported NetBSD to the Qemu m68k "virt" platform, and this was discovered when running NetBSD's automated tests.  Certain arithmetic operation that will trap in the guest will crash Qemu.  First case encountered is below.
+Steps to reproduce:
+1. Compile and run the following program in the m68k guest:
+
+```
+virt68k:thorpej 3$ cat crash-qemu.c                                            
+#include <limits.h>
+#include <stdlib.h>
+
+int divisor = -1;
+
+int
+main(int argc, char *argv[])
+{
+
+	if (argc > 1)
+		divisor = atoi(argv[1]);
+
+	return INT_MIN / divisor;
+}
+virt68k:thorpej 4$ 
+```
+
+Another minimal case would be:
+
+```
+move.l #-2147483648,%d0
+move.l #-1,%d1
+divsl.l %d1,%d1:%d0
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_TCG/2249 b/gitlab/issues_text/target_m68k/host_missing/accel_TCG/2249
new file mode 100644
index 00000000..7bbaa744
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_TCG/2249
@@ -0,0 +1,33 @@
+[qemu-system-m68k] [q800] Ishar 1 makes Qemu crash
+Description of problem:
+qemu-system-m68k crashes when running the classic RPG game "Ishar", this is what can be seen on the TTY console on the host system:
+
+```
+qemu: fatal: DOUBLE MMU FAULT
+
+D0 = 000000af   A0 = 000b91d2   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = 00000074   A1 = 50f02000   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = 00000000   A2 = 00067274   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = f7f6f600   A3 = 40809be0   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = f8ff2a2a   A4 = 00000000   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = 54aa0027   A5 = 007ef2b8   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = 0000000a   A6 = 000001e3   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = ffffffe6   A7 = 0000000a   F7 = 7fff ffffffffffffffff  (         nan)
+PC = 00067288   SR = 2218 T:0 I:2 SI XN---
+FPSR = 00000000 ---- 
+                                FPCR =     0000 X RN 
+  A7(MSP) = 00000000   A7(USP) = 00000000 ->A7(ISP) = 0000000a
+VBR = 0x00000000
+SFC = 0 DFC 5
+SSW 00000445 TCR 0000c000 URP 00000000 SRP 01ff6c00
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at fffffffe
+./mac: line 5: 806788 Aborted                 (core dumped) qemu-system-m68k -M q800 -m 32 -bios q800.rom -display sdl -audio driver=alsa -device scsi-hd,scsi-id=0,drive=hd0 -drive file=system71.img,media=disk,format=raw,if=none,id=hd0 -display sdl
+```
+Steps to reproduce:
+1. Download Ishar 1 Color version (available in https://www.grenier-du-mac.net/fiches/Jeux/ishar1.htm, on the lower part of the page).
+2. Copy it to the emulated system and decompress the .sit archive with Stuffit Expander 5.5
+3. Run the game by clicking on it's icon and clicking on "Commandes->Jouer" or pressing Command+J
+4. Watch it making qemu-system-m68k crash'n burn!
+Additional information:
+The same game works fine on current MAME Mac II/Ci emulation, etc.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_TCG/2290 b/gitlab/issues_text/target_m68k/host_missing/accel_TCG/2290
new file mode 100644
index 00000000..94588f75
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_TCG/2290
@@ -0,0 +1,143 @@
+Wrong multiplication result of 'long double' on m68k
+Description of problem:
+In both x86 and m68k, 'long double' is an 80-bit format consisting of
+  - 1 bit sign, 15 bits exponent,
+  - 1 explicit 1 bit, 63 fraction bits.
+
+According to <https://en.wikipedia.org/wiki/Extended_precision> and
+<https://www.nxp.com/docs/en/reference-manual/M68000PRM.pdf> table 1-6 (page 1-23), with two differences:
+  - In m68k, there are 16 zero bits as filler after the sign/exponent
+    word, so that the total size is 96 bits.
+  - In x86, the minimum exponent of normalized numbers is 1;
+    in m68k, the minimum exponent of normalized numbers is 0.
+
+The latter difference is reflected in the values of LDBL_MIN_EXP and
+LDBL_MIN in gcc:
+
+In x86:
+```
+$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN_EXP_
+#define LDBL_MIN_EXP __LDBL_MIN_EXP__
+#define __LDBL_MIN_EXP__ (-16381)
+$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN__
+#define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L
+#define LDBL_MIN __LDBL_MIN__
+```
+In m68k (I use Debian 12/Linux):
+```
+$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN_EXP_
+#define LDBL_MIN_EXP __LDBL_MIN_EXP__
+#define __LDBL_MIN_EXP__ (-16382)
+$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN__
+#define __LDBL_MIN__ 1.68105157155604675313e-4932L
+#define LDBL_MIN __LDBL_MIN__
+```
+Steps to reproduce:
+Take this program, foo.c:
+```
+/* Show extended-precision https://en.wikipedia.org/wiki/Extended_precision
+   multiplication bug in QEMU.  */
+
+#include <stdio.h>
+
+static void
+show (const long double *p)
+{
+#ifdef __m68k__
+  printf("<S,E: 0x%08X M: 0x%08X%08X>",
+         ((const unsigned int *) p)[0],
+         ((const unsigned int *) p)[1],
+         ((const unsigned int *) p)[2]);
+#else /* x86 */
+  printf("<S,E: 0x%04X M: 0x%08X%08X>",
+         ((const unsigned short *) p)[4],
+         ((const unsigned int *) p)[1],
+         ((const unsigned int *) p)[0]);
+#endif
+  printf (" = %La = %Lg", *p, *p);
+}
+
+static void
+show_mult (long double a, long double b)
+{
+  printf ("Factors: ");
+  show (&a);
+  printf ("\n    and: ");
+  show (&b);
+  long double c = a * b;
+  printf ("\nProduct: ");
+  show (&c);
+  printf ("\n\n");
+}
+
+/* Return 2^n.  */
+static long double
+pow2l (int n)
+{
+  int k = n;
+  volatile long double x = 1;
+  volatile long double y = 2;
+  /* Invariant: 2^n == x * y^k.  */
+  if (k < 0)
+    {
+      y = 0.5L;
+      k = - k;
+    }
+  while (k > 0)
+    {
+      if (k != 2 * (k / 2))
+        {
+          x = x * y;
+          k = k - 1;
+        }
+      if (k == 0)
+        break;
+      y = y * y;
+      k = k / 2;
+    }
+  /* Now k == 0, hence x == 2^n.  */
+  return x;
+}
+
+int main ()
+{
+  show_mult (pow2l (-16382), 0.5L);
+  show_mult (pow2l (-16381), 0.25L);
+  return 0;
+}
+```
+Its output on x86:
+```
+$ ./a.out 
+Factors: <S,E: 0x0001 M: 0x8000000000000000> = 0x8p-16385 = 3.3621e-4932
+    and: <S,E: 0x3FFE M: 0x8000000000000000> = 0x8p-4 = 0.5
+Product: <S,E: 0x0000 M: 0x4000000000000000> = 0x4p-16385 = 1.68105e-4932
+
+Factors: <S,E: 0x0002 M: 0x8000000000000000> = 0x8p-16384 = 6.72421e-4932
+    and: <S,E: 0x3FFD M: 0x8000000000000000> = 0x8p-5 = 0.25
+Product: <S,E: 0x0000 M: 0x4000000000000000> = 0x4p-16385 = 1.68105e-4932
+```
+Its output on m68k:
+```
+$ ./a.out 
+Factors: <S,E: 0x00010000 M: 0x8000000000000000> = 0x8p-16385 = 3.3621e-4932
+    and: <S,E: 0x3FFE0000 M: 0x8000000000000000> = 0x8p-4 = 0.5
+Product: <S,E: 0x00000000 M: 0x4000000000000000> = 0x4p-16386 = 8.40526e-4933
+
+Factors: <S,E: 0x00020000 M: 0x8000000000000000> = 0x8p-16384 = 6.72421e-4932
+    and: <S,E: 0x3FFD0000 M: 0x8000000000000000> = 0x8p-5 = 0.25
+Product: <S,E: 0x00000000 M: 0x4000000000000000> = 0x4p-16386 = 8.40526e-4933
+```
+The product, computed by QEMU, is incorrect. It is only half as large as the
+correct value. The expected output should be:
+```
+Factors: <S,E: 0x00010000 M: 0x8000000000000000> = 0x8p-16385 = 3.3621e-4932
+    and: <S,E: 0x3FFE0000 M: 0x8000000000000000> = 0x8p-4 = 0.5
+Product: <S,E: 0x00000000 M: 0x8000000000000000> = 0x8p-16386 = 1.68105e-4932
+
+Factors: <S,E: 0x00020000 M: 0x8000000000000000> = 0x8p-16384 = 6.72421e-4932
+    and: <S,E: 0x3FFD0000 M: 0x8000000000000000> = 0x8p-5 = 0.25
+Product: <S,E: 0x00000000 M: 0x8000000000000000> = 0x8p-16386 = 1.68105e-4932
+```
+Additional information:
+In QEMU's source code, I would guess that this multiplication is performed by the `floatx80_mul` function.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_TCG/754 b/gitlab/issues_text/target_m68k/host_missing/accel_TCG/754
new file mode 100644
index 00000000..d93ba56b
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_TCG/754
@@ -0,0 +1,207 @@
+qem_m68k : trapcs instruction causes the non-execution of the following 2 instructions
+Description of problem:
+In try to run following code :
+```
+8004615a:	204f           	moveal %sp,%a0
+8004615c:	b1c7           	cmpal %d7,%a0
+8004615e:	55fc           	trapcs
+80046160:	4e56 0000      	linkw %fp,#0
+80046164:	2f14           	movel %a4@,%sp@-
+80046166:	288e           	movel %fp,%a4@
+80046168:	c74d           	exg %a3,%a5
+8004616a:	48e7 3030      	moveml %d2-%d3/%a2-%a3,%sp@-
+8004616e:	7001           	moveq #1,%d0
+80046170:	3b40 816c      	movew %d0,%a5@(-32404)
+80046174:	7218           	moveq #24,%d1
+80046176:	3b41 816a      	movew %d1,%a5@(-32406)
+8004617a:	242d 8004      	movel %a5@(-32764),%d2
+8004617e:	2b42 815c      	movel %d2,%a5@(-32420)
+80046182:	206d 8008      	moveal %a5@(-32760),%a0
+80046186:	2268 8010      	moveal %a0@(-32752),%a1
+8004618a:	2b49 8158      	movel %a1,%a5@(-32424)
+8004618e:	42ad 8154      	clrl %a5@(-32428)
+80046192:	246d 8154      	moveal %a5@(-32428),%a2
+80046196:	2b4a 8160      	movel %a2,%a5@(-32416)
+8004619a:	2b4a 8164      	movel %a2,%a5@(-32412)
+8004619e:	422d 8168      	clrb %a5@(-32408)
+800461a2:	7604           	moveq #4,%d3
+800461a4:	2b43 8150      	movel %d3,%a5@(-32432)
+800461a8:	2668 8010      	moveal %a0@(-32752),%a3
+800461ac:	2b4b 814c      	movel %a3,%a5@(-32436)
+800461b0:	2268 8010      	moveal %a0@(-32752),%a1
+800461b4:	266d 8008      	moveal %a5@(-32760),%a3
+800461b8:	206b 8008      	moveal %a3@(-32760),%a0
+800461bc:	4e90           	jsr %a0@
+800461be:	2b48 8148      	movel %a0,%a5@(-32440)
+800461c2:	4cdf 0c0c      	moveml %sp@+,%d2-%d3/%a2-%a3
+800461c6:	c74d           	exg %a3,%a5
+800461c8:	289f           	movel %sp@+,%a4@
+800461ca:	4e5e           	unlk %fp
+800461cc:	4e75           	rts
+```
+When I run qemu-m68k -cpu m68020 -d in_asm,cpu, I have : 
+```
+----------------
+IN: 
+0x8004615a:  moveal %sp,%a0
+0x8004615c:  cmpal %d7,%a0
+0x8004615e:  trapcs
+0x80046160:  linkw %fp,#0
+0x80046164:  movel %a4@,%sp@-
+0x80046166:  movel %fp,%a4@
+0x80046168:  exg %a3,%a5
+0x8004616a:  moveml %d2-%d3/%a2-%a3,%sp@-
+0x8004616e:  moveq #1,%d0
+0x80046170:  movew %d0,%a5@(-32404)
+0x80046174:  moveq #24,%d1
+0x80046176:  movew %d1,%a5@(-32406)
+0x8004617a:  movel %a5@(-32764),%d2
+0x8004617e:  movel %d2,%a5@(-32420)
+0x80046182:  moveal %a5@(-32760),%a0
+0x80046186:  moveal %a0@(-32752),%a1
+0x8004618a:  movel %a1,%a5@(-32424)
+0x8004618e:  clrl %a5@(-32428)
+0x80046192:  moveal %a5@(-32428),%a2
+0x80046196:  movel %a2,%a5@(-32416)
+0x8004619a:  movel %a2,%a5@(-32412)
+0x8004619e:  clrb %a5@(-32408)
+0x800461a2:  moveq #4,%d3
+0x800461a4:  movel %d3,%a5@(-32432)
+0x800461a8:  moveal %a0@(-32752),%a3
+0x800461ac:  movel %a3,%a5@(-32436)
+0x800461b0:  moveal %a0@(-32752),%a1
+0x800461b4:  moveal %a5@(-32760),%a3
+0x800461b8:  moveal %a3@(-32760),%a0
+0x800461bc:  jsr %a0@
+
+Trace 0: 0x7f83a807e780 [00000000/8004615a/00000000/00000000] 
+D0 = 00000012   A0 = 8004615a   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = 00000001   A1 = 800466d6   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = 00000000   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = 00000000   A3 = 8000c3b0   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = 00000000   A4 = 8004604c   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = 00000000   A5 = 3ffd7000   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = 00000004   A6 = 80046038   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = 80042050   A7 = 80045ff4   F7 = 7fff ffffffffffffffff  (         nan)
+PC    SR = 0004 T:0 I:0 UI --Z--
+FPSR = 00000000 ---- 
+                                FPCR =     0000 X RN 
+								
+
+----------------
+IN: 
+0x80046358:  lea %a1@(0,%d0:l),%a0
+0x8004635c:  rts
+
+Trace 0: 0x7f83a807eac0 [00000000/80046358/00000000/00000000] 
+D0 = 00000001   A0 = 80046358   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = 00000018   A1 = 00000000   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = ffffffff   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = 00000004   A3 = 8000c040   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = 00000000   A4 = 8004604c   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = 00000000   A5 = 8000c3b0   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = 00000004   A6 = 80046038   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = 80042050   A7 = 80045fe0   F7 = 7fff ffffffffffffffff  (         nan)
+PC = 80046358   SR = 0004 T:0 I:0 UI --Z--
+FPSR = 00000000 ---- 
+                                FPCR =     0000 X RN 
+----------------
+```
+Stack pointer is  80045fe0, it should be 80045FD8.
+
+When I run with options -cpu m68020 -d in_asm,cpu,op -singlestep, I have :
+```
+----------------
+IN:
+0x8004615e:  trapcs
+0x80046160:  linkw %fp,#0
+Disassembler disagrees with translator over instruction decoding
+Please report this to qemu-devel@nongnu.org
+
+OP:
+ ld_i32 tmp0,env,$0xfffffffffffffff8
+ brcond_i32 tmp0,$0x0,lt,$L0
+
+ ---- 8004615e 00000000
+ mov_i32 tmp0,$0x0
+ call flush_flags,$0x0,$0,env,CC_OP
+ setcond_i32 tmp2,CC_C,tmp0,ne
+ neg_i32 tmp2,tmp2
+ mov_i32 tmp0,$0x56
+ mov_i32 PC,$0x80046162
+ exit_tb $0x0
+ set_label $L0
+ exit_tb $0x7fba001a75c3
+
+D0 = 00000012   A0 = 80045ff4   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = 00000001   A1 = 800466d6   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = 00000000   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = 00000000   A3 = 8000c3b0   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = 00000000   A4 = 8004604c   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = 00000000   A5 = 3ffd5000   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = 00000004   A6 = 80046038   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = 80042050   A7 = 80045ff4   F7 = 7fff ffffffffffffffff  (         nan)
+PC = 8004615e   SR = 0000 T:0 I:0 UI -----
+FPSR = 00000000 ----
+                                FPCR =     0000 X RN
+----------------
+IN:
+0x80046162:  orib #20,%d0
+
+OP:
+ ld_i32 tmp0,env,$0xfffffffffffffff8
+ brcond_i32 tmp0,$0x0,lt,$L0
+
+ ---- 80046162 00000000
+ mov_i32 tmp0,$0x14
+ ext8s_i32 tmp3,D0
+ or_i32 tmp4,tmp3,tmp0
+ and_i32 D0,D0,$0xffffff00
+ ext8u_i32 tmp6,tmp4
+ or_i32 D0,D0,tmp6
+ ext8s_i32 CC_N,tmp4
+ discard CC_C
+ discard CC_Z
+ discard CC_V
+ mov_i32 CC_OP,$0xb
+ mov_i32 PC,$0x80046166
+ exit_tb $0x0
+ set_label $L0
+ exit_tb $0x7fba001a7683
+
+D0 = 00000012   A0 = 80045ff4   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = 00000001   A1 = 800466d6   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = 00000000   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = 00000000   A3 = 8000c3b0   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = 00000000   A4 = 8004604c   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = 00000000   A5 = 3ffd5000   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = 00000004   A6 = 80046038   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = 80042050   A7 = 80045ff4   F7 = 7fff ffffffffffffffff  (         nan)
+PC = 80046162   SR = 0000 T:0 I:0 UI -----
+FPSR = 00000000 ----
+                                FPCR =     0000 X RN
+----------------
+IN:
+0x80046166:  movel %fp,%a4@
+
+OP:
+ ld_i32 tmp0,env,$0xfffffffffffffff8
+ brcond_i32 tmp0,$0x0,lt,$L0
+
+...
+```
+I can see that instructions 
+```
+0x80046160:  linkw %fp,#0
+0x80046164:  movel %a4@,%sp@-
+```
+are not executed
+and an extra instruction
+```
+0x80046162:  orib #20,%d0
+```
+is executed
+Steps to reproduce:
+Run chroot qemu-m68k qemu-m68k-static -cpu m68020 -d in_asm,cpu -D log1.txt ./test
+Additional information:
+
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/1314 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1314
new file mode 100644
index 00000000..174b4a8d
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1314
@@ -0,0 +1,40 @@
+68k: issues with fremx and fmodx
+Description of problem:
+Some of the mac68k folks have been testing my MacOS branch at https://github.com/mcayland/qemu/tree/q800.upstream2-vm and noticed problems with the values of some of the MacOS _Pack5 transcendental functions. This is easily visible when calling the `sin()` and `cos()` functions whereby some angle ranges use the values from the wrong section of the waveform and/or return values with the incorrect sign.
+
+SolraBizna was kind enough to write a 68K MacOS test program to generate a sine table (including dumping the hex values of the FP registers) that could be run on real hardware for comparison with QEMU. Using this it was discovered that the issue is related to the implementation of the `fremx` and `fmodx` instructions which can be found in [`floatx80_modrem()`](https://gitlab.com/qemu-project/qemu/-/blob/master/fpu/softfloat.c#L2601).
+
+I have taken the output of the test program run on a real 68040 Mac and used it to create a test harness at https://github.com/mcayland/qemu/commits/68k-fmodrem-bug [(diff from git master)](https://github.com/mcayland/qemu/commit/4afd6b7c3cad89df943ec43395f95dad7f368338.diff) which iterates over 100 points of the sine table and uses the registers to indicate any failures according to the following comment:
+
+```
+    /*
+     * The test program below hangs when it completes and the exit
+     * condition can be determined using the monitor via "info
+     * registers" command as follows:
+     *
+     *     D7 is the test number (0-99)
+     *     D6 is the error code
+     *         0 = no error
+     *         1 = frem result incorrect
+     *         2 = frem fpsr result incorrect
+     *         3 = fmod result incorrect
+     *         4 = fmod fpsr result incorrect
+     *     D2 is the actual result of the long comparison
+     *     D1 is the expected result of the long comparison
+     *
+     * A successful termination of the test program is when D7 == 100
+     * and D6 == 0.
+     */
+```
+
+This enables the majority of debugging to be done directly using `info registers` in the monitor rather than manually stepping through the example code using the gdbstub.
+
+Based upon my local testing on `qemu-system-m68k` there are 2 main differences between QEMU and the output from a real 68040:
+
+- Differences in precision
+
+The very first `fremx` result comparison fails here returning `0x3ffe0000 0xc90fdaa2 0x2168c23c 0x........` instead of `0x3ffe0000 0xc90fdaa2 0x2168c238 0x........`. Fortunately the difference in precision is small, and while it may not be possible to fix this, at least it gives a measure of how QEMU's emulation compares to a real 68040.
+
+- Incorrect setting of the quotient byte
+
+Bits 16-23 of the FPSR are supposed to contain the sign and 7 LSBs of the quotient for `fremx` and `fmodx` instructions, which is used in _Pack5 to generate an offset into a lookup table for the transcendental functions. It appears that the main cause of the incorrect `sin()` and `cos()` functions is due to the quotient byte being set incorrectly by `fremx`, causing MacOS to jump to the wrong segment of the lookup table for certain angle ranges.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/1462 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1462
new file mode 100644
index 00000000..478cfcd0
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1462
@@ -0,0 +1,14 @@
+qemu-system-m68k segfaults on opcode 0x4848
+Description of problem:
+Running an m68k executable with opcode 0x4848 will segfault qemu-system-m68k
+Steps to reproduce:
+1. Boot m68k debian
+2. Compile program (see above for the oops.c source) that executes opcode 0x4848
+3. Run program
+4. QEMU segfaults:
+
+```
+./debian-m68k.sh: line 10:  4420 Segmentation fault      (core dumped) qemu-system-m68k -boot c -M q800 -serial none -serial mon:stdio -m 1000M -net nic,model=dp83932,addr=08:00:07:12:34:89 -net user -append "root=/dev/sda2 rw console=ttyS0 console=tty" -kernel virt/vmlinux-4.16.0-1-m68k -initrd virt/initrd.img-4.16.0-1-m68k -drive file=virt/debian-m68k-deb10.qcow2,format=qcow2 -nographic
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/1502 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1502
new file mode 100644
index 00000000..be35035a
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1502
@@ -0,0 +1 @@
+Usermode qemu-m68k futex crash while running "cmake -E cmake_autogen"
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/1568 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1568
new file mode 100644
index 00000000..30b27fa4
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1568
@@ -0,0 +1,39 @@
+qemu-system-m68k fails whenever the option "-d cpu_reset" is specified
+Description of problem:
+When specifying the option "-d cpu_reset", the following output is generated, and QEMU eventually crashes with a Segmentation fault:
+```
+CPU Reset (CPU 0)
+D0 = 00000000   A0 = 00000000   F0 = 0000 0000000000000000  (           0)
+D1 = 00000000   A1 = 00000000   F1 = 0000 0000000000000000  (           0)
+D2 = 00000000   A2 = 00000000   F2 = 0000 0000000000000000  (           0)
+D3 = 00000000   A3 = 00000000   F3 = 0000 0000000000000000  (           0)
+D4 = 00000000   A4 = 00000000   F4 = 0000 0000000000000000  (           0)
+D5 = 00000000   A5 = 00000000   F5 = 0000 0000000000000000  (           0)
+D6 = 00000000   A6 = 00000000   F6 = 0000 0000000000000000  (           0)
+D7 = 00000000   A7 = 00000000   F7 = 0000 0000000000000000  (           0)
+PC = 00000000   qemu: fatal: Bad CC_OP 0
+D0 = 00000000   A0 = 00000000   F0 = 0000 0000000000000000  (           0)
+D1 = 00000000   A1 = 00000000   F1 = 0000 0000000000000000  (           0)
+D2 = 00000000   A2 = 00000000   F2 = 0000 0000000000000000  (           0)
+D3 = 00000000   A3 = 00000000   F3 = 0000 0000000000000000  (           0)
+D4 = 00000000   A4 = 00000000   F4 = 0000 0000000000000000  (           0)
+D5 = 00000000   A5 = 00000000   F5 = 0000 0000000000000000  (           0)
+D6 = 00000000   A6 = 00000000   F6 = 0000 0000000000000000  (           0)
+D7 = 00000000   A7 = 00000000   F7 = 0000 0000000000000000  (           0)
+...
+D0 = 00000000   A0 = 00000000   F0 = 0000 0000000000000000  (           0)
+D1 = 00000000   A1 = 00000000   F1 = 0000 0000000000000000  (           0)
+D2 = 00000000   A2 = 00000000   F2 = 0000 0000000000000000  (           0)
+D3 = 00000000   A3 = 00000000   F3 = 0000 0000000000000000  (           0)
+D4 = 00000000   A4 = 00000000   F4 = 0000 0000000000000000  (           0)
+D5 = 00000000   A5 = 00000000   F5 = 0000 0000000000000000  (           0)
+D6 = 00000000   A6 = 00000000   F6 = 0000 0000000000000000  (           0)
+D7 = 00000000   A7 = 00000000   F7 = 0000 0000000000000000  (           0)
+PC = 00000000   qemu: fatal: Bad CC_OP 0
+Segmentation fault (core dumped)
+```
+This also happens with the other m68k machine types.
+Steps to reproduce:
+1. Run QEMU with the given command line.
+Additional information:
+
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/1831 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1831
new file mode 100644
index 00000000..8d4ec9e1
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1831
@@ -0,0 +1 @@
+qemu-system-m68k: ../hw/scsi/scsi-disk.c:557: scsi_write_data: Assertion `r->req.aiocb == NULL' failed.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2000 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2000
new file mode 100644
index 00000000..1d919b7f
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2000
@@ -0,0 +1,45 @@
+m68k: error "fatal: Unimplemented control register write 0x0 = 0x1"
+Description of problem:
+An attempt to run the NetBSD m68k kernel under QEMU crashes.
+The error message is:
+```
+qemu: fatal: Unimplemented control register write 0x0 = 0x1
+```
+Steps to reproduce:
+1. ```wget http://cdn.netbsd.org/pub/NetBSD/iso/9.3/NetBSD-9.3-mac68k.iso```
+2. Pull kernel out of the installation CD:
+```
+sudo mount -r -t iso9660 -o loop /home/bruno/vms/os-install-media/NetBSD-9.3-mac68k.iso /mnt
+cp /mnt/mac68k/binary/kernel/netbsd-GENERIC.gz .
+sudo umount /mnt
+chmod u+w netbsd-GENERIC.gz
+gunzip netbsd-GENERIC.gz
+```
+3. ```qemu-img create -f qcow2 netbsd93.qcow2 10G```
+4. ```qemu-system-m68k -m 256 -drive file=netbsd93.qcow2,format=qcow2,index=0 -nographic -kernel netbsd-GENERIC -cdrom NetBSD-9.3-mac68k.iso```
+
+It crashes like this:
+```
+qemu: fatal: Unimplemented control register write 0x0 = 0x1
+
+D0 = 00000001   A0 = 00000000   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = 00000000   A1 = 00000000   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = 00000000   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = 00000000   A3 = 00000000   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = 00000000   A4 = 00000000   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = 00000000   A5 = 00000000   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = 00000000   A6 = 00000000   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = 00000000   A7 = 00330346   F7 = 7fff ffffffffffffffff  (         nan)
+PC = 00002e14   SR = 2700 T:0 I:7 SI -----
+FPSR = 00000000 ----
+                                FPCR =     0000 X RN
+  A7(MSP) = 00000000 ->A7(USP) = 00330346   A7(ISP) = 00000000
+VBR = 0x00000000
+SFC = 0 DFC 0
+SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at 00000000
+Aborted (core dumped)
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2091 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2091
new file mode 100644
index 00000000..215ce277
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2091
@@ -0,0 +1,3 @@
+m68k: virt: Pass the configured cpu type via bootinfo instead of the default 68040
+Additional information:
+
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2093 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2093
new file mode 100644
index 00000000..53cd67b3
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2093
@@ -0,0 +1,3 @@
+m68k: virt: Add command to virt-ctrl device to pause cpu until an interrupt happens
+Additional information:
+I'm working on how to implement this myself. Any hints would be great.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2164 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2164
new file mode 100644
index 00000000..768ce63b
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2164
@@ -0,0 +1,7 @@
+m68k: 68010 exception format is incorrect
+Description of problem:
+The exception format for the original 68000 is different to the 68010 and QEMU uses the incorrect format for 68010.
+Steps to reproduce:
+You need to have something that depends on the stack layout (i.e. nommu linux) to notice it.
+Additional information:
+I have posted a patch to fix it already: https://lists.gnu.org/archive/html/qemu-devel/2024-01/msg02800.html
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2165 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2165
new file mode 100644
index 00000000..27276236
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2165
@@ -0,0 +1,68 @@
+m68k: 68000 strict alignment requirements not emulated correctly
+Description of problem:
+Unaligned accesses should cause an address error on the 68000 but apparently currently don't.
+Steps to reproduce:
+1. Create a 68000 based QEMU machine to port u-boot/linux
+2. Get u-boot/linux working perfectly on your QEMU machine
+3. Copy kernel over to your real 68000 hardware
+4. Notice that the kernel doesn't work
+5. Spend a day adding inline assembly all over the kernel to work out where the real hardware is locking up
+6. Find that the issue is probably memmove() being called with an unaligned src pointer:
+
+C level..
+
+```
+Breakpoint 1, memmove (n=215, src=0x2059df <printk_shared_pbufs+215>, dest=0x2059ee <printk_shared_pbufs+230>) at ../arch/m68k/lib/memmove.c:152
+152                             *--sdest = *--ssrc;
+(gdb) bt
+#0  memmove (n=215, src=0x2059df <printk_shared_pbufs+215>, dest=0x2059ee <printk_shared_pbufs+230>) at ../arch/m68k/lib/memmove.c:152
+#1  memmove (dest=<optimized out>, src=<optimized out>, n=<optimized out>) at ../arch/m68k/lib/memmove.c:10
+#2  0x000265b6 in record_print_text (r=<optimized out>, syslog=<optimized out>, time=<optimized out>) at ../kernel/printk/printk.c:1472
+#3  0x00027be6 in printk_get_next_message (pmsg=<optimized out>, seq=<optimized out>, is_extended=<optimized out>, may_suppress=<optimized out>) at ../kernel/printk/printk.c:2952
+#4  0x00027e5a in console_emit_next_record (cookie=0, handover=0x1d9e37, con=0x1edf14 <early_con>) at ../kernel/printk/printk.c:3019
+#5  console_flush_all (do_cond_resched=false, next_seq=0x1d9e38, handover=0x1d9e37) at ../kernel/printk/printk.c:3118
+#6  0x00027fc8 in console_unlock () at ../kernel/printk/printk.c:3187
+#7  0x00028a04 in vprintk_emit (facility=0, level=<optimized out>, dev_info=0x0, fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n", args=0x1d9e98) at ../kernel/printk/printk.c:2359
+#8  0x00028a26 in vprintk_default (fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n", args=0x1d9e98) at ../kernel/printk/printk.c:2374
+#9  0x00028c22 in vprintk (fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n", args=0x1d9e98) at ../kernel/printk/printk_safe.c:45
+#10 0x0019d016 in _printk (fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n") at ../kernel/printk/printk.c:2384
+#11 0x0002857e in register_console (newcon=<optimized out>) at ../kernel/printk/printk.c:3693
+#12 0x001fbf1e in register_earlycon (match=<optimized out>, buf=0x0) at ../drivers/tty/serial/earlycon.c:161
+#13 setup_earlycon (buf=<optimized out>) at ../drivers/tty/serial/earlycon.c:212
+#14 0x001fbf72 in param_setup_earlycon (buf=0x2009e9 <tmp_cmdline+9> "mc68ez328,0xfffff900") at ../drivers/tty/serial/earlycon.c:244
+#15 0x001f1102 in do_early_param (param=0x2009e0 <tmp_cmdline> "earlycon", val=0x2009e9 <tmp_cmdline+9> "mc68ez328,0xfffff900", unused=0x1b96c6 "early options", arg=0x0)
+    at ../init/main.c:744
+#16 0x00017eac in parse_one (handle_unknown=<optimized out>, arg=<optimized out>, max_level=<optimized out>, min_level=<optimized out>, num_params=<optimized out>, params=<optimized out>, 
+    doing=0x1b96c6 "early options", val=0x2009e9 <tmp_cmdline+9> "mc68ez328,0xfffff900", param=0x2009e0 <tmp_cmdline> "earlycon") at ../kernel/params.c:154
+#17 parse_args (doing=<optimized out>, args=0x2009fe <tmp_cmdline+30> "console=ttyDB0 root=/dev/mmcblk0p2 rootfstype=squashfs rootwait", params=<optimized out>, num=<optimized out>, 
+    min_level=<optimized out>, max_level=<optimized out>, arg=<optimized out>, unknown=<optimized out>) at ../kernel/params.c:189
+#18 0x001f13ea in parse_early_options (cmdline=0x2009e0 <tmp_cmdline> "earlycon") at ../init/main.c:754
+#19 0x001f1420 in parse_early_param () at ../init/main.c:769
+#20 0x001f1570 in start_kernel () at ../init/main.c:908
+#21 0x000004b8 in _clear_bss () at ../arch/m68k/dt/head.S:95
+#22 0x00000000 in ?? ()
+```
+
+Asm level:
+
+```
+152                             *--sdest = *--ssrc;
+   0x0019bed8 <+324>:   movel %a1,%d2
+   0x0019beda <+326>:   subql #2,%d2
+   0x0019bedc <+328>:   movel %a2,%d1
+   0x0019bede <+330>:   subql #2,%d1
+=> 0x0019bee0 <+332>:   movew %a1@(-2),%a2@(-2)
+```
+
+This is a word store so needs to be aligned but a1 isn't aligned so we should get an address error:
+
+```
+(gdb) print/x $a1
+$3 = 0x2059df
+(gdb) print/x $a2
+$4 = 0x2059ee
+```
+
+
+7. Check QEMU source code to work out why it doesn't crash the cpu at the same place.
+8. Notice it doesn't seem to check the alignment.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2360 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2360
new file mode 100644
index 00000000..a67d1063
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2360
@@ -0,0 +1,30 @@
+qemu-system-m68k: double mmu fault
+Description of problem:
+Shutting down Mac OS 7.5.3 after boot from CD image results in a double MMU fault.
+qemu: fatal: DOUBLE MMU FAULT
+
+D0 = 00000008   A0 = 22152a78   F0 = 7fff ffffffffffffffff  (         nan)\
+D1 = 40810000   A1 = 0000c190   F1 = 7fff ffffffffffffffff  (         nan)\
+D2 = 00010490   A2 = 000207a0   F2 = 7fff ffffffffffffffff  (         nan)\
+D3 = 0002befe   A3 = a88879d0   F3 = 7fff ffffffffffffffff  (         nan)\
+D4 = db6d0000   A4 = 00041a86   F4 = 7fff ffffffffffffffff  (         nan)\
+D5 = 00000000   A5 = 39ec4080   F5 = 7fff ffffffffffffffff  (         nan)\
+D6 = 00000001   A6 = 00053178   F6 = 7fff ffffffffffffffff  (         nan)\
+D7 = 07b6d258   A7 = 00000004   F7 = 7fff ffffffffffffffff  (         nan)\
+
+PC = 97f87008   SR = 2210 T:0 I:2 SI X---- \
+FPSR = 00000000 ---- \
+FPCR =     0000 X RN \
+A7(MSP) = 00000000   A7(USP) = 00000000 ->A7(ISP) = 00000004 \
+VBR = 0x00000000 \
+SFC = 0 DFC 5 \
+SSW 00000505 TCR 0000c000 URP 00000000 SRP 07fffa00 \
+DTTR0/1: f900c060/807fc040 ITTR0/1: f900c060/807fc040 \
+MMUSR 00000000, fault at fffffffc \
+Steps to reproduce:
+1. Boot from CD image
+2. Choose Shut down from the Special menu
+Additional information:
+Reproducing requires a quadra 800 rom file.\
+A CD image (f.e. SYSTEM_7-5-3-RETAIL.ISO) can be obtained here: https://macintoshgarden.org/apps/macintosh-os-755 \
+Also see here: https://gitlab.com/qemu-project/qemu/-/issues/2249
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2468 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2468
new file mode 100644
index 00000000..b463f1c5
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2468
@@ -0,0 +1,33 @@
+m68k: movec to/from CAAR not emulated?
+Description of problem:
+
+Steps to reproduce:
+1. Start adding a machine for the Motorola MVME147 VME module
+2. Step through the standard ROM for this board (147BUG)
+3. Step until `ff823bf0 4e 7b 18 02     movec      D1,CAAR`
+4. Watch QEMU show a fatal error for an unimplemented control register:
+
+```
+QEMU 9.0.50 monitor - type 'help' for more information
+(qemu) qemu: fatal: Unimplemented control register write 0x802 = 0xffffffff
+
+D0 = ffffffff   A0 = fffe0000   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = ffffffff   A1 = 00000000   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = ffff271f   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = ffffffff   A3 = 00000000   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = ffffffff   A4 = 00000000   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = ffffffff   A5 = 00000400   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = ffffffff   A6 = 00000000   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = ffffffff   A7 = 000037dc   F7 = 7fff ffffffffffffffff  (         nan)
+PC = ff823bf0   SR = 2714 T:0 I:7 SI X-Z--
+FPSR = 00000000 ---- 
+                                FPCR =     0000 X RN 
+  A7(MSP) = 00000000   A7(USP) = ffffffff ->A7(ISP) = 000037dc
+VBR = 0xffffffff
+SFC = 0 DFC 0
+SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at 00000000
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2479 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2479
new file mode 100644
index 00000000..47e46db8
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2479
@@ -0,0 +1,30 @@
+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.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2483 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2483
new file mode 100644
index 00000000..df22f6af
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2483
@@ -0,0 +1,20 @@
+m68k: jsr (sp) doesn't work as expected
+Description of problem:
+Consider the following code (disassembly from ghidra). This copies the current `SP` to `A1` then copies 0x68 bytes from the address pointed at by `A0` to the address pointed at by `A1` with increment. This should end up with a copy of some bytes and `SP` pointing at the first.
+
+```
+        ff8241e6 22 4f           movea.l    SP,A1
+        ff8241e8 70 68           moveq      #0x68,D0
+                             LAB_ff8241ea                                    XREF[1]:     ff8241ee(j)  
+        ff8241ea 12 d8           move.b     (A0)+,(A1)+
+        ff8241ec 53 80           subq.l     #0x1,D0
+        ff8241ee 66 fa           bne.b      LAB_ff8241ea
+        ff8241f0 4e 97           jsr        (SP)
+```
+
+`SP` is `0x3bfc` at the `jsr` so we'd expect to jump to `0x3bfc` and put the address to return to at `0x3bf8` so the `jsr` can return I think?
+What currently happens in QEMU is the return address is put at `0xb3f8` and `PC` also becomes `0x3bf8` and the return address starts being executed as code and things go off the rails.
+
+Forgive the screenshot but this is what it looks like with GDB connected. Dumping the memory where the `PC` is shows that the return address is actually there and we can see there is garbage before the instructions it should be executing.
+
+![image](/uploads/d5fd6f455e5a433735d8fae2be3d53ee/image.png){width=289 height=759}
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2488 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2488
new file mode 100644
index 00000000..1234227e
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2488
@@ -0,0 +1,65 @@
+m68k: 68030 (?): fmove.p doesn't work (6888[1|2] emulation isn't implemented??)
+Description of problem:
+The following code should be executing a move to the fpu and then a move from it and then branching.
+
+```
+        ff813590 f2 10 4f 00     fmove.p    (A0),FP6
+        ff813594 f2 11 6f 7f     fmove.p    FP6,(A1) {#0x7f}
+        ff813598 61 00 fe 52     bsr.w      SUB_ff8133ec
+```
+
+However, hitting the instruction at `0xff813590` causes the `PC` to go off into the weeds and then the emulation gets stuck and never proceeds.
+
+Before executing the instruction the CPU state looks like this
+
+```
+(qemu) info registers
+
+CPU#0
+D0 = ffffffff   A0 = ff813584   F0 = c004 cc00000000000000  (         -51)
+D1 = 0000ffff   A1 = 0000335e   F1 = c00d a866000000000000  (      -21555)
+D2 = 00000002   A2 = ff8138a2   F2 = 401b 91a2b3c000000000  (  3.0542e+08)
+D3 = 00000003   A3 = ff824008   F3 = 3fb4 ab3c4d0000000000  ( 3.54107e-23)
+D4 = 00000004   A4 = ff81dbb6   F4 = 3d12 919a22ab33bc4000  (3.84141e-226)
+D5 = 00000000   A5 = 00000400   F5 = 1020 8060708090a0b0c0  (           0)
+D6 = 0000000c   A6 = 00003790   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = 00000000   A7 = 0000316e   F7 = 7fff ffffffffffffffff  (         nan)
+PC = ff813590   SR = 2708 T:0 I:7 SI -N---
+FPSR = 00000000 ---- 
+                                FPCR =     0000 X RN 
+  A7(MSP) = 00000000   A7(USP) = 80000000 ->A7(ISP) = 00003796
+VBR = 0x0000338e
+SFC = 3 DFC 0
+SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at 00000000
+```
+
+After single stepping:
+
+```
+(qemu) info registers
+
+CPU#0
+D0 = ffffffff   A0 = ff813584   F0 = c004 cc00000000000000  (         -51)
+D1 = 0000ffff   A1 = 0000335e   F1 = c00d a866000000000000  (      -21555)
+D2 = 00000002   A2 = ff8138a2   F2 = 401b 91a2b3c000000000  (  3.0542e+08)
+D3 = 00000003   A3 = ff824008   F3 = 3fb4 ab3c4d0000000000  ( 3.54107e-23)
+D4 = 00000004   A4 = ff81dbb6   F4 = 3d12 919a22ab33bc4000  (3.84141e-226)
+D5 = 00000000   A5 = 00000400   F5 = 1020 8060708090a0b0c0  (           0)
+D6 = 0000000c   A6 = 00003790   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = 00000000   A7 = 00003166   F7 = 7fff ffffffffffffffff  (         nan)
+PC = ff8138a2   SR = 2708 T:0 I:7 SI -N---
+FPSR = 00000000 ---- 
+                                FPCR =     0000 X RN 
+  A7(MSP) = 00000000   A7(USP) = 80000000 ->A7(ISP) = 0000316e
+VBR = 0x0000338e
+SFC = 3 DFC 0
+SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at 00000000
+```
+
+With this code the `VBR` doesn't point at an actual vector table from what I can tell and it is pointing at some memory that contains `0xff8138a2` so I guess it hits the instruction, the FPU isn't implemented so it tries to do an `F-line exception` instead but the vector table doesn't actually contain a handler and it's trying to execute garbage that causes the lock up.
+
+Basically, I guess I need to implement the 6888[1|2] for this code to work.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2497 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2497
new file mode 100644
index 00000000..edf8d6ab
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2497
@@ -0,0 +1,3 @@
+m68k: fpu: FPIAR register is not implemented
+Description of problem:
+QEMU doesn't currently implement the `FPIAR` register in the FPU which is fine in most cases but test code (like that in 147bug) that is testing if instructions like `fmove` are working correctly by writing to the register and reading it back don't get the value written when reading it back and detect a failure.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2498 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2498
new file mode 100644
index 00000000..c62e8062
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2498
@@ -0,0 +1,51 @@
+m68k: fpu: fmovem with multiple control registers has incorrect in memory order
+Description of problem:
+It looks like the order of reading/writing registers is currently incorrect for `fmovem` with multiple fpu control registers.
+
+According to the manual:
+
+```
+The
+registers are always moved in the same order, regardless of the addressing mode
+used; the floating-point control register is moved first, followed by the floating-point
+status register, and the floating-point instruction address register is moved last.
+```
+
+Current QEMU reads/writes them in the reverse order which is fine for most things but the test cases in 147bug compare against data that is in its binary and expects the data generated in memory by the CPU to match what is in it's binary.
+
+Maybe something like this is needed:
+
+``` diff
+commit 466e8ead0115b6535e89aa2715f171112444b294 (HEAD -> m68kdt)
+Author: Daniel Palmer <daniel@thingy.jp>
+Date:   Tue Aug 13 09:52:54 2024 +0900
+
+    fix fmovem ordering
+
+diff --git a/target/m68k/translate.c b/target/m68k/translate.c
+index 92dc9d8563..64ff2df06e 100644
+--- a/target/m68k/translate.c
++++ b/target/m68k/translate.c
+@@ -4924,8 +4924,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s,
+      */
+ 
+     if (is_write && mode == 4) {
+-        for (i = 2; i >= 0; i--, mask >>= 1) {
+-            if (mask & 1) {
++        for (i = 2; i >= 0; i--, mask <<= 1) {
++            if (mask & 0b100) {
+                 gen_qemu_store_fcr(s, addr, 1 << i);
+                 if (mask != 1) {
+                     tcg_gen_subi_i32(addr, addr, opsize_bytes(OS_LONG));
+@@ -4934,8 +4934,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s,
+        }
+        tcg_gen_mov_i32(AREG(insn, 0), addr);
+     } else {
+-        for (i = 0; i < 3; i++, mask >>= 1) {
+-            if (mask & 1) {
++        for (i = 2; i >= 0; i--, mask <<= 1) {
++            if (mask & 0b100) {
+                 if (is_write) {
+                     gen_qemu_store_fcr(s, addr, 1 << i);
+                 } else {
+```
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2499 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2499
new file mode 100644
index 00000000..19ff522d
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2499
@@ -0,0 +1,30 @@
+m68k: fpu: fsave/frestore should be enabled for 68020/68030
+Description of problem:
+valid 68020/68030 code can use `fsave`/`frestore` instructions to save/restore the state of an external 68881/68882 but currently QEMU only allows these instructions on 68040 and everyone else gets an f-line exception.
+
+I guess something like this to allow frestore/fsave. m68k programmers reference manual says they are 68881/68882/68040 and there don's seem to be any differences.
+
+``` diff
+diff --git a/target/m68k/translate.c b/target/m68k/translate.c
+index d5d2322329..92dc9d8563 100644
+--- a/target/m68k/translate.c
++++ b/target/m68k/translate.c
+@@ -5455,7 +5455,7 @@ DISAS_INSN(frestore)
+         gen_exception(s, s->base.pc_next, EXCP_PRIVILEGE);
+         return;
+     }
+-    if (m68k_feature(s->env, M68K_FEATURE_M68040)) {
++    if (m68k_feature(s->env, M68K_FEATURE_FPU)) {
+         SRC_EA(env, addr, OS_LONG, 0, NULL);
+         /* FIXME: check the state frame */
+     } else {
+@@ -5472,7 +5472,7 @@ DISAS_INSN(fsave)
+         return;
+     }
+ 
+-    if (m68k_feature(s->env, M68K_FEATURE_M68040)) {
++    if (m68k_feature(s->env, M68K_FEATURE_FPU)) {
+         /* always write IDLE */
+         TCGv idle = tcg_constant_i32(0x41000000);
+         DEST_EA(env, insn, OS_LONG, idle, NULL);
+```
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2500 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2500
new file mode 100644
index 00000000..4ac7610a
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2500
@@ -0,0 +1,4 @@
+m68k: mmu: 68030 mmu instructions are missing
+Description of problem:
+The 68030 has some mmu instructions like `pmove` that are only valid for the 68030 (and maybe the external mmu for the 68020??).
+QEMU doesn't currently implement `pmove` and the encoding of `pmove` seems to be the same as an f-line instruction that should generate an f-line exception on everything except the 68030 so currently an f-line exception happens instead of the intended load/store to the mmu.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2507 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2507
new file mode 100644
index 00000000..948a843e
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2507
@@ -0,0 +1,13 @@
+m68k: fpu: frestore with NULL state should reset FPU state
+Description of problem:
+According to the PRM:
+
+```
+Floating-Point Status Register: Cleared if the state size is NULL; otherwise, not affected. 
+```
+
+But this does not currently happen.
+Steps to reproduce:
+1. set a value in fpsr
+2. do frestore with state size zero
+3. read back fpsr and notice it isn't zero.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2675 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2675
new file mode 100644
index 00000000..d47843ac
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2675
@@ -0,0 +1,11 @@
+q800 machine is broken when compiling with --enable-cfi
+Description of problem:
+When compiling QEMU that is configured like this:
+```
+ .../configure --target-list=m68k-softmmu --enable-cfi --cc=clang
+```
+the q800 machine crashes with an illegal exception on the host very early, somewhere during q800_machine_init()
+Steps to reproduce:
+1. .../configure --target-list=m68k-softmmu --enable-cfi --cc=clang
+2. make qemu-system-m68k
+3. ./qemu-system-m68k -M q800
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2794 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2794
new file mode 100644
index 00000000..b0d82664
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2794
@@ -0,0 +1,49 @@
+qemu-system-m68k virt machine doesn't boot Linux kernels using 68020, 68030 and 68060 CPUs
+Description of problem:
+QEMU doesn't seem to be able to start Linux kernels using a CPU other than a 68040 (which does work fine)
+
+To rule out host issues, the issue is reproductible on Debian Unstable amd64 (with version QEMU emulator version 9.2.0)(Debian 1:9.2.0+ds-5))
+
+To rule out cross-compilation issues, the kernel has been rebuild inside a virt machine (using a 68040 CPU), running Debian Unstable 
+
+Each CPU model below gets stuck early before kernel boot during the ABCGHIJK thing. The Kernel doesn't seem to boot and QEMU process eat 100% of a CPU physical core
+
+**68020**
+```
+qemu-system-m68k -M virt -cpu m68060 -m 1G -nographic -kernel /home/demik/tmp/vmlinux
+ABCGH
+```
+
+**68030**
+```
+qemu-system-m68k -M virt -cpu m68060 -m 1G -nographic -kernel /home/demik/tmp/vmlinux
+ABC
+```
+
+**68060**
+```
+qemu-system-m68k -M virt -cpu m68060 -m 1G -nographic -kernel /home/demik/tmp/vmlinux
+ABC
+```
+Steps to reproduce:
+1. build a kernel with 68020/030/060 support (using virt_defconfig as base)
+2. start QEMU with the command line above
+Additional information:
+68020 is understandable as it may need some sort of 68851 emulation.
+
+Relevant Kernel config Processor configuration:
+```
+#
+# Processor Type
+#
+CONFIG_M68KCLASSIC=y
+# CONFIG_COLDFIRE is not set
+CONFIG_M68020=y
+CONFIG_M68030=y
+CONFIG_M68040=y
+CONFIG_M68060=y
+```
+
+This may be related to the following issues (but I don't have the skillset to confirm that)
+- https://gitlab.com/qemu-project/qemu/-/issues/2091
+- https://gitlab.com/qemu-project/qemu/-/issues/2500
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2807 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2807
new file mode 100644
index 00000000..b68aba30
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2807
@@ -0,0 +1,31 @@
+DOUBLE MMU FAULT when running -M virt in qemu-system-m68k
+Description of problem:
+When running qemu-system-m68k with the -M virt machine type, a DOUBLE MMU FAULT occurs immediately upon startup, even without any BIOS, disk image, or additional configuration.
+Steps to reproduce:
+1. qemu-system-m68k -M virt -m 4M -serial stdio
+
+QEMU crashes immediately with the following output:
+```
+qemu: fatal: DOUBLE MMU FAULT
+D0 = 00000000   A0 = 00000000   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = 00000000   A1 = 00000000   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = 00000000   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = 00000000   A3 = 00000000   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = 00000000   A4 = 00000000   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = 00000000   A5 = 00000000   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = 00000000   A6 = 00000000   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = 00000000   A7 = 00000000   F7 = 7fff ffffffffffffffff  (         nan)
+PC = 00400000   SR = 2704 T:0 I:7 SI --Z--
+FPSR = 00000000 ----
+                                FPCR =     0000 X RN
+  A7(MSP) = 00000000   A7(USP) = 00000000 ->A7(ISP) = 00000000
+VBR = 0x00000000
+SFC = 0 DFC 0
+SSW 00000105 TCR 00000000 URP 00000000 SRP 00000000
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at fffffffc
+```
+Additional information:
+The issue seems to be related to incorrect memory initialization, causing a fault at address fffffffc.
+The PC = 00400000 suggests that QEMU is jumping to an invalid address early in the boot process.
+The fact that the fault is consistent across different configurations (q800, next-cube, etc) points to a possible regression or incomplete memory initialization in the virt machine.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2812 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2812
new file mode 100644
index 00000000..d0b1a425
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2812
@@ -0,0 +1 @@
+Crash initializing audio device
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/442 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/442
new file mode 100644
index 00000000..c54fb91d
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/442
@@ -0,0 +1 @@
+Firebird crashes on qemu-m68k-user with pthread_mutex_init error
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/710 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/710
new file mode 100644
index 00000000..636302c0
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/710
@@ -0,0 +1 @@
+maybe-uninitialized warning building target/m68k/ with -O3
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/756 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/756
new file mode 100644
index 00000000..ac383d4b
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/756
@@ -0,0 +1 @@
+qemu-system-m68k -M q800 -bios /dev/null segfaults
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/957 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/957
new file mode 100644
index 00000000..3f0733cf
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/957
@@ -0,0 +1,71 @@
+qemu-m68k: python runtime failures, "The futex facility returned an unexpected error code."
+Description of problem:
+The python interpreter (both Python 3.9 and Python 3.10) crashes during a rebuild of Python itself (fairly reproducible but not always at the same point of the build; using MAKEOPTS=-j1 or running under high system load decreases the probability, as does using the qemu -systrace switch). The output is
+```
+The futex facility returned an unexpected error code.
+```
+
+Digging into glibc sources, this error together with an abort occurs when the return value of a futex call is not in a short list of allowed values, see ``nptl/futex-internal.c`` and ``sysdeps/nptl/futex-internal.h``.
+
+Running qemu with QEMU_STRACE=1 decreases the probability of the error greatly, but after some attempts I was able to get a log. Several threads seem to write at the same time, leading to rather garbled output, but my interpretation is an error value of "Invalid argument".
+
+
+```
+116876 get_thread_area(0x00000001) = 989882672
+116876 116876 get_thread_area(0x00000001)get_thread_area(0x00000018) = 989882672
+ = 1065219744
+116876 get_thread_area(0x00000000) = 1065219744
+116876 futex(0x3f5003fa,FUTEX_PRIVATE_FLAG|FUTEX_WAIT116876 ,2,116876 NULL,0x3fffda10,get_thread_area(0xffffffff) = 1065219744
+futex(0x3f5003fa,1073732112)FUTEX_PRIVATE_FLAG|FUTEX_WAIT = ,2,NULL,-1 errno=22 (Invalid argument)116876 get_thread_area(0x00000000)
+ = 1065219744
+0x3fffda10,116876 get_thread_area(0x00000000)1073732112 = )1065219744
+116876 futex(0x3f7d4c34,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL, = 0)-1 errno=22 (Invalid argument)
+ = 0
+ = 116876 get_thread_area(0x3f7d4c34)1 = 
+116876 get_thread_area(0x00000000) = 1065219744
+926968112
+116876 get_thread_area(0x00000016) = 926968112
+116876 get_thread_area(0x00000000) = 1065219744
+116876 get_thread_area(0x00000000) = 1065219744
+116876 get_thread_area(0x00000001)116876  = futex(116876 0x3f5003fa,get_thread_area(0x00000000)FUTEX_PRIVATE_FLAG| = 926968112
+116876 get_thread_area(0x00000000) = 926968112FUTEX_WAKE
+,1,116876 NULL,0x3fffda10,get_thread_area(0x00000000) = 926968112
+1065219744
+116876 get_thread_area(0x00000001)116876  = 1065219744
+1073732112) = 116876 -1 errno=22 (Invalid argument)
+futex(0x3ba005fc,FUTEX_PRIVATE_FLAG|FUTEX_CLOCK_REALTIME|FUTEX_WAIT_BITSET,0,NULL,NULL,get_thread_area(0x00000000)0 = 926968112)
+116876 get_thread_area(0x00000000) = 926968112
+116876 futex(0x3f7d4c38,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,0x40007bf8,1073773560) = 0
+116876 futex(0x40053a8c,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1
+ = 0
+116876 get_thread_area(0x40053a8c) = 885025072
+116876 get_thread_area(0x00000001) = 885025072
+116876 get_thread_area(0x00b4b456) = 885025072
+116876 get_thread_area(0x00000000) = 885025072
+116876 get_thread_area(0x00000000) = 885025072
+116876 Unknown syscall 403
+116876 get_thread_area(0x00000000) = 885025072
+116876 get_thread_area(0x00003baa) = 885025072
+116876 get_thread_area(0x00003b01) = 885025072
+116876 get_thread_area(0x00003b01) = 885025072
+116876 116876 futex(get_thread_area(0x00b4b456)0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAIT_BITSET,0,0x34bfe62c,NULL,0) = 926968112
+116876 get_thread_area(0x00000018) = 926968112
+116876 get_thread_area(0x3ed5b9c8) = 926968112
+116876 get_thread_area(0x00000000) = 926968112
+116876 get_thread_area(0x00000000) = 926968112
+116876 get_thread_area(0x00000000) = 926968112
+116876 get_thread_area(0x00000000) = 926968112
+116876 get_thread_area(0x00000000) = 926968112
+116876 futex(0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1
+116876 get_thread_area(0x00000000) = 926968112
+116876 get_thread_area(0x00000001) = 926968112
+116876 get_thread_area(0x0000000f) = 926968112116876  = 0
+
+116876 get_thread_area(0x00000001) = 926968112
+116876 get_thread_area(0x00000001) = 926968112
+116876 get_thread_area(0x00000001)writev(2,0x3affed88,0x1) = 926968112
+The futex facility returned an unexpected error code.
+116876 get_thread_area(0x3f7d4c30) = 885025072
+```
+
+Advice on how to do further debuggging is appreciated.
diff --git a/gitlab/issues_text/target_microblaze/host_missing/accel_TCG/2229 b/gitlab/issues_text/target_microblaze/host_missing/accel_TCG/2229
new file mode 100644
index 00000000..c6b709a6
--- /dev/null
+++ b/gitlab/issues_text/target_microblaze/host_missing/accel_TCG/2229
@@ -0,0 +1,5 @@
+tcg/tcg.c:813:tcg_register_thread: assertion failed: (n < tcg_max_ctxs)
+Description of problem:
+When running qemu-system-microblazeel with the xlnx-zynqmp-pmu machine and an additional xlnx-zynqmp-pmu-soc device, TCG crashes via an assertion.
+Steps to reproduce:
+Run: `` ./qemu-system-microblazeel -machine xlnx-zynqmp-pmu -device xlnx-zynqmp-pmu-soc ``
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_TCG/1126 b/gitlab/issues_text/target_mips/host_missing/accel_TCG/1126
new file mode 100644
index 00000000..5aaac690
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_TCG/1126
@@ -0,0 +1,8 @@
+qemu-system-mipsel freezes for nanoMIPS in the semihosting mode
+Description of problem:
+In the current git master branch (SHA: 7b17a1a8) there is a problem with qemu-system-mipsel when trying to execute a simple hello.elf program in the semihosting mode for the nanoMIPS architecture. I.e. after executing the following command the terminal freezes: 
+ ```
+   $ ./qemu-system-mipsel -cpu I7200 -semihosting -nographic -kernel hello.elf
+ ```
+hello.elf file is generated using the nanoMIPS GNU Toolchain (https://github.com/MediaTek-Labs/nanomips-gnu-toolchain/releases).
+The program regularly terminates with QEMU emulator version 6.0.1.
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_TCG/2193 b/gitlab/issues_text/target_mips/host_missing/accel_TCG/2193
new file mode 100644
index 00000000..9ba7d2b3
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_TCG/2193
@@ -0,0 +1,30 @@
+qemu-system-mips64el 70 times slower than qemu -ppc64, -riscv64, -s390x
+Description of problem:
+I installed Debian 12 inside a `qemu-system-mips64el` virtual machine. The performances are awfully slow, roughly 70 times slower than other qemu targets on the same host, namely ppc64, riscv64, s390x.
+
+The idea is to recompile and test an open source project on various platforms.
+
+Using a command such as `time make path/to/bin/file.o`, I compiled one single source file on the host and within qemu for various targets. The same source file, inside the same project, is used in all cases.
+
+The results are shown below (the "x" number between parentheses is the time factor compared to the compilation on the host).
+
+- Host (native): 0m1.316s
+- qemu-system-ppc64: 0m31.622s (x24)
+- qemu-system-riscv64: 0m40.691s (x31)
+- qemu-system-s390x: 0m43.459s (x33)
+- qemu-system-mips64el: 48m33.587s (x2214)
+
+The compilation of the same source is 24 to 33 times slower on the first three emulated targets, compared to the same compilation on the host, which is understandable. However, the same compilation on the mips64el target is 2214 time slower than the host, roughly 70 times slower than other emulated targets.
+
+Why do we have such a tremendous difference between qemu mips64el and other targets?
+Additional information:
+For reference, here are the other qemu to boot the other targets. Guest OS are Debian 12 or Ubuntu 22.
+```
+qemu-system-ppc64 -smp 8 -m 8192 -nographic ...
+qemu-system-riscv64 -machine virt -smp 8 -m 8192 -nographic ...
+qemu-system-s390x -machine s390-ccw-virtio -cpu max,zpci=on -smp 8 -m 8192 -nographic ...
+```
+
+The other targets use `-smp 8` while qemu-system-mips64el does not support smp. However, the test compiles one single source file and does not (or marginally) use more than one CPU.
+
+Arguably, each compilation addresses a different target, uses a different backend, and the compilation time is not necessarily identical. OK, but 70 times slower seems way too much for this.
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_TCG/244 b/gitlab/issues_text/target_mips/host_missing/accel_TCG/244
new file mode 100644
index 00000000..943aea12
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_TCG/244
@@ -0,0 +1 @@
+MIPS MT dvpe does not regard VPEConf0.MVP
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_TCG/2470 b/gitlab/issues_text/target_mips/host_missing/accel_TCG/2470
new file mode 100644
index 00000000..7b640d03
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_TCG/2470
@@ -0,0 +1,31 @@
+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/gitlab/issues_text/target_mips/host_missing/accel_TCG/422 b/gitlab/issues_text/target_mips/host_missing/accel_TCG/422
new file mode 100644
index 00000000..59406723
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_TCG/422
@@ -0,0 +1 @@
+Unable to execute MIPS MSA code due to illegal instruction
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_TCG/94 b/gitlab/issues_text/target_mips/host_missing/accel_TCG/94
new file mode 100644
index 00000000..96c08c48
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_TCG/94
@@ -0,0 +1 @@
+MIPS r4k "TLB modified exception" generated for TLB entries that are not visible to the TLBP instruction
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/115 b/gitlab/issues_text/target_mips/host_missing/accel_missing/115
new file mode 100644
index 00000000..b9176977
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/115
@@ -0,0 +1 @@
+shmat fails on 32-to-64 setup
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1238 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1238
new file mode 100644
index 00000000..ca4b5702
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1238
@@ -0,0 +1,119 @@
+qemu-mipsn32el and qemu-mipsn32 problems with coreutils-9*, fadvise64 or fallocate related?
+Description of problem:
+- Recently about 15 of the ca. 250 packages in our system set fail during `make install`. A typical error is
+> `/usr/bin/install: error deallocating '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin/troff': Invalid argument`
+- Given the timing and the involved binaries (most of the times `install`, but also `cp`), I suspect this was triggered by coreutils-9
+- The problem seems to only occur on ext4 (our release engineering box), but not on btrfs (my home development box)
+- The problem seems to be limited to n32 (both big and little endian)
+
+Here's a run with strace functionality enabled:
+
+```
+dilfridge-mips64el-n32 /var/tmp/portage/sys-apps/groff-1.22.4/work/groff-1.22.4 # /usr/bin/qemu-mipsn32el -strace /usr/bin/install troff '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin'
+3216 brk(NULL) = 0x40032000
+3216 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f7ba000
+3216 uname(0x3fffebb0) = 0
+3216 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory)
+3216 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
+3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe280) = 0
+3216 mmap(NULL,11294,PROT_READ,MAP_PRIVATE,3,0) = 0x3f7b7000
+3216 close(3) = 0
+3216 openat(AT_FDCWD,"/lib32/libacl.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
+3216 read(3,0x3fffe4c4,512) = 512
+3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe220) = 0
+3216 mmap(NULL,197008,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f786000
+3216 mmap(0x3f790000,131472,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f790000
+3216 munmap(0x3f786000,40960) = 0
+3216 munmap(0x3f7b1000,20880) = 0
+3216 mprotect(0x3f797000,98304,PROT_NONE) = 0
+3216 mmap(0x3f7af000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x3f7af000
+3216 close(3) = 0
+3216 openat(AT_FDCWD,"/lib32/libattr.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
+3216 read(3,0x3fffe4b4,512) = 512
+3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe210) = 0
+3216 mmap(NULL,196864,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f75f000
+3216 mmap(0x3f760000,131328,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f760000
+3216 munmap(0x3f75f000,4096) = 0
+3216 munmap(0x3f781000,57600) = 0
+3216 mprotect(0x3f764000,110592,PROT_NONE) = 0
+3216 mmap(0x3f77f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x3f77f000
+3216 close(3) = 0
+3216 openat(AT_FDCWD,"/lib32/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
+3216 read(3,0x3fffe4a4,512) = 512
+3216 pread64(3,1073734640,32,34504,1065377824,0) = 32
+3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe200) = 0
+3216 mmap(NULL,2056864,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f569000
+3216 mmap(0x3f570000,1991328,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f570000
+3216 munmap(0x3f569000,28672) = 0
+3216 munmap(0x3f757000,33440) = 0
+3216 mprotect(0x3f73c000,61440,PROT_NONE) = 0
+3216 mmap(0x3f74b000,28672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1cb000) = 0x3f74b000
+3216 mmap(0x3f752000,17056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x3f752000
+3216 close(3) = 0
+3216 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f569000
+3216 set_thread_area(0x3f570580) = 0
+3216 set_tid_address(1062637704,1065348616,1065377824,0,-1,0) = 3216
+3216 set_robust_list(1062637712,12,1065377824,0,-1,0) = -1 errno=89 (Function not implemented)
+3216 Unknown syscall 6331
+3216 mprotect(0x3f74b000,16384,PROT_READ) = 0
+3216 mprotect(0x3f77f000,4096,PROT_READ) = 0
+3216 mprotect(0x3f7af000,4096,PROT_READ) = 0
+3216 mprotect(0x4002e000,4096,PROT_READ) = 0
+3216 mprotect(0x3f7fc000,8192,PROT_READ) = 0
+3216 getrlimit(3,1073737152,1064664656,1062638996,1064337736,1064664656) = 0
+3216 munmap(0x3f7b7000,11294) = 0
+3216 getrandom(1064649956,4,1,1064337736,2130640639,1077952576) = 4
+3216 brk(NULL) = 0x40032000
+3216 brk(0x40053000) = 0x40053000
+3216 brk(0x40054000) = 0x40054000
+3216 openat(AT_FDCWD,"/usr/lib/locale/locale-archive",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
+3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffed58) = 0
+3216 mmap(NULL,2097152,PROT_READ,MAP_PRIVATE,3,0) = 0x3f369000
+3216 close(3) = 0
+3216 geteuid() = 0
+3216 umask(0) = 18
+3216 openat(AT_FDCWD,"/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin",O_RDONLY|O_DIRECTORY|O_LARGEFILE|O_PATH) = 3
+3216 statx(AT_FDCWD,"troff",AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0
+3216 statx(3,"troff",AT_NO_AUTOMOUNT|AT_SYMLINK_NOFOLLOW,STATX_BASIC_STATS,0x3fffe998) = 0
+3216 unlinkat(3,"troff",0) = 0
+3216 openat(AT_FDCWD,"troff",O_RDONLY|O_LARGEFILE) = 4
+3216 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0
+3216 openat(3,"troff",O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE,0600) = 5
+3216 ioctl(5,FICLONE,4) = -1 errno=122 (Operation not supported)
+3216 statx(5,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0
+3216 lseek(4,0,SEEK_DATA) = 0
+3216 fadvise64(4,0,0,2,1664557525,0) = -1 errno=22 (Invalid argument)
+3216 lseek(4,0,SEEK_HOLE) = 716800
+3216 lseek(4,0,SEEK_SET) = 0
+3216 mmap(NULL,139264,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f347000
+3216 read(4,0x3f348000,131072) = 131072
+3216 write(5,0x3f348000,122880) = 122880
+3216 read(4,0x3f348000,131072) = 131072
+3216 lseek(5,12288,SEEK_CUR) = 135168
+3216 fallocate(5,FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE,122880,4290510848) = -1 errno=22 (Invalid argument)
+3216 openat(AT_FDCWD,"/usr/share/locale/locale.alias",O_RDONLY|O_CLOEXEC) = 6
+3216 statx(6,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe2c8) = 0
+3216 read(6,0x400333a0,4096) = 2998
+3216 read(6,0x400333a0,4096) = 0
+3216 close(6) = 0
+3216 openat(AT_FDCWD,"/usr/share/locale/C.UTF-8/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory)
+3216 openat(AT_FDCWD,"/usr/share/locale/C.utf8/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory)
+3216 openat(AT_FDCWD,"/usr/share/locale/C/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory)
+3216 write(2,0x3fffc888,18)/usr/bin/install:  = 18
+3216 write(2,0x3fffc8b8,79)error deallocating '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin/troff' = 79
+3216 openat(AT_FDCWD,"/usr/share/locale/C.UTF-8/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory)
+3216 openat(AT_FDCWD,"/usr/share/locale/C.utf8/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory)
+3216 openat(AT_FDCWD,"/usr/share/locale/C/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory)
+3216 write(2,0x3fffc428,18): Invalid argument = 18
+3216 write(2,0x3fffc858,1)
+ = 1
+3216 close(5) = 0
+3216 close(4) = 0
+3216 munmap(0x3f347000,139264) = 0
+3216 lseek(0,0,SEEK_CUR) = -1 errno=29 (Illegal seek)
+3216 close(0) = 0
+3216 close(1) = 0
+3216 close(2)dilfridge-mips64el-n32 /var/tmp/portage/sys-apps/groff-1.22.4/work/groff-1.22.4 # 
+```
+
+More information and debugging on request. Any advice is appreciated.
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1251 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1251
new file mode 100644
index 00000000..fbed7e7d
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1251
@@ -0,0 +1,15 @@
+Octeon Instruction BBIT Bug
+Steps to reproduce:
+1. Compile 64bit binary for Octeon with Octeon instructions    
+`mips64-octeon-linux-gnu-gcc -o hello hello.c`
+2. Run with `qemu-mips64`    
+`qemu-mips64 -cpu Octeon68XX hello`
+3. Get the output below:
+```
+qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+Illegal instruction
+```
+Additional information:
+I have a patch for this that I will be submitting to trivial-patches. This is not enough to emulate Octeon specific binaries alone. For small binaries mapping the `CVMSEG_LM = 0xFFFFFFFFFFFF8000 - 0xFFFFFFFFFFFF9FFF` to empty RAM and using this patch is enough. There are additional support issues for `N32` binaries that will require a separate issue.
+
+[hello](/uploads/d8b5e631508fd232b4a7b3a40f7e08f6/hello)
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1531 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1531
new file mode 100644
index 00000000..17aeb6b1
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1531
@@ -0,0 +1,15 @@
+MIPSr6+MSA emulation is broken in QEMU 6.2.0 (Ubuntu 22.04 LTS) and 7.0.0
+Description of problem:
+Many tests (8,11,12,13,15,19,23,30,31,36) are failing due to QEMU emulation problem.
+Steps to reproduce:
+1. Download the source code from https://github.com/VectorChief/UniSIMD-assembler (master or v1.1.0c)
+2. Change to project's test directory and build the binary for MIPS using cross-compiler (see simd_make_m64.mk)
+3. Run the binary with QEMU linux-user mode: qemu-mips64el -cpu I6400 simd_test.m64f32Lr6 -c 1 | tee qemu64
+4. Check the output text file qemu64 (with pluma or any other text editor) to see the error printouts
+Additional information:
+The pre-built binary and its output file are attached as test.tar.gz
+[test.tar.gz](/uploads/7a54ba10919a1b221dd8ea0e8c02c064/test.tar.gz)
+
+Please note, that standalone cross-compiler for MIPS downloaded from the site
+(Codescape.GNU.Tools.Package.2020.06-01.for.MIPS.MTI.Linux.CentOS-6.x86_64.tar.gz)
+comes with its own version of QEMU 4.1.0 which masks the system's QEMU when added to the PATH.
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1624 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1624
new file mode 100644
index 00000000..8446e0cd
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1624
@@ -0,0 +1,23 @@
+8.0.0: Crash when emulating MIPS executable
+Description of problem:
+A change to QEMU introduced within the 6.0.0 development cycle causes MIPS executable to crash.
+Similar problem occurred within the same time-frame for Aarch64 executables, but was fixed.
+Patches in QEMU causing both Aarch64 and MIPS occurrences are identified and attached below.
+Steps to reproduce:
+1. Download attached core_test.zip archive.
+2. Run pre-built MIPS executable with QEMU.
+3. Observe the crash somewhere in tdelete.
+4. Source for the test is here: https://github.com/VectorChief/QuadRay-engine
+5. The binaries were built with GCC 9.4 cross-compilers using slightly modified makefiles (-ggdb3) for gdb-multiarch
+6. Building on Ubuntu 22.04 and Ubuntu 23.04 also reproduces the problem, so it's not OS or compiler specific.
+Additional information:
+Archive with pre-built binaries: [core_test.zip](/uploads/529833c6f83aeec253df647a94868f8a/core_test.zip)
+
+Patch breaking Aarch64: [qemu_arm_br.diff](/uploads/476321e40a551e964be41a8bfda96613/qemu_arm_br.diff)
+commit 8fe35e0444be88de4e3ab80a2a0e210a1f6d663d
+
+Patch fixing Aarch64: [qemu_arm_fix.diff](/uploads/2db3892d6839e9a4dfaf427359d6f004/qemu_arm_fix.diff)
+commit ae30e86661b0f48562cd95918d37cbeec5d02262
+
+Patch breaking MIPS: [qemu_mips_br.diff](/uploads/0a482e61c1245e5783364db845a55dfa/qemu_mips_br.diff)
+commit 96e5b4c7584d623f6cdcb0083829c19141b2b130
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1639 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1639
new file mode 100644
index 00000000..0a33a72f
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1639
@@ -0,0 +1 @@
+No supported machine for loongson-3A4000 mips64el
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1660 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1660
new file mode 100644
index 00000000..7bc0c1c2
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1660
@@ -0,0 +1 @@
+tests/avocado/linux_ssh_mips_malta.py references mips image URLs that doesn't exist any more
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1722 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1722
new file mode 100644
index 00000000..55d170b8
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1722
@@ -0,0 +1,87 @@
+qemu-mipsn32: Illegal Instruction at `exts` instruction
+Description of problem:
+Run with the command above, I got this error:
+
+```
+qemu-mipsn32 run
+qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+Illegal instruction (core dumped)
+```
+
+I then tried to debug the program with qemu option `-g 1234` and know that 
+
+```
+$ gdb-multiarch run
+...
+
+pwndbg> target remote 0:1234
+...
+
+pwndbg> c
+Continuing.
+
+Program received signal SIGILL, Illegal instruction.
+0x3f7d2434 in ?? () from /lib32/ld.so.1
+warning: GDB can't find the start of the function at 0x3f7d2434.
+x/10i
+
+pwndbg> x/10i $pc
+=> 0x3f7d2434:	0x7047f03a
+   0x3f7d2438:	lui	a3,0x7000
+   0x3f7d243c:	ori	a3,a3,0x5e
+   0x3f7d2440:	b	0x3f7d241c
+   0x3f7d2444:	subu	v0,a3,v0
+   0x3f7d2448:	sltiu	a7,a3,-3
+   0x3f7d244c:	bnezl	a7,0x3f7d246c
+   0x3f7d2450:	subu	a3,a4,v0
+   0x3f7d2454:	addiu	a3,a3,1
+   0x3f7d2458:	li	v0,-4
+```
+
+So I know the problem is in libc32/ld.so.1. When I dissasemble that file and look at offset 0x4434, it's an `exts` instruction as below:
+
+```
+$ file /lib32/ld.so.1
+/lib32/ld-2.15.so: ELF 32-bit MSB shared object, MIPS, N32 MIPS64 rel2 version 1 (SYSV), dynamically linked, stripped
+
+$ ./mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-objdump -d /lib32/ld.so.1 | less
+    ...
+    4434:       7047f03a        exts    a3,v0,0x0,0x1e
+    4438:       3c077000        lui     a3,0x7000
+    443c:       34e7005e        ori     a3,a3,0x5e
+    4440:       1000fff6        b       441c <GLIBC_2.0@@GLIBC_2.0+0x441c>
+    4444:       00e21023        subu    v0,a3,v0
+    4448:       2cebfffd        sltiu   a7,a3,-3
+    444c:       55600007        bnezl   a7,446c <GLIBC_2.0@@GLIBC_2.0+0x446c>
+    4450:       01023823        subu    a3,a4,v0
+    4454:       24e70001        addiu   a3,a3,1
+    4458:       2402fffc        li      v0,-4
+```
+Steps to reproduce:
+1. Download toolchain of mips64-n32 on toolchains.bootlin.com [here](https://toolchains.bootlin.com/releases_mips64-n32.html)
+2. Write this c code to file `run.c`:
+
+```c
+#include <stdio.h>
+
+int main(){
+	puts("hello world");
+	while (1);
+}
+```
+
+3. Compile file run.c with downloaded toolchain:
+
+```
+mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-gcc run.c -o run
+```
+
+> Step 1, 2 and 3 can be skip if you download the attached `run` file.
+
+4. Download the attached ld
+5. Make new dir at `/lib32` and move the file ld to `/lib32`
+6. Run command `qemu-mipsn32 run`
+Additional information:
+[ld-2.15.so](/uploads/95f4da26e42d43d39aa2350670134bb5/ld-2.15.so)
+
+[run](/uploads/01be57442009a75cf2f59cbcf53474f4/run)
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1806 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1806
new file mode 100644
index 00000000..f1843342
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1806
@@ -0,0 +1,5 @@
+Tests: YAMON binaries unavailable
+Description of problem:
+The [tests for MIPS](https://gitlab.com/qemu-project/qemu/-/blame/master/tests/avocado/machine_mips_malta.py#L127) download the YAMON firmware binaries, however that link does not exist anymore. It appears that it may have [moved to ](https://www.mips.com/develop/tools/boot-loaders/)mips.com (or maybe that's where it came from?), which states "To support existing users of these, and the QEMU project, YAMON is now available under the GPL License." However those links are also dead. I've not been able to find the referenced binaries or source anywhere. @philmd, do you happen to have a copy you can upload? Alternatively, I've found the 2.16 source [here](https://github.com/binsgit/mips-yamon).
+
+Another alternative would be to use U-boot, which is easy to get a hold of and would work for this test (just getting to a prompt, although I've had issues with it being able to access an IDE drive). I haven't found prebuilt binaries for MIPS and u-boot though.
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1922 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1922
new file mode 100644
index 00000000..cce0db52
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1922
@@ -0,0 +1,20 @@
+loongson3-virt machine fails to bring up secondary CPUs
+Description of problem:
+When booting Debian netboot on `loongson3-virt` machine with SMP, cores other than number 0 fail to come up.  Boot without SMP is successful.
+
+I provided the details of the first combination I tested, but I have also tested on an x86_64 host, as well as with Debian 11 (kernel `5.10.0-22-loongson-3`) on both hosts, with the same results.
+Steps to reproduce:
+1.  `wget https://ftp.debian.org/debian/dists/bookworm/main/installer-mips64el/current/images/loongson-3/netboot/vmlinuz-6.1.0-10-loongson-3`
+2.  `wget https://ftp.debian.org/debian/dists/bookworm/main/installer-mips64el/current/images/loongson-3/netboot/initrd.gz`
+3.  `qemu-system-mips64el -M loongson3-virt -kernel vmlinuz-6.1.0-10-loongson-3 -initrd initrd.gz -append "console=ttyS0" -serial stdio -smp 2`
+Additional information:
+Boot is successful when removing `-smp 2` from command line.  With it present, the following error is in `dmesg` (extends to all other CPUs when a larger SMP value is passed):
+```
+[    2.248229] rcu: Hierarchical SRCU implementation.
+[    2.248446] rcu:     Max phase no-delay instances is 1000.
+[    2.647997] smp: Bringing up secondary CPUs ...
+[    2.749706] Booting CPU#1...
+[    7.093229] CPU1: failed to start
+[    7.096508] smp: Brought up 1 node, 1 CPU
+```
+The boot eventually stalls after this.
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/193 b/gitlab/issues_text/target_mips/host_missing/accel_missing/193
new file mode 100644
index 00000000..a19fcdc5
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/193
@@ -0,0 +1 @@
+piix crashes on mips when using multiple cpus
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1987 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1987
new file mode 100644
index 00000000..4c916986
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1987
@@ -0,0 +1,48 @@
+snapshot: main thread hangs for a while after 'loadvm'
+Description of problem:
+When I was testing qemu snapshots, I found that after the `loadvm` command, the virtual machine would often get stuck for a while, and it can **resume execution after I enter some characters into the terminal**, this is weird because my guest system doesn't need to accept input.
+
+After some debugging, I found that the guest kernel is executing a `wait` instruction in `__r4k_wait()`.
+
+And I found that the main thread usually does not sleep at `qemu_poll_ns()` during normal execution, but after `loadvm`, the timeout is set to a large value (related to the interval time of snapshot operations), causes the main thread to get stuck on 'qemu_poll_ns()'.
+
+After some analysis, I think it is because save/load_snapshot() does not handle timers related to QEMU_CLOCK_VIRTUAL well, such as `mips_timer_cb()`, resulting in incorrect value when calculating timeout.
+Steps to reproduce:
+1. Start emulation and connect monitor
+2. `savevm` and wait for a moment
+3. `loadvm`
+Additional information:
+Stack backtrace of the guest kernel:
+```
+►  0 0x80104d40 __r4k_wait+32
+   1 0x80143cc4 cpu_startup_entry+284
+   2 0x80143cc4 cpu_startup_entry+284
+   3 0x80143cc4 cpu_startup_entry+284
+   4 0x80633fe0 kernel_init
+   5 0x80825cb8 start_kernel+1072
+```
+
+Stack backtrace of the main thread:
+```
+0 0x7ffff74f0a96 ppoll+166
+1 0x555555ea4786 qemu_poll_ns+221
+2 0x555555e9fea7 os_host_main_loop_wait+93
+3 0x555555e9ffd6 main_loop_wait+187
+4 0x555555a644fd qemu_main_loop+46
+5 0x5555557d2b6a qemu_default_main+17
+6 0x5555557d2ba9 main+45
+7 0x7ffff7402083 __libc_start_main+243
+```
+
+Stack backtrace of the vCPU thread:
+```
+#0  futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556550848) at ../sysdeps/nptl/futex-internal.h:183
+#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5555564d0860 <qemu_global_mutex>, cond=0x555556550820) at pthread_cond_wait.c:508
+#2  __pthread_cond_wait (cond=0x555556550820, mutex=0x5555564d0860 <qemu_global_mutex>) at pthread_cond_wait.c:647
+#3  0x0000555555e85602 in qemu_cond_wait_impl (cond=0x555556550820, mutex=0x5555564d0860 <qemu_global_mutex>, file=0x5555560122ab "../system/cpus.c", line=431) at ../util/qemu-thread-posix.c:225
+#4  0x0000555555a5618f in qemu_wait_io_event (cpu=0x555556825200) at ../system/cpus.c:431
+#5  0x0000555555c8bcf1 in mttcg_cpu_thread_fn (arg=0x555556825200) at ../accel/tcg/tcg-accel-ops-mttcg.c:118
+#6  0x0000555555e85e50 in qemu_thread_start (args=0x555556550860) at ../util/qemu-thread-posix.c:541
+#7  0x00007ffff75d8609 in start_thread (arg=<optimized out>) at pthread_create.c:477
+#8  0x00007ffff74fd133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
+```
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/2013 b/gitlab/issues_text/target_mips/host_missing/accel_missing/2013
new file mode 100644
index 00000000..795869ef
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/2013
@@ -0,0 +1,78 @@
+The avocado test replay_kernel.py:ReplayKernelNormal.test_mips64el_malta is unreliable
+Description of problem:
+This test keeps hanging on CI
+Steps to reproduce:
+Run the test on GitLab's CI infrastructure and it will hang on replay. Examples: https://gitlab.com/stsquad/qemu/-/jobs/5664260736
+Additional information:
+Excerpt from log:
+
+```
+18:02:49 DEBUG| Transitioning from 'Runstate.CONNECTING' to 'Runstate.RUNNING'.
+18:02:49 DEBUG| Opening console file
+18:02:49 DEBUG| Opening console socket
+18:02:49 DEBUG| [    0.000000] Initializing cgroup subsys cpuset
+18:02:49 DEBUG| [    0.000000] Initializing cgroup subsys cpu
+18:02:49 DEBUG| [    0.000000] Linux version 2.6.32-5-5kc-malta (Debian 2.6.32-48) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Fri Feb 15 21:38:11 UTC 2013
+18:02:49 DEBUG| [    0.000000]
+18:02:49 DEBUG| [    0.000000] LINUX started...
+18:02:49 DEBUG| [    0.000000] bootconsole [early0] enabled
+18:02:49 DEBUG| [    0.000000] CPU revision is: 000182a0 (MIPS 20Kc)
+18:02:49 DEBUG| [    0.000000] FPU revision is: 000f8200
+18:02:49 DEBUG| [    0.000000] Checking for the multiply/shift bug... no.
+18:02:49 DEBUG| [    0.000000] Checking for the daddiu bug... no.
+18:02:49 DEBUG| [    0.000000] Determined physical RAM map:
+18:02:49 DEBUG| [    0.000000]  memory: 0000000000001000 @ 0000000000000000 (reserved)
+18:02:49 DEBUG| [    0.000000]  memory: 00000000000ef000 @ 0000000000001000 (ROM data)
+18:02:49 DEBUG| [    0.000000]  memory: 0000000000659000 @ 00000000000f0000 (reserved)
+18:02:49 DEBUG| [    0.000000]  memory: 00000000078b7000 @ 0000000000749000 (usable)
+18:02:49 DEBUG| [    0.000000] Wasting 104440 bytes for tracking 1865 unused pages
+18:02:49 DEBUG| [    0.000000] Initrd not found or empty - disabling initrd
+18:02:49 DEBUG| [    0.000000] Zone PFN ranges:
+18:02:49 DEBUG| [    0.000000]   DMA      0x00000000 -> 0x00001000
+18:02:49 DEBUG| [    0.000000]   Normal   0x00001000 -> 0x00008000
+18:02:49 DEBUG| [    0.000000] Movable zone start PFN for each node
+18:02:49 DEBUG| [    0.000000] early_node_map[1] active PFN ranges
+18:02:49 DEBUG| [    0.000000]     0: 0x00000000 -> 0x00008000
+18:02:49 DEBUG| [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32320
+18:02:49 DEBUG| [    0.000000] Kernel command line: printk.time=1 panic=-1 console=ttyS0
+18:02:49 DEBUG| Shutting down VM appliance; timeout=30
+18:02:49 DEBUG| Attempting graceful termination
+18:02:49 DEBUG| Closing console file
+18:02:49 DEBUG| Closing console socket
+18:02:49 DEBUG| Politely asking QEMU to terminate
+...
+
+18:02:49 DEBUG| Transitioning from 'Runstate.CONNECTING' to 'Runstate.RUNNING'.
+18:02:49 DEBUG| Opening console file
+18:02:49 DEBUG| Opening console socket
+18:02:49 DEBUG| [    0.000000] Initializing cgroup subsys cpuset
+18:02:49 DEBUG| [    0.000000] Initializing cgroup subsys cpu
+18:02:49 DEBUG| [    0.000000] Linux version 2.6.32-5-5kc-malta (Debian 2.6.32-48) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Fri Feb 15 21:38:11 UTC 2013
+18:02:49 DEBUG| [    0.000000]
+18:02:49 DEBUG| [    0.000000] LINUX started...
+18:02:49 DEBUG| [    0.000000] bootconsole [early0] enabled
+18:02:49 DEBUG| [    0.000000] CPU revision is: 000182a0 (MIPS 20Kc)
+18:02:49 DEBUG| [    0.000000] FPU revision is: 000f8200
+18:02:49 DEBUG| [    0.000000] Checking for the multiply/shift bug... no.
+18:02:49 DEBUG| [    0.000000] Checking for the daddiu bug... no.
+18:02:49 DEBUG| [    0.000000] Determined physical RAM map:
+18:02:49 DEBUG| [    0.000000]  memory: 0000000000001000 @ 0000000000000000 (reserved)
+18:02:49 DEBUG| [    0.000000]  memory: 00000000000ef000 @ 0000000000001000 (ROM data)
+18:02:49 DEBUG| [    0.000000]  memory: 0000000000659000 @ 00000000000f0000 (reserved)
+18:02:49 DEBUG| [    0.000000]  m
+18:04:48 ERROR| 
+18:04:48 ERROR| Reproduced traceback from: /builds/stsquad/qemu/build/pyvenv/lib/python3.10/site-packages/avocado/core/test.py:770
+18:04:48 ERROR| Traceback (most recent call last):
+18:04:48 ERROR|   File "/builds/stsquad/qemu/build/tests/avocado/replay_kernel.py", line 147, in test_mips64el_malta
+18:04:48 ERROR|     self.run_rr(kernel_path, kernel_command_line, console_pattern, shift=5)
+18:04:48 ERROR|   File "/builds/stsquad/qemu/build/tests/avocado/replay_kernel.py", line 78, in run_rr
+18:04:48 ERROR|     t2 = self.run_vm(kernel_path, kernel_command_line, console_pattern,
+18:04:48 ERROR|   File "/builds/stsquad/qemu/build/tests/avocado/replay_kernel.py", line 61, in run_vm
+18:04:48 ERROR|     self.wait_for_console_pattern(console_pattern, vm)
+18:04:48 ERROR|   File "/builds/stsquad/qemu/build/tests/avocado/boot_linux_console.py", line 52, in wait_for_console_pattern
+18:04:48 ERROR|     wait_for_console_pattern(self, success_message,
+18:04:48 ERROR|   File "/builds/stsquad/qemu/build/tests/avocado/avocado_qemu/__init__.py", line 199, in wait_for_console_pattern
+18:04:48 ERROR|     _console_interaction(test, success_message, failure_message, None, vm=vm)
+18:04:48 ERROR|   File "/builds/stsquad/qemu/build/tests/avocado/avocado_qemu/__init__.py", line 148, in _console_interaction
+18:04:48 ERROR|     msg = console.readline().decode().strip()
+```
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/221 b/gitlab/issues_text/target_mips/host_missing/accel_missing/221
new file mode 100644
index 00000000..ff350268
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/221
@@ -0,0 +1 @@
+piix crashes on mips when accessing acpi-pci-hotplug
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/240 b/gitlab/issues_text/target_mips/host_missing/accel_missing/240
new file mode 100644
index 00000000..7a98ed35
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/240
@@ -0,0 +1 @@
+qemu-3.1.0-rc0: mips emulation hangs when executing invalid instructions
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/241 b/gitlab/issues_text/target_mips/host_missing/accel_missing/241
new file mode 100644
index 00000000..960eac64
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/241
@@ -0,0 +1 @@
+Please refactor linux-user/mips/cpu_loop.c
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/2464 b/gitlab/issues_text/target_mips/host_missing/accel_missing/2464
new file mode 100644
index 00000000..dfed795a
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/2464
@@ -0,0 +1,11 @@
+"rc4030: invalid read at 0xf0-0xf8" shows up, then NT MIPS bluescreens
+Description of problem:
+The problem is fairly nondescript, but it seems to be a chipset regression that popped up between QEMU 8 and QEMU 9. I had a Windows NT 4 VM that I tried booting in the latest QEMU update after a while of not using it, and it just flat-out refused to do that, outputting the ``INACCESSIBLE_BOOT_DEVICE`` error. Any attempt to boot from the hard drive or reinstall the OS from the CD image would return the same bluescreen, and would show the very message shown in the title in the process log.
+Steps to reproduce:
+1. Download a Windows NT 3.5x/4.0 ISO.
+2. Create a disk image ≤2GB in size.
+3. Enter the command above.
+4. Go through the preparatory setup, as described in [here](https://computernewb.com/wiki/QEMU/Guests/Windows_NT_3.x-4.0_(MIPS)). (ignore the networking switches, or replace ``dp83932`` with ``ne2k_isa``)
+5. Launch the installer by running ``cd:\mips\setupldr``.
+Additional information:
+![exhibit A; shows the 0x0000007b bugcheck output](/uploads/389e7b5fe77e259c6f3b2a703945df73/Screenshot_from_2024-07-28_18-44-15.png)
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/2826 b/gitlab/issues_text/target_mips/host_missing/accel_missing/2826
new file mode 100644
index 00000000..9277b6a8
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/2826
@@ -0,0 +1,9 @@
+The host PCI bridge disappeared on the big endian MIPS Malta machine
+Description of problem:
+The tests/avocado/linux_ssh_mips_malta.py test currently fails for the big endian machines. It tries to check for the PCI host bridge with ``lspci -d 11ab:4620``, but that does not show the expected output anymore -- it looks like the host bridge cannot be correctly discovered by the guest Linux kernel anymore.
+Steps to reproduce:
+1. Get the kernel and disk image from https://people.debian.org/~aurel32/qemu/mips/
+2. Boot the guest as described above.
+3. lspci -d 11ab:4620
+Additional information:
+This used to work fine before commit 145e2198d749ec09a405f1607a9932499b76f1eb , so this rework likely introduced the bug. Looking at the code that got removed there, I could see an additional check ``phb->config_reg & 0x00fff800`` that is not present in the new code anymore, so the space for the host bridge itself likely should not get swapped. Reverting 3d85c7c15fc7ce986cf1a8e73da1217228f35685 and 145e2198d749ec09a405f1607a9932499b76f1eb seems to fix the problem (at least on little endian hosts).
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/44 b/gitlab/issues_text/target_mips/host_missing/accel_missing/44
new file mode 100644
index 00000000..3ff83149
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/44
@@ -0,0 +1 @@
+QEMU aborts when specifying additional isa-vga devices
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/51 b/gitlab/issues_text/target_mips/host_missing/accel_missing/51
new file mode 100644
index 00000000..81c051be
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/51
@@ -0,0 +1 @@
+Linux kernel oops on Malta board while accessing pflash
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/571 b/gitlab/issues_text/target_mips/host_missing/accel_missing/571
new file mode 100644
index 00000000..c01150f3
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/571
@@ -0,0 +1 @@
+maybe-uninitialized warning in mips cpu_loop()
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/602 b/gitlab/issues_text/target_mips/host_missing/accel_missing/602
new file mode 100644
index 00000000..0360e8cb
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/602
@@ -0,0 +1,13 @@
+Failure to translate host to target errno in IP_RECVERR, IPV6_RECVERR emulation
+Description of problem:
+In translated IP_RECVERR (and IPV6_RECVERR) control messages, the `ee_errno` is not translated, so host errnos are observed on guests.  E.g., `ECONNREFUSED` is 111 on x86_64 host, but expected to be 146 in MIPS ABI.
+Steps to reproduce:
+1. https://cirrus-ci.com/task/5914289870471168
+Additional information:
+The bugs are on [lines 1970 and 2014 here](https://github.com/qemu/qemu/blob/211364c21e7f757ae1acf4e72b5df39c498fb88b/linux-user/syscall.c#L1970-L2014).
+
+The fix is something like:
+
+```
+__put_user(host_to_target_errno(errh->ee.ee_errno), &target_errh->ee.ee_errno);
+```
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/63 b/gitlab/issues_text/target_mips/host_missing/accel_missing/63
new file mode 100644
index 00000000..350121de
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/63
@@ -0,0 +1 @@
+Illegal delay slot code causes abort on mips64
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/644 b/gitlab/issues_text/target_mips/host_missing/accel_missing/644
new file mode 100644
index 00000000..82784294
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/644
@@ -0,0 +1,9 @@
+generic loader does not do virtual to physical address translation when loading MIPS ELF
+Description of problem:
+
+Steps to reproduce:
+1.build two ELFs, whose virtual address is at kseg0<p>
+2.load one ELF with generic loader "-device loader,file=test1.elf", the other ELF with "-kernel test2.elf"<p>
+3.generic loader loads test1.elf without doing address translation, while mipssim load_kernel will do that with cpu_mips_kseg0_to_phys<p>
+Additional information:
+generic_loader_realize calls load_elf_as with the argument translate_fn=NULL. Maybe, we can set translate_fn when elf_machine is EM_MIPS.
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/694 b/gitlab/issues_text/target_mips/host_missing/accel_missing/694
new file mode 100644
index 00000000..76c81c95
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/694
@@ -0,0 +1 @@
+Crash using MIPS I7200 CPU with non-nanoMIPS ELF
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/695 b/gitlab/issues_text/target_mips/host_missing/accel_missing/695
new file mode 100644
index 00000000..0504be48
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/695
@@ -0,0 +1 @@
+MIPS: nanomips p32 ABI not supported
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/758 b/gitlab/issues_text/target_mips/host_missing/accel_missing/758
new file mode 100644
index 00000000..d3db7f69
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/758
@@ -0,0 +1,46 @@
+[Cross compilation] qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+Description of problem:
+On the X86 platform, chroot to the latest MIP environment, download the source package, install the dependency, and then compile. It is found that the variation is in error
+
+Grab logs with GDB on the real machine
+
+Thread 1 "bash" received signal SIGSEGV, Segmentation fault.
+0x00007f094429c656 in code_gen_buffer ()
+(gdb) bt
+#0  0x00007f094429c656 in code_gen_buffer ()
+#1  0x000000000053878e in cpu_tb_exec (cpu=0x2441050, itb=<optimized out>, tb_exit=0x7ffd5bae38e8) at ../../accel/tcg/cpu-exec.c:353
+#2  0x000000000053965e in cpu_loop_exec_tb (tb_exit=0x7ffd5bae38e8, last_tb=<synthetic pointer>, tb=0x7f09441caac0 <code_gen_buffer+690835>, cpu=0x2441050) at ../../accel/tcg/cpu-exec.c:812
+#3  cpu_exec (cpu=cpu@entry=0x2441050) at ../../accel/tcg/cpu-exec.c:970
+#4  0x0000000000465b60 in cpu_loop (env=env@entry=0x2449340) at ../../linux-user/mips64/cpu_loop.c:78
+#5  0x0000000000413b27 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../linux-user/main.c:910   
+(gdb) thread apply all bt
+
+Thread 2 (LWP 26312):
+#0  0x0000000000766a19 in syscall ()
+#1  0x000000000058ee0a in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at ./include/qemu/trace-events:29
+#2  qemu_event_wait (ev=ev@entry=0xd44e68 <rcu_call_ready_event>) at ../../util/qemu-thread-posix.c:480
+#3  0x000000000059690a in call_rcu_thread (opaque=opaque@entry=0x0) at ./b/user-static/thread.h:258
+#4  0x000000000058dc29 in qemu_thread_start (args=<optimized out>) at ../../util/qemu-thread-posix.c:541
+#5  0x00000000006e665e in start_thread (arg=0x7f094c9a3640) at pthread_create.c:463
+#6  0x000000000076836f in clone ()
+
+Thread 1 (LWP 26310):
+#0  0x00007f094429c656 in code_gen_buffer ()
+#1  0x000000000053878e in cpu_tb_exec (cpu=0x2441050, itb=<optimized out>, tb_exit=0x7ffd5bae38e8) at ../../accel/tcg/cpu-exec.c:353
+#2  0x000000000053965e in cpu_loop_exec_tb (tb_exit=0x7ffd5bae38e8, last_tb=<synthetic pointer>, tb=0x7f09441caac0 <code_gen_buffer+690835>, cpu=0x2441050) at ../../accel/tcg/cpu-exec.c:812
+#3  cpu_exec (cpu=cpu@entry=0x2441050) at ../../accel/tcg/cpu-exec.c:970
+#4  0x0000000000465b60 in cpu_loop (env=env@entry=0x2449340) at ../../linux-user/mips64/cpu_loop.c:78
+#5  0x0000000000413b27 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../linux-user/main.c:910
+(gdb) 
+```
+Steps to reproduce:
+```
+1.Minimum environment for building MIPS platform on 
+2.On X86 platform sudo chroot .
+3.cd build
+4.apt source adwaita-icon-theme
+5.cd adwaita-icon-theme-3.30.1
+6.debuild -b
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/843 b/gitlab/issues_text/target_mips/host_missing/accel_missing/843
new file mode 100644
index 00000000..2efc00ca
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/843
@@ -0,0 +1,3 @@
+qemu-binfmt-conf causes duplicate magic mips headers when installing all patterns
+Description of problem:
+The magic/mask patterns are the same for mips[el] and nipsn32[el]
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/909 b/gitlab/issues_text/target_mips/host_missing/accel_missing/909
new file mode 100644
index 00000000..96c0b3c1
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/909
@@ -0,0 +1,11 @@
+qemu-mipsn32(el) user mode emulator fails to execute any recently built n32 binaries
+Description of problem:
+**Note: Before trying to reproduce this issue, have a look at issue 843 - the binfmt-misc magic for n32 needs to be fixed.**
+
+Trying to chroot into a mips n32 installation fails with 
+```
+/bin/bash: error while loading shared libraries: /lib32/libc.so.6: cannot read file data
+```
+however, bash, libc.so.6, and qemu all exist and have the proper abi
+
+The problem occurs for both big and little endian N32 ABI. O32 and N64 work fine. The same N32 binaries also work fine on native hardware.
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/939 b/gitlab/issues_text/target_mips/host_missing/accel_missing/939
new file mode 100644
index 00000000..a5e40ca3
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/939
@@ -0,0 +1,75 @@
+qemu-mipsn32el user mode emulator allocates pointers beyond upper memory limit
+Description of problem:
+In qemu-based N32 mips chroots (both BE and LE), I became aware of memory-intensive programs segfaulting, apparently at random. tar, gcc, but only in specific situations. Watching the strace output of gcc, I got the impression that it happens when memory beyond 2Gbyte is allocated. (mips n32 and o32 uses only 31 bit of a pointer, I've been told, so this is somewhat expected, but a segfault is nevertheless wrong.) 
+
+So, I used the following test program, statically linked:
+```
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+
+int main() {
+
+  char *pointer;
+  int i;
+
+  for (i=1; i<301; i++) {
+
+    printf("Allocation %i : ", i);
+    pointer = malloc(20480000 * sizeof(char));
+
+    printf(" pointer is %p, ", pointer);
+
+    if (! pointer) {
+      printf("malloc failed\n");
+      exit(0);
+    };
+
+    memset(pointer, 0xDB, 20480000);
+    printf(" filled\n");
+  }
+};
+```
+
+With mips3 n32 I get the following output:
+```
+pinacolada ~ # file /var/lib/machines/mips64el-n32/root/memtest
+/var/lib/machines/mips64el-n32/root/memtest: ELF 32-bit LSB executable, MIPS, N32 MIPS-III version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, not stripped
+pinacolada ~ # /usr/bin/qemu-mipsn32el /var/lib/machines/mips64el-n32/root/memtest
+Allocation 1 :  pointer is 0x40802010,  filled
+Allocation 2 :  pointer is 0x41b8b010,  filled
+Allocation 3 :  pointer is 0x42f14010,  filled
+[...]
+Allocation 51 :  pointer is 0x7d8c4010,  filled
+Allocation 52 :  pointer is 0x7ec4d010,  filled
+qemu: unhandled CPU exception 0x15 - aborting
+pc=0x0000000010021944 HI=0x0000000000000004 LO=0x00000000100218f0 ds 02ea 00000000100218f0 0
+GPR00: r0 0000000000000000 at 0000000000000001 v0 000000007ffd6010 v1 0000000026f77200
+GPR04: a0 000000007ffd6010 a1 dbdbdbdbdbdbdbdb a2 0000000001388000 a3 0000000001388000
+GPR08: t0 0000000025252525 t1 0000000025252525 t2 ffffffffffffffff t3 000000001006c369
+GPR12: t4 000000001006c368 t5 0000000000000000 t6 0000000000000000 t7 0000000000000010
+GPR16: s0 0000000000000001 s1 00000000407ffd54 s2 000000001009b270 s3 0000000000000000
+GPR20: s4 0000000010000760 s5 00000000407ffd5c s6 0000000000000000 s7 0000000000000000
+GPR24: t8 0000000000000000 t9 00000000100218f0 k0 0000000000000000 k1 0000000000000000
+GPR28: gp 00000000100a7320 sp 00000000407ffbf0 s8 00000000407ffbf0 ra 0000000010000854
+CP0 Status  0x24800010 Cause   0x00000000 EPC    0x0000000000000000
+    Config0 0x80004482 Config1 0xbe61309b LLAddr 0x0000000000000000
+    Config2 0x80000000 Config3 0x00000000
+    Config4 0x00000000 Config5 0x00000000
+**
+ERROR:../accel/tcg/cpu-exec.c:928:cpu_exec: assertion failed: (cpu == current_cpu)
+Bail out! ERROR:../accel/tcg/cpu-exec.c:928:cpu_exec: assertion failed: (cpu == current_cpu)
+```
+
+For mips2 o32 I get the more correct looking output
+```
+pinacolada ~ # file /var/lib/machines/mips-o32/root/memtest
+/var/lib/machines/mips-o32/root/memtest: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, not stripped
+pinacolada ~ # /usr/bin/qemu-mips /var/lib/machines/mips-o32/root/memtest
+Allocation 1 :  pointer is 0x3ec76008,  filled
+Allocation 2 :  pointer is 0x3d8ed008,  filled
+Allocation 3 :  pointer is 0x3c564008,  filled
+[...]
+Allocation 104 :  pointer is 0x4082c008,  filled
+Allocation 105 :  pointer is (nil), malloc failed
+```
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/995 b/gitlab/issues_text/target_mips/host_missing/accel_missing/995
new file mode 100644
index 00000000..0c3bbd99
--- /dev/null
+++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/995
@@ -0,0 +1,11 @@
+Segfault when saving VM snapshot via QEMU monitor on MIPS and MIPSEL
+Description of problem:
+When entering the QEMU monitor using Ctrl-A then C, and running the savevm QEMU command, the emulator hangs for a while and then exits with a segfault. This occurs on MIPS and MIPSEL system emulators using the same command line arguments. ARM32, aarch64 and x86_64 emulators don't seem to have this problem. I haven't tested it on any other architectures as I don't have kernel or drive images for them. `qemu-img` seems to work fine with the QCOW2 images used for this test, I was able to create and load offline snapshots from them. The images were created from raw EXT2 filesystem images produced by Buildroot, using `qemu-img convert`.
+Steps to reproduce:
+1. Start the QEMU system emulator for MIPS/MIPSEL with the given command line.
+2. Enter the QEMU monitor with Ctrl-A, C.
+3. Run `savevm <vm name>`.
+Additional information:
+I tried logging what QEMU was doing with the `-D ./log.txt` command line option, but the produced log file was empty.
+
+If you need me to send you the kernel image files and QCOW2 images used, I would be happy to do so.
diff --git a/gitlab/issues_text/target_missing/host_aarch64/accel_KVM/2692 b/gitlab/issues_text/target_missing/host_aarch64/accel_KVM/2692
new file mode 100644
index 00000000..6a8731b5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_aarch64/accel_KVM/2692
@@ -0,0 +1 @@
+Using the ldp instruction to access the I/O address space in KVM mode causes an exception
diff --git a/gitlab/issues_text/target_missing/host_arm/accel_HVF/2895 b/gitlab/issues_text/target_missing/host_arm/accel_HVF/2895
new file mode 100644
index 00000000..e3f9da29
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_arm/accel_HVF/2895
@@ -0,0 +1,30 @@
+qemu-system-aarch64: Error: r = HV_BAD_ARGUMENT (0xfae94003, at ../target/arm/hvf/hvf.c:2259)
+Description of problem:
+When I launch a Linux guest in QEMU with `-accel hvf` + `-gdb "tcp::1234"`, and I try to debug the kernel with `lldb`, QEMU crashes with the following report:
+
+```
+qemu-system-aarch64: Error: r = HV_BAD_ARGUMENT (0xfae94003, at ../target/arm/hvf/hvf.c:2259)
+```
+Steps to reproduce:
+1. Run QEMU with `-accel hvf` + `-gdb "tcp::1234"` and a custom kernel (`-kernel Image`)
+2. Try to attach using `lldb vmlinux` + `(lldb) gdb-remote 1234`
+Additional information:
+Debugging QEMU I see the crash is due to the `cpu->accel->fd` file descriptor being `0`:
+
+```
+warning: qemu-system-aarch64 was compiled with optimization - stepping may behave oddly; variables may not be available.
+frame #4: 0x00000001003dd24c qemu-system-aarch64`hvf_arch_update_guest_debug [inlined] hvf_put_guest_debug_registers(cpu=0x0000000158118000) at hvf.c:2259:9 [opt]
+   2256     for (i = 0; i < max_hw_bps; i++) {
+   2257         r = hv_vcpu_set_sys_reg(cpu->accel->fd, dbgbcr_regs[i],
+   2258                                 env->cp15.dbgbcr[i]);
+-> 2259         assert_hvf_ok(r);
+   2260         r = hv_vcpu_set_sys_reg(cpu->accel->fd, dbgbvr_regs[i],
+   2261                                 env->cp15.dbgbvr[i]);
+   2262         assert_hvf_ok(r);
+(lldb) print cpu->accel->fd
+(hvf_vcpuid) 0
+(lldb) print dbgbcr_regs[i]
+(const uint16_t) 32773
+(lldb) print env->cp15.dbgbcr[i]
+(uint64_t) 480
+```
diff --git a/gitlab/issues_text/target_missing/host_arm/accel_TCG/1147 b/gitlab/issues_text/target_missing/host_arm/accel_TCG/1147
new file mode 100644
index 00000000..e5a68adc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_arm/accel_TCG/1147
@@ -0,0 +1,9 @@
+x86_64 emu on aarch64 host: cpu_exec: assertion failed: (cpu == current_cpu)
+Description of problem:
+Execution of some binaries crashes with `Bail out! ERROR:../qemu-7.0.0/accel/tcg/cpu-exec.c:933:cpu_exec: assertion failed: (cpu == current_cpu)`. Looking at the code, that code is wrapped in a gcc/clang ifdef. Recompiling with clang produces this crash instead: `... include/qemu/rcu.h:102: void rcu_read_unlock(void): Assertion 'p_rcu_reader->depth != 0' failed.`
+
+No easier steps to reproduce (yet) than `systemd-nspawn`ing into an x86_64 Ubuntu container invoking qemu-x86_64-static through binfmt. Commands such as `ls` work fine, while `apt-get` will immediately crash with the error listed above.
+
+Note that this happens running Asahi Linux on the bare metal of an M1-based Macbook Pro. This same issue does *not* occur running the *same* binaries with the *same* x86_64 Ubuntu image on an Arch or Ubuntu VM under macOS on the same machine - regardless of if the QEMU binaries were built in a VM or in Asahi.
+
+These are big.LITTLE chips. Using taskset/affinity to limit the target process to a single specific core does not help. The Asahi kernel has a 16K page-size, which is known to cause trouble for some programs. qemu-arm(-static) however works without any issues (the M1 cannot run 32-bit ARM code natively, only 64-bit).
diff --git a/gitlab/issues_text/target_missing/host_arm/accel_TCG/1714 b/gitlab/issues_text/target_missing/host_arm/accel_TCG/1714
new file mode 100644
index 00000000..09eafb6f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_arm/accel_TCG/1714
@@ -0,0 +1,27 @@
+QEMU crashes on ARMv7 since at least commit 493c9b19
+Description of problem:
+I'm trying to build QEMU for Android, Arm64 versions work well, but **Armv7** builds began to crash nearly since this series of commits (QEMU 7.2.50), related to 'TCG_TARGET_HAS_direct_jump' removal by @rth7680.
+More precisely, this commit still works:
+
+https://gitlab.com/qemu-project/qemu/-/commit/82df11e78d0baef7ffb7e7933c6fb830ffed087c
+
+and this one crashes:
+
+https://gitlab.com/qemu-project/qemu/-/commit/493c9b19a7fb7f387c4fcf57d3836504d5242bf5
+
+(I tracked commits of 'tcg' subfolder and didn't bisect finer, but it's possible if needed).
+
+Both qemu-system-x86_64 and qemu-system-i386 emulators crash.
+
+**The crash is related to translation buffer size** : if I don't specify "-accel tcg,thread=single **,tb-size=256** ", the machine works.
+
+The problem is that I can not run debugger on a phone, and crash dump does not show any useful information, just "segfault" reason ("Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xe19b8000").
+
+Even more, the Linux starts and runs, but it crashes only when I'm trying to run the GIMP, between splash screen and main interface appearance.
+
+I know that 1) Android is not officially supported and 2) 32-bit hosts were considered deprecated recently, but maybe it's possible to do something with these crashes?
+
+Recent master (https://gitlab.com/qemu-project/qemu/-/commit/5692a39f329413a00020a61fff95aff6b9884a73) doesn't work as well.
+All 8.0.x Arm64 builds are runnable.
+
+Thanks in advance.
diff --git a/gitlab/issues_text/target_missing/host_arm/accel_TCG/2295 b/gitlab/issues_text/target_missing/host_arm/accel_TCG/2295
new file mode 100644
index 00000000..a525f8cd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_arm/accel_TCG/2295
@@ -0,0 +1,4 @@
+Support Apple Silicon acceleration for x86 / x86_64 guests
+Additional information:
+* [Top-level discussion on UTM downstream](https://github.com/utmapp/UTM/issues/5460)
+* [Discussion on memory access instructions on UTM downstream](https://github.com/utmapp/UTM/issues/2366)
diff --git a/gitlab/issues_text/target_missing/host_arm/accel_missing/1168 b/gitlab/issues_text/target_missing/host_arm/accel_missing/1168
new file mode 100644
index 00000000..0d702564
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_arm/accel_missing/1168
@@ -0,0 +1,13 @@
+ivshmem: ivshmem-doorbell can't notify the MSI-X interrupt on Arm64 guest
+Description of problem:
+I init several qemu-kvm VMs on my arm64 host, which is a NVIDIA Xavier board. I want to use qemu's ivshmem-doorbell to build a sync shared memory communition with its MSI-X interrupt mechanism. I init the ivshmem-server and ivshmem-client on the host first, after then init the guests. The visul PCI-e device named "Inter-VM shared memory" can be successfully seen in my guests with command "lspci".
+I write a driver for this pci-e device to request and handle the MSI-X interrupts, which init well in the guest and can ring or receive from an interrupt vector on other peerID with the driver's IOCTL interface, the peer that receive vector in my environment is the ivshmem-client. However, when i use the ivshmem-client command "int" to ring my guest , the guest can't receive the msi-x interrupt notification.
+Steps to reproduce:
+1. init ivshmem-server on the host, with command "ivshmem-server -l 4M -M fg-doorbell -n 8 -F -v".
+2. init ivshmem-client on the host, with command "ivshmem-client -v".
+3. init the qemu-kvm VM .
+4. init the driver with "insmod" in guest to request the msi-x interrupt, while "cat /proc/interrupts" shows the interrupt request successfully!
+5. on host, ivshmem-client use command "int 1 0" to ring the guest's interrupt trigger, however ,nothing happened.
+Additional information:
+I am fully sure that there is no problem about the driver I wrote for the pci-e inter-VM shared memory device, for i has tested that the driver works on my X86 PC, where I deployed qemu-x86 VMs and the driver can work well in X86 guests with the inshmem-doorbell mechanism. The ivshmem-client work on host can notify the guest to trigger the correct msix-x interrupt. 
+Therefore, I digged the msi-x interrupt structure and use devmem tool to write the data to the messageAddress manually, which can correctly trigger the msi-x interrupt in my arm64 guest in the Xavier board, meaning the msi-x interrupt is OK in the guest. So I doubt maybe there is any issue on the ivshmem-doorbell mechanism that ring a interrupt vector in the guset of qemu-aarch64.
diff --git a/gitlab/issues_text/target_missing/host_arm/accel_missing/1434 b/gitlab/issues_text/target_missing/host_arm/accel_missing/1434
new file mode 100644
index 00000000..a3c0f2bf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_arm/accel_missing/1434
@@ -0,0 +1,3 @@
+Windows on ARM64 host support
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_arm/accel_missing/1635 b/gitlab/issues_text/target_missing/host_arm/accel_missing/1635
new file mode 100644
index 00000000..98f20175
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_arm/accel_missing/1635
@@ -0,0 +1,37 @@
+Slow graphics output under aarch64 hvf (no dirty bitmap tracking)
+Description of problem:
+When using a display adapter such as `bochs-display` (which, yes, I realize is not the ideal choice for an aarch64 guest, but it works fine under TCG and KVM, so bear with me) under `hvf` acceleration on an M1 Mac, display output is slow enough to be measured in seconds-per-frame.
+
+The issue seems to stem from each write to the framebuffer memory resulting in a data abort, while the expected behavior is that only one such write results in a data abort exception, which is handled by marking the region dirty and then subsequent writes do not yield exceptions until the display management in QEMU resets the dirty flag. Instead, every pixel drawn causes the VM to trap, and performance is degraded.
+Steps to reproduce:
+1. Start an aarch64 HVF guest with the `bochs-display` display adapter.
+2. Observe performance characteristics.
+3.
+Additional information:
+I reported this issue on IRC around a year ago, and was provided with a patch by @agraf which I have confirmed works. That patch was shared on the `qemu-devel` mailing list in February, 2022, with a response from @pm215: https://lists.gnu.org/archive/html/qemu-devel/2022-02/msg00609.html
+
+As a quick summary, the patch takes this snippet from the i386 HVF target:
+
+https://gitlab.com/qemu-project/qemu/-/blob/master/target/i386/hvf/hvf.c#L132-138
+
+And applies a variation of it to the ARM target when handling a data abort exception, before this assert:
+
+https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/hvf/hvf.c#L1381
+
+Something to the effect of:
+
+```c
+        if (iswrite) {
+            uint64_t gpa = hvf_exit->exception.physical_address;
+            hvf_slot *slot = hvf_find_overlap_slot(gpa, 1);
+
+            if (slot && slot->flags & HVF_SLOT_LOG) {
+                memory_region_set_dirty(slot->region, 0, slot->size);
+                hv_vm_protect(slot->start, slot->size, HV_MEMORY_READ |
+                              HV_MEMORY_WRITE | HV_MEMORY_EXEC);
+                break;
+            }
+        }
+```
+
+I am reporting this issue now as I updated my git checkout with the release of QEMU 8.0.0 and was surprised to find that the patch had never made it upstream and the issue persists.
diff --git a/gitlab/issues_text/target_missing/host_arm/accel_missing/1678 b/gitlab/issues_text/target_missing/host_arm/accel_missing/1678
new file mode 100644
index 00000000..f0edb754
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_arm/accel_missing/1678
@@ -0,0 +1,8 @@
+Running Qemu on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work.
+Description of problem:
+Running QemuV8.0 on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work.
+Steps to reproduce:
+1.qemu-img.exe create hdd.img 10G
+2.qemu-system-x86_64.exe -m 8096 hdd.img -cdrom ubuntu22.04-desktop-amd64.iso  -machine pc
+Additional information:
+both Use qemu v8.0 and qemu v8.1 to test, but failed also
diff --git a/gitlab/issues_text/target_missing/host_arm/accel_missing/443 b/gitlab/issues_text/target_missing/host_arm/accel_missing/443
new file mode 100644
index 00000000..b8059db5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_arm/accel_missing/443
@@ -0,0 +1 @@
+QEMU on Windows aarch64
diff --git a/gitlab/issues_text/target_missing/host_loongarch64/accel_missing/2230 b/gitlab/issues_text/target_missing/host_loongarch64/accel_missing/2230
new file mode 100644
index 00000000..c5b97a43
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_loongarch64/accel_missing/2230
@@ -0,0 +1,141 @@
+Problems running x86_64 programs on loongarch64 platform
+Description of problem:
+There is also a running service program on the platform, and **gate_svr** program needs to communicate with it. The following problem occurs:
+```
+ERROR:../plugins/core.c:220:qemu_plugin_vcpu_init_hook: assertion failed: (success)
+Bail out! ERROR:../plugins/core.c:220:qemu_plugin_vcpu_init_hook: assertion failed: (success)
+```
+The following is the log：
+```
+[root@localhost bin]# ./gate_svr -y 0 -g 1 -p 18700 -i 127.0.0.1 -l 127.0.0.1,18082
+V4.3.20.1-build-20240126.210622
+NdsGate : start
+yan_lis:0
+unix_domain_name=/tmp/test_1.ss
+conf dir: /root/sql_proxy/gate/conf
+
+
+indicate port:18700
+indicate ipv6_support:0
+indicate link-ctl:127.0.0.1,18082
+
+directory:/root/operating/oci_test/bin
+processname:gate_svr
+model_path_in:/root/operating/oci_test/conf/in model_path_out:/root/operating/oci_test/conf/out
+tr: 写入错误: 断开的管道
+tr: 写入错误
+
+----------------------------------------------------------------------
+
+Create SGA, shmid = 53608511
+----------------------------------------------------------------------
+
+Attach SGA, shmid = 53608511, sga_address = 0xffb5700000
+----------------------------------------------------------------------
+
+Init SGA, shmid = 53608511, sga_address = 0xffb5700000,ret = 0
+----------------------------------------------------------------------
+tr: 写入错误: 断开的管道
+tr: 写入错误
+fc_shmid:50003996 
+tr: 写入错误: 断开的管道
+tr: 写入错误
+ai_shmid:50036765 
+/tmp/alarm_report_log is exist, no need create
+NdsGate : start thread->>anhua_lock_detecter sucess! shmid_t=53608511 loop_time=3
+new NCSocket sk_:6
+-------------Detect Mutex-----------
+mypid = 20953
+ControllerClient::startConnect ip:127.0.0.1, port:18082
+connect success, socket:6
+NdsGate : connect to controller ok, send handshake packet ...sk:6 
+check cen_time_enable 0 0
+NdsGate : handshake ok, gate id is 1
+get_node_name->gid=1,node_name=configuration_1
+shm get ok, config_store len: 9924
+
+
+start config init...
+
+----------------------------------------------------------------------
+Ƥ׃½㏶א...
+
+~~~~~~~~~~~~~~~~~~~~~~log1
+~~~~~~~~~~~~~~~~~~~~~~log2
+~~~~~~~~~~~~~~~~~~~~~~log3
+~~~~~~~~~~~~~~~~~~~~~~log4
+~~~~~~~~~~~~~~~~~~~~~~log5
+~~~~~~~~~~~~~~~~~~~~~~log6
+~~~~~~~~~~~~~~~~~~~~~~log7
+~~~~~~~~~~~~~~~~~~~~~~log8
+Ƥ׃½㏶ºŊ±: 0.000000(s)
+
+
+----------------------------------------------------------------------
+
+
+log file name->./nds.log_0
+g_ai_check=0
+nds_config_rule_database_creatºŊ±: 0.000000(s)
+nds_config_app_rule_database_creatºŊ±: 0.000000(s)
+nds_config_real_database_creatºŊ±: 0.000000(s)
+nds_config_virtual_database_creatºŊ±: 0.000000(s)
+nds_config_app_creatºŊ±: 0.000000(s)
+nds_config_app_server_createºŊ±: 0.000000(s)
+
+
+app-vdb-ip config list:
+
+
+inner_list=1
+default_list=2
+
+----------------------------------------------------------------------
+
+Start attach, shmid = 53608511
+----------------------------------------------------------------------
+
+Attach SGA, shmid = 53608511, sga_address = 0xff65000000
+----------------------------------------------------------------------
+1
+
+Load rules, shmid = 53608511, sga_address = 0xff65000000,ret = -1
+2----------------------------------------------------------------------
+
+SqlEngine_AppRulesMap ret=0
+
+----------------------------------------------------------------------
+gate disconnect from ctl ok
+
+ctl config trans_mode=1
+getReadBufferLength bev is null !! sock:-646169440
+
+gate_net_name:bond1
+grep: /etc/keepalived/keepalived.conf: 没有那个文件或目录
+
+get_bond_ip->cmd=grep -w -A 2 'virtual_ipaddress' /etc/keepalived/keepalived.conf|grep bond1|grep -v 'virtual_ipaddress'|awk '{print $1}'
+grep: /etc/keepalived/keepalived.conf: 没有那个文件或目录
+
+get_bond_ip->cmd=grep -w -A 2 'virtual_ipaddress' /etc/keepalived/keepalived.conf|grep bond1|grep -v 'virtual_ipaddress'|awk '{print $1}'
+grep: /etc/keepalived/keepalived.conf: 没有那个文件或目录
+
+get_bond_ip->cmd=grep -w -A 2 'virtual_ipaddress_excluded' /etc/keepalived/keepalived.conf|grep bond1|grep -v 'virtual_ipaddress_excluded'|awk '{print $1}'
+grep: /etc/keepalived/keepalived.conf: 没有那个文件或目录
+
+get_bond_ip->cmd=grep -w -A 2 'virtual_ipaddress_excluded' /etc/keepalived/keepalived.conf|grep bond1|grep -v 'virtual_ipaddress_excluded'|awk '{print $1}'
+grep: /etc/keepalived/keepalived.conf: 没有那个文件或目录
+
+get_bond_ip->cmd=grep -w -A 2 'virtual_ipaddress' /etc/keepalived/keepalived.conf|grep bond1|grep -v 'virtual_ipaddress'|awk '{print $1}'
+grep: /etc/keepalived/keepalived.conf: 没有那个文件或目录
+
+get_bond_ip->cmd=grep -w -A 2 'virtual_ipaddress' /etc/keepalived/keepalived.conf|grep bond1|grep -v 'virtual_ipaddress'|awk '{print $1}'
+
+listen_ip(ipv4):0.0.0.0
+
+gate_epoll_start...
+**
+ERROR:../plugins/core.c:220:qemu_plugin_vcpu_init_hook: assertion failed: (success)
+Bail out! ERROR:../plugins/core.c:220:qemu_plugin_vcpu_init_hook: assertion failed: (success)
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_loongarch64/accel_missing/2336 b/gitlab/issues_text/target_missing/host_loongarch64/accel_missing/2336
new file mode 100644
index 00000000..ed291a27
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_loongarch64/accel_missing/2336
@@ -0,0 +1,23 @@
+qemu-x86_64 crash on LoongArch
+Description of problem:
+
+Steps to reproduce:
+1. build a static  hello test on x86_64 machine.
+2. build qemu-x86_64 on LoongArch.
+3. run 'qemu-x86_64 hello 'on LoongArch.
+Additional information:
+1  result
+
+[root@localhost qemu]# ./build/qemu-x86_64 ~/hello  
+Bus error (core dumped)
+
+2  Since commit 45bf0e7aa648369cf8ab2333bd20144806fc1be3 
+
+3  full log with -d in_asm,op,out_asm,strace
+see log.txt
+
+[log.txt](/uploads/9a0e3250bfafa6db31d6688b8c60feb7/log.txt)
+
+[qemu-x86_64](/uploads/728fc4f4633054097b6028cd99a20e8b/qemu-x86_64)
+
+[hello](/uploads/d7dec3bdb844273a8e26464ed418c1a0/hello)
diff --git a/gitlab/issues_text/target_missing/host_loongarch64/accel_missing/2504 b/gitlab/issues_text/target_missing/host_loongarch64/accel_missing/2504
new file mode 100644
index 00000000..1147f584
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_loongarch64/accel_missing/2504
@@ -0,0 +1,7 @@
+linux-user:   qemu-x86_64   run /bin/XX got some error on LoongArch machine
+Description of problem:
+on LoongArch host,   chroot x86_64-rootfs   then run 'ls' got some error.
+Steps to reproduce:
+[chrootlog.txt](/uploads/2b77e7d9216396491ef4dc42bf24acc0/chrootlog.txt)
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_loongarch64/accel_missing/2871 b/gitlab/issues_text/target_missing/host_loongarch64/accel_missing/2871
new file mode 100644
index 00000000..8b6d854e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_loongarch64/accel_missing/2871
@@ -0,0 +1 @@
+loongarch64: unknown register name 'f0' in asm
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HAX/188 b/gitlab/issues_text/target_missing/host_missing/accel_HAX/188
new file mode 100644
index 00000000..a4dcb3c8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HAX/188
@@ -0,0 +1 @@
+savevm with hax saves wrong register state
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/1011 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1011
new file mode 100644
index 00000000..4307c03d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1011
@@ -0,0 +1,21 @@
+hvf: RDTSCP capability not passed to guests
+Description of problem:
+
+Steps to reproduce:
+1. Run:
+wget https://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x86/alpine-standard-3.15.4-x86.iso
+./qemu-system-x86_64 -cpu host,+rdtscp -machine q35,accel=hvf -m 512 -cdrom ./alpine-standard-3.15.4-x86.iso
+
+2. login as "root"
+3. type
+
+cat /etc/cpuinfo | grep rdtscp
+
+Expected result: cpu flag lines including rdtscp
+Actual result: empty, with:
+
+warning: host doesn't support requested feature: CPUID.80000001H:EDX.rdtscp [bit 27]
+Additional information:
+This patch apparently resolves the issue according to my tests:
+
+https://lore.kernel.org/qemu-devel/20211101054836.21471-1-dirty@apple.com/
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/1091 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1091
new file mode 100644
index 00000000..fb807aaf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1091
@@ -0,0 +1,13 @@
+qemu-system-x86_64 hard crashes when using `--accel hvf` on intel Mac
+Description of problem:
+The QEMU process hard crashes after a few minutes. The only message is:
+
+```
+vmx_write_mem: mmu_gva_to_gpa ffff990489fa0000 failed
+```
+Steps to reproduce:
+1. Run QEMU with the above commandline
+2. Do something to keep the VM busy - running `git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git` reliably crashes it for me
+3. Wait a 3-5 minutes
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/1299 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1299
new file mode 100644
index 00000000..8c7d34ba
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1299
@@ -0,0 +1,24 @@
+User networking with an SMB Share while not running as root
+Description of problem:
+When attempting to write a file to the qemu share, Samba always responds with NT_STATUS_ACCESS_DENIED.
+
+This only happens on the MacOS version of Samba, on Linux it appears to work without issues for now.
+Steps to reproduce:
+1. Start a VM with a SMB share attached to it
+2. Create a test file to upload `touch test-file.txt`
+3. Upload the test file `smbclient //10.0.2.4/qemu -c 'put test-file.txt'
+Additional information:
+QEMU has been using Samba for it's SMB shares for quite some time now.
+But in the 4.17.x release a bug has appeared in the MacOS Build of Samba.
+
+I've filed a bug with Samba, and suggested a fix for it.
+https://bugzilla.samba.org/show_bug.cgi?id=15215
+
+The origin of the bug lies in the fact that when running SMBD as a non-root user, a function sets `errno` unexpectedly.
+But after discussing this with Samba, they concluded that running smbd as an un-privileged user is not a supported use case.
+
+Whilst this is not a QEMU bug per se, it is caused by the fact that QEMU is running smbd in an unsupported manner.
+
+As a side note, on Linux this bug does not appear to exist as of yet.
+The Linux version of `unbecome_root` doesn't seem to set `errno`. (tested on a recent ArchLinux install).
+But I think this depends on the LibC implementation of setuid/seteuid/setreuid/etc. so I can't say it won't happen in the future, or with a different LibC implementation.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/1364 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1364
new file mode 100644
index 00000000..77ce3808
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1364
@@ -0,0 +1,15 @@
+Support vmnet networking without elevated permissions
+Additional information:
+Here is a command, that doesn't work when running as normal user:
+```bash
+$ qemu-system-aarch64 \
+    -device virtio-net-pci,netdev=net0 \
+    -netdev vmnet-bridged,id=net0,ifname=en0 \
+    -machine virt
+```
+It fails with:
+```
+qemu-system-aarch64: -netdev vmnet-bridged,id=net0,ifname=en0: cannot create vmnet interface: general failure (possibly not enough privileges)
+```
+
+When running the same command using elevated permissions (i.e. via `sudo`), it works without any issue.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/1571 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1571
new file mode 100644
index 00000000..2a70dcaf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/1571
@@ -0,0 +1,12 @@
+accel/hvf: Instance size not properly declared
+Description of problem:
+In [`include/sysemu/hvf.h`](https://gitlab.com/qemu-project/qemu/-/blob/master/include/sysemu/hvf.h#L36), `HVFState` is declared to have the QOM type `TYPE_HVF_ACCEL`;
+However, when the type is registered, proper `instance_size` for it was [not declared](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/hvf/hvf-accel-ops.c#L351).
+
+As a result, a bad workaround was introduced. That is, when [`hvf_accel_init`](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/hvf/hvf-accel-ops.c#L329) is called from [`accel_init_machine`](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/accel-softmmu.c#L33), an new instance of `HVFState` is allocated while we should have used the pre-allocated instance in `ms->accelerator` similar to [what KVM does](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/kvm/kvm-all.c#L2381) (the code didn't do so since the allocated ([using `object_new_with_class`](https://gitlab.com/qemu-project/qemu/-/blob/master/softmmu/vl.c#L2218)) instance didn't allocate enough memory for `HVFState`).
+
+Eventhough the code wouldn't crash nor have any serious implication, this would leak an `AccelState` and attempts to manually manage accelerators would cause a buffer-overflow.
+Steps to reproduce:
+1. Run a HVF-accelerated VM
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/2258 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/2258
new file mode 100644
index 00000000..0ed2d01d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/2258
@@ -0,0 +1,23 @@
+Breakpoint setting not working on apple Mac host
+Description of problem:
+1. When use with parameter "-machine virt,accel=hvf -cpu host" to run launch a emulator, it can't set breakpoint and will report error: "warning: failed to set breakpoint site at 0xffff800081bf03cc for breakpoint 1.1: error: 34 sending the breakpoint request"
+but if not use with parameter "-machine virt -cpu cortex-a57"，The breakpoint can be set successfully.
+
+2. Set hardware breakpoint with lldb command "breakpoint set -H -a 0xFFFF800080000000" not report error, but can't hint breakpoint. I try set breakpoint on a old x86 MacOS, It will hint breakpoint successfully.
+
+3. I also try run qemu-system-x86_64 emulator on apple silicon mac, It also can't hint hardware breakping. The command is:
+```
+qemu-system-x86_64 -machine q35,accel=tcg -smp cpus=8  \
+  -kernel arch/x86/boot/bzImage \
+  -append "okaslr"\
+  -nographic -serial mon:stdio \
+  -m 16G \
+  -s -S
+```
+Steps to reproduce:
+1. Launch qemu on Apple silicon Mac. Remember to user "hvf" 
+2. Launch lldb or gdb to set breakpoint.
+3. Set breakpoint and hardware breakpoint.
+4. resume to run qemu by lldb.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/2800 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/2800
new file mode 100644
index 00000000..09155f41
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/2800
@@ -0,0 +1,7 @@
+-accel hvf: Error: ret = HV_DENIED (0xfae94007, at ../accel/hvf/hvf-accel-ops.c:334)
+Description of problem:
+QEMU fails to use -accel i.e., qemu-system-aarch64-unsigned: -accel hvf: Error: ret = HV_DENIED (0xfae94007, at ../accel/hvf/hvf-accel-ops.c:334)
+Steps to reproduce:
+1. Execute the above QEMU command line on a macOS Sequia 15.3
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/444 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/444
new file mode 100644
index 00000000..82aeeaa7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/444
@@ -0,0 +1 @@
+EFI stub: ERROR: This 64 KB granular kernel is not supported by your CPU
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_HVF/899 b/gitlab/issues_text/target_missing/host_missing/accel_HVF/899
new file mode 100644
index 00000000..297cef0c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_HVF/899
@@ -0,0 +1,14 @@
+HVF: Ubuntu Server fails to boot Linux 5.4.0-104
+Description of problem:
+On macOS with HVF, when Ubuntu Server updates the Linux kernel to 5.4.0-104, it no longer boots and gets stuck at `EFI stub: Exiting boot services and installing virtual address map...`. This is not the case with QEMU 6.0.0 (with @agraf's HVF patches applied).
+
+It seems like 5.4.0-104 is the culprit because 5.4.0-100 boots fine.
+Steps to reproduce:
+1. Download Ubuntu Server 20.04 ARM64 ISO: https://ubuntu.com/download/server/arm
+2. Run the above QEMU command (make sure networking is disabled so Ubuntu installer does not auto-upgrade the kernel)
+3. Install Ubuntu with the default settings and reboot
+4. It will not reboot (expected) so Ctrl+C and restart the command adding `-device virtio-net-pci,netdev=net0 -netdev user,id=net0` to the end to get networking
+5. Boot into Ubuntu and install 5.4.0-104 kernel: `sudo apt install linux-image-5.4.0-104-generic`
+6. Reboot and it will get stuck at `EFI stub: Exiting boot services and installing virtual address map...`
+Additional information:
+![image](/uploads/5151ce8ae43911f503411902d330470c/image.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/1003 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/1003
new file mode 100644
index 00000000..f21487f3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/1003
@@ -0,0 +1,21 @@
+"Cannot allocate memory" when boots a VM > 1026GB memory with -accel kvm
+Description of problem:
+I can boot an empty VM using command `qemu-system-x86_64 -m 1026G -accel kvm -vnc :1` or `qemu-system-x86_64 -m 8T -vnc :1`
+
+But when I use `qemu-system-x86_64 -m 1027G -accel kvm -vnc :1`, it will not boot:
+
+```
+root@debian11:~# qemu-system-x86_64 -m 1027G -accel kvm -vnc :1
+qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=1, start=0x100000000, size=0x10000000000: Cannot allocate memory
+kvm_set_phys_mem: error registering slot: Cannot allocate memory
+Aborted
+```
+
+Which means, with `-accel kvm`, it only can boot a VM which memory <= 1026G, but without these args, it can boot whatever you want.
+Steps to reproduce:
+1. sysctl vm.overcommit_memory=1  # enable overcommit first
+2. qemu-system-x86_64 -m 1027G -accel kvm -vnc :1
+Additional information:
+The qemu I use is compiled from the latest source, not the package provided by debian.
+
+Hardware is `PowerEdge R630` with `E5-2630 v4` * 2, 128G physical RAM.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/1009 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/1009
new file mode 100644
index 00000000..37e54546
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/1009
@@ -0,0 +1,23 @@
+Nested KVM Networking Issue (OpenStack)
+Description of problem:
+Hi, 
+
+Inside openstack i have an instance of Ubuntu 20.04 and i have installed KVM ( using virt-manager ) to setup a Virtual Machine ... i have done that and i created a VM of ubuntu 20.04 inside the Openstack Instance but there are networking issue while i set the default parameter as setting up the VM ( i mean the networking is as default to NAT ) , So when the VM is up and running the PING to 8.8.8.8 is available and also ping to google.com is also valid which shows that the DNS is correctly working ... but there is not connectivity with packages while i do sudo apt update, it will not get any package update and also the wget to google.com is shows that its connected to it but it wont able to download!!! the same happen with curl to any other websites...
+
+
+I'm confirming that the openstack instance has full access to the internet including ping and wget , .... but the VM is not working correctly!
+
+P.S. I have set the ip forwarding, Iptables , ... also disabled firewals but notting changed!!
+
+
+Would you please fix this ?
+Steps to reproduce:
+1. creating an openstack instance from ubuntu 20.04 server image
+2. updating and upgrading packages setting ip forwarding to 1 ( Enabled), firewall
+3. and kernel to 5.13.0.40 and installing virt-manager then reboot 
+3. creating a VM with default KVM networking ( NAT ) using ubuntu 20.04 server image
+4. trying ping, wget, curl , ...
+
+
+Thanks
+Best regards
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/110 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/110
new file mode 100644
index 00000000..392bb89d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/110
@@ -0,0 +1 @@
+KVM guest VM does not reattach a throughpassed USB printer from Host after switching printer off and on
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/1274 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/1274
new file mode 100644
index 00000000..5ab368da
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/1274
@@ -0,0 +1,32 @@
+Cannot debug init using "qemu -s -S" if init is compiled dynamically or if kvm is enabled
+Description of problem:
+I'm trying to connect from host to init process running in guest. I'm using this guide: https://qemu-project.gitlab.io/qemu/system/gdb.html . Everything works well, but there is two problems:
+1. Debugging stops to work if I add "-enable-kvm"
+2. Debugging stops to work if I remove "-static" when compiling init
+Steps to reproduce:
+I have absolutely fresh Debian sid system (as of 2022-10-22). I create the following file on it:
+```c
+#include <stdio.h>
+
+int
+main ()
+{
+  printf ("a\n");
+  printf ("b\n");
+  for (;;);
+}
+```
+
+Then I compile it so: `gcc -static -g a.c`. Result is saved as `/root/a.out`. Then I run `sync; echo 3 > /proc/sys/vm/drop_caches; sync` to make sure this `/root/a.out` actually got to disk.
+
+Then I start the host system inside of qemu using well-known `-snapshot /dev/sda` trick. Exact command is here:
+
+```bash
+qemu-system-x86_64 -daemonize -m 300M -s -S -kernel /vmlinuz -initrd /initrd.img -snapshot -append "root=/dev/sda init=/root/a.out" -drive file=/dev/sda,format=raw
+```
+
+(As you guessed, my disk has no partitions, it directly stores ext4 filesystem.)
+
+Then I type on host `gdb ./a.out`. And then inside of gdb I type `target remote localhost:1234`, then `br 7` (line 7 is `printf ("b\n")`, then `c`. Then guest OS boots and reaches init (i. e. `/root/a.out`). And then gdb actually pauses on line 7. I. e. everything works!
+
+But if I add `-enable-kvm` to qemu command line OR remove `-static` from gcc command line, then breakpoint doesn't work, i. e. gdb doesn't pause on breakpoint, the execution continues and the execution fails to infinite loop.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/1344 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/1344
new file mode 100644
index 00000000..ad31baac
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/1344
@@ -0,0 +1 @@
+custom kernel give me KVM internal error. Suberror: 4
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/165 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/165
new file mode 100644
index 00000000..bf44e640
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/165
@@ -0,0 +1 @@
+No evdev mouse passthrough with virtio-vga or kvm
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/1936 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/1936
new file mode 100644
index 00000000..6d00582e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/1936
@@ -0,0 +1 @@
+Pass file descriptor to /dev/kvm device node?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/1999 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/1999
new file mode 100644
index 00000000..29f70125
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/1999
@@ -0,0 +1,51 @@
+qemu got sigabrt when using vpp in guest and dpdk for qemu
+Description of problem:
+When set the interface up in vpp, the qemu process is crashed with signal sigabrt. 
+
+After some debug, i have identified that the problem lies in the following function.
+
+```c
+static int setup_routing_entry(struct kvm *kvm,
+			       struct kvm_irq_routing_table *rt,
+			       struct kvm_kernel_irq_routing_entry *e,
+			       const struct kvm_irq_routing_entry *ue)
+{
+	struct kvm_kernel_irq_routing_entry *ei;
+	int r;
+	u32 gsi = array_index_nospec(ue->gsi, KVM_MAX_IRQ_ROUTES);
+
+	/*
+	 * Do not allow GSI to be mapped to the same irqchip more than once.
+	 * Allow only one to one mapping between GSI and non-irqchip routing.
+	 */
+	hlist_for_each_entry(ei, &rt->map[gsi], link)
+		if (ei->type != KVM_IRQ_ROUTING_IRQCHIP ||
+		    ue->type != KVM_IRQ_ROUTING_IRQCHIP ||
+		    ue->u.irqchip.irqchip == ei->irqchip.irqchip)
+			return -EINVAL;
+
+```
+
+I added some debug printk like following
+
+```c
+        hlist_for_each_entry(ei, &rt->map[gsi], link)
+                if (ei->type != KVM_IRQ_ROUTING_IRQCHIP ||
+                    ue->type != KVM_IRQ_ROUTING_IRQCHIP ||
+                    ue->u.irqchip.irqchip == ei->irqchip.irqchip){
+                        printk("ei->type: %u, KVM_IRQ_ROUTING_IRQCHIP: %u, ue->type: %u, ue->u.irqchip.irqchip: %u , ei->irqchip.irqchip: %u",  ei->type, KVM_IRQ_ROUTING_IRQCHIP , ue->type, ue->u.irqchip.irqchip , ei->irqchip.irqchip);
+                        return -EINVAL;
+        }
+```
+
+Then i got following in dmesg
+
+```
+[Thu Nov 23 09:29:10 2023] ei->type: 2, KVM_IRQ_ROUTING_IRQCHIP: 1, ue->type: 1, ue->u.irqchip.irqchip: 2 , ei->irqchip.irqchip: 4276097024
+[Thu Nov 23 09:29:10 2023] ei->type: 2, KVM_IRQ_ROUTING_IRQCHIP: 1, ue->type: 1, ue->u.irqchip.irqchip: 2 , ei->irqchip.irqchip: 4276097024
+```
+Steps to reproduce:
+This is a kube-ovn + dpdk env, not easy to reproduce now..
+Additional information:
+* I also file a bug on kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=218177
+* the libvirt xml file is also attached [instance.xml](/uploads/05b391046fdc1263fd7e63bcfab6f4fb/instance.xml)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/2321 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2321
new file mode 100644
index 00000000..fcc4a1da
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2321
@@ -0,0 +1,40 @@
+Segfault when hibernating a KVM VM with QEMU 8.2.3
+Description of problem:
+Attempting to hibernate the machine crashes QEMU.
+Steps to reproduce:
+This involves Nix, please tell me if you want a reproducer that doesn't.
+
+1. nix build github:NixOS/nixpkgs#nixosTests.hibernate.driver
+2. ./result/bin/nixos-test-driver
+3. Observe crash
+Additional information:
+Backtrace:
+
+```
+#0  kvm_virtio_pci_vq_vector_release (proxy=0x55bd979fd130, vector=<optimized out>) at ../hw/virtio/virtio-pci.c:834
+#1  kvm_virtio_pci_vector_release_one (proxy=proxy@entry=0x55bd979fd130, queue_no=queue_no@entry=0) at ../hw/virtio/virtio-pci.c:965
+#2  0x000055bd9380c430 in virtio_pci_set_vector (vdev=0x55bd97a05500, proxy=0x55bd979fd130, queue_no=0, old_vector=1, new_vector=65535)
+    at ../hw/virtio/virtio-pci.c:1445
+#3  0x000055bd939c5490 in memory_region_write_accessor (mr=0x55bd979fdc70, addr=26, value=<optimized out>, size=2, shift=<optimized out>, 
+    mask=<optimized out>, attrs=...) at ../system/memory.c:497
+#4  0x000055bd939c4d56 in access_with_adjusted_size (addr=addr@entry=26, value=value@entry=0x7ff49d1ff3e8, size=size@entry=2, 
+    access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55bd939c5410 <memory_region_write_accessor>, mr=<optimized out>, 
+    attrs=...) at ../system/memory.c:573
+#5  0x000055bd939c5081 in memory_region_dispatch_write (mr=mr@entry=0x55bd979fdc70, addr=addr@entry=26, data=<optimized out>, op=<optimized out>, 
+    attrs=attrs@entry=...) at ../system/memory.c:1528
+#6  0x000055bd939ccb0c in flatview_write_continue (fv=fv@entry=0x7ff4445771c0, addr=addr@entry=61572651286554, attrs=..., attrs@entry=..., 
+    ptr=ptr@entry=0x7ff4a082d028, len=len@entry=2, addr1=<optimized out>, l=<optimized out>, mr=0x55bd979fdc70) at ../system/physmem.c:2714
+#7  0x000055bd939ccd83 in flatview_write (fv=0x7ff4445771c0, addr=addr@entry=61572651286554, attrs=attrs@entry=..., buf=buf@entry=0x7ff4a082d028, 
+    len=len@entry=2) at ../system/physmem.c:2756
+#8  0x000055bd939d0099 in address_space_write (len=2, buf=0x7ff4a082d028, attrs=..., addr=61572651286554, as=0x55bd94a4e720 <address_space_memory>)
+    at ../system/physmem.c:2863
+#9  address_space_rw (as=0x55bd94a4e720 <address_space_memory>, addr=61572651286554, attrs=attrs@entry=..., buf=buf@entry=0x7ff4a082d028, len=2, 
+    is_write=<optimized out>) at ../system/physmem.c:2873
+#10 0x000055bd93a24548 in kvm_cpu_exec (cpu=cpu@entry=0x55bd9628a3e0) at ../accel/kvm/kvm-all.c:2915
+#11 0x000055bd93a25795 in kvm_vcpu_thread_fn (arg=arg@entry=0x55bd9628a3e0) at ../accel/kvm/kvm-accel-ops.c:51
+#12 0x000055bd93bb5fa8 in qemu_thread_start (args=0x55bd96294940) at ../util/qemu-thread-posix.c:541
+#13 0x00007ff4a19fd272 in start_thread (arg=<optimized out>) at pthread_create.c:447
+#14 0x00007ff4a1a78dcc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
+```
+
+Bisected to https://gitlab.com/qemu-project/qemu/-/commit/fcbb086ae590e910614fe5b8bf76e264f71ef304, reverting that change seems to make things work again.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/2324 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2324
new file mode 100644
index 00000000..62055cad
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2324
@@ -0,0 +1,47 @@
+SELinux is preventing some qemu-kvm operations on CentOS Stream 9
+Description of problem:
+Some operations are being denied by SELinux.
+
+First it was read access on file max_map_count, then open and getattr access on /proc/sys/vm/max_map_count (same file but with full path).
+
+All have been fixed by creating and applying a semodule with the TE policy shown on "Additional Information" below.
+
+```
+May  2 18:01:00 rd02 setroubleshoot[14757]: SELinux is preventing /usr/libexec/qemu-kvm from read access on the file max_map_count. For complete SELinux messages run: sealert -l c92d5506-0b40-4bc8-be6a-133fe360014d
+May  2 18:01:00 rd02 setroubleshoot[14757]: SELinux is preventing /usr/libexec/qemu-kvm from read access on the file max_map_count.#012#012*****  Plugin qemu_file_image (98.8 confidence) suggests   *******************#012#012If max_map_count is a virtualization target#012Then you need to change the label on max_map_count'#012Do#012# semanage fcontext -a -t virt_image_t 'max_map_count'#012# restorecon -v 'max_map_count'#012#012*****  Plugin catchall (2.13 confidence) suggests   **************************#012#012If you believe that qemu-kvm should be allowed read access on the max_map_count file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm#012# semodule -X 300 -i my-qemukvm.pp#012
+
+---
+
+May  3 10:24:58 rd02 setroubleshoot[3981]: SELinux is preventing /usr/libexec/qemu-kvm from open access on the file /proc/sys/vm/max_map_count. For complete SELinux messages run: sealert -l 655af27c-6bc7-4278-9aad-7fc99929d24b
+May  3 10:24:58 rd02 setroubleshoot[3981]: SELinux is preventing /usr/libexec/qemu-kvm from open access on the file /proc/sys/vm/max_map_count.#012#012*****  Plugin qemu_file_image (98.8 confidence) suggests   *******************#012#012If max_map_count is a virtualization target#012Then you need to change the label on max_map_count'#012Do#012# semanage fcontext -a -t virt_image_t '/proc/sys/vm/max_map_count'#012# restorecon -v '/proc/sys/vm/max_map_count'#012#012*****  Plugin catchall (2.13 confidence) suggests   **************************#012#012If you believe that qemu-kvm should be allowed open access on the max_map_count file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm#012# semodule -X 300 -i my-qemukvm.pp#012
+
+---
+
+May  3 10:41:17 rd02 setroubleshoot[6894]: SELinux is preventing /usr/libexec/qemu-kvm from getattr access on the file /proc/sys/vm/max_map_count. For complete SELinux messages run: sealert -l db78c5b9-3890-44d4-a40e-d4011ad42913
+May  3 10:41:17 rd02 setroubleshoot[6894]: SELinux is preventing /usr/libexec/qemu-kvm from getattr access on the file /proc/sys/vm/max_map_count.#012#012*****  Plugin qemu_file_image (98.8 confidence) suggests   *******************#012#012If max_map_count is a virtualization target#012Then you need to change the label on max_map_count'#012Do#012# semanage fcontext -a -t virt_image_t '/proc/sys/vm/max_map_count'#012# restorecon -v '/proc/sys/vm/max_map_count'#012#012*****  Plugin catchall (2.13 confidence) suggests   **************************#012#012If you believe that qemu-kvm should be allowed getattr access on the max_map_count file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm#012# semodule -X 300 -i my-qemukvm.pp#012
+
+
+```
+Steps to reproduce:
+1. On a CentOS Stream 9 system with a selinux enforced, create a VM and install an OS with cockpit or with virt-install.    
+        - example with virt-install:    
+                  `virt-install --connect qemu:///system --os-variant centos-stream9 --reinstall ipa03 --wait -1 --location  /mnt/CentOS-Stream9.iso`
+2. Check the SELinux logs, either on cockpit or on /var/log/messages
+Additional information:
+TE module that solved the issue, created with `ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm`
+
+```
+module my-qemukvm 1.1;
+
+require {
+        type sysctl_vm_t;
+        type svirt_t;
+        class file { getattr open read };
+}
+
+#============= svirt_t ==============
+
+#!!!! This avc is allowed in the current policy
+allow svirt_t sysctl_vm_t:file read;
+allow svirt_t sysctl_vm_t:file { getattr open };
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/2414 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2414
new file mode 100644
index 00000000..80d82e67
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2414
@@ -0,0 +1,117 @@
+qemu 9.0.0 crashing with OpenBSD 7.5
+Description of problem:
+After upgrading from Qemu 8.23 to 9.0 this virtual does not start anymore (others do). The bootloader runs fine and starts the OpenBSD kernel, some kernel messages are shown on VGA console. It never reaches userland.
+Additional information:
+```
+Jun 29 07:15:10 hypervisor kernel: qemu-system-x86[12021]: segfault at 14 ip 000056547310bee4 sp 00007fc6d68c8310 error 4 in qemu-system-x86_64[565472ee0000+6ea000]
+Jun 29 07:15:10 hypervisor kernel: Code: 01 00 00 48 83 c4 58 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 1f 40 00 89 f0 48 8b 8b 40 83 00 00 4c 8d 0c 40 49 c1 e1 03 4c 01 c9 <8b> 41 14 85 c0 0f 84 11 01 00 00 83 c0 01 89 41 14 41 80 bf d1 01
+Jun 29 07:15:10 hypervisor systemd[1]: Started Process Core Dump (PID 12122/UID 0).
+Jun 29 07:15:39 hypervisor systemd-coredump[12123]: Process 12017 (qemu-system-x86) of user 954 dumped core.
+
+                                                   Stack trace of thread 12021:
+                                                   #0 0x000056547310bee4 n/a (qemu-system-x86_64 + 0x397ee4)
+                                                   #1 0x000056547330d5e2 n/a (qemu-system-x86_64 + 0x5995e2)
+                                                   #2 0x000056547330dba6 n/a (qemu-system-x86_64 + 0x599ba6)
+                                                   #3 0x000056547330e059 memory_region_dispatch_write (qemu-system-x86_64 + 0x59a059)
+                                                   #4 0x00005654735c1e1f n/a (qemu-system-x86_64 + 0x84de1f)
+                                                   #5 0x0000565473314a7d n/a (qemu-system-x86_64 + 0x5a0a7d)
+                                                   #6 0x0000565473314b76 address_space_write (qemu-system-x86_64 + 0x5a0b76)
+                                                   #7 0x000056547336cafe kvm_cpu_exec (qemu-system-x86_64 + 0x5f8afe)
+                                                   #8 0x000056547336f56e n/a (qemu-system-x86_64 + 0x5fb56e)
+                                                   #9 0x000056547352fca8 n/a (qemu-system-x86_64 + 0x7bbca8)
+                                                   #10 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded)
+                                                   #11 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc)
+
+                                                   Stack trace of thread 12026:
+                                                   #0 0x00007fc6d93b3740 n/a (libc.so.6 + 0x8f740)
+                                                   #1 0x00007fc6d93ba551 pthread_mutex_lock (libc.so.6 + 0x96551)
+                                                   #2 0x0000565473535858 qemu_mutex_lock_impl (qemu-system-x86_64 + 0x7c1858)
+                                                   #3 0x000056547313f906 bql_lock_impl (qemu-system-x86_64 + 0x3cb906)
+                                                   #4 0x00005654735c1c7f n/a (qemu-system-x86_64 + 0x84dc7f)
+                                                   #5 0x0000565473313776 flatview_read_continue (qemu-system-x86_64 + 0x59f776)
+                                                   #6 0x0000565473314df0 n/a (qemu-system-x86_64 + 0x5a0df0)
+                                                   #7 0x0000565473314eb6 address_space_read_full (qemu-system-x86_64 + 0x5a0eb6)
+                                                   #8 0x000056547336cdf5 kvm_cpu_exec (qemu-system-x86_64 + 0x5f8df5)
+                                                   #9 0x000056547336f56e n/a (qemu-system-x86_64 + 0x5fb56e)
+                                                   #10 0x000056547352fca8 n/a (qemu-system-x86_64 + 0x7bbca8)
+                                                   #11 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded)
+                                                   #12 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc)
+
+                                                   Stack trace of thread 12018:
+                                                   #0 0x00007fc6d9402f43 clock_nanosleep (libc.so.6 + 0xdef43)
+                                                   #1 0x00007fc6d940ed77 __nanosleep (libc.so.6 + 0xead77)
+                                                   #2 0x00007fc6d98ccee0 g_usleep (libglib-2.0.so.0 + 0x8dee0)
+                                                   #3 0x0000565473545a75 n/a (qemu-system-x86_64 + 0x7d1a75)
+                                                   #4 0x000056547352fca8 n/a (qemu-system-x86_64 + 0x7bbca8)
+                                                   #5 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded)
+                                                   #6 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc)
+
+                                                   Stack trace of thread 12020:
+                                                   #0 0x00007fc6d942c39d __poll (libc.so.6 + 0x10839d)
+                                                   #1 0x00007fc6d98fd8fd n/a (libglib-2.0.so.0 + 0xbe8fd)
+                                                   #2 0x00007fc6d989c787 g_main_loop_run (libglib-2.0.so.0 + 0x5d787)
+                                                   #3 0x00005654733bf7c2 n/a (qemu-system-x86_64 + 0x64b7c2)
+                                                   #4 0x000056547352fca8 n/a (qemu-system-x86_64 + 0x7bbca8)
+                                                   #5 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded)
+                                                   #6 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc)
+
+                                                   Stack trace of thread 12017:
+                                                   #0 0x00007fc6d942c910 ppoll (libc.so.6 + 0x108910)
+                                                   #1 0x000056547354ae83 qemu_poll_ns (qemu-system-x86_64 + 0x7d6e83)
+                                                   #2 0x000056547355800e main_loop_wait (qemu-system-x86_64 + 0x7e400e)
+                                                   #3 0x000056547337a337 qemu_default_main (qemu-system-x86_64 + 0x606337)
+                                                   #4 0x00007fc6d9349c88 n/a (libc.so.6 + 0x25c88)
+                                                   #5 0x00007fc6d9349d4c __libc_start_main (libc.so.6 + 0x25d4c)
+                                                   #6 0x0000565472ef08b5 _start (qemu-system-x86_64 + 0x17c8b5)
+
+                                                   Stack trace of thread 12025:
+                                                   #0 0x00007fc6d942c39d __poll (libc.so.6 + 0x10839d)
+                                                   #1 0x00007fc6d98fd8fd n/a (libglib-2.0.so.0 + 0xbe8fd)
+                                                   #2 0x00007fc6d989c787 g_main_loop_run (libglib-2.0.so.0 + 0x5d787)
+                                                   #3 0x00007fc6d78ff0cb n/a (libspice-server.so.1 + 0x530cb)
+                                                   #4 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded)
+                                                   #5 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc)
+
+                                                   Stack trace of thread 12117:
+                                                   #0 0x00007fc6d93b34e9 n/a (libc.so.6 + 0x8f4e9)
+                                                   #1 0x00007fc6d93b6242 pthread_cond_timedwait (libc.so.6 + 0x92242)
+                                                   #2 0x0000565473536546 n/a (qemu-system-x86_64 + 0x7c2546)
+                                                   #3 0x00005654735367ad qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x7c27ad)
+                                                   #4 0x00005654735569d5 n/a (qemu-system-x86_64 + 0x7e29d5)
+                                                   #5 0x000056547352fca8 n/a (qemu-system-x86_64 + 0x7bbca8)
+                                                   #6 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded)
+                                                   #7 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc)
+
+                                                   Stack trace of thread 12028:
+                                                   #0 0x00007fc6d93b3740 n/a (libc.so.6 + 0x8f740)
+                                                   #1 0x00007fc6d93ba551 pthread_mutex_lock (libc.so.6 + 0x96551)
+                                                   #2 0x0000565473535858 qemu_mutex_lock_impl (qemu-system-x86_64 + 0x7c1858)
+                                                   #3 0x000056547313f906 bql_lock_impl (qemu-system-x86_64 + 0x3cb906)
+                                                   #4 0x00005654735c1c7f n/a (qemu-system-x86_64 + 0x84dc7f)
+                                                   #5 0x0000565473313776 flatview_read_continue (qemu-system-x86_64 + 0x59f776)
+                                                   #6 0x0000565473314df0 n/a (qemu-system-x86_64 + 0x5a0df0)
+                                                   #7 0x0000565473314eb6 address_space_read_full (qemu-system-x86_64 + 0x5a0eb6)
+                                                   #8 0x000056547336cdf5 kvm_cpu_exec (qemu-system-x86_64 + 0x5f8df5)
+                                                   #9 0x000056547336f56e n/a (qemu-system-x86_64 + 0x5fb56e)
+                                                   #10 0x000056547352fca8 n/a (qemu-system-x86_64 + 0x7bbca8)
+                                                   #11 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded)
+                                                   #12 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc)
+
+                                                   Stack trace of thread 12027:
+                                                   #0 0x00007fc6d93b3740 n/a (libc.so.6 + 0x8f740)
+                                                   #1 0x00007fc6d93ba551 pthread_mutex_lock (libc.so.6 + 0x96551)
+                                                   #2 0x0000565473535858 qemu_mutex_lock_impl (qemu-system-x86_64 + 0x7c1858)
+                                                   #3 0x000056547313f906 bql_lock_impl (qemu-system-x86_64 + 0x3cb906)
+                                                   #4 0x00005654735c1c7f n/a (qemu-system-x86_64 + 0x84dc7f)
+                                                   #5 0x0000565473313776 flatview_read_continue (qemu-system-x86_64 + 0x59f776)
+                                                   #6 0x0000565473314df0 n/a (qemu-system-x86_64 + 0x5a0df0)
+                                                   #7 0x0000565473314eb6 address_space_read_full (qemu-system-x86_64 + 0x5a0eb6)
+                                                   #8 0x000056547336cdf5 kvm_cpu_exec (qemu-system-x86_64 + 0x5f8df5)
+                                                   #9 0x000056547336f56e n/a (qemu-system-x86_64 + 0x5fb56e)
+                                                   #10 0x000056547352fca8 n/a (qemu-system-x86_64 + 0x7bbca8)
+                                                   #11 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded)
+                                                   #12 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc)
+                                                   ELF object binary architecture: AMD x86-64
+Jun 29 07:15:40 hypervisor systemd[1]: systemd-coredump@2-12122-0.service: Deactivated successfully.
+Jun 29 07:15:40 hypervisor systemd[1]: systemd-coredump@2-12122-0.service: Consumed 20.231s CPU time.
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/2436 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2436
new file mode 100644
index 00000000..33acff1c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2436
@@ -0,0 +1 @@
+virtio kvm iofd sigfault bypass
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/2445 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2445
new file mode 100644
index 00000000..81651f28
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2445
@@ -0,0 +1,87 @@
+virtio-pci: the number of irq routes keeps increasing and qemu abort
+Description of problem:
+
+Steps to reproduce:
+1. Start a virtual machine and add a virtio-scsi controller for vm, E.g:
+
+   `<controller type='scsi' model='virtio-scsi' index='1'/>`
+2. write rand value and rand address in port IO address space of virtio-scsi device in the guest, E.g:
+
+   ```
+   int main(){
+       iopl(3);
+       srand(10001);
+       unsigned port_base = 0xc000;
+       unsigned port_space_size = 32;
+       time_t now;
+       struct tm *tm_struct;
+       int i;
+   
+       for (i=0;i<100000000;i++){
+           outb(rand()&0xff,port_base+rand()%port_space_size);
+           outw(rand()&0xffff,port_base+rand()%port_space_size);
+           outl(rand(),port_base+rand()%port_space_size);
+       }
+       return 0;
+   }
+   ```
+
+   or write some special value:
+
+   ```
+   int main(){
+       iopl(3);
+       srand(10001);
+       unsigned port_base = 0xc000;
+       unsigned port_space_size = 32;
+       int i;
+   
+       for (i=0;i<100000000;i++){
+           outw(13170, port_base + 18); // DRIVER
+           outw(16, port_base + 20);    // config_vector = 16
+           outw(34244, port_base + 18); // DRIVE OK
+           outw(29, port_base + 20);    // config_vector = 65535
+           outw(5817, port_base + 18);  // not DRIVE OK
+           usleep(1000);
+       }
+       return 0;
+   }
+   ```
+3. the number of irq routes will keep increasing and qemu process on the host will abort
+Additional information:
+stack infomation after qemu process aborts:
+
+```
+#0  0x00007f3cd38500ff in  () at /usr/lib64/libc.so.6
+#1  0x00007f3cd3803d06 in raise () at /usr/lib64/libc.so.6
+#2  0x00007f3cd37ef1f7 in abort () at /usr/lib64/libc.so.6
+#3  0x0000563055c54d68 in kvm_irqchip_commit_routes (s=0x563058b24bc0) at ../accel/kvm/kvm-all.c:1872
+#4  kvm_irqchip_commit_routes (s=0x563058b24bc0) at ../accel/kvm/kvm-all.c:1855
+#5  0x0000563055a1c242 in kvm_irqchip_commit_route_changes (c=0x7f3ccaffc040) at /Images/syg/code/openEuler/qemu/include/sysemu/kvm.h:470
+#6  kvm_virtio_pci_vq_vector_use (vector=18, proxy=0x563059b7f320) at ../hw/virtio/virtio-pci.c:875
+#7  kvm_virtio_pci_vector_use_one (proxy=proxy@entry=0x563059b7f320, queue_no=queue_no@entry=17) at ../hw/virtio/virtio-pci.c:948
+#8  0x0000563055a1d718 in kvm_virtio_pci_vector_vq_use (nvqs=18, proxy=0x563059b7f320) at ../hw/virtio/virtio-pci.c:1010
+#9  virtio_pci_set_guest_notifiers (d=0x563059b7f320, nvqs=18, assign=<optimized out>) at ../hw/virtio/virtio-pci.c:1373
+#10 0x00005630559cb5f9 in virtio_scsi_dataplane_start (vdev=0x563059b876f0) at ../hw/scsi/virtio-scsi-dataplane.c:116
+#11 0x0000563055a194f2 in virtio_bus_start_ioeventfd (bus=bus@entry=0x563059b87670) at ../hw/virtio/virtio-bus.c:236
+#12 0x0000563055a1c9f2 in virtio_pci_start_ioeventfd (proxy=0x563059b7f320) at ../hw/virtio/virtio-pci.c:375
+#13 virtio_ioport_write (val=34244, addr=18, opaque=0x563059b7f320) at ../hw/virtio/virtio-pci.c:471
+#14 virtio_pci_config_write (opaque=0x563059b7f320, addr=18, val=<optimized out>, size=<optimized out>) at ../hw/virtio/virtio-pci.c:617
+#15 0x0000563055bfb3af in memory_region_write_accessor (mr=mr@entry=0x563059b7fd50, addr=18, value=value@entry=0x7f3ccaffc2c8, size=size@entry=2, shift=<optimized out>, mask=mask@entry=65535, attrs=...)
+    at ../system/memory.c:497
+#16 0x0000563055bfc05e in access_with_adjusted_size (addr=addr@entry=18, value=value@entry=0x7f3ccaffc2c8, size=size@entry=2, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=
+    0x563055bfb330 <memory_region_write_accessor>, mr=0x563059b7fd50, attrs=...) at ../system/memory.c:573
+#17 0x0000563055bfd074 in memory_region_dispatch_write (mr=0x563059b7fd50, addr=18, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../system/memory.c:1528
+#18 0x0000563055c040f4 in flatview_write_continue
+    (fv=fv@entry=0x7f3aa40198b0, addr=addr@entry=49170, attrs=attrs@entry=..., ptr=ptr@entry=0x7f3cd0002000, len=len@entry=2, addr1=<optimized out>, l=<optimized out>, mr=<optimized out>)
+    at /Images/syg/code/openEuler/qemu/include/qemu/host-utils.h:238
+#19 0x0000563055c043e0 in flatview_write (fv=0x7f3aa40198b0, addr=addr@entry=49170, attrs=attrs@entry=..., buf=buf@entry=0x7f3cd0002000, len=len@entry=2) at ../system/physmem.c:2799
+#20 0x0000563055c07c48 in address_space_write (len=2, buf=0x7f3cd0002000, attrs=..., addr=49170, as=0x563056cc8fe0 <address_space_io>) at ../system/physmem.c:2906
+#21 address_space_rw (as=0x563056cc8fe0 <address_space_io>, addr=addr@entry=49170, attrs=attrs@entry=..., buf=0x7f3cd0002000, len=len@entry=2, is_write=is_write@entry=true) at ../system/physmem.c:2916
+#22 0x0000563055c58663 in kvm_handle_io (count=1, size=2, direction=<optimized out>, data=<optimized out>, attrs=..., port=49170) at ../accel/kvm/kvm-all.c:2670
+#23 kvm_cpu_exec (cpu=cpu@entry=0x563058ee2a40) at ../accel/kvm/kvm-all.c:2943
+#24 0x0000563055c59965 in kvm_vcpu_thread_fn (arg=0x563058ee2a40) at ../accel/kvm/kvm-accel-ops.c:51
+#25 0x0000563055ddb9df in qemu_thread_start (args=0x563058eecaa0) at ../util/qemu-thread-posix.c:541
+#26 0x00007f3cd384e51a in  () at /usr/lib64/libc.so.6
+#27 0x00007f3cd38d0e00 in  () at /usr/lib64/libc.so.6
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/2450 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2450
new file mode 100644
index 00000000..d8942ae8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2450
@@ -0,0 +1,17 @@
+Intel GVT-g does not produce any output.
+Description of problem:
+I'm unable to see anything from screen:
+![screenshot](/uploads/6822c2572547cb758c613f35f1bf51f3/图片.png){width=1201 height=956}
+
+By enabling VGA, I'm able to see the virtual monitor is presented in the guest OS:
+![screenshot](/uploads/fc9596f333ce8b549332fd25ea084fa9/图片.png){width=977 height=694}
+
+however it still cannot produce any output:
+
+![screenshot](/uploads/6bb1b2de249d8f5735c51a6a737c7288/图片.png){width=977 height=694}
+Steps to reproduce:
+1. echo "29d65a71-b9eb-45b2-aaaf-49e96f8cf753"> /sys/devices/pci0000:00/*/mdev_supported_types/i915-GVTg_V5_4/create
+2. Download the romfile
+3. Run the machine
+Additional information:
+CPU: i7-10700
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/2699 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2699
new file mode 100644
index 00000000..a3dbd95c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2699
@@ -0,0 +1,18 @@
+kvm_mem_ioeventfd_del: error deleting ioeventfd: Bad file descriptor (9)
+Description of problem:
+QEMU 9.1.91 monitor - type 'help' for more information
+(qemu) kvm_mem_ioeventfd_del: error deleting ioeventfd: Bad file descriptor (9)
+test.sh: line 14: 105283 Aborted                 (core dumped) /usr/local/bin/qemu-system-x86_64 -M q35 -m 8G -smp 8 -cpu host -enable-kvm -device VGA,bus=pcie.0,addr=0x2 -drive file=//home/fedora-38.qcow2,media=disk,if=virtio -device virtio-net-pci,mac=00:11:22:33:44:00,netdev=id8cxFGH,id=idaFLYjy,bus=pcie.0,addr=0x7 -netdev tap,id=id8cxFGH,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -vnc :0 -monitor stdio -qmp tcp:0:5555,server,nowait
+Steps to reproduce:
+1. Boot a guest
+2. set_link false nic and set_link true nic
+
+{"execute": "qmp_capabilities"}
+{"return": {}}
+{"execute": "set_link", "arguments": {"name": "idaFLYjy", "up": false}}
+{"return": {}}
+{"execute": "set_link", "arguments": {"name": "idaFLYjy", "up": true}}
+
+3. Guest hit qemu core dump
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/2710 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2710
new file mode 100644
index 00000000..54d0fe8c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2710
@@ -0,0 +1,126 @@
+QEMU can't detect guest debug support on older (pre v5.7) x86 host kernels due to missing KVM_CAP_SET_GUEST_DEBUG
+Description of problem:
+```
+qemu-system-x86_64: -s: gdbstub: current accelerator doesn't support guest debugging
+```
+Additional information:
+I initially located the QEMU source code to determine whether KVM supports gdbstub by checking for `KVM_CAP_SET_GUEST_DEBUG`. The corresponding code can be found at: 
+```c
+// qemu/accel/kvm/kvm-all.c:2695
+#ifdef TARGET_KVM_HAVE_GUEST_DEBUG
+    kvm_has_guest_debug =
+        (kvm_check_extension(s, KVM_CAP_SET_GUEST_DEBUG) > 0);
+#endif
+```
+It can be observed that if the return value is <= 0 (in practice, this function only returns 0 on failure), the debug_flag is set to false.
+
+Upon further investigation of the Linux 4.15 kernel code, I discovered that in earlier versions, support for checking VM debugging capabilities via `KVM_CAP_SET_GUEST_DEBUG` was almost non-existent (it was only supported on arm64). However, for x86_64, VM debugging is supported on the 4.15 kernel.
+
+```c
+// linu4.15/arch/x86/kvm/x86.c:2672
+int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
+{
+	int r;
+
+	switch (ext) {
+	case KVM_CAP_IRQCHIP:
+	case KVM_CAP_HLT:
+	case KVM_CAP_MMU_SHADOW_CACHE_CONTROL:
+	case KVM_CAP_SET_TSS_ADDR:
+	case KVM_CAP_EXT_CPUID:
+	case KVM_CAP_EXT_EMUL_CPUID:
+	case KVM_CAP_CLOCKSOURCE:
+	case KVM_CAP_PIT:
+	case KVM_CAP_NOP_IO_DELAY:
+	case KVM_CAP_MP_STATE:
+	case KVM_CAP_SYNC_MMU:
+	case KVM_CAP_USER_NMI:
+	case KVM_CAP_REINJECT_CONTROL:
+	case KVM_CAP_IRQ_INJECT_STATUS:
+	case KVM_CAP_IOEVENTFD:
+	case KVM_CAP_IOEVENTFD_NO_LENGTH:
+	case KVM_CAP_PIT2:
+	case KVM_CAP_PIT_STATE2:
+	case KVM_CAP_SET_IDENTITY_MAP_ADDR:
+	case KVM_CAP_XEN_HVM:
+	case KVM_CAP_VCPU_EVENTS:
+	case KVM_CAP_HYPERV:
+	case KVM_CAP_HYPERV_VAPIC:
+	case KVM_CAP_HYPERV_SPIN:
+	case KVM_CAP_HYPERV_SYNIC:
+	case KVM_CAP_HYPERV_SYNIC2:
+	case KVM_CAP_HYPERV_VP_INDEX:
+	case KVM_CAP_PCI_SEGMENT:
+	case KVM_CAP_DEBUGREGS:
+	case KVM_CAP_X86_ROBUST_SINGLESTEP:
+	case KVM_CAP_XSAVE:
+	case KVM_CAP_ASYNC_PF:
+	case KVM_CAP_GET_TSC_KHZ:
+	case KVM_CAP_KVMCLOCK_CTRL:
+	case KVM_CAP_READONLY_MEM:
+	case KVM_CAP_HYPERV_TIME:
+	case KVM_CAP_IOAPIC_POLARITY_IGNORED:
+	case KVM_CAP_TSC_DEADLINE_TIMER:
+	case KVM_CAP_ENABLE_CAP_VM:
+	case KVM_CAP_DISABLE_QUIRKS:
+	case KVM_CAP_SET_BOOT_CPU_ID:
+ 	case KVM_CAP_SPLIT_IRQCHIP:
+	case KVM_CAP_IMMEDIATE_EXIT:
+		r = 1;
+		break;
+	case KVM_CAP_ADJUST_CLOCK:
+		r = KVM_CLOCK_TSC_STABLE;
+		break;
+	case KVM_CAP_X86_GUEST_MWAIT:
+		r = kvm_mwait_in_guest();
+		break;
+	case KVM_CAP_X86_SMM:
+		/* SMBASE is usually relocated above 1M on modern chipsets,
+		 * and SMM handlers might indeed rely on 4G segment limits,
+		 * so do not report SMM to be available if real mode is
+		 * emulated via vm86 mode.  Still, do not go to great lengths
+		 * to avoid userspace's usage of the feature, because it is a
+		 * fringe case that is not enabled except via specific settings
+		 * of the module parameters.
+		 */
+		r = kvm_x86_ops->cpu_has_high_real_mode_segbase();
+		break;
+	case KVM_CAP_VAPIC:
+		r = !kvm_x86_ops->cpu_has_accelerated_tpr();
+		break;
+	case KVM_CAP_NR_VCPUS:
+		r = KVM_SOFT_MAX_VCPUS;
+		break;
+	case KVM_CAP_MAX_VCPUS:
+		r = KVM_MAX_VCPUS;
+		break;
+	case KVM_CAP_NR_MEMSLOTS:
+		r = KVM_USER_MEM_SLOTS;
+		break;
+	case KVM_CAP_PV_MMU:	/* obsolete */
+		r = 0;
+		break;
+	case KVM_CAP_MCE:
+		r = KVM_MAX_MCE_BANKS;
+		break;
+	case KVM_CAP_XCRS:
+		r = boot_cpu_has(X86_FEATURE_XSAVE);
+		break;
+	case KVM_CAP_TSC_CONTROL:
+		r = kvm_has_tsc_control;
+		break;
+	case KVM_CAP_X2APIC_API:
+		r = KVM_X2APIC_API_VALID_FLAGS;
+		break;
+	default:
+		r = 0;
+		break;
+	}
+	return r;
+
+}
+```
+
+I attempted to bypass this check in QEMU and verified that the QEMU gdbstub works normally on the 4.15 kernel.
+
+For modifications related to this part in QEMU, you can refer to the email: https://lore.kernel.org/all/20211111110604.207376-5-pbonzini@redhat.com/.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/2712 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2712
new file mode 100644
index 00000000..32a0388f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/2712
@@ -0,0 +1,11 @@
+Windows VM doesn't boot on QEMU KVM when hypervisor is disabled in Linux 6.12
+Description of problem:
+Windows VM doesn't boot on QEMU KVM when hypervisor is disabled in Linux 6.12. QEMU uses 100% CPU core usage and nothing happens.
+
+It boots properly in Linux 6.11.10. I don't know if it's a kernel bug or QEMU needs some changes to work with the new kernel correctly.
+Steps to reproduce:
+1. Boot Windows 10 or 11 (can be installation ISO form official website) with KVM, but set "hypervisor=off" CPU parameter.
+2. Wait.
+3. Nothing happens - doesn't boot.
+Additional information:
+Nothing is displayed in console.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/337 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/337
new file mode 100644
index 00000000..fc94f8ff
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/337
@@ -0,0 +1 @@
+QEMU emulator version 6.0.50 Failure with nested FreeBSD bhyve
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/439 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/439
new file mode 100644
index 00000000..e60d4de5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/439
@@ -0,0 +1 @@
+Hard crash - qemu-6.0.0 with windows 10 guest
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/477 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/477
new file mode 100644
index 00000000..6af3585b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/477
@@ -0,0 +1,12 @@
+Nested kvm-svm does not work since f5cc5a5c16
+Description of problem:
+Nested SVM virtualization seems to not work. I bisected this to f5cc5a5c16.
+Steps to reproduce:
+1. Boot up a Linux guest such as the Debian Live CD with -accel kvm -cpu host
+2. ```dmesg | grep kvm; ls /dev/kvm```; # Shows that KVM is disabled within the guest
+Additional information:
+Details about my AMD host:
+```
+model name      : AMD Ryzen 5 2600 Six-Core Processor
+flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/478 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/478
new file mode 100644
index 00000000..d1691452
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/478
@@ -0,0 +1,399 @@
+Loss of network trafic when virtual iommu is enabled
+Steps to reproduce:
+1. Setup the hypervisor
+- Vt-x and Vt-d present
+- IOMMU enabled on the kernel command line (iommu=force intel_iommu=on)
+- OpenvSwitch started with DPDK and IOMMU support
+```shell
+ovs-vsctl --no-wait set Open_vSwitch . other_config:vhost-iommu-support=true
+ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true
+```
+- One OVS bridge with DPDK enabled
+```shell
+ovs-vsctl add-br br_dpdk  -- set bridge br_dpdk datapath_type=netdev
+```
+- VM1 makes use of a DPDK port without virtualized IOMMU
+- VM2 makes use of a DPDK port with virtualized IOMMU
+- Add a virtual port (DPDPK) for VM1,
+```shell
+ovs-vsctl add-port br_dpdk dpdk1 -- set Interface dpdk1 \
+      type=dpdkvhostuserclient options:vhost-server-path=/var/run/openvswitch/dpdk1
+```
+- Add a virtual port (DPDPK) for VM2,
+```shell
+ovs-vsctl add-port br_dpdk dpdk2 -- set Interface dpdk2 \
+      type=dpdkvhostuserclient options:vhost-server-path=/var/run/openvswitch/dpdk2
+```
+
+2. Start VM1. This VM is used to generate traffic toward VM2
+- VM1 is started. The way it is started has no impact on the outcome of the test.
+- It declares a vhost-user interface (server mode) with dpdk1 as the source.
+- The guest OS makes use of virtio-pci to handle its network interface.
+- Its interface is having the IP 192.168.3.10/24
+
+3. Start VM2. This VM shows the defect
+- VM2 is started.
+- It declares an iommu device and a vhost-user network interface (server mode) with
+dpdk2 as the source.
+- The vhost-user interface enables iommu and the ats service.
+- It uses the Q35 chipset, it has a PCI topology that ensures that the network interface is its in own IOMMU group
+- The VM is started this way:
+```shell
+qemu-system-x86_64 
+  -enable-kvm \
+  -name guest=debian-iommu,debug-threads=on \
+  -machine pc-q35-3.1,accel=kvm,usb=off,dump-guest-core=off,\
+mem-merge=off,kernel_irqchip=split \
+  -cpu IvyBridge-IBRS,ss=on,movbe=on,hypervisor=on,arat=on,\
+tsc_adjust=on,mpx=on,rdseed=on,smap=on,clflushopt=on,sha-ni=on,\
+umip=on,ssbd=on,xsaveopt=on,xsavec=on,xgetbv1=on,xsaves=on,pdpe1gb=on,\
+3dnowprefetch=on,avx=off,f16c=off \
+  -m 4096 \
+  -mem-prealloc \
+  -overcommit mem-lock=on \
+  -smp 2,sockets=1,cores=2,threads=1 \
+  -object memory-backend-file,id=ram-node0,\
+mem-path=/dev/hugepages/libvirt/qemu/2-debian-iommu,\
+share=yes,size=4294967296 \
+  -numa node,nodeid=0,cpus=0-1,memdev=ram-node0 \
+  -uuid 65847f47-3454-4576-ab6c-6a1c75041ea7 \
+  -display none \
+  -no-user-config \
+  -nodefaults \
+  -rtc base=utc \
+  -no-shutdown \
+  -global ICH9-LPC.disable_s3=1 \
+  -global ICH9-LPC.disable_s4=1 \
+  -boot strict=on \
+  -device intel-iommu,intremap=on,caching-mode=on,eim=off,device-iotlb=on \
+  -device pcie-root-port,port=0x8,chassis=1,id=pci.1,\
+bus=pcie.0,multifunction=off,addr=0x1 \
+  -device pcie-root-port,port=0x10,chassis=2,id=pci.2,\
+bus=pcie.0,multifunction=off,addr=0x2 \
+  -device pcie-root-port,port=0x18,chassis=3,id=pci.3,\
+bus=pcie.0,multifunction=off,addr=0x3 \
+  -device pcie-root-port,port=0x20,chassis=4,id=pci.4,\
+bus=pcie.0,multifunction=off,addr=0x4 \
+  -device pcie-root-port,port=0x28,chassis=5,id=pci.5,\
+bus=pcie.0,multifunction=off,addr=0x5 \
+  -device pcie-root-port,port=0x30,chassis=6,id=pci.6,\
+bus=pcie.0,multifunction=off,addr=0x6 \
+  -device pcie-root-port,port=0x38,chassis=7,id=pci.7,\
+bus=pcie.0,multifunction=off,addr=0x7 \
+  -device qemu-xhci,id=usb,bus=pci.4,addr=0x0 \
+  -drive file=/var/lib/libvirt/images/backing-storage/\
+debian-iommu/debian-iommu-0.qcow2,format=qcow2,if=none,\
+id=drive-virtio-disk0,cache=directsync \
+  -device virtio-blk-pci,scsi=off,bus=pci.5,addr=0x0,\
+drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=off \
+\
+  -chardev socket,id=charnet0,\
+path=/var/run/openvswitch/dpdk2,server=on \
+  -netdev vhost-user,chardev=charnet0,id=hostnet0 \
+  -device virtio-net-pci,mrg_rxbuf=on,netdev=hostnet0,\
+id=net0,mac=52:54:00:c2:bf:aa,bus=pci.1,addr=0x0,iommu_platform=on,ats=on \
+\
+  -chardev pty,id=charserial0 \
+  -device isa-serial,chardev=charserial0,id=serial0 \
+\
+  -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,\
+resourcecontrol=deny \
+  -msg timestamp=on
+```
+
+- the guest OS kernel has IOMMU enabled (iommu=true intel_iommu=on)
+
+4. The DPDK application is started in VM2
+- the network interface is bound to the vfio driver
+```shell
+# echo 0000:01:00.0 > /sys/bus/pci/drivers/virtio-pci/unbind
+# echo vfio-pci > /sys/bus/pci/devices/0000:01:00.0/driver_override
+# echo 0000:01:00.0 > /sys/bus/pci/drivers/vfio-pci/bind
+# echo 512 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
+```
+
+- the dpdk-testpmd is used to start a forwarding between the network
+interface and a tap device
+```shell
+dpdk-testpmd --pci-whitelist "01:00.0" --iova-mode va --legacy-mem --socket-mem 500 --vdev=net_tap0
+
+EAL: Detected 2 lcore(s)
+EAL: Detected 1 NUMA nodes
+EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
+EAL: No free hugepages reported in hugepages-1048576kB
+EAL: Probing VFIO support...
+EAL: VFIO support initialized
+EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable clo!
+EAL: PCI device 0000:01:00.0 on NUMA socket -1
+EAL:   Invalid NUMA socket, default to 0
+EAL:   probe driver: 1af4:1041 net_virtio
+EAL:   using IOMMU type 1 (Type 1)
+rte_pmd_tap_probe(): Initializing pmd_tap for net_tap0 as dtap%d
+[   47.283172] tun: Universal TUN/TAP device driver, 1.6
+testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=155456, size=2176, sock0
+testpmd: preferred mempool ops selected: ring_mp_mc
+Configuring Port 0 (socket 0)
+EAL: Error disabling MSI-X interrupts for fd 267
+Port 0: 52:54:00:C2:BF:AA
+Configuring Port 1 (socket 0)
+Port 1: CE:61:2A:67:F4:B8
+Checking link statuses...
+[   47.562560] device dtap0 entered promiscuous mode
+
+No commandline core given, start packet forwarding
+io packet forwarding - ports=2 - cores=1 - streams=2 - NUMA support enabled, MPe
+Logical Core 1 (socket 0) forwards packets on 2 streams:
+  RX P=0/Q=0 (socket 0) -> TX P=1/Q=0 (socket 0) peer=02:00:00:00:00:01
+  RX P=1/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00
+
+  io packet forwarding packets/burst=32
+  nb forwarding cores=1 - nb forwarding ports=2
+  port 0: RX queue number: 1 Tx queue number: 1
+    Rx offloads=0x0 Tx offloads=0x0
+    RX queue: 0
+      RX desc=0 - RX free threshold=0
+      RX threshold registers: pthresh=0 hthresh=0  wthresh=0
+      RX Offloads=0x0
+    TX queue: 0
+      TX desc=0 - TX free threshold=0
+      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
+      TX offloads=0x0 - TX RS bit threshold=0
+  port 1: RX queue number: 1 Tx queue number: 1
+    Rx offloads=0x0 Tx offloads=0x0
+    RX queue: 0
+      RX desc=0 - RX free threshold=0
+      RX threshold registers: pthresh=0 hthresh=0  wthresh=0
+      RX Offloads=0x0
+    TX queue: 0
+      TX desc=0 - TX free threshold=0
+      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
+      TX offloads=0x0 - TX RS bit threshold=0
+Press enter to exit
+```
+
+- An IP is set on the dtap0 interface
+
+```shell
+^Z
+# ip a a 192.168.3.20/24 dev dtap0
+# fg
+```
+
+5. The traffic is initiated from VM1
+- from the VM1 console a ping the VM2 is started and is working fine.
+
+```shell
+# ping 192.168.3.20
+PING 192.168.3.20 (192.168.3.20) 56(84) bytes of data.
+64 bytes from 192.168.3.20: icmp_seq=1 ttl=64 time=0.320 ms
+64 bytes from 192.168.3.20: icmp_seq=2 ttl=64 time=0.172 ms
+64 bytes from 192.168.3.20: icmp_seq=3 ttl=64 time=0.163 ms
+^C
+--- 192.168.3.20 ping statistics ---
+3 packets transmitted, 3 received, 0% packet loss, time 4ms
+rtt min/avg/max/mdev = 0.163/0.218/0.320/0.072 ms
+```
+- from the VM1 console a UDP iperf is started and is working fine (no server-side iperf is started)
+```shell
+# iperf -c 192.168.3.20 -u
+------------------------------------------------------------
+Client connecting to 192.168.3.20, UDP port 5001
+Sending 1470 byte datagrams, IPG target: 11215.21 us (kalman adjust)
+UDP buffer size:  208 KByte (default)
+------------------------------------------------------------
+[  3] local 192.168.3.10 port 49124 connected with 192.168.3.20 port 5001
+read failed: Connection refused
+[  3] WARNING: did not receive ack of last datagram after 1 tries.
+[ ID] Interval       Transfer     Bandwidth
+[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
+[  3] Sent 892 datagrams
+```
+- from the VM2 console the <Enter> key is pressed
+```shell
+Telling cores to stop...
+Waiting for lcores to finish...
+
+  ---------------------- Forward statistics for port 0  ----------------------
+  RX-packets: 904            RX-dropped: 0             RX-total: 904
+  TX-packets: 37             TX-dropped: 0             TX-total: 37
+  ----------------------------------------------------------------------------
+
+  ---------------------- Forward statistics for port 1  ----------------------
+  RX-packets: 37             RX-dropped: 0             RX-total: 37
+  TX-packets: 904            TX-dropped: 0             TX-total: 904
+  ----------------------------------------------------------------------------
+
+  +++++++++++++++ Accumulated forward statistics for all ports+++++++++++++++
+  RX-packets: 941            RX-dropped: 0             RX-total: 941
+  TX-packets: 941            TX-dropped: 0             TX-total: 941
+  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+Done.
+
+Stopping port 0...
+Stopping ports...
+Done
+
+Stopping port 1...
+Stopping ports...
+Done
+
+Shutting down port 0...
+Closing ports...
+EAL: Error disabling MSI-X interrupts for fd 267
+Done
+
+Shutting down port 1...
+Closing ports...
+Done
+
+Bye...
+
+```
+
+- the guest OS is rebooted (the QEMU emulator is not restarted)
+```shell
+# shutdown -r now
+```
+
+6. After reboot, impossible to resume the network traffic
+- the same setup is applied (bind the interface to the vfio driver, add enough huge pages, start the dpdk-testpmd program, add an ip to the tap interface). The dpdk-testpmd output shows:
+```shell
+EAL: Detected 2 lcore(s)
+EAL: Detected 1 NUMA nodes
+EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
+EAL: No free hugepages reported in hugepages-1048576kB
+EAL: Probing VFIO support...
+EAL: VFIO support initialized
+EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable clo!
+EAL: PCI device 0000:01:00.0 on NUMA socket -1
+EAL:   Invalid NUMA socket, default to 0
+EAL:   probe driver: 1af4:1041 net_virtio
+EAL:   using IOMMU type 1 (Type 1)
+rte_pmd_tap_probe(): Initializing pmd_tap for net_tap0 as dtap%d
+[   37.865360] tun: Universal TUN/TAP device driver, 1.6
+testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=155456, size=2176, sock0
+testpmd: preferred mempool ops selected: ring_mp_mc
+Configuring Port 0 (socket 0)
+EAL: Error disabling MSI-X interrupts for fd 267
+Port 0: 52:54:00:C2:BF:AA
+Configuring Port 1 (socket 0)
+Port 1: 0A:78:00:1F:D6:CB
+Checking link statuses...
+[   38.151800] device dtap0 entered promiscuous mode
+
+No commandline core given, start packet forwarding
+io packet forwarding - ports=2 - cores=1 - streams=2 - NUMA support enabled, MPe
+Logical Core 1 (socket 0) forwards packets on 2 streams:
+  RX P=0/Q=0 (socket 0) -> TX P=1/Q=0 (socket 0) peer=02:00:00:00:00:01
+  RX P=1/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00
+
+  io packet forwarding packets/burst=32
+  nb forwarding cores=1 - nb forwarding ports=2
+  port 0: RX queue number: 1 Tx queue number: 1
+    Rx offloads=0x0 Tx offloads=0x0
+    RX queue: 0
+      RX desc=0 - RX free threshold=0
+      RX threshold registers: pthresh=0 hthresh=0  wthresh=0
+      RX Offloads=0x0
+    TX queue: 0
+      TX desc=0 - TX free threshold=0
+      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
+      TX offloads=0x0 - TX RS bit threshold=0
+  port 1: RX queue number: 1 Tx queue number: 1
+    Rx offloads=0x0 Tx offloads=0x0
+    RX queue: 0
+      RX desc=0 - RX free threshold=0
+      RX threshold registers: pthresh=0 hthresh=0  wthresh=0
+      RX Offloads=0x0
+    TX queue: 0
+      TX desc=0 - TX free threshold=0
+      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
+      TX offloads=0x0 - TX RS bit threshold=0
+Press enter to exit
+```
+
+- From the VM2 console, any attempt to send pings or the engage in UDP iperf will fail
+```shell
+# ping 192.168.3.20
+PING 192.168.3.20 (192.168.3.20) 56(84) bytes of data.
+From 192.168.3.10 icmp_seq=1 Destination Host Unreachable
+From 192.168.3.10 icmp_seq=2 Destination Host Unreachable
+From 192.168.3.10 icmp_seq=3 Destination Host Unreachable
+From 192.168.3.10 icmp_seq=4 Destination Host Unreachable
+From 192.168.3.10 icmp_seq=5 Destination Host Unreachable
+From 192.168.3.10 icmp_seq=6 Destination Host Unreachable
+From 192.168.3.10 icmp_seq=7 Destination Host Unreachable
+From 192.168.3.10 icmp_seq=8 Destination Host Unreachable
+From 192.168.3.10 icmp_seq=9 Destination Host Unreachable
+From 192.168.3.10 icmp_seq=10 Destination Host Unreachable
+From 192.168.3.10 icmp_seq=11 Destination Host Unreachable
+From 192.168.3.10 icmp_seq=12 Destination Host Unreachable
+^C
+--- 192.168.3.20 ping statistics ---
+13 packets transmitted, 0 received, +12 errors, 100% packet loss, time 327ms
+
+# iperf -c 192.168.3.20 -u
+------------------------------------------------------------
+Client connecting to 192.168.3.20, UDP port 5001
+Sending 1470 byte datagrams, IPG target: 11215.21 us (kalman adjust)
+UDP buffer size:  208 KByte (default)
+------------------------------------------------------------
+[  3] local 192.168.3.10 port 54228 connected with 192.168.3.20 port 5001
+[  3] WARNING: did not receive ack of last datagram after 10 tries.
+[ ID] Interval       Transfer     Bandwidth
+[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
+[  3] Sent 892 datagrams
+```
+
+- from the VM2 console the <Enter> key is pressed
+```shell
+Telling cores to stop...
+Waiting for lcores to finish...
+
+  ---------------------- Forward statistics for port 0  ----------------------
+  RX-packets: 0              RX-dropped: 0             RX-total: 0
+  TX-packets: 10             TX-dropped: 0             TX-total: 10
+  ----------------------------------------------------------------------------
+
+  ---------------------- Forward statistics for port 1  ----------------------
+  RX-packets: 10             RX-dropped: 0             RX-total: 10
+  TX-packets: 0              TX-dropped: 0             TX-total: 0
+  ----------------------------------------------------------------------------
+
+  +++++++++++++++ Accumulated forward statistics for all ports+++++++++++++++
+  RX-packets: 10             RX-dropped: 0             RX-total: 10
+  TX-packets: 10             TX-dropped: 0             TX-total: 10
+  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+Done.
+
+Stopping port 0...
+Stopping ports...
+Done
+
+Stopping port 1...
+Stopping ports...
+Done
+
+Shutting down port 0...
+Closing ports...
+EAL: Error disabling MSI-X interrupts for fd 267
+Done
+
+Shutting down port 1...
+Closing ports...
+Done
+
+Bye...
+```
+Additional information:
+1. How to resume the network traffic
+
+- If VM2 is fully restarted (the QEMU processed is restarted), and the setup is reapplied,
+the trafic with VM1 is restored.
+
+2. Alternate cases
+- Not systematically, it also happens that the trafic is definitively lost only by stopping and then restarting dpdk-testpmd in VM2
+
+- I also met the case while running another DPDK application that is making use of multithreading: one thread is receiving data from the network interface and pushing it to the tap interface, while the other thread is receiving data from the tap interface and pushing it to the network interface. No reboot of the guest OS, no interruption of the DPDK application, the traffic is just flowing for less than a minute until it is definitively lost.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/504 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/504
new file mode 100644
index 00000000..aef76e0f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/504
@@ -0,0 +1,18 @@
+kvm_log_clear_one_slot: KVM_CLEAR_DIRTY_LOG failed
+Description of problem:
+```
+ $ ./qemu-system-i386 -enable-kvm -cdrom ubuntu-20.04.2.0-desktop-amd64.iso
+qemu-system-i386: kvm_log_clear_one_slot: KVM_CLEAR_DIRTY_LOG failed, slot=9, start=0x0, size=0x10, errno=-14
+qemu-system-i386: kvm_log_clear: kvm log clear failed: mr=vga.vram offset=10000 size=10000
+Aborted
+
+ $ ./qemu-system-x86_64 -enable-kvm -cdrom ubuntu-20.04.2.0-desktop-amd64.iso
+qemu-system-x86_64: kvm_log_clear_one_slot: KVM_CLEAR_DIRTY_LOG failed, slot=9, start=0x0, size=0x10, errno=-14
+qemu-system-x86_64: kvm_log_clear: kvm log clear failed: mr=vga.vram offset=0 size=10000
+Aborted
+```
+Steps to reproduce:
+1. qemu crashes right at start
+Additional information:
+- last successfully used qemu version: 5.2.0
+ - first seen failing qemu version: 6.0
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/706 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/706
new file mode 100644
index 00000000..cbfa7af2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/706
@@ -0,0 +1,38 @@
+NVMe End-to-End Data Protection
+Description of problem:
+When activating end-to-end data protection inside qemu NVMe virtual namespace, guest can not read or write anything to discovered /dev/nvme0n1. Guest kernel has NVMe support compiled-in, when booting i get the following messages related to emulated nvme pi-enabled drive inside guest:
+
+```
+[    0.661260] blk_update_request: protection error, dev nvme0n1, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[    0.663774] Buffer I/O error on dev nvme0n1, logical block 1, async page read
+[    0.665043] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[    0.666976] Buffer I/O error on dev nvme0n1, logical block 0, async page read
+[    0.676702] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[    0.678664] Buffer I/O error on dev nvme0n1, logical block 0, async page read
+[    0.679923] blk_update_request: protection error, dev nvme0n1, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[    0.681811] Buffer I/O error on dev nvme0n1, logical block 1, async page read
+[    0.683544]  nvme0n1: unable to read partition table
+```
+
+Same when trying to read anything:
+
+```
+/ # dd bs=512 count=1 skip=0 if=/dev/nvme0n1 iflag=direct
+[  432.017616] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0
+[  432.020596] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[  432.023530] Buffer I/O error on dev nvme0n1, logical block 0, async page read
+[  432.025345] blk_update_request: protection error, dev nvme0n1, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[  432.028289] Buffer I/O error on dev nvme0n1, logical block 1, async page read
+dd: /dev/nvme0n1: Input/output error
+``` 
+
+And write:
+
+```
+/ # dd bs=512 count=1 if=output.dat of=/dev/nvme0n1
+[  597.679455] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+dd: error writing '/dev/nvme0n1': Input/output error
+1+0 records in
+0+0 records out
+0 bytes (0B) copied, 0.003864 seconds, 0B/s
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/73 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/73
new file mode 100644
index 00000000..2c773637
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/73
@@ -0,0 +1 @@
+KVM Windows 98 sound card passthrough is not working for DOS programs..
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_KVM/849 b/gitlab/issues_text/target_missing/host_missing/accel_KVM/849
new file mode 100644
index 00000000..4e70ea93
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_KVM/849
@@ -0,0 +1,22 @@
+High mouse polling rate stutters some applications
+Description of problem:
+There are couple of instances where moving the mouse would slow down some applications, especially for games
+
+https://www.reddit.com/r/VFIO/comments/ect3sd/having_an_issue_with_my_vm_where_games_stutter/
+
+https://www.reddit.com/r/VFIO/comments/n9hwtg/game_fps_drop_on_mouse_input/
+
+https://www.reddit.com/r/VFIO/comments/ln1uwb/evdev_mouse_passthrough_with_1000hz_mouse_causes/
+
+https://www.reddit.com/r/VFIO/comments/se92rq/looking_for_advice_on_poor_gpu_passthrough/
+
+I myself included, is impacted by this mysterious issue, I'm not pretty sure whether this is related to VFIO or QEMU or both, but I'm definitely sure this is a kind of regression in between since I had no such issue before.
+Steps to reproduce:
+1. Do a GPU passthrough
+2. Get a mouse capable of outputting high polling rate like 1000Hz, usually they are categorized as gaming mouses
+3. Start any 3D applications, including stuff like Unreal Engine 4 Editor or any games
+4. See mysterious stuttering
+Additional information:
+I'm using an AMD Ryzen 7 3700X CPU as the host, but I have made scripts that pins CPU to the VM to get better performance speculatively by putting the threads on the same CCX to minimize memory latency as much as possible. This alleviated some terrible lag, but not by much. (like 11 FPS to 20 FPS if you move your mouse which is still crappy compared to 90+ FPS when static)
+
+I suspect there is something wrong with the USB subsystem.
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 00000000..56855537
--- /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 00000000..4cf0cef1
--- /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 00000000..ba349c10
--- /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 00000000..794813dc
--- /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 00000000..eb38cedc
--- /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 00000000..298f3be3
--- /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 00000000..c4d4bcd4
--- /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 00000000..b4250676
--- /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 00000000..f15dfebf
--- /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 00000000..8ab7691d
--- /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 00000000..b4d44645
--- /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 00000000..20881e5f
--- /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 00000000..bc81e3dc
--- /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 00000000..271d4583
--- /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.
+![Captura_de_tela_2023-06-03_212555](/uploads/970abc27e3adf29b14abea17c5faeff9/Captura_de_tela_2023-06-03_212555.jpg)
+
+VirtManager VM #1 config for x86_64 on aarch64
+![Captura_de_tela_2023-06-03_212617](/uploads/1884d4808cb24aae688dace64cdd275d/Captura_de_tela_2023-06-03_212617.jpg)
+
+VirtManager VM #2 config for aarch64 on aarch64
+![Captura_de_tela_2023-06-03_212711](/uploads/11e785a1a798423dfd9e7a56db8a8a35/Captura_de_tela_2023-06-03_212711.jpg)
+
+VirtManager VM #2 hypervisor used as KVM
+![Captura_de_tela_2023-06-03_212727](/uploads/996783f4141f8e296885ebe79b3b53f2/Captura_de_tela_2023-06-03_212727.jpg)
+
+VirtManager VM #1 hypervisor used as TGC
+![Captura_de_tela_2023-06-03_212742](/uploads/a9ee42aa217ba150be8cc34de716a8a4/Captura_de_tela_2023-06-03_212742.jpg)
+
+100% on host of all cores being used with stress-ng at aarch64 guest
+![Captura_de_tela_2023-06-03_212822](/uploads/880f7a7f69bb4eb87eab5c6912b2ff91/Captura_de_tela_2023-06-03_212822.jpg)
+
+All cores at 100% on aarch64 guest
+![Captura_de_tela_2023-06-03_212853](/uploads/8c154c0c403a06964b7f3439b7e5b2bf/Captura_de_tela_2023-06-03_212853.jpg)
+
+100% on host of just one core being used with stress-ng at x86_64 guest
+![Captura_de_tela_2023-06-03_212932](/uploads/ba82f08f1ceba18d35006689cacaafa4/Captura_de_tela_2023-06-03_212932.jpg)
+
+Cool down after both VMs ended stress-ng process
+![Captura_de_tela_2023-06-03_212959](/uploads/ed91dba107929c93d0ca7062ae4c3b05/Captura_de_tela_2023-06-03_212959.jpg)
+
+virsh version
+![Captura_de_tela_2023-06-03_213026](/uploads/bf5529e6f3a02eb11ad20d31380e3d5b/Captura_de_tela_2023-06-03_213026.jpg)
+
+"dmesg | head -n50" at host machine
+![Captura_de_tela_2023-06-03_213637](/uploads/87737c69a2a178c9062dcc6340b03d3e/Captura_de_tela_2023-06-03_213637.jpg)
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 00000000..d3700379
--- /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 00000000..30ccf63c
--- /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 00000000..6d02df80
--- /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 00000000..b3f775c6
--- /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 00000000..554e180a
--- /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 00000000..421389bf
--- /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 00000000..ea0fd498
--- /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 00000000..a4ab3715
--- /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 00000000..481c2f87
--- /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 00000000..0620c0bc
--- /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 00000000..9e0ce4c4
--- /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 00000000..a10d6b50
--- /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 00000000..84b17c81
--- /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 00000000..1a53f990
--- /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 00000000..b9c082ca
--- /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 00000000..0461315a
--- /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 00000000..dea9128d
--- /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 00000000..cbc16f86
--- /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 00000000..49292945
--- /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 00000000..105ef56a
--- /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 00000000..d8fa3884
--- /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 00000000..13ae1bb2
--- /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 00000000..5807c339
--- /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 00000000..22ea4e20
--- /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 00000000..d0181271
--- /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 00000000..78e5de8d
--- /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 00000000..43a5b271
--- /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 00000000..5da1198c
--- /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 00000000..8ee9d654
--- /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 00000000..86c813df
--- /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 00000000..df00cc5d
--- /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 00000000..380615a8
--- /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 00000000..38dba665
--- /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 00000000..67663cbd
--- /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 00000000..13445756
--- /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 00000000..1dff81ac
--- /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 00000000..ffe4c1d7
--- /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 00000000..f4458e17
--- /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 00000000..d0630306
--- /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 00000000..af97843d
--- /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 00000000..91b7c08f
--- /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 00000000..9c2f7a7f
--- /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 00000000..6b2e8c92
--- /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 00000000..27f4f37c
--- /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 00000000..4e4f56e8
--- /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 00000000..3b522718
--- /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 00000000..01b9116f
--- /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 00000000..e8535f9b
--- /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 00000000..70d2f1fc
--- /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)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_WHPX/1820 b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/1820
new file mode 100644
index 00000000..9a920599
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/1820
@@ -0,0 +1,10 @@
+whpx is slower than tcg
+Description of problem:
+I find whpx much slower than tcg, which is rather odd.
+Steps to reproduce:
+1. Enable Hyper-V
+2. run qemu with **-accel whpx,kernel-irqchip=off**
+Additional information:
+my cpu: intel i7 6500u
+memory: 8go
+my gpu: intel graphics 520 hd
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_WHPX/233 b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/233
new file mode 100644
index 00000000..7fcef4ae
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/233
@@ -0,0 +1 @@
+QEMU installer with WHPX support
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_WHPX/2402 b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/2402
new file mode 100644
index 00000000..98c7068c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/2402
@@ -0,0 +1,24 @@
+WHPX accelerator run with edk2 EFI fails to process the reboot signal from guest OS
+Description of problem:
+Qemu freezes any time WHPX-accelerated guest Windows 11 sends a reboot signal to Qemu while running on edk2 EFI. At rare cases, Qemu errors out with `qemu: WHPX: Unexpected VP exit code 4`
+Steps to reproduce:
+1. Grab Windows 11 23H2 ISO from https://www.microsoft.com/en-Us/software-download/windows11 using either Media Creation Tool or directly and save it under C:\\windows11_23H2.iso
+2. Download QEMU 9.0 from https://qemu.weilnetz.de/w64/qemu-w64-setup-20240423.exe and install it into C:\\Program Files\\qemu
+3. Make one merged EFI file from two ones bundled in QEMU 9.0 (merged EFI is the only working option for edk2 EFI on windows host): `cd /d C:\Program Files\qemu\share`
+
+`copy /B edk2-i386-vars.fd + edk2-x86_64-code.fd edk2-x86_64.fd`
+
+4. Run this command:
+
+`qemu-system-x86_64.exe -accel whpx -bios share\edk2-x86_64.fd -cpu Westmere,aes=on,avx=on,sse4.1=on,sse4.2=on,ssse3=on,x2apic=on,xsave=on -machine q35 -m 4096 -cdrom C:\windows11_23H2.iso`
+
+5. Press any key once you see "Press any key to boot from CD..." and wait until Windows Setup suggests to opt for language and currency.
+6. Click red "X" close button inside Windows Setup and confirm your choice when Windows Setup asks you to.
+
+Windows Setup sends a reboot signal to the underlying hardware and Qemu freezes.
+Additional information:
+If `-bios share\edk2-x86_64.fd` switch is omitted, this command works ok:
+
+`qemu-system-x86_64 -accel whpx -cpu Westmere,aes=on,avx=on,sse4.1=on,sse4.2=on,ssse3=on,x2apic=on,xsave=on -machine q35 -m 4096 -cdrom D:\originalWindows11_23H2.iso`
+
+This bug seems to be closely related to this one: https://gitlab.com/qemu-project/qemu/-/issues/2042 - Not able to reboot Linux guest on Windows host
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_WHPX/2461 b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/2461
new file mode 100644
index 00000000..1650b260
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/2461
@@ -0,0 +1,56 @@
+Qemu with -accel whpx doesn't set WRMSR permissions, which blocks nested virtualization
+Description of problem:
+This bug blocks https://gitlab.com/qemu-project/qemu/-/issues/628
+
+Qemu doesn't set the host's Hyper-V permissions for WRMSR command to allow using SVM or VMX. Unset permissions lead to `unchecked MSR access error: WRMSR to 0xc0000080` inside Linux VM when trying to launch nested VM on real AMD cpu. Intel users do not see guest VMX feature at all. Please see **Additional info** section to understand how Hyper-V permissions for nested virtualization work in Windows.
+Steps to reproduce:
+1. Turn on VT-x (for Intel) or AMD-V virtualization in your real hardware BIOS/EFI. This was tested only on AMD cpu and Qemu 9, Intel \*may\* behave differently.
+ 2. Install any distro in qemu disk c:\\linux_disk.qcow2 with MSR enabled in kernel, for example, Ubuntu 22.04 LTS.
+ 3. Run qemu using `qemu-system-x86_64.exe -m 2048 -machine q35 -accel whpx -cpu Opteron_G5,check,+svm -hda c:\linux_disk.qcow2`
+
+    To check if your distro has MSR mod enabled, run `grep -i msr /boot/config-$(uname -r)` and it should return `CONFIG_X86_MSR=m` or `CONFIG_X86_MSR=y`. If not, recompile and reinstall your kernel.
+ 4. Run `sudo modprobe msr` and then `sudo rdmsr 0xc0000080 #EFER`. You should see `d01` on modern AMD models. \[Untested\] For intel, run `sudo modprobe msr`, then `sudo rdmsr 0x3A`. You should see `5` or `0x5` or `0x100005`. d01 for AMD and 5 for Intel in output are necessary to enable nested VM. If RDMSR returns non-zero value, it means that qemu developers implemented this part of functionality and your Hyper-V on Windows is not broken.
+ 5. Run `cat /proc/cpuinfo | grep -c svm` on AMD cpu, which should output a positive digit.
+ 6. Run `sudo dmesg | grep kvm` and note:
+
+    `[1.924036] kvm_amd: Nested Virtualization enabled`
+
+    `[1.924038] kvm_amd: Nested Paging disabled`\
+    `[1.924040] kvm_amd: PMU virtualization is disabled`
+ 7. This, in theory, is sufficient for KVM-acclelerated qemu to start a nested VM.
+ 8. Run `xhost si:localuser:root` to prevent `gtk initialization failed` error
+ 9. Run `sudo qemu-system-x86_64 -accel kvm`. A black window with "Guest has not initialized the display (yet)." appears.
+10. Run `sudo dmesg` and note qemu crash starting with `unchecked MSR access error: WRMSR`
+
+    \* Steps 1-4 are only required for diagnostics, and KVM works (in native Windows Hyper-V manager) without the necessarity to enter these commands in usual usage scenarios. If you run <span dir="">`cat /proc/cpuinfo | grep -c vmx` on Intel cpu</span> on Step 5, you may get zero. See Step 5 of Additional Info to understand why.
+
+    \
+    Microsoft released useful info about how to look into Hyper-V MSR access problems:\
+    WRMSR research in Hyper-V - https://msrc.microsoft.com/blog/2018/12/first-steps-in-hyper-v-research/
+Additional information:
+By default, Hyper-V manager in Windows does not allow nested virtualization.\
+To see what happens, do the following:
+
+ 1. Open Hyper-V manager built in the host Windows and create default Ubuntu 22.04 LTS suggested. Upon installation, shut down the VM. Note the name of the VM ("Ubuntu 22.04 LTS" by default).
+ 2. Open Powershell console in the host and run `Set-VMProcessor -VMName "Ubuntu 22.04 LTS" -ExposeVirtualizationExtensions $false`
+ 3. Launch guest Ubuntu 22.04 LTS, open its terminal and run `sudo dmesg | grep kvm`. No output.
+ 4. Run `sudo rdmsr 0xc0000080 #EFER` that outputs d01, which means that Hyper-V manager allows this **ring 0 level** operation.
+ 5. Run `cat /proc/cpuinfo | grep -c svm` for AMD or `cat /proc/cpuinfo | grep -c vmx`  for Intel. Note that output is `0`.
+ 6. Shut the VM down.
+ 7. Now, Open Powershell console and `run Set-VMProcessor -VMName "Ubuntu 22.04 LTS" -ExposeVirtualizationExtensions $true`
+ 8. Launch Ubuntu 22.04 LTS, open its terminal and run `sudo dmesg | grep kvm`. Output:
+
+    `[2.369144] kvm: Nested Virtualization enabled`
+
+    `[2.369146] SVM: kvm: Nested Paging enabled`
+
+    `[2.369148] SVM: kvm: Hyper-V enlightened NPT TLB flush enabled`
+
+    `[2.369149] SVM: kvm: Hyper-V Direct TLB flush enabled`
+
+    `[2.369153] SVM: Virtual VMLOAD VMSAVE supported`
+ 9. Run `cat /proc/cpuinfo | grep -c svm` for AMD or `cat /proc/cpuinfo | grep -c vmx`  for Intel. Note that output is `1` or other positive digit, depending on the number of cpus you've assigned to the VM.
+10. Run `xhost si:localuser:root` to prevent `gtk initialization failed` error
+11. Run `sudo qemu-system-x86_64 -accel kvm` and it successfully boots into qemu BIOS.
+12. Running `sudo qemu-system-x86_64 -accel kvm` calls WRMSR in background, so if you see\
+    booted qemu BIOS in KVM, wrmsr was successfully called.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_WHPX/2748 b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/2748
new file mode 100644
index 00000000..d15f2875
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/2748
@@ -0,0 +1,250 @@
+Windows specific main loop deadlock when using serial pipe communication
+Description of problem:
+Attaching WinDBG (or for that matter, any other serial end that sends data quickly enough) causes QEMU to deadlock.
+Steps to reproduce:
+1. Fire up QEMU with Windows (serial debugging enable)
+2. Restart
+3. At boot time, plug-in host WinDBG
+Additional information:
+WinDBG QEMU stacktrace
+```
+0:020> g
+(34c4.2330): Control-C exception - code 40010005 (first chance)
+First chance exceptions are reported before any exception handling.
+This exception may be expected and handled.
+KERNELBASE!CtrlRoutine+0x1be:
+00007ffe`82ace6ce 0f1f440000      nop     dword ptr [rax+rax]
+0:019> g
+(34c4.3b3c): Break instruction exception - code 80000003 (first chance)
+ntdll!DbgBreakPoint:
+00007ffe`850d4090 cc              int     3
+0:017> ~*k
+
+   0  Id: 34c4.28b8 Suspend: 1 Teb: 0000009f`a24ac000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a27f7388 00007ffe`829e6656     ntdll!NtCreateEvent+0x14
+0000009f`a27f7390 00007ff7`38abcbd6     KERNELBASE!PeekNamedPipe+0xa6
+0000009f`a27f7460 00007ff7`38bb8f11     qemu_system_x86_64!win_chr_pipe_poll+0x84
+0000009f`a27f74d0 00007ff7`38bb93fb     qemu_system_x86_64!os_host_main_loop_wait+0x133
+0000009f`a27ffba0 00007ff7`38686c45     qemu_system_x86_64!main_loop_wait+0xce
+0000009f`a27ffc00 00007ff7`38ac2f14     qemu_system_x86_64!qemu_main_loop+0x2b
+0000009f`a27ffc40 00007ff7`38ac2f52     qemu_system_x86_64!qemu_default_main+0x14
+0000009f`a27ffc80 00007ff7`38bdeede     qemu_system_x86_64!SDL_main+0x26
+0000009f`a27ffcb0 00007ff7`3838140a     qemu_system_x86_64!__mingw_enum_import_library_names+0x24e
+0000009f`a27ffd30 00007ff7`383814f6     qemu_system_x86_64!__tmainCRTStartup+0xea
+0000009f`a27ffd70 00007ffe`83ca259d     qemu_system_x86_64!mainCRTStartup+0x16
+0000009f`a27ffda0 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a27ffdd0 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+   1  Id: 34c4.2738 Suspend: 1 Teb: 0000009f`a24ae000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a29ffaa8 00007ffe`8506586e     ntdll!NtWaitForWorkViaWorkerFactory+0x14
+0000009f`a29ffab0 00007ffe`83ca259d     ntdll!TppWorkerThread+0x2ee
+0000009f`a29ffd90 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a29ffdc0 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+   2  Id: 34c4.35e4 Suspend: 1 Teb: 0000009f`a24b0000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a2bffa88 00007ffe`8506586e     ntdll!NtWaitForWorkViaWorkerFactory+0x14
+0000009f`a2bffa90 00007ffe`83ca259d     ntdll!TppWorkerThread+0x2ee
+0000009f`a2bffd70 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a2bffda0 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+   3  Id: 34c4.24f0 Suspend: 1 Teb: 0000009f`a24b2000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a2dff838 00007ffe`8506586e     ntdll!NtWaitForWorkViaWorkerFactory+0x14
+0000009f`a2dff840 00007ffe`83ca259d     ntdll!TppWorkerThread+0x2ee
+0000009f`a2dffb20 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a2dffb50 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+   4  Id: 34c4.2898 Suspend: 1 Teb: 0000009f`a24b4000 Unfrozen "pool"
+Child-SP          RetAddr               Call Site
+0000009f`a2fffb58 00007ffe`850997db     ntdll!NtWaitForAlertByThreadId+0x14
+0000009f`a2fffb60 00007ffe`829df2e9     ntdll!RtlSleepConditionVariableSRW+0x13b
+0000009f`a2fffbe0 00007ffd`cb1c6903     KERNELBASE!SleepConditionVariableSRW+0x29
+0000009f`a2fffc20 00007ffd`cb235399     libglib_2_0_0!g_byte_array_sort_with_data+0x143
+0000009f`a2fffc80 00007ffd`cb234a41     libglib_2_0_0!g_get_num_processors+0x2c9
+0000009f`a2fffce0 00007ffd`cb2696f7     libglib_2_0_0!g_test_get_path+0x51
+0000009f`a2fffd20 00007ffe`8424e634     libglib_2_0_0!g_private_replace+0x117
+0000009f`a2fffd50 00007ffe`8424e70c     msvcrt!_callthreadstartex+0x28
+0000009f`a2fffd80 00007ffe`83ca259d     msvcrt!_threadstartex+0x7c
+0000009f`a2fffdb0 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a2fffde0 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+   5  Id: 34c4.2ed8 Suspend: 1 Teb: 0000009f`a24b6000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a31ff9b8 00007ffe`829a9cee     ntdll!NtWaitForSingleObject+0x14
+0000009f`a31ff9c0 00007ff7`38b9f99f     KERNELBASE!WaitForSingleObjectEx+0x8e
+0000009f`a31ffa60 00007ff7`38baba83     qemu_system_x86_64!qemu_event_wait+0xe3
+0000009f`a31ffac0 00007ff7`38b9faf2     qemu_system_x86_64!call_rcu_thread+0x6c
+0000009f`a31ffb00 00007ffe`8424e634     qemu_system_x86_64!win32_start_routine+0x4e
+0000009f`a31ffb50 00007ffe`8424e70c     msvcrt!_callthreadstartex+0x28
+0000009f`a31ffb80 00007ffe`83ca259d     msvcrt!_threadstartex+0x7c
+0000009f`a31ffbb0 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a31ffbe0 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+   6  Id: 34c4.2980 Suspend: 1 Teb: 0000009f`a24b8000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a35ff888 00007ffe`82dc54a7     win32u!NtUserMsgWaitForMultipleObjectsEx+0x14
+0000009f`a35ff890 00007ffe`71373c70     USER32!MsgWaitForMultipleObjects+0x57
+0000009f`a35ff8d0 00007ffe`71373bc9     gdiplus!BackgroundThreadProc+0x70
+0000009f`a35ff940 00007ffe`83ca259d     gdiplus!DllRefCountSafeThreadThunk+0x29
+0000009f`a35ff970 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a35ff9a0 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+   7  Id: 34c4.3880 Suspend: 1 Teb: 0000009f`a24ba000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a37ff808 00007ffe`829c6849     ntdll!NtWaitForMultipleObjects+0x14
+0000009f`a37ff810 00007ffe`837707ad     KERNELBASE!WaitForMultipleObjectsEx+0xe9
+0000009f`a37ffaf0 00007ffe`8377061a     combase!WaitCoalesced+0xa9
+0000009f`a37ffd90 00007ffe`8377040f     combase!CROIDTable::WorkerThreadLoop+0x5a
+0000009f`a37ffde0 00007ffe`83770829     combase!CRpcThread::WorkerLoop+0x57
+0000009f`a37ffe60 00007ffe`83ca259d     combase!CRpcThreadCache::RpcWorkerThreadEntry+0x29
+0000009f`a37ffe90 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a37ffec0 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+   8  Id: 34c4.1bd0 Suspend: 1 Teb: 0000009f`a24bc000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a39ffaa8 00007ffe`8506586e     ntdll!NtWaitForWorkViaWorkerFactory+0x14
+0000009f`a39ffab0 00007ffe`83ca259d     ntdll!TppWorkerThread+0x2ee
+0000009f`a39ffd90 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a39ffdc0 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+   9  Id: 34c4.20fc Suspend: 1 Teb: 0000009f`a24be000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a3bffa78 00007ffe`8506586e     ntdll!NtWaitForWorkViaWorkerFactory+0x14
+0000009f`a3bffa80 00007ffe`83ca259d     ntdll!TppWorkerThread+0x2ee
+0000009f`a3bffd60 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a3bffd90 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+  10  Id: 34c4.1768 Suspend: 1 Teb: 0000009f`a24c0000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a3dff438 00007ffe`8457a212     win32u!NtUserMsgWaitForMultipleObjectsEx+0x14
+0000009f`a3dff440 00007ffe`8456fa2e     shcore!WorkThreadManager::CThread::ThreadProc+0xbf2
+0000009f`a3dff6f0 00007ffe`8456f9f1     shcore!WorkThreadManager::CThread::s_ExecuteThreadProc+0x22
+0000009f`a3dff730 00007ffe`83ca259d     shcore!<lambda_9844335fc14345151eefcc3593dd6895>::<lambda_invoker_cdecl>+0x11
+0000009f`a3dff760 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a3dff790 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+  11  Id: 34c4.3ac0 Suspend: 1 Teb: 0000009f`a24d6000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a41fead0 00007ffe`8506d249     ntdll!RtlpAllocateHeap+0x835
+0000009f`a41fed30 00007ffe`85134832     ntdll!RtlpAllocateHeapInternal+0x6c9
+0000009f`a41fee30 00007ffe`850ee2e8     ntdll!RtlDebugAllocateHeap+0x102
+0000009f`a41feed0 00007ffe`8506d249     ntdll!RtlpAllocateHeap+0x7f1a8
+0000009f`a41ff130 00007ffe`85059634     ntdll!RtlpAllocateHeapInternal+0x6c9
+0000009f`a41ff230 00007ffe`85058877     ntdll!LdrpAllocateTls+0x108
+0000009f`a41ff300 00007ffe`850a45af     ntdll!LdrpInitializeThread+0x6f
+0000009f`a41ff3e0 00007ffe`850a44e3     ntdll!_LdrpInitialize+0x93
+0000009f`a41ff460 00007ffe`850a440e     ntdll!LdrpInitializeInternal+0x6b
+0000009f`a41ff6e0 00000000`00000000     ntdll!LdrInitializeThunk+0xe
+
+  12  Id: 34c4.3fac Suspend: 1 Teb: 0000009f`a24c4000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a43ff268 00007ffe`85067e65     ntdll!NtWaitForAlertByThreadId+0x14
+0000009f`a43ff270 00007ff7`38b9edcd     ntdll!RtlAcquireSRWLockExclusive+0x165
+0000009f`a43ff2e0 00007ff7`386771e6     qemu_system_x86_64!qemu_mutex_lock_impl+0x73
+0000009f`a43ff320 00007ff7`388b5654     qemu_system_x86_64!bql_lock_impl+0x78
+0000009f`a43ff370 00007ff7`388b5b00     qemu_system_x86_64!prepare_mmio_access+0x30
+0000009f`a43ff3b0 00007ff7`388b5c6c     qemu_system_x86_64!flatview_read_continue_step+0xa0
+0000009f`a43ff430 00007ff7`388b5db9     qemu_system_x86_64!flatview_read_continue+0x66
+0000009f`a43ff480 00007ff7`388b5e60     qemu_system_x86_64!flatview_read+0xe2
+0000009f`a43ff500 00007ff7`388b5fb6     qemu_system_x86_64!address_space_read_full+0x78
+0000009f`a43ff570 00007ff7`38786ddf     qemu_system_x86_64!address_space_rw+0x68
+0000009f`a43ff5c0 00007ffd`c624af05     qemu_system_x86_64!whpx_emu_ioport_callback+0x63
+0000009f`a43ff610 00007ffd`c62523d5     WinHvEmulation!IoPortHandler::NotifyIoPortRead+0x45
+0000009f`a43ff640 00007ffd`c624b916     WinHvEmulation!EmulatorVp::DispatchIoPortOperation+0x159
+0000009f`a43ff690 00007ffd`c624a77f     WinHvEmulation!EmulatorVp::TrySimpleIoEmulation+0xc2
+0000009f`a43ff800 00007ffd`c6248caf     WinHvEmulation!EmulatorWrapper::TryEmulationHelper<<lambda_6e350ef384ad69a259a7e747c2fadeeb> &>+0xcb
+0000009f`a43ff8a0 00007ff7`38787201     WinHvEmulation!WHvEmulatorTryIoEmulation+0x10f
+0000009f`a43ff930 00007ff7`38788cd6     qemu_system_x86_64!whpx_handle_portio+0x73
+0000009f`a43ff9a0 00007ff7`38789bd2     qemu_system_x86_64!whpx_vcpu_run+0x4a8
+0000009f`a43ffb20 00007ff7`3878c008     qemu_system_x86_64!whpx_vcpu_exec+0x54
+0000009f`a43ffb60 00007ff7`38b9faf2     qemu_system_x86_64!whpx_cpu_thread_fn+0xfb
+0000009f`a43ffbb0 00007ffe`8424e634     qemu_system_x86_64!win32_start_routine+0x4e
+0000009f`a43ffc00 00007ffe`8424e70c     msvcrt!_callthreadstartex+0x28
+0000009f`a43ffc30 00007ffe`83ca259d     msvcrt!_threadstartex+0x7c
+0000009f`a43ffc60 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a43ffc90 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+  13  Id: 34c4.3ecc Suspend: 1 Teb: 0000009f`a24c6000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a45ff8c8 00007ffe`829a9cee     ntdll!NtWaitForSingleObject+0x14
+0000009f`a45ff8d0 00007ffd`e15631e2     KERNELBASE!WaitForSingleObjectEx+0x8e
+0000009f`a45ff970 00007ffd`e156b621     WinHvPlatform!WHvApi::Processor::RunVp+0x486
+0000009f`a45ffbe0 00007ff7`38788b9a     WinHvPlatform!WHvRunVirtualProcessor+0x31
+0000009f`a45ffc20 00007ff7`38789bd2     qemu_system_x86_64!whpx_vcpu_run+0x36c
+0000009f`a45ffda0 00007ff7`3878c008     qemu_system_x86_64!whpx_vcpu_exec+0x54
+0000009f`a45ffde0 00007ff7`38b9faf2     qemu_system_x86_64!whpx_cpu_thread_fn+0xfb
+0000009f`a45ffe30 00007ffe`8424e634     qemu_system_x86_64!win32_start_routine+0x4e
+0000009f`a45ffe80 00007ffe`8424e70c     msvcrt!_callthreadstartex+0x28
+0000009f`a45ffeb0 00007ffe`83ca259d     msvcrt!_threadstartex+0x7c
+0000009f`a45ffee0 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a45fff10 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+  14  Id: 34c4.3d08 Suspend: 1 Teb: 0000009f`a24c8000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a47ff1a8 00007ffe`829a9cee     ntdll!NtWaitForSingleObject+0x14
+0000009f`a47ff1b0 00007ffd`e15631e2     KERNELBASE!WaitForSingleObjectEx+0x8e
+0000009f`a47ff250 00007ffd`e156b621     WinHvPlatform!WHvApi::Processor::RunVp+0x486
+0000009f`a47ff4c0 00007ff7`38788b9a     WinHvPlatform!WHvRunVirtualProcessor+0x31
+0000009f`a47ff500 00007ff7`38789bd2     qemu_system_x86_64!whpx_vcpu_run+0x36c
+0000009f`a47ff680 00007ff7`3878c008     qemu_system_x86_64!whpx_vcpu_exec+0x54
+0000009f`a47ff6c0 00007ff7`38b9faf2     qemu_system_x86_64!whpx_cpu_thread_fn+0xfb
+0000009f`a47ff710 00007ffe`8424e634     qemu_system_x86_64!win32_start_routine+0x4e
+0000009f`a47ff760 00007ffe`8424e70c     msvcrt!_callthreadstartex+0x28
+0000009f`a47ff790 00007ffe`83ca259d     msvcrt!_threadstartex+0x7c
+0000009f`a47ff7c0 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a47ff7f0 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+  15  Id: 34c4.3eb4 Suspend: 1 Teb: 0000009f`a24ca000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a49ff278 00007ffe`829a9cee     ntdll!NtWaitForSingleObject+0x14
+0000009f`a49ff280 00007ffd`e15631e2     KERNELBASE!WaitForSingleObjectEx+0x8e
+0000009f`a49ff320 00007ffd`e156b621     WinHvPlatform!WHvApi::Processor::RunVp+0x486
+0000009f`a49ff590 00007ff7`38788b9a     WinHvPlatform!WHvRunVirtualProcessor+0x31
+0000009f`a49ff5d0 00007ff7`38789bd2     qemu_system_x86_64!whpx_vcpu_run+0x36c
+0000009f`a49ff750 00007ff7`3878c008     qemu_system_x86_64!whpx_vcpu_exec+0x54
+0000009f`a49ff790 00007ff7`38b9faf2     qemu_system_x86_64!whpx_cpu_thread_fn+0xfb
+0000009f`a49ff7e0 00007ffe`8424e634     qemu_system_x86_64!win32_start_routine+0x4e
+0000009f`a49ff830 00007ffe`8424e70c     msvcrt!_callthreadstartex+0x28
+0000009f`a49ff860 00007ffe`83ca259d     msvcrt!_threadstartex+0x7c
+0000009f`a49ff890 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a49ff8c0 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+  16  Id: 34c4.3844 Suspend: 1 Teb: 0000009f`a24cc000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`a4bff328 00007ffe`829c6849     ntdll!NtWaitForMultipleObjects+0x14
+0000009f`a4bff330 00007ffd`cb215d94     KERNELBASE!WaitForMultipleObjectsEx+0xe9
+0000009f`a4bff610 00007ffd`cb21607a     libglib_2_0_0!g_pattern_match_simple+0x214
+0000009f`a4bff690 00007ffd`cb216612     libglib_2_0_0!g_pattern_match_simple+0x4fa
+0000009f`a4bff6e0 00007ffd`cb203740     libglib_2_0_0!g_poll+0x392
+0000009f`a4bffbd0 00007ffd`cb204180     libglib_2_0_0!g_get_monotonic_time+0xac0
+0000009f`a4bffc60 00007ffd`c9eaa829     libglib_2_0_0!g_main_loop_run+0x120
+0000009f`a4bffcb0 00007ffd`e5ab4e2b     libspice_server_1!spice_server_init+0x1ca9
+0000009f`a4bffcf0 00007ffe`8424e634     libwinpthread_1!pthread_create_wrapper+0x9b
+0000009f`a4bffd30 00007ffe`8424e70c     msvcrt!_callthreadstartex+0x28
+0000009f`a4bffd60 00007ffe`83ca259d     msvcrt!_threadstartex+0x7c
+0000009f`a4bffd90 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`a4bffdc0 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+# 17  Id: 34c4.3b3c Suspend: 1 Teb: 0000009f`a24d8000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`c4dffd08 00007ffe`8510735e     ntdll!DbgBreakPoint
+0000009f`c4dffd10 00007ffe`83ca259d     ntdll!DbgUiRemoteBreakin+0x4e
+0000009f`c4dffd40 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`c4dffd70 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+
+  18  Id: 34c4.16c4 Suspend: 1 Teb: 0000009f`a24d0000 Unfrozen
+Child-SP          RetAddr               Call Site
+0000009f`c53ffb58 00007ffe`850997db     ntdll!NtWaitForAlertByThreadId+0x14
+0000009f`c53ffb60 00007ffe`829df2e9     ntdll!RtlSleepConditionVariableSRW+0x13b
+0000009f`c53ffbe0 00007ff7`38b9f403     KERNELBASE!SleepConditionVariableSRW+0x29
+0000009f`c53ffc20 00007ff7`38bbc9e5     qemu_system_x86_64!qemu_cond_timedwait_impl+0x92
+0000009f`c53ffc70 00007ff7`38b9faf2     qemu_system_x86_64!worker_thread+0xc9
+0000009f`c53ffce0 00007ffe`8424e634     qemu_system_x86_64!win32_start_routine+0x4e
+0000009f`c53ffd30 00007ffe`8424e70c     msvcrt!_callthreadstartex+0x28
+0000009f`c53ffd60 00007ffe`83ca259d     msvcrt!_threadstartex+0x7c
+0000009f`c53ffd90 00007ffe`8508af38     KERNEL32!BaseThreadInitThunk+0x1d
+0000009f`c53ffdc0 00000000`00000000     ntdll!RtlUserThreadStart+0x28
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_WHPX/2877 b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/2877
new file mode 100644
index 00000000..79a3593b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/2877
@@ -0,0 +1 @@
+Windows Hypervisor Acceleration does not work in Qemu 9.5.20 on Windows 11 24H2 Host
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_WHPX/289 b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/289
new file mode 100644
index 00000000..0f08a5ce
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/289
@@ -0,0 +1 @@
+Guest freezes until there is a keyboard input on Windows version
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_WHPX/430 b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/430
new file mode 100644
index 00000000..ebe9aaaf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/430
@@ -0,0 +1 @@
+Microsoft Hyper-V acceleration not working
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_WHPX/628 b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/628
new file mode 100644
index 00000000..7476dd8a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/628
@@ -0,0 +1,8 @@
+nested virtualization on whpx
+Additional information:
+Depends on, first needs fixing of, Issue #346 / Issue #430 , Essentially accel=whpx is not working/is broken/has regression.
+```
+PS J:\> E:\scoopg\shims\qemu-system-x86_64.exe  --version
+QEMU emulator version 6.1.0 (v6.1.0-11882-g7deea770bf-dirty)
+Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_WHPX/689 b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/689
new file mode 100644
index 00000000..7c43c0b5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/689
@@ -0,0 +1,33 @@
+Unable To Open UDP Port
+Description of problem:
+Unable to forward UDP port
+Steps to reproduce:
+Used **..\qemu-system-x86_64.exe" -smp  4 -accel whpx -hda ".\ubuntu01.qcow2" -m 8G  -vga std -net nic -net user,hostfwd=tcp::80-:80,hostfwd=tcp::443-:443,hostfwd=tcp::10000-:10000,hostfwd=udp::10000-:10000**__ to run qemu.
+Additional information:
+I want to use 10000(UDP) port at my server i used upper command to run my Qemu server as i was using it for TCP ports. Here are the logs:
+<br/>
+**AT Guest(UBUNTU):**<br/>
+10000/tcp                  ALLOW       Anywhere<br/>
+10000/udp                  ALLOW       Anywhere<br/><br/>
+
+**AT Host(Windows):**<br/>
+_**FOR TCP 10000 (IT'S WORKING)**_<br/>
+ Starting portqry.exe -n 127.0.0.1 -e 10000 -p TCP ...<br/>
+Querying target system called:<br/>
+ 127.0.0.1<br/>
+Attempting to resolve IP address to a name...<br/>
+IP address resolved to DESKTOP-Node001<br/>
+querying...<br/>
+TCP port 10000 (unknown service): LISTENING<br/>
+portqry.exe -n 127.0.0.1 -e 10000 -p TCP exits with return code 0x00000000.<br/><br/>
+
+
+_**FOR UDP 10000 (IT'S NOT WORKING)**_<br/>
+Starting portqry.exe -n 127.0.0.1 -e 10000 -p UDP ...<br/>
+Querying target system called:<br/>
+ 127.0.0.1<br/>
+Attempting to resolve IP address to a name...<br/>
+IP address resolved to DESKTOP-Node001<br/>
+querying...<br/>
+UDP port 10000 (unknown service): LISTENING or FILTERED<br/>
+portqry.exe -n 127.0.0.1 -e 10000 -p UDP exits with return code 0x00000002.<br/>
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_WHPX/858 b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/858
new file mode 100644
index 00000000..e2621ef0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_WHPX/858
@@ -0,0 +1,11 @@
+qemu-system-x86_64: WHPX: Unexpected VP exit code 4
+Description of problem:
+Qemu closes and  prints following message:
+
+WHPX: setting APIC emulation mode in the hypervisor
+Windows Hypervisor Platform accelerator is operational
+whpx: injection failed, MSI (0, 0) delivery: 0, dest_mode: 0, trigger mode: 0, vector: 0, lost (c0350005)
+qemu-system-x86_64: WHPX: Unexpected VP exit code 4
+Steps to reproduce:
+1. build OVMF firmware from edk2
+2. run cmd : qemu-system-x86_64 -accel whpx --bios D:\Projects\FW\uefi\edk2\Build\OvmfX64\DEBUG_VS2019\FV\OVMF.fd
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_Xen/1061 b/gitlab/issues_text/target_missing/host_missing/accel_Xen/1061
new file mode 100644
index 00000000..134a5780
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_Xen/1061
@@ -0,0 +1,246 @@
+xen/pt: Incorrect register mask for PCI passthrough prevents Linux guest from completing boot process
+Description of problem:
+In brief, the problem is that PCI/GPU passthrough functions normally with Xen/Qemu if the Xen HVM guest is Windows, but if the guest is Linux, the guest will not complete the booting process and it never reaches the systemd targets that allow the GUI environment to start and login to the desktop environment. The problem is that a bug in the way Qemu initializes the PCI status register of the passed through devices causes the PCI capabilities list bit of the PCI status register to be disabled instead of enabled. This in turn disables the MSI-x interrupt handling capability of the passed through PCI devices. I think the reason only Linux guests are affected is that Linux guests use a different method of delivering interrupts from the passed through PCI devices to the guest from the method used by Windows guests, and the method used by Windows does not require the MSI-x capability of the PCI devices but the method used by Linux does need the MSI-x capability of the passed through devices. I will explain this further in the additional information section with logs and other relevant information.
+Steps to reproduce:
+1. It might only be reproducible on specific hardware. It is very reproducible on my system, an ASRock B85M-Pro4 with BIOS version P2.50 and a Haswell core i5-4590S CPU.
+2. Configure the system to pass through the Intel integrated graphics device (IGD), the on-board USB 3 controller, and the onboard PCI audio device to a Windows Xen HVM guest with Qemu running as the device model for the Windows guest in Dom0 using the Xen xl toolstack, and verify that the Windows guest boots and functions properly. This is not trivial and can probably only be done by persons familiar with Xen and its PCI and VGA/GPU passthrough feature. Here is the xl domain configuration file that the Xen xl toolstack used to create and boot the working Windows HVM domain with passthrough of three PCI devices on my hardware:
+```
+builder = 'hvm'
+bios = 'seabios'
+memory = '3072'
+vcpus = '4'
+device_model_version = 'qemu-xen'
+disk = ['/dev/systems/windows,,xvda,w']
+name = 'bullseye'
+vif = [ 'model=e1000,script=vif-route,ip=<redacted>' ]
+on_poweroff = 'destroy'
+on_reboot = 'restart'
+on_crash = 'destroy'
+boot = 'c'
+acpi = '1'
+apic = '1'
+viridian = '1'
+xen_platform_pci = '1'
+serial = 'pty'
+vga = 'none'
+sdl = '0'
+vnc = '0'
+gfx_passthru = '1'
+pci = [ '00:1b.0', '00:14.0,rdm_policy=relaxed', '00:02.0' ]
+```
+3. Shut down the working Windows Xen HVM and replace it with a Linux Xen HVM disk image and try to boot that in place of Windows, keeping all other configuration options the same as with the working Windows guest. To create and boot the non-working Linux HVM domain, I used the same xl domain configuration as for Windows with the exception that the disk line was replaced with:
+```
+disk = ['/dev/systems/linux,,xvda,w']
+```
+which obviously points to a virtual disk that boots Linux instead of Windows. A Linux guest, such as Debian bullseye or Debian buster or Debian sid will not boot properly and instead exhibit the problem handling IRQs from the passed through PCI devices, as discussed above.
+Additional information:
+This problem is known by QubesOS and they have been using a patch to fix it since 2017, but they give very few details about the problem in their commit messages:
+
+https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/pull/3/commits/ab2b4c2ad02827a73c52ba561e9a921cc4bb227c
+
+That same patch to hw/xen/xen_pt_config_init.c also fixes the problem on my system.
+
+Some logs:
+
+Without the QubesOS patch, I get error messages indicating problems handling IRQs like this in the Dom0:
+
+May 10 08:50:03 bullseye kernel: [79077.644346] pciback 0000:00:1b.0: xen_pciback: vpci: assign to virtual slot 0  
+May 10 08:50:03 bullseye kernel: [79077.644478] pciback 0000:00:1b.0: registering for 16  
+May 10 08:50:03 bullseye kernel: [79077.644732] pciback 0000:00:14.0: xen_pciback: vpci: assign to virtual slot 1  
+May 10 08:50:03 bullseye kernel: [79077.644874] pciback 0000:00:14.0: registering for 16  
+May 10 08:50:03 bullseye kernel: [79077.645024] pciback 0000:00:02.0: xen_pciback: vpci: assign to virtual slot 2  
+May 10 08:50:03 bullseye kernel: [79077.645107] pciback 0000:00:02.0: registering for 16  
+May 10 08:50:30 bullseye kernel: [79105.273876] vif vif-16-0 vif16.0: Guest Rx ready  
+May 10 08:50:30 bullseye kernel: [79105.273893] IPv6: ADDRCONF(NETDEV_CHANGE): vif16.0: link becomes ready  
+May 10 08:50:30 bullseye kernel: [79105.278023] xen-blkback: backend/vbd/16/51712: using 4 queues, protocol 1 (x86_64-abi) persistent grants  
+May 10 08:50:44 bullseye kernel: [79119.104937] irq 16: nobody cared (try booting with the "irqpoll" option)  
+May 10 08:50:44 bullseye kernel: [79119.104973] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-6-amd64 #1 Debian 5.10.28-1  
+May 10 08:50:44 bullseye kernel: [79119.104976] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B85M Pro4, BIOS P2.50 12/11/2015  
+May 10 08:50:44 bullseye kernel: [79119.104979] Call Trace:  
+May 10 08:50:44 bullseye kernel: [79119.104984]  <IRQ>  
+May 10 08:50:44 bullseye kernel: [79119.104998]  dump_stack+0x6b/0x83  
+May 10 08:50:44 bullseye kernel: [79119.105008]  __report_bad_irq+0x35/0xa7  
+May 10 08:50:44 bullseye kernel: [79119.105014]  note_interrupt.cold+0xb/0x61  
+May 10 08:50:44 bullseye kernel: [79119.105024]  handle_irq_event+0xa8/0xb0  
+May 10 08:50:44 bullseye kernel: [79119.105030]  handle_fasteoi_irq+0x78/0x1c0  
+May 10 08:50:44 bullseye kernel: [79119.105037]  generic_handle_irq+0x47/0x50  
+May 10 08:50:44 bullseye kernel: [79119.105044]  __evtchn_fifo_handle_events+0x175/0x190  
+May 10 08:50:44 bullseye kernel: [79119.105054]  __xen_evtchn_do_upcall+0x66/0xb0  
+May 10 08:50:44 bullseye kernel: [79119.105063]  __xen_pv_evtchn_do_upcall+0x11/0x20  
+May 10 08:50:44 bullseye kernel: [79119.105069]  asm_call_irq_on_stack+0x12/0x20  
+May 10 08:50:44 bullseye kernel: [79119.105072]  </IRQ>  
+May 10 08:50:44 bullseye kernel: [79119.105079]  xen_pv_evtchn_do_upcall+0xa2/0xc0  
+May 10 08:50:44 bullseye kernel: [79119.105084]  exc_xen_hypervisor_callback+0x8/0x10  
+May 10 08:50:44 bullseye kernel: [79119.105091] RIP: e030:xen_hypercall_sched_op+0xa/0x20  
+May 10 08:50:44 bullseye kernel: [79119.105097] Code: 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  
+May 10 08:50:44 bullseye kernel: [79119.105100] RSP: e02b:ffffffff82603de8 EFLAGS: 00000246  
+May 10 08:50:44 bullseye kernel: [79119.105106] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff810023aa  
+May 10 08:50:44 bullseye kernel: [79119.105108] RDX: 0000000009d62df2 RSI: 0000000000000000 RDI: 0000000000000001  
+May 10 08:50:44 bullseye kernel: [79119.105111] RBP: ffffffff82613940 R08: 00000066a1715350 R09: 000047f57b235dc9  
+May 10 08:50:44 bullseye kernel: [79119.105114] R10: 0000000000007ff0 R11: 0000000000000246 R12: 0000000000000000  
+May 10 08:50:44 bullseye kernel: [79119.105117] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000  
+May 10 08:50:44 bullseye kernel: [79119.105124]  ? xen_hypercall_sched_op+0xa/0x20  
+May 10 08:50:44 bullseye kernel: [79119.105133]  ? xen_safe_halt+0xc/0x20  
+May 10 08:50:44 bullseye kernel: [79119.105140]  ? default_idle+0xa/0x10  
+May 10 08:50:44 bullseye kernel: [79119.105145]  ? default_idle_call+0x38/0xc0  
+May 10 08:50:44 bullseye kernel: [79119.105152]  ? do_idle+0x208/0x2b0  
+May 10 08:50:44 bullseye kernel: [79119.105158]  ? cpu_startup_entry+0x19/0x20  
+May 10 08:50:44 bullseye kernel: [79119.105164]  ? start_kernel+0x587/0x5a8  
+May 10 08:50:44 bullseye kernel: [79119.105170]  ? xen_start_kernel+0x625/0x631  
+May 10 08:50:44 bullseye kernel: [79119.105180]  ? startup_xen+0x3e/0x3e  
+May 10 08:50:44 bullseye kernel: [79119.105184] handlers:  
+May 10 08:50:44 bullseye kernel: [79119.105222] [<000000005d228d5f>] usb_hcd_irq [usbcore]  
+May 10 08:50:44 bullseye kernel: [79119.105245] [<00000000e534b010>] ath_isr [ath9k]  
+May 10 08:50:44 bullseye kernel: [79119.105257] Disabling IRQ #16  
+
+Also, without the patch, I get error messages about failure to handle IRQs in the Linux Xen HVM guest:
+
+Oct 23 18:50:32 domU kernel: irq 36: nobody cared (try booting with the "irqpoll" option)  
+Oct 23 18:50:32 domU kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-9-amd64 #1 Debian 5.10.70-1  
+Oct 23 18:50:32 domU kernel: Hardware name: Xen HVM domU, BIOS 4.14.3 10/22/2021  
+Oct 23 18:50:32 domU kernel: Call Trace:  
+Oct 23 18:50:32 domU kernel:  <IRQ>  
+Oct 23 18:50:32 domU kernel:  dump_stack+0x6b/0x83  
+Oct 23 18:50:32 domU kernel:  __report_bad_irq+0x35/0xa7  
+Oct 23 18:50:32 domU kernel:  note_interrupt.cold+0xb/0x61  
+Oct 23 18:50:32 domU kernel:  handle_irq_event+0xa8/0xb0  
+Oct 23 18:50:32 domU kernel:  handle_fasteoi_irq+0x78/0x1c0  
+Oct 23 18:50:32 domU kernel:  generic_handle_irq+0x47/0x50  
+Oct 23 18:50:32 domU kernel:  __evtchn_fifo_handle_events+0x175/0x190  
+Oct 23 18:50:32 domU kernel:  __xen_evtchn_do_upcall+0x66/0xb0  
+Oct 23 18:50:32 domU kernel:  __sysvec_xen_hvm_callback+0x22/0x30  
+Oct 23 18:50:32 domU kernel:  asm_call_irq_on_stack+0x12/0x20  
+Oct 23 18:50:32 domU kernel:  </IRQ>  
+Oct 23 18:50:32 domU kernel:  sysvec_xen_hvm_callback+0x72/0x80  
+Oct 23 18:50:32 domU kernel:  asm_sysvec_xen_hvm_callback+0x12/0x20  
+Oct 23 18:50:32 domU kernel: RIP: 0010:native_safe_halt+0xe/0x10  
+Oct 23 18:50:32 domU kernel: Code: 02 20 48 8b 00 a8 08 75 c4 e9 7b ff ff ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc e9 07 00 00 00 0f 00 2d a6 6f 54 00 fb f4 <c3> 90 e9 07 00 00 00 0f 00 2d 96 6f 54 00 f4 c3 cc cc 0f 1f 44 00  
+Oct 23 18:50:32 domU kernel: RSP: 0018:ffffffff89003e48 EFLAGS: 00000246  
+Oct 23 18:50:32 domU kernel: RAX: 0000000000004000 RBX: 0000000000000001 RCX: ffff8dbb7cc2c9c0  
+Oct 23 18:50:32 domU kernel: RDX: ffff8dbb7cc00000 RSI: ffff8dbaf55b1400 RDI: ffff8dbaf55b1464  
+Oct 23 18:50:32 domU kernel: RBP: ffff8dbaf55b1464 R08: ffffffff891b9120 R09: 0000000000000008  
+Oct 23 18:50:32 domU kernel: R10: 000000000000000e R11: 000000000000000d R12: 0000000000000001  
+Oct 23 18:50:32 domU kernel: R13: ffffffff891b91a0 R14: 0000000000000001 R15: 0000000000000000  
+Oct 23 18:50:32 domU kernel:  ? xen_sched_clock+0x11/0x20  
+Oct 23 18:50:32 domU kernel:  acpi_idle_do_entry+0x46/0x50  
+Oct 23 18:50:32 domU kernel:  acpi_idle_enter+0x86/0xc0  
+Oct 23 18:50:32 domU kernel:  cpuidle_enter_state+0x89/0x350  
+Oct 23 18:50:32 domU kernel:  cpuidle_enter+0x29/0x40  
+Oct 23 18:50:32 domU kernel:  do_idle+0x1ef/0x2b0  
+Oct 23 18:50:32 domU kernel:  cpu_startup_entry+0x19/0x20  
+Oct 23 18:50:32 domU kernel:  start_kernel+0x587/0x5a8  
+Oct 23 18:50:32 domU kernel:  secondary_startup_64_no_verify+0xb0/0xbb  
+Oct 23 18:50:32 domU kernel: handlers:  
+Oct 23 18:50:32 domU kernel: [<000000007d3a0964>] usb_hcd_irq [usbcore]  
+Oct 23 18:50:32 domU kernel: Disabling IRQ #36  
+Oct 23 18:50:32 domU kernel: PM: Image not found (code -22)  
+Oct 23 18:50:32 domU kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:45:pipe A] flip_done timed out  
+
+To prove the cause of the bug, I compare some logs without the patch
+and with the patch that fixes it.
+
+First, relevant logs generated by Qemu in Dom0, for existing Qemu without the patch. On Debian these logs are located in /var/log/xen in the Dom0:
+
+[00:06.0] xen_pt_realize: Assigning real physical device 00:14.0 to devfn 0x30  
+[...]  
+[00:06.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0290, syncing to 0x0280.  
+[...]  
+[00:06.0] xen_pt_realize: Real physical device 00:14.0 registered successfully  
+[00:02.0] xen_pt_realize: Assigning real physical device 00:02.0 to devfn 0x10  
+[...]  
+[00:02.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0090, syncing to 0x0080.  
+[...]  
+[00:02.0] xen_pt_realize: Real physical device 00:02.0 registered successfully  
+
+Next, the same logs, but now using a version of Qemu with the patch that fixes the bug:
+
+[00:06.0] xen_pt_realize: Assigning real physical device 00:14.0 to devfn 0x30  
+[...]  
+[00:06.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0290, syncing to 0x0290.  
+[...]  
+[00:06.0] xen_pt_realize: Real physical device 00:14.0 registered successfully   
+[00:02.0] xen_pt_realize: Assigning real physical device 00:02.0 to devfn 0x10  
+[...]  
+[00:02.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0090, syncing to 0x0090.  
+[...]  
+[00:02.0] xen_pt_realize: Real physical device 00:02.0 registered successfully  
+
+To decipher what is happening here, one must refer to the definitions
+in the pci/header.h file from PCI Utilities that in Debian is in the
+libpci-dev package and is probably in similarly named packages on other
+distros.
+
+The Offset of 0x0006 corresponds to the 16-bit PCI_STATUS register of
+the passed through device, and the Emulated value of 0x0010 sets the desired
+emulated value of the PCI_STATUS_CAP_LIST bit to 1 in the PCI_STATUS register.
+The host values of 0x0290, 0x0090 correspond to the setting of the register in the
+physical device for real device 00:14.0 and 00:02.0, respectively.
+The syncing to value indicates the value of the register that Qemu
+exposes to the guest. Notice that without the patch, the PCI_STATUS_CAP_LIST
+bit is turned off for the two PCI devices (register value = 0x0280 and 0x0080
+for real device 00:14.0 and 00:02.0, respectively), but the bit is turned
+on (0x0290 and 0x0090) for these devices with the patch. With the capabilities list enabled, the guest can use the MSI-x capability of the device, but with the capabilities
+list disabled, the guest cannot use the MSI-x capability of the devices.
+That explains why this patch is needed in Qemu to fix this problem and enable the Linux guest to use the MSI-x capability of the passed through PCI devices.
+
+This is the QubesOS patch thatfixes it:
+```
+--- a/hw/xen/xen_pt_config_init.c
++++ b/hw/xen/xen_pt_config_init.c
+@@ -1969,7 +1969,7 @@
+             /* Mask out host (including past size). */
+             new_val = val & host_mask;
+             /* Merge emulated ones (excluding the non-emulated ones). */
+-            new_val |= data & host_mask;
++            new_val |= data & reg->emu_mask;
+             /* Leave intact host and emulated values past the size - even though
+              * we do not care as we write per reg->size granularity, but for the
+              * logging below lets have the proper value. */
+```
+The QubesOS patch that fixes it in Debian's Qemu 7.0.0 build is also attached as a file.[xen-fix-emu-mask.patch](/uploads/3bef189175549cd9854f8dc3d1affc88/xen-fix-emu-mask.patch)
+
+~~I will not officially submit it as a patch because I am not its author.~~
+
+~~I do not know why QubesOS never officially requested that this fix
+be committed to Qemu upstream, but I hope after review by the
+maintainers of the code touched by this patch it will be recognized
+as a necessary fix to a mistake that causes the desired merge of
+the host and emulated values to be incorrect.~~
+
+For reference, the commit that is fixed by the QubesOS patch is:
+
+Fixes: 2e87512eccf3c5e40f3142ff5a763f4f850839f4 (xen/pt: Sync up the dev.config and data values.)
+
+I think perhaps that commit and the patched file might need some other cleanup so I might try my hand at officially submitting a patch to Qemu that fixes this issue on my hardware without breaking something else, because it is possible that the simple QubesOS patch is not suitable as the correct fix. 
+
+But before I do that, I wish to make one more comment. In my logs, the only other register than the PCI_STATUS register that is affected by the QubesOS patch is the PCI_HEADER_TYPE register. Without the patch, the register's value is always exposed to the guest as 0x80, and with the patch, the value is always exposed as 0x00 (PCI_HEADER_TYPE_NORMAL as defined in pci/header.h). That is because Qemu sets the initial emulated value of PCI_HEADER_TYPE register to 0x80, but Qemu also sets the emu_mask to 0x00, so after correcting the merging of the host and emulated values with the QubesOS patch, the value is synced to 0x00 instead of 0x80. What I don't understand is why the register is initialized with 0x80, but the emu_mask is 0x00. Shouldn't the emu_mask be 0x80, to pass through the initial emulated value of 0x80? ~~Also, I don't know why the initial emulated value of PCI_HEADER_TYPE is set to 0x80 but I will assume that is the correct emulated value that should be exposed to the guest.~~ Update: After doing some research, I discovered the bit that is set in the PCI_HEADER_TYPE register (0x80) because of this issue is the bit to define the device as a multifunction device. None of my devices are multifunction, and the fact that the multifunction bit is incorrectly set on my passed through devices because of this issue seems to have no effect on the operation of the device or the guest. Apparently the author of the code to initialize the PCI_HEADER_TYPE register planned to initialize every passed through device as a multifunction device, but is this needed? My testing indicates it is not needed on my system.
+
+I am referring to this code in hw/xen/xen_pt_config_init.c:
+
+```
+static int xen_pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                       XenPTRegInfo *reg, uint32_t real_offset,
+                                       uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+[...]
+
+     /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = xen_pt_header_type_reg_init,
+        .u.b.read   = xen_pt_byte_reg_read,
+        .u.b.write  = xen_pt_byte_reg_write,
+    },
+```
+I would appreciate any guidance that experienced Qemu or Xen contributors can give me about this question. ~~If no one gives me any guidance here in a timely manner, I plan to propose my own fix officially to Qemu as the QubesOS patch plus changing the emu_mask value of the PCI_HEADER_TYPE register from 0x00 to 0x80. I verified that fixes the problem I am seeing in the PCI_STATUS register without also causing the change that the QubesOS patch makes to the PCI_HEADER_TYPE register.~~
+
+I plan to submit a patch to fix this issue, noting the effect the patch has on the PCI_HEADER_TYPE register in the commit message.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_Xen/485 b/gitlab/issues_text/target_missing/host_missing/accel_Xen/485
new file mode 100644
index 00000000..69a5db7a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_Xen/485
@@ -0,0 +1 @@
+Failed to restore domain - error load load virtio-balloon:virtio
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_Xen/685 b/gitlab/issues_text/target_missing/host_missing/accel_Xen/685
new file mode 100644
index 00000000..b11f237c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_Xen/685
@@ -0,0 +1,69 @@
+QEMU Segmentation fault - Xen / Ubuntu 18.04
+Description of problem:
+See notes below.
+Steps to reproduce:
+See notes below.
+Additional information:
+* The error is very rare.
+* The VMs have been created with `xl create` (Xen utility).
+* The error has been found with _coredump_ ([core.qemu-system-i38.0.abb1047980ee4143937dcce7b8da9e60.16892.1634806267000000.lz4](/uploads/a90e21a2e14c9ebba07585034de25b1a/core.qemu-system-i38.0.abb1047980ee4143937dcce7b8da9e60.16892.1634806267000000.lz4)):
+```bash
+$ sudo coredumpctl info 16892
+           PID: 16892 (qemu-system-i38)
+           UID: 0 (root)                               
+           GID: 0 (root)                                                                                                                                                                                                                      
+        Signal: 11 (SEGV)                
+     Timestamp: Thu 2021-10-21 11:51:07 MSK (17min ago)           
+  Command Line: /usr/bin/qemu-system-i386 -xen-domid 2679 -no-shutdown -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-2679,server,nowait -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,path=/var/run/xen/qmp
+    Executable: /usr/bin/qemu-system-i386
+ Control Group: /system.slice/ptms.sandbox.sandbox-creator.service
+          Unit: ptms.sandbox.sandbox-creator.service
+         Slice: system.slice
+       Boot ID: abb1047980ee4143937dcce7b8da9e60                                                                            
+    Machine ID: bdce82649a9d4d9db192a692b330943f                      
+      Hostname: ptms-7
+       Storage: /var/lib/systemd/coredump/core.qemu-system-i38.0.abb1047980ee4143937dcce7b8da9e60.16892.1634806267000000.lz4
+       Message: Process 16892 (qemu-system-i38) of user 0 dumped core.         
+                                                                           
+                Stack trace of thread 16892:                 
+                #0  0x00007f1c6d33ca5f __memmove_avx_unaligned_erms (libc.so.6)
+                #1  0x00005586abeae8bf iov_from_buf_full (qemu-system-i386)
+                #2  0x00005586abe03d46 n/a (qemu-system-i386)
+                #3  0x00005586abdd17ad n/a (qemu-system-i386)
+                #4  0x00005586abeac93c n/a (qemu-system-i386)        
+                #5  0x00007f1c6d2067b0 n/a (libc.so.6)                
+                #6  0x00005586abeb89bd n/a (qemu-system-i386)
+                #7  0x00005586abeaaf87 aio_bh_poll (qemu-system-i386)            
+                #8  0x00005586abe9a45e aio_dispatch (qemu-system-i386)  
+                #9  0x00005586abeaad9e n/a (qemu-system-i386)           
+                #10 0x00007f1c6fd7f537 g_main_context_dispatch (libglib-2.0.so.0)
+                #11 0x00005586abeb5caa main_loop_wait (qemu-system-i386)
+                #12 0x00005586abca092d qemu_main_loop (qemu-system-i386)
+                #13 0x00005586ab9f508e main (qemu-system-i386)
+                #14 0x00007f1c6d1cfbf7 __libc_start_main (libc.so.6)
+                #15 0x00005586ab9f97fa _start (qemu-system-i386)
+                                                                         
+                Stack trace of thread 16932:                 
+                #0  0x00007f1c6d2c9639 syscall (libc.so.6)   
+                #1  0x00005586abe9de1b qemu_event_wait (qemu-system-i386)
+                #2  0x00005586abea5e28 n/a (qemu-system-i386)
+                #3  0x00005586abe9d0b6 n/a (qemu-system-i386)
+                #4  0x00007f1c6d5a66db start_thread (libpthread.so.0)
+                #5  0x00007f1c6d2cf71f __clone (libc.so.6)          
+                                                               
+                Stack trace of thread 16957:                   
+                #0  0x00007f1c6d5b0474 __libc_read (libpthread.so.0)
+                #1  0x00007f1c71f67777 n/a (libxenstore.so.3.0)      
+                #2  0x00007f1c71f6784d n/a (libxenstore.so.3.0)
+                #3  0x00007f1c71f67b61 n/a (libxenstore.so.3.0)
+                #4  0x00007f1c6d5a66db start_thread (libpthread.so.0)
+                #5  0x00007f1c6d2cf71f __clone (libc.so.6)          
+
+                Stack trace of thread 16958:                   
+                #0  0x00007f1c6d5b0474 __libc_read (libpthread.so.0)
+                #1  0x00007f1c71f67777 n/a (libxenstore.so.3.0)      
+                #2  0x00007f1c71f6784d n/a (libxenstore.so.3.0)
+                #3  0x00007f1c71f67b61 n/a (libxenstore.so.3.0)
+                #4  0x00007f1c6d5a66db start_thread (libpthread.so.0)
+                #5  0x00007f1c6d2cf71f __clone (libc.so.6)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/100 b/gitlab/issues_text/target_missing/host_missing/accel_missing/100
new file mode 100644
index 00000000..78bf9ef6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/100
@@ -0,0 +1 @@
+GDB context is inconsistent after "monitor system_reset"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1000 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1000
new file mode 100644
index 00000000..6e85abef
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1000
@@ -0,0 +1,4 @@
+Can qemu support different core on one machine?
+Description of problem:
+I want to build a machine, including three core which is different types, arm Cortex-M3 core, cortex-m33 core, contex-a53 core, communicate through mailbox. I checked the current implementation of QEMU and saw that a machine uses a core, such as mps2.c virt.c . I want to know whether the QEMU strategy supports different types of cores on one machine and can communicate with each other.
+Thanks.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1001 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1001
new file mode 100644
index 00000000..fbb5ab4d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1001
@@ -0,0 +1 @@
+query the current cursor position with QMP
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1005 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1005
new file mode 100644
index 00000000..6ba080cc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1005
@@ -0,0 +1,177 @@
+blockdev-del doesn't work after blockdev-backup with incremental, which using dirty-bitmap
+Description of problem:
+After incremental backup with bitmap, blockdev-del doesn't work at target node.  
+Because of this, incremental backup cannot rebase to base node.  
+I refered this. https://qemu-project.gitlab.io/qemu/interop/bitmaps.html#example-incremental-push-backups-without-backing-files
+Steps to reproduce:
+1. `blockdev-add` incremental backup node
+```
+echo '{"execute":"qmp_capabilities"}{"execute":"blockdev-add","arguments":{"driver":"qcow2","node-name":"incre0","file":{"driver":"file","filename":"/mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/incre0.qcow2"}}}' | nc -U /mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/qmp.sock -N
+
+{
+    "return": {
+    }
+}
+```
+2. `blockdev-backup` with `vda` to target `incre0` node
+```
+echo '{"execute":"qmp_capabilities"}{"execute":"blockdev-backup", "arguments": {"device": "vda", "bitmap":"bitmap0", "target": "incre0", "sync": "incremental", "job-id": "incre0-job", "speed": 536870912}}' | nc -U /mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/qmp.sock -N
+
+{
+    "timestamp": {
+        "seconds": 1651050066,
+        "microseconds": 848370
+    },
+    "event": "JOB_STATUS_CHANGE",
+    "data": {
+        "status": "created",
+        "id": "incre0-job"
+    }
+}
+{
+    "timestamp": {
+        "seconds": 1651050066,
+        "microseconds": 848431
+    },
+    "event": "JOB_STATUS_CHANGE",
+    "data": {
+        "status": "running",
+        "id": "incre0-job"
+    }
+}
+{
+    "timestamp": {
+        "seconds": 1651050066,
+        "microseconds": 848464
+    },
+    "event": "JOB_STATUS_CHANGE",
+    "data": {
+        "status": "paused",
+        "id": "incre0-job"
+    }
+}
+{
+    "timestamp": {
+        "seconds": 1651050066,
+        "microseconds": 848485
+    },
+    "event": "JOB_STATUS_CHANGE",
+    "data": {
+        "status": "running",
+        "id": "incre0-job"
+    }
+}
+{
+    "return": {
+    }
+}
+
+```
+3. `query-block-jobs` check `incre0-job` is done
+```
+echo '{"execute":"qmp_capabilities"}{"execute":"query-block-jobs"}' | nc -U /mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/qmp.sock -N
+
+{
+    "return": {
+    }
+}
+{
+    "return": [
+    ]
+}
+```
+4. To release write lock (need to rebase in incre0.qcow2), `blockdev-del`
+```
+echo '{"execute":"qmp_capabilities"}{"execute":"blockdev-del","arguments":{"node-name":"incre0"}' | nc -U /mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/qmp.sock -N
+
+{
+    "return": {
+    }
+}
+```
+5. `qemu-img rebase`
+```
+qemu-img rebase -b base.qcow2 -u incre0.qcow2
+
+qemu-img: Could not open 'incre0.qcow2': Failed to get "write" lock
+Is another process using the image [incre0.qcow2]?
+```
+
+6. check `query-named-block-nodes` after `blockdev-del`
+```
+{
+    "return": [
+        {
+            "iops_rd": 0,
+            "detect_zeroes": "off",
+            "image": {
+                "virtual-size": 53687091200,
+                "filename": "/mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/incre0.qcow2",
+                "cluster-size": 65536,
+                "format": "qcow2",
+                "actual-size": 241340416,
+                "format-specific": {
+                    "type": "qcow2",
+                    "data": {
+                        "compat": "1.1",
+                        "compression-type": "zlib",
+                        "lazy-refcounts": false,
+                        "refcount-bits": 16,
+                        "corrupt": false,
+                        "extended-l2": false
+                    }
+                },
+                "dirty-flag": false
+            },
+            "iops_wr": 0,
+            "ro": false,
+            "node-name": "incre0",
+            "backing_file_depth": 0,
+            "drv": "qcow2",
+            "iops": 0,
+            "bps_wr": 0,
+            "write_threshold": 0,
+            "encrypted": false,
+            "bps": 0,
+            "bps_rd": 0,
+            "cache": {
+                "no-flush": false,
+                "direct": false,
+                "writeback": true
+            },
+            "file": "/mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/incre0.qcow2"
+        },
+        {
+            "iops_rd": 0,
+            "detect_zeroes": "off",
+            "image": {
+                "virtual-size": 240451584,
+                "filename": "/mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/incre0.qcow2",
+                "format": "file",
+                "actual-size": 241340416,
+                "dirty-flag": false
+            },
+            "iops_wr": 0,
+            "ro": false,
+            "node-name": "#block412",
+            "backing_file_depth": 0,
+            "drv": "file",
+            "iops": 0,
+            "bps_wr": 0,
+            "write_threshold": 0,
+            "encrypted": false,
+            "bps": 0,
+            "bps_rd": 0,
+            "cache": {
+                "no-flush": false,
+                "direct": false,
+                "writeback": true
+            },
+            "file": "/mnt/7b12fe9c-fa0f-4f2a-82b1-3a6cd4e15ae8/temp/incre0.qcow2"
+        },
+        ......
+    ]
+}
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1006 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1006
new file mode 100644
index 00000000..5375c480
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1006
@@ -0,0 +1,3 @@
+qga:  add get disk stats of guest interface
+Additional information:
+just for linux
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1007 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1007
new file mode 100644
index 00000000..bf3829fe
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1007
@@ -0,0 +1 @@
+qemu-user: add execveat syscall support
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1010 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1010
new file mode 100644
index 00000000..35c82409
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1010
@@ -0,0 +1,78 @@
+Errors on 9p mounts
+Description of problem:
+I'm trying to run Docker VMs with [Lima](https://github.com/lima-vm/lima), which uses QEMU. I'm trying to expose my home directory on macOS to the Ubuntu VM using `9p`. This is how the mount point looks like inside the Ubuntu VM:
+
+```
+root@lima-docker:~# mount | grep Users
+mount0 on /Users/carlos type 9p (rw,relatime,dirsync,fscache,cachetag=4294894070,access=user,trans=virtio,version=9p2000.u)
+root@lima-docker:~#
+```
+
+The problem I'm seeing is that doing an `ls -l /Users/carlos` gives a "Timer expired" error, and no output:
+
+```
+root@lima-docker:~# ls -l /Users/carlos
+ls: reading directory '/Users/carlos': Timer expired
+total 0
+```
+
+Under `strace`, it seems that the timer error is raised by the `getdents64` system call:
+
+```
+root@lima-docker:~# strace -f ls -l /Users/carlos
+[..]
+openat(AT_FDCWD, "/Users/carlos", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
+newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=1984, ...}, AT_EMPTY_PATH) = 0
+mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffa16bf000
+getdents64(3, 0xffffa16bf040, 131072)   = -1 ETIME (Timer expired)
+[..]
+```
+
+I've also tried the `9p2000.L` protocol instead, and the results are a bit better. I do get a directory listing, but I see "xxx" errors:
+
+```
+root@lima-docker:~# ls -l /Users/carlos
+ls: /Users/carlos: Network dropped connection on reset
+ls: /Users/carlos/Music: Network dropped connection on reset
+ls: /Users/carlos/Pictures: Network dropped connection on reset
+ls: /Users/carlos/Desktop: Network dropped connection on reset
+ls: /Users/carlos/Library: Network dropped connection on reset
+ls: /Users/carlos/Public: Network dropped connection on reset
+ls: /Users/carlos/Movies: Network dropped connection on reset
+ls: /Users/carlos/Applications: Network dropped connection on reset
+ls: /Users/carlos/Dropbox: Network dropped connection on reset
+ls: /Users/carlos/Maildir: Network dropped connection on reset
+ls: /Users/carlos/Documents: Network dropped connection on reset
+ls: /Users/carlos/Downloads: Network dropped connection on reset
+total 0
+drwx------   5 carlos dialout  160 Dec  6 10:31  Applications
+drwx------   4 carlos dialout  128 Apr 28 14:40  Desktop
+drwx------  12 carlos dialout  384 Apr 30 08:44  Documents
+drwx------ 164 carlos dialout 5248 Apr 29 13:50  Downloads
+drwx------   8 carlos dialout  256 Sep  4  2021  Dropbox
+drwx------  82 carlos dialout 2624 Apr  8 14:05  Library
+drwxr-xr-x   3 carlos dialout   96 Nov 12 12:28  Maildir
+drwx------   4 carlos dialout  128 Jul 19  2021  Movies
+drwx------   4 carlos dialout  128 Aug 19  2021  Music
+drwx------   4 carlos dialout  128 Jul 19  2021  Pictures
+drwxr-xr-x   4 carlos dialout  128 Jul 19  2021  Public
+```
+
+The errors in this case seem to come from the `lgetxattr`system call:
+
+```
+root@lima-docker:~# strace -f ls -l /Users/carlos
+[..]
+statx(AT_FDCWD, "/Users/carlos/Downloads", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFDIR|0700, stx_size=5248, ...}) = 0
+lgetxattr("/Users/carlos/Downloads", "security.selinux", 0xaaaaec72da70, 255) = -1 ENETRESET (Network dropped connection on reset)
+write(2, "ls: ", 4ls: )                     = 4
+write(2, "/Users/carlos/Downloads", 23/Users/carlos/Downloads) = 23
+write(2, ": Network dropped connection on "..., 37: Network dropped connection on reset) = 37
+[..]
+```
+
+I've reported this to the Lima folks at https://github.com/lima-vm/lima/issues/831, and they suggested opening an issue here. Any ideas?
+Steps to reproduce:
+1. If you have Lima installed (I'm using version 0.10.0): `limactl start --name=docker ./lima-templates/docker.yaml`
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1012 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1012
new file mode 100644
index 00000000..b0aa424c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1012
@@ -0,0 +1,41 @@
+9p: newfstatat behaves differently than fstat causing ENOENT for here-documents
+Description of problem:
+After recent gnulib and coreutils update bash here-documents stopped to work producing `cat: -: No such file or directory` error.
+Steps to reproduce:
+1. I have file `a` with:
+```
+cat <<EOF
+x
+EOF
+```
+2. User visible error inside VM:
+```
+root@x86_64:~# grep 9p /proc/mounts
+/dev/root / 9p rw,dirsync,relatime,loose,access=any,msize=262144,trans=virtio 0 0
+root@x86_64:~# bash a
+cat: -: No such file or directory
+```
+3. `strace -fyv bash a` shows:
+```
+  [pid   291] newfstatat(1</dev/ttyS0>, "", {st_dev=makedev(0, 0x5), st_ino=85, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(0x4, 0x40), st_atime=1651577553 /* 2022-05-03T11:32:33.969984203+0000 */,
+st_atime_nsec=969984203, st_mtime=1651577553 /* 2022-05-03T11:32:33.969984203+0000 */, st_mtime_nsec=969984203, st_ctime=1651577069 /* 2022-05-03T11:24:29.969984203+0000 */, st_ctime_nsec=969984203}, AT_EMPTY_PATH) = 0
+  [pid   291] newfstatat(0</usr/src/tmp/sh-thd.420UUL (deleted)>, "", 0x7ffd1b96a3a0, AT_EMPTY_PATH) = -1 ENOENT (No such file or directory)
+  [pid   291] write(2</dev/ttyS0>, "cat: ", 5cat: ) = 5
+  [pid   291] write(2</dev/ttyS0>, "-", 1-) = 1
+  [pid   291] write(2</dev/ttyS0>, ": No such file or directory", 27: No such file or directory) = 27
+  [pid   291] write(2</dev/ttyS0>, "\n", 1
+```
+Additional information:
+In comparison, `strace -fyv bash a` in the old system w/o gnulib/coreutils update shows:
+```
+  [pid   283] fstat(1</dev/ttyS0>, {st_dev=makedev(0, 0x5), st_ino=85, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(0x4, 0x40), st_atime=1651577784 /* 2022-05-03T11:36:24.238343204+0000 */, st_atime_nsec=238343204,
+st_mtime=1651577784 /* 2022-05-03T11:36:24.238343204+0000 */, st_mtime_nsec=238343204, st_ctime=1651577774 /* 2022-05-03T11:36:14.238343204+0000 */, st_ctime_nsec=238343204}) = 0
+  [pid   283] fstat(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, {st_dev=makedev(0, 0x14), st_ino=17926519, st_mode=S_IFREG|0600, st_nlink=0, st_uid=502, st_gid=502, st_blksize=262144, st_blocks=0, st_size=2, st_atime=1651577786 /* 2022-05-03T11:36:26.295302472+0000 */,
+st_atime_nsec=295302472, st_mtime=1651577785 /* 2022-05-03T11:36:25+0000 */, st_mtime_nsec=0, st_ctime=1651577785 /* 2022-05-03T11:36:25+0000 */, st_ctime_nsec=0}) = 0
+  [pid   283] fadvise64(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
+  [pid   283] mmap(NULL, 270336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f715f13e000
+  [pid   283] read(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, "x\n", 262144) = 2
+  [pid   283] write(1</dev/ttyS0>, "x\n", 2x
+```
+
+So it seems that they started to use `newfstatat` instead of `fstat`, which behaves differently.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1013 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1013
new file mode 100644
index 00000000..4f5449d1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1013
@@ -0,0 +1 @@
+[Bug] user input is not sanitized in QEMU_Elf_init and can lead to buffer overflow
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1014 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1014
new file mode 100644
index 00000000..d853ec92
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1014
@@ -0,0 +1,3 @@
+Make -chardev, -serial and others accept stderr like they accept stdio
+Additional information:
+It's not clear what should happen when the guest tries to read from (instead of write to) the character device. On the other hand, I don't think the specific behavior matters very much.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1015 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1015
new file mode 100644
index 00000000..6d8e325f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1015
@@ -0,0 +1 @@
+qemu-7.0 there is no device "hostdev0" defined
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1016 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1016
new file mode 100644
index 00000000..6cb6a7cc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1016
@@ -0,0 +1,3 @@
+In-process sandboxing of the majority of QEMU via WebAssembly or similar
+Additional information:
+This would be in addition to other sandboxes, such as sVirt.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1018 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1018
new file mode 100644
index 00000000..77835c67
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1018
@@ -0,0 +1,23 @@
+virtio-scsi-pci with iothread results in 100% CPU in qemu 7.0.0
+Description of problem:
+Top reports constant 100% host CPU usage by `qemu-system-x86`. I have narrowed the issue down to the following section of the config:
+```
+        -object iothread,id=t0 \
+        -device virtio-scsi-pci,iothread=t0,num_queues=4 \
+```
+If this is replaced by
+```
+        -device virtio-scsi-pci \
+```
+Then CPU usage is normal (near 0%). 
+
+This problem doesn't appear with qemu 6.2.0 where CPU usage is near 0% even with iothread in the qemu options.
+Steps to reproduce:
+1. Download Kubuntu 22.04 LTS ISO (https://cdimage.ubuntu.com/kubuntu/releases/22.04/release/kubuntu-22.04-desktop-amd64.iso),
+2. Create a root virtual drive for the guest with 'qemu-img create -f qcow2 -o cluster_size=4k kubuntu.img 256G',
+3. Start the guest with the config given above,
+4. Connect to the guest (using spicy for example, password 'p'), select "try kubuntu" in grub menu AND later in the GUI, let it boot to plasma desktop, monitor host CPU usage using 'top'.
+
+(there could be a faster way to reproduce it)
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1019 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1019
new file mode 100644
index 00000000..86d951f9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1019
@@ -0,0 +1,13 @@
+Cannot create a shared directory between Ubuntu 20.04 host and (sparc) NetBSD 8.2 guest
+Description of problem:
+I am currently trying to set up a shared directory between the Ubuntu 20.04 LTS host and the QEMU guest. However, the error messages that I receive from QEMU immediately are the following, but unfortunately I don't know the proper way to do this given the host and guest OS.
+```
+qemu-system-sparc: warning: hub port hub0port1 has no peer
+qemu-system-sparc: warning: hub 0 with no nics
+qemu-system-sparc: warning: netdev hub0port1 has no peer
+qemu-system-sparc: warning: requested NIC (#net276, model virtio) was not created (not supported by this machine?)
+```
+Steps to reproduce:
+1. Installed `samba` on the host with `sudo apt install samba`
+2. Created `/home/rflint/shared_dir` on the host
+3. Ran the command indicated at the top of the page.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/102 b/gitlab/issues_text/target_missing/host_missing/accel_missing/102
new file mode 100644
index 00000000..17011619
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/102
@@ -0,0 +1 @@
+Mouse stops working when connected usb-storage-device
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1020 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1020
new file mode 100644
index 00000000..96cc115d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1020
@@ -0,0 +1,16 @@
+Display mode 0x6 doubles lines
+Description of problem:
+When developing https://github.com/korneliuszo/ne2000xt I've occured problem with double lines in mode 0x06 of VGA display, problem doesn't exist in mode 0x05
+Steps to reproduce:
+1. Call int 0x10, to setup video mode
+2. put data into video ram  (./cga.py -i 192.168.1.102 -I ~/a.png)
+3. bad display
+Additional information:
+Bad display:
+![a](/uploads/a6d13b7f5f45000c46371b0bdf526d2a/a.png)
+
+Same data, but in mode 0x05
+![b](/uploads/585d4dfe35b4ee028374100c10929f68/b.png)
+
+Same script as in bad display but run under 86Box
+![20220510-172456-004004](/uploads/bf42813fbcbb6a73e736d0635c6425c5/20220510-172456-004004.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1024 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1024
new file mode 100644
index 00000000..115880f7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1024
@@ -0,0 +1,10 @@
+Unable to build QEMU with dbus display support on Windows
+Description of problem:
+When building QEMU on Windows with `./configure --enable-dbus-display --enable-modules`, the following error appears:
+
+`ERROR: Modules are not available for Windows`
+Steps to reproduce:
+1. Attempt to build QEMU on Windows (MSYS2 MinGW) with dbus display support
+Additional information:
+Attempting to build with only `--enable-dbus-display` does not work either, as it requires `--enable-modules`, which does not work on Windows:
+`../meson.build:1598:0: ERROR: Feature dbus_display cannot be enabled: -display dbus requires --enable-modules`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1025 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1025
new file mode 100644
index 00000000..b6c9ac52
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1025
@@ -0,0 +1,3 @@
+qemu-img create  will silently overwrite existing image
+Description of problem:
+If file exists, it is silently overwritten, causing loss of data. oups.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1026 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1026
new file mode 100644
index 00000000..b840d2c4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1026
@@ -0,0 +1,116 @@
+Backup with large RBD disk is slow since QEMU 6.2.0 (since commit 0347a8fd)
+Description of problem:
+Since commit 0347a8fd4c ("block/rbd: implement bdrv_co_block_status"), there is a big slowdown for large RBD images for backup.
+Steps to reproduce:
+I used the following script
+```
+root@pve701 ~ # cat rbdbackup.sh
+#!/bin/bash
+rbd create emptytestA -p rbdkvm --size $2
+rbd create emptytestB -p rbdkvm --size $2
+$1 \
+    -qmp stdio \
+    -drive file=rbd:rbdkvm/emptytestA:conf=/etc/pve/ceph.conf:id=admin:keyring=/etc/pve/priv/ceph/rbdkvm.keyring,if=none,id=driveA,format=raw \
+    -drive file=rbd:rbdkvm/emptytestB:conf=/etc/pve/ceph.conf:id=admin:keyring=/etc/pve/priv/ceph/rbdkvm.keyring,if=none,id=driveB,format=raw \
+<<EOF
+{"execute": "qmp_capabilities"}
+{"execute": "blockdev-backup",
+     "arguments": { "device": "driveA",
+                    "sync": "full",
+                    "target": "driveB" } }
+EOF
+rbd -p rbdkvm rm emptytestA
+rbd -p rbdkvm rm emptytestB
+```
+with 200G and 500G images respectively and QEMU binaries built from current master (i.e. 10c2a0c5e7d48e590d945c017b5b8af5b4c89a3c) and from current master with fc176116cdea816ceb8dd969080b2b95f58edbc0, 9e302f64bb407a9bb097b626da97228c2654cfee and 0347a8fd4c3faaedf119be04c197804be40a384b reverted.
+
+
+Timings:
+```
+200G master:         92s
+200G master+reverts: 57s
+500G master:         526s
+500G master+reverts: 142s
+```
+
+I checked how long a single call to `rbd_diff_iterate2()` in `block/rbd.c` takes, and it seems to take about linearly more time the bigger the image is. But it is also called linearly more often, resulting in about quadratic slowdown overall.
+Additional information:
+Full commands/output:
+```
+root@pve701 ~ # ./rbdbackup.sh ./qemu-upstream/10c2a0c5e7d48e590d945c017b5b8af5b4c89a3c/qemu-system-x86_64 200G                 
+{"QMP": {"version": {"qemu": {"micro": 50, "minor": 0, "major": 7}, "package": "v7.0.0-981-g10c2a0c5e7"}, "capabilities": ["oob"]}}
+VNC server running on 127.0.0.1:5900
+{"return": {}}
+{"timestamp": {"seconds": 1652695629, "microseconds": 651397}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695629, "microseconds": 651447}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695629, "microseconds": 651464}, "event": "JOB_STATUS_CHANGE", "data": {"status": "paused", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695629, "microseconds": 651490}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}}
+{"return": {}}
+{"timestamp": {"seconds": 1652695721, "microseconds": 415892}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695721, "microseconds": 416066}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695721, "microseconds": 416197}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "driveA", "len": 214748364800, "offset": 214748364800, "speed": 0, "type": "backup"}}
+{"timestamp": {"seconds": 1652695721, "microseconds": 416239}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695721, "microseconds": 416265}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "driveA"}}
+^Cqemu-system-x86_64: terminating on signal 2
+{"timestamp": {"seconds": 1652695727, "microseconds": 145031}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-signal"}}
+Removing image: 100% complete...done.
+Removing image: 100% complete...done.
+./rbdbackup.sh  200G  81.15s user 6.31s system 89% cpu 1:38.21 total
+root@pve701 ~ # ./rbdbackup.sh ./qemu-upstream/10c2a0c5e7d48e590d945c017b5b8af5b4c89a3c-with-rbd-reverts/qemu-system-x86_64 200G 
+{"QMP": {"version": {"qemu": {"micro": 50, "minor": 0, "major": 7}, "package": "v7.0.0-984-g20a19f8eae"}, "capabilities": ["oob"]}}
+VNC server running on 127.0.0.1:5900
+{"return": {}}
+{"timestamp": {"seconds": 1652695737, "microseconds": 444734}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695737, "microseconds": 444818}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695737, "microseconds": 444860}, "event": "JOB_STATUS_CHANGE", "data": {"status": "paused", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695737, "microseconds": 444885}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}}
+{"return": {}}
+{"timestamp": {"seconds": 1652695794, "microseconds": 437168}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695794, "microseconds": 437248}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695794, "microseconds": 437341}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "driveA", "len": 214748364800, "offset": 214748364800, "speed": 0, "type": "backup"}}
+{"timestamp": {"seconds": 1652695794, "microseconds": 437368}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695794, "microseconds": 437381}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "driveA"}}
+^Cqemu-system-x86_64: terminating on signal 2
+{"timestamp": {"seconds": 1652695803, "microseconds": 242148}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-signal"}}
+Removing image: 100% complete...done.
+Removing image: 100% complete...done.
+./rbdbackup.sh  200G  40.68s user 111.12s system 228% cpu 1:06.47 total
+root@pve701 ~ # ./rbdbackup.sh ./qemu-upstream/10c2a0c5e7d48e590d945c017b5b8af5b4c89a3c/qemu-system-x86_64 500G 
+{"QMP": {"version": {"qemu": {"micro": 50, "minor": 0, "major": 7}, "package": "v7.0.0-981-g10c2a0c5e7"}, "capabilities": ["oob"]}}
+VNC server running on 127.0.0.1:5900
+{"return": {}}
+{"timestamp": {"seconds": 1652695970, "microseconds": 663752}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695970, "microseconds": 663892}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695970, "microseconds": 663920}, "event": "JOB_STATUS_CHANGE", "data": {"status": "paused", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695970, "microseconds": 663980}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}}
+{"return": {}}
+{"timestamp": {"seconds": 1652696496, "microseconds": 556219}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "driveA"}}
+{"timestamp": {"seconds": 1652696496, "microseconds": 556386}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "driveA"}}
+{"timestamp": {"seconds": 1652696496, "microseconds": 556497}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "driveA", "len": 536870912000, "offset": 536870912000, "speed": 0, "type": "backup"}}
+{"timestamp": {"seconds": 1652696496, "microseconds": 556536}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "driveA"}}
+{"timestamp": {"seconds": 1652696496, "microseconds": 556555}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "driveA"}}
+^Cqemu-system-x86_64: terminating on signal 2
+{"timestamp": {"seconds": 1652696786, "microseconds": 408273}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-signal"}}
+Removing image: 100% complete...done.
+Removing image: 100% complete...done.
+./rbdbackup.sh  500G  453.34s user 28.30s system 58% cpu 13:36.48 total
+root@pve701 ~ # ./rbdbackup.sh ./qemu-upstream/10c2a0c5e7d48e590d945c017b5b8af5b4c89a3c-with-rbd-reverts/qemu-system-x86_64 500G
+{"QMP": {"version": {"qemu": {"micro": 50, "minor": 0, "major": 7}, "package": "v7.0.0-984-g20a19f8eae"}, "capabilities": ["oob"]}}
+VNC server running on 127.0.0.1:5900
+{"return": {}}
+{"timestamp": {"seconds": 1652695810, "microseconds": 648931}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695810, "microseconds": 649012}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695810, "microseconds": 649057}, "event": "JOB_STATUS_CHANGE", "data": {"status": "paused", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695810, "microseconds": 649080}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}}
+{"return": {}}
+{"timestamp": {"seconds": 1652695952, "microseconds": 13070}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695952, "microseconds": 13144}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695952, "microseconds": 13210}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "driveA", "len": 536870912000, "offset": 536870912000, "speed": 0, "type": "backup"}}
+{"timestamp": {"seconds": 1652695952, "microseconds": 13233}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "driveA"}}
+{"timestamp": {"seconds": 1652695952, "microseconds": 13249}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "driveA"}}
+^Cqemu-system-x86_64: terminating on signal 2
+{"timestamp": {"seconds": 1652695955, "microseconds": 692599}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-signal"}}
+Removing image: 100% complete...done.
+Removing image: 100% complete...done.
+./rbdbackup.sh  500G  99.49s user 277.78s system 258% cpu 2:25.78 total
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1027 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1027
new file mode 100644
index 00000000..51c51dd9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1027
@@ -0,0 +1,15 @@
+Executables should have embedded plist on macOS
+Description of problem:
+QEMU binaries on macOS should have an embedded property list (`plist`).
+
+The bundle identifier of an application, as well as many other settings, are usually not set programmatically but through an `Info.plist` file found within the application bundle (`.app`) which is a property list (basically a settings file in XML format). 
+
+When liking a command line binary, you can tell the linker to embed such a property list inside the binary and the system will respect that when loading the binary. Having an embedded `Info.plist` is highly recommended for all macOS applications, even command line tools, as many system features will not work correctly (or are not even possible) unless they have one (not in all places the binary name will work instead of a bundle identifier).
+
+All you need to do is writing a [plist file by hand](https://docs.transifex.com/formats/apple-plist) (for a list of available keys, see [Apple's documentation](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Introduction/Introduction.html)) and then tell the liker to embed it into the binary:
+
+```
+-sectcreate __TEXT __info_plist YourPlistFile.plist
+```
+
+This makes it far easier to set app specific settings correctly, as in #334 for example. Also things like sudden termination can be disabled completely that way without a single line of code.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/103 b/gitlab/issues_text/target_missing/host_missing/accel_missing/103
new file mode 100644
index 00000000..30a41471
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/103
@@ -0,0 +1 @@
+9pfs does not honor open file handles on unlinked files
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1032 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1032
new file mode 100644
index 00000000..039b57fd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1032
@@ -0,0 +1,16 @@
+Slow random performance of virtio-blk
+Steps to reproduce:
+1. Download Virtualbox Windows 11 image from https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/
+2. Download virtio-win-iso: `wget https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.215-2/virtio-win-0.1.215.iso`
+3. Extract WinDev*.zip `unzip WinDev2204Eval.VirtualBox.zip`and import the extracted Ova in VirtualBox (import WinDev with the option "conversion to vdi" clicked)
+4. `qemu-img convert -f vdi -O raw <YourVirtualBoxVMFolder>/WinDev2204Eval-disk001.vdi<YourQemuImgFolder>/WinDev2204Eval-disk001.img`
+5. Start Windows 11 in Qemu: 
+``` 
+qemu-system-x86_64 -enable-kvm -cpu host -device virtio-blk-pci,scsi=off,drive=WinDevDrive,id=virtio-disk0,bootindex=0  -drive file=<YourQemuImgFolder>/WinDev2204Eval-disk001.img,if=none,id=WinDevDrive,format=raw -net nic -net user,hostname=windowsvm -m 8G -monitor stdio -name "Windows" -usbdevice tablet -device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -cdrom <YourDownloadFolder>/virtio-win-0.1.215.iso
+```
+6. Win 11 won't boot and will go into recovery mode (even the safeboot trick doesn't work here), please follow that [answer](https://superuser.com/questions/1057959/windows-10-in-kvm-change-boot-disk-to-virtio#answer-1200899) to load the viostor driver over recovery cmd
+7. Reboot the VM and it should start
+2. Install CrystalDiskMark 
+3. Execute CrystalDiskMark Benchmark
+Additional information:
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1033 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1033
new file mode 100644
index 00000000..b10dce17
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1033
@@ -0,0 +1,27 @@
+fakeroot under qemu fails with 'semop(1): encountered an error: Function not implemented'
+Description of problem:
+Appears to be the same issue as that discussed and reportedly fixed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965109
+
+Running raspberry pi os in a chroot (using schroot). Execution of fakeroot as part of dpkg-buildpackage results in:
+
+```
+dpkg-buildpackage: info: source package clementine
+dpkg-buildpackage: info: source version 1.4.0rc1-836-g4665916ba~bullseye
+dpkg-buildpackage: info: source distribution bullseye
+dpkg-buildpackage: info: source changed by David Sansome <me@davidsansome.com>
+dpkg-buildpackage: info: host architecture armhf
+ dpkg-source --before-build .
+ fakeroot debian/rules clean
+semop(1): encountered an error: Function not implemented
+dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 1
+```
+
+This is the same error as reported in bug 965109, but I'm running the most recent version of qemu - I built it from the git repo, so it should include the fix for 965109.
+Steps to reproduce:
+1. Setup (s)chroot with arm architecture (although the architecture may not matter) 
+2. Run fakeroot in the chroot
+3. Observe the failure related to the semop syscall
+Additional information:
+- Not sure what other information I can provide to be helpful.
+- The command line listed above is what I gather from ps; it's how qemu-arm-static is called by schroot. I've not been able to figure out _how_ schroot calls qemu-arm-static, I only know it does.
+- I compiled qemu from source using my own user id, and ran into an issue with make install, so I manually used install to deploy the executable to /usr/local/bin... And then had to symlink that to /usr/bin as schroot apparently hardcodes the location of qemu-arm-static (at least it did not pick up the version I'd placed in /usr/local/bin).
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1036 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1036
new file mode 100644
index 00000000..b34f0dc2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1036
@@ -0,0 +1,15 @@
+QEMU immediately exits when combining a GL-enabled SDL display with SPICE
+Description of problem:
+Running QEMU with the given command line results in QEMU immediately exiting with this line being printed, and no other output:
+
+```
+qemu-system-x86_64: Display spice is incompatible with the GL context
+```
+
+I am unsure whether this is a supported mode of setting up QEMU, but QEMU 6.2.0 ran just fine with it (or, to be more precise, it wasn't an issue until ac32b2fff127843355b4f7e7ac9f93dd4a395adf).
+
+The issue does not happen with `-display sdl,gl=off`, as GL is presumably not involved at all in that case.
+Steps to reproduce:
+1. Run `./qemu-system-x86_64 -display sdl,gl=on -spice port=5930`.
+Additional information:
+This issue has been reproduced on other distributions, including Ubuntu 20.04 and Ubuntu 22.04.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1037 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1037
new file mode 100644
index 00000000..e7672794
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1037
@@ -0,0 +1 @@
+Let's encrypt certificate for *.qemu.org has expired
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/104 b/gitlab/issues_text/target_missing/host_missing/accel_missing/104
new file mode 100644
index 00000000..3ca97e10
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/104
@@ -0,0 +1 @@
+Cursor jumps on shape change with vmware vga
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1044 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1044
new file mode 100644
index 00000000..724a1be8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1044
@@ -0,0 +1 @@
+Warning: libevent-loop-base.a the table of contents is empty
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1048 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1048
new file mode 100644
index 00000000..4cb7b98c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1048
@@ -0,0 +1,6 @@
+usb/ohci does not reset HccaPad1 after frame number update.
+Description of problem:
+When the OHCI controller's framenumber is incremented, HccaPad1 register should be set to zero. Ref OHCI Spec 4.4.1.
+Relevant code section: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/usb/hcd-ohci.c#L1201
+
+ReactOS uses hccaPad1 to determine if the OHCI hardware is running, consequently it fails this check in current qemu master.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1049 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1049
new file mode 100644
index 00000000..c687090c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1049
@@ -0,0 +1 @@
+Have DeviceRealize return boolean indicating error
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1052 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1052
new file mode 100644
index 00000000..ca8602de
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1052
@@ -0,0 +1,79 @@
+QEMU monitor hangs after "stop" QMP command called in postcopy-paused migration state
+Description of problem:
+QEMU monitor hangs when I try to pause virtual CPUs using "stop" QMP command
+on the destination host once migration enters postcopy-paused (after it was
+paused using "migrate-pause" QMP command on the source host). QEMU just does
+not send any reply to the "stop" command.
+Steps to reproduce:
+1. start migration
+2. wait for the first iteration to finish
+3. switch to post-copy using "migrate-start-postcopy"
+3. break migration with "migrate-pause"
+4. send "stop" to the destination monitor
+Additional information:
+Unfortunately I haven't been able to get a stack trace as gdb just hangs when
+I try to attach it to QEMU after step 4. I can see threads getting SIGUSR1
+after the "stop" command, but I cannot get to gdb prompt afterwards:
+
+```
+(gdb) c
+Continuing.
+[New Thread 0x7f41ec9be640 (LWP 1112)]
+[New Thread 0x7f41d7fff640 (LWP 1113)]
+Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1.
+Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1.
+Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1.
+Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1.
+Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1.
+Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1.
+Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1.
+Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1.
+Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1.
+Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1.
+Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1.
+Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1.
+```
+
+I was able to attach strace to it though (in case it is at least a bit
+useful). The first line corresponds to the final '}' of the
+{"execute":"stop","id":"libvirt-413"} QMP comamnd:
+
+```
+[pid 72970] recvmsg(20, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="}", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 1
+[pid 72970] write(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid 72949] <... ppoll resumed>)        = 1 ([{fd=4, revents=POLLIN}], left {tv_sec=0, tv_nsec=513181335})
+[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...>
+[pid 72949] read(4,  <unfinished ...>
+[pid 72970] <... write resumed>)        = 8
+[pid 72949] <... read resumed>"\1\0\0\0\0\0\0\0", 512) = 8
+[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...>
+[pid 72949] ppoll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=29, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}, {fd=32, events=POLLIN}, {fd=33, events=POLLIN}, {fd=34, events=POLLIN}, {fd=38, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}, {fd=44, events=POLLIN}, {fd=45, events=POLLIN}, {fd=46, events=POLLIN}, {fd=47, events=POLLIN}, {fd=48, events=POLLIN}, {fd=49, events=POLLIN}, {fd=50, events=POLLIN}, {fd=51, events=POLLIN}, {fd=52, events=POLLIN}, {fd=53, events=POLLIN}, {fd=54, events=POLLIN}, {fd=55, events=POLLIN}, {fd=56, events=POLLIN}, ...], 74, {tv_sec=0, tv_nsec=0}, NULL, 8 <unfinished ...>
+[pid 72970] <... write resumed>)        = 8
+[pid 72949] <... ppoll resumed>)        = 0 (Timeout)
+[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...>
+[pid 72949] write(8, "\1\0\0\0\0\0\0\0", 8 <unfinished ...>
+[pid 72970] <... write resumed>)        = 8
+[pid 72949] <... write resumed>)        = 8
+[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...>
+[pid 72949] ppoll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=29, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}, {fd=32, events=POLLIN}, {fd=33, events=POLLIN}, {fd=34, events=POLLIN}, {fd=38, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}, {fd=44, events=POLLIN}, {fd=45, events=POLLIN}, {fd=46, events=POLLIN}, {fd=47, events=POLLIN}, {fd=48, events=POLLIN}, {fd=49, events=POLLIN}, {fd=50, events=POLLIN}, {fd=51, events=POLLIN}, {fd=52, events=POLLIN}, {fd=53, events=POLLIN}, {fd=54, events=POLLIN}, {fd=55, events=POLLIN}, {fd=56, events=POLLIN}, ...], 74, {tv_sec=0, tv_nsec=0}, NULL, 8 <unfinished ...>
+[pid 72970] <... write resumed>)        = 8
+[pid 72949] <... ppoll resumed>)        = 1 ([{fd=8, revents=POLLIN}], left {tv_sec=0, tv_nsec=0})
+[pid 72970] poll([{fd=18, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=0}], 3, -1 <unfinished ...>
+[pid 72949] rt_sigprocmask(SIG_BLOCK, ~[],  <unfinished ...>
+[pid 72970] <... poll resumed>)         = 1 ([{fd=19, revents=POLLIN}])
+[pid 72949] <... rt_sigprocmask resumed>[BUS USR1 ALRM IO], 8) = 0
+[pid 72970] read(19,  <unfinished ...>
+[pid 72949] getpid()                    = 72949
+[pid 72970] <... read resumed>"\5\0\0\0\0\0\0\0", 16) = 8
+[pid 72949] tgkill(72949, 72971, SIGUSR1 <unfinished ...>
+[pid 72970] poll([{fd=18, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=0}], 3, -1 <unfinished ...>
+[pid 72949] <... tgkill resumed>)       = 0
+[pid 72949] rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], NULL, 8) = 0
+[pid 72949] rt_sigprocmask(SIG_BLOCK, ~[], [BUS USR1 ALRM IO], 8) = 0
+[pid 72949] getpid()                    = 72949
+[pid 72949] tgkill(72949, 72972, SIGUSR1) = 0
+[pid 72949] rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], NULL, 8) = 0
+[pid 72949] futex(0x5606f6cb73a8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY
+```
+
+And that's it, the last futex never returns.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1055 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1055
new file mode 100644
index 00000000..ea9150ed
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1055
@@ -0,0 +1,16 @@
+QEMU does not close listening socket for incoming migration when post-copy migration breaks
+Description of problem:
+QEMU keeps listening on the incoming port even after breaking a post-copy
+migration using "migrate-pause" QMP command. And even once migration is
+finished after recovering it "migrate-recover" using a different port number.
+If "migrate-recover" is called with a URI specifying the original port (which
+is still in LISTEN state), QEMU reports "Failed to find an available port:
+Address already in use".
+Steps to reproduce:
+1. start migration
+2. wait for the first iteration to finish
+3. switch to post-copy using "migrate-start-postcopy"
+3. break migration with "migrate-pause"
+4. check lsof -p $QEMU_PID
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/106 b/gitlab/issues_text/target_missing/host_missing/accel_missing/106
new file mode 100644
index 00000000..c39e83c1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/106
@@ -0,0 +1 @@
+qemu-git gravis ultrasound not working
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1063 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1063
new file mode 100644
index 00000000..e055770f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1063
@@ -0,0 +1,9 @@
+qemu: could not load PC BIOS 'bios-256k.bin'
+Description of problem:
+I cloned latest QEMU and build in Ubuntu 18.04, when I run QEMU to start a vm, it tells me `could not load PC BIOS 'bios-256k.bin'
+
+![image](/uploads/ce3eecac2f3a840e29f764d18a515dfd/image.png)
+Steps to reproduce:
+1. Clone latest QEMU in Ubuntu18.04
+2. build QEMU
+3. Use QEMU and libvirt to start a virtual machine.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1064 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1064
new file mode 100644
index 00000000..897c85af
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1064
@@ -0,0 +1,43 @@
+aarch64:qemu6.2.0 compile error
+Description of problem:
+
+Steps to reproduce:
+1. download qemu source package
+`wget http://mirrors.163.com/centos-vault/centos/8-stream/AppStream/Source/SPackages/qemu-kvm-6.2.0-12.module_el8.7.0%2b1140%2bff0772f9.src.rpm`
+2. install qemu source package
+`rpm -ivh qemu-*.rpm`
+3. build qemu 
+` rpmbuild --define "_topdir /xxx/src_qemu6.2.0" -bb SPECS/qemu-kvm.spec`
+4. error message:
+```
+In function 'dump_receive_iov',
+    inlined from 'filter_dump_receive_iov' at ../net/dump.c:157:5:
+../net/dump.c:89:9: error: 'writev' specified size 18446744073709551600 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=]
+   89 |     if (writev(s->fd, dumpiov, cnt + 1) != sizeof(hdr) + caplen) {
+      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+In file included from /home/xxx/src_qemu6.2.0/BUILD/qemu-kvm-6.2.0/include/qemu/osdep.h:108,
+                 from ../net/dump.c:25:
+../net/dump.c: In function 'filter_dump_receive_iov':
+/usr/include/sys/uio.h:52:16: note: in a call to function 'writev' declared with attribute 'read_only (2, 3)'
+   52 | extern ssize_t writev (int __fd, const struct iovec *__iovec, int __count)
+      |                ^~~~~~
+cc1: all warnings being treated as errors
+```
+**gcc version**
+```
+# gcc --version
+gcc (GCC) 10.3.1
+Copyright (C) 2020 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+```
+```
+[root]# meson -v
+0.62.1
+[root]# ninja -v
+ninja: error: loading 'build.ninja': No such file or directory
+[root@vm77 src_qemu6.2.0]# ninja --version
+1.8.2
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1066 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1066
new file mode 100644
index 00000000..366dcf0e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1066
@@ -0,0 +1,32 @@
+virtfs fails to access contents of non-readable directories
+Description of problem:
+Attempting to access a directory inside a non-readable directory via virtfs fails.
+Steps to reproduce:
+On host:
+1. `mkdir -p test/foo/bar`
+2. `echo hello world >test/foo/bar/baz.txt`
+3. `chmod -r test/foo`
+
+The following works on host:
+
+```
+$ ls test
+foo
+$ ls test/foo
+ls: cannot open directory 'test/foo': Permission denied
+$ ls test/foo/bar
+baz.txt
+```
+
+However on guest:
+
+```
+bash-5.1# ls /test/
+foo
+bash-5.1# ls /test/foo/
+ls: cannot open directory '/test/foo/': Permission denied
+bash-5.1# ls /test/foo/bar/
+ls: cannot access '/test/foo/bar/': Permission denied
+```
+Additional information:
+I am guessing virtfs attempts to check rights (via access?) on the directory itself when obtaining an inode to give to the guest, however not having read access doesn't mean something can't be executed, especially for directories.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/107 b/gitlab/issues_text/target_missing/host_missing/accel_missing/107
new file mode 100644
index 00000000..d102e979
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/107
@@ -0,0 +1 @@
+qemu-img fixed vhd issues
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1070 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1070
new file mode 100644
index 00000000..09648ccd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1070
@@ -0,0 +1,10 @@
+gdbstub XML generation for ARM is done for every CPU
+Description of problem:
+- As arm_cpu_register_gdb_regs_for_features is called from the device
+   realize stage for each vCPU in user mode we end up uselessly
+   regenerating the XML for every new thread. Once you get up to 100
+   threads this starts exceeding the large maps done for QHT and PageDesc
+Steps to reproduce:
+See above command line, valgrind picks it up
+Additional information:
+See also #866, #967
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1071 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1071
new file mode 100644
index 00000000..114db7ec
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1071
@@ -0,0 +1,12 @@
+Cannot passthrough two network devices (Mellanox ConnectX-3) to VM.
+Description of problem:
+Cannot passthrough two network devices (Mellanox ConnectX-3) to VM.
+
+It generated me an error:
+[ 6322.674602] genirq: Flags mismatch irq 16. 00000000 (vfio-intx(0000:05:00.0)) vs. 00000000 (vfio-intx(0000:88:00.0))
+
+Passthrough only one device to VM goes well.
+Steps to reproduce:
+1. Add a first passthrough network device.
+2. Add a second passthrough network device.
+3. Run VM.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1072 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1072
new file mode 100644
index 00000000..28ad202e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1072
@@ -0,0 +1,24 @@
+different behavior when remote debugger is used
+Description of problem:
+I found Qemu shows different behavior when I run Qemu with hello-world (statically linked binary enclosed) directly or run it through remote debugger. I need help to understand the following: 
+
+1. Is this intended behavior?
+1. Any way to make the two approaches have consistent behavior (I prefer the behavior shown in the 2nd approach described below)
+1. If it is intended behavior, any explanation why or suggestions how to dig further to root cause the difference.
+
+The corresponding source code is the line 86 in [filedoalloc.c](https://code.woboq.org/userspace/glibc/libio/filedoalloc.c.html#86). It tests if the file (stdout) is char special device (S_ISCHR)
+The preprocessed code is as follows:
+   if (((((st.st_mode)) & 0170000) == (0020000))) 
+
+I then compared two different approaches to run Qemu:
+
+1. I used the following command line to collect the trace:  qemu_aarch64 -strace  -plugin $QEMU_ROOT/build/contrib/plugins/libexeclog.so -d plugin hello.a64. This one tests False for S_ISCHR
+1. when I used gdb to connect to Qemu and single-step the instructions, S_ISCHR tests True, which is different from running qemu directly (approach 1). 
+
+Thanks!
+Steps to reproduce:
+1.[hello.a64](/uploads/4b4ccae8c1e4b045c39ceae6a094d55a/hello.a64)
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1074 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1074
new file mode 100644
index 00000000..5fc475cb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1074
@@ -0,0 +1,18 @@
+File under symlink gets corrupted when directory is mounted as FAT32 drive
+Description of problem:
+When mouting a directory as a FAT32 drive, the symlinked BOOTx64.EFI inside gets corrupted after booting it.
+Steps to reproduce:
+1. mkdir -p fat_dir/EFI/BOOT/
+2. ln -s BOOTx64.EFI fat_dir/EFI/BOOT/BOOTx64.EFI
+3. md5sum BOOTx64.EFI
+4. Run qemu with arguments like above.
+5. md5sum BOOTx64.EFI should print out different hash, confirming corruption.
+Additional information:
+[BOOTx64.EFI](/uploads/d0a6e899ec9331461179f8dc82fbc421/BOOTx64.EFI)
+
+The issue was not visible on earlier versions, but I don't know which one exactly was it.\
+I can only say, it was still working in April and it was possible that I was using Fedora 36 Beta.
+
+Copying the file instead of using a symlink can be used as a workaround.
+
+The binary should print some debug stuff, like avaliable memory regions and end with an infinite halt-loop.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1075 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1075
new file mode 100644
index 00000000..a4999862
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1075
@@ -0,0 +1,16 @@
+Unable to create a cluster using ppc64le specific kind binary on x86 host architecture
+Description of problem:
+
+Steps to reproduce:
+1. docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
+2. wget https://github.com/kubernetes-sigs/kind/releases/download/v0.14.0/kind-linux-ppc64le
+3. chmod u+x kind-linux-ppc64le
+4. curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/ppc64le/kubectl
+5. chmod +x kubectl
+6. sudo cp kubectl /usr/local/bin/
+7. KUBECONFIG="${HOME}/kind-test-config"
+8. export KUBECONFIG
+9. ./kind-linux-ppc64le create cluster --image quay.io/mayurwaghmode111/node-ppc64le:ppc64le -v=3 --wait 1m --retain
+10. ./kind-linux-ppc64le export logs
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1076 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1076
new file mode 100644
index 00000000..c2684f4a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1076
@@ -0,0 +1,12 @@
+AC97+DirectSound only polls for audio every 10ms with no way to change it
+Description of problem:
+The AC97 device emulation, at least in combination with the DirectSound backend, only polls for audio every 10ms, meaning that DMA interrupts are received at a maximum frequency of 100Hz. This applies regardless of how large the buffers in the AC97's buffer list are, meaning that if one buffer takes less than 10ms to play, glitches can be heard with no possible mitigations on the host system.
+
+I came across this when fiddling with Serenity's own latencies in the AC97 driver and userland mixer. As soon as less than 512-sample buffers are used, audio becomes glitchy. Based on timing tests, kernel and userland processing of audio combined takes less than 200μs for one buffer, while the lowest average rate that DMA interrupts are received at is almost exactly 10ms.
+
+No changes to the dsound latency option, as listed [here](https://www.qemu.org/docs/master/system/invocation.html?highlight=dsound), made any difference; I tried as low as 2ms: `-audiodev dsound,id=snd0,latency=2000`. As far as I can tell there are no IRQ- or latency-related options for the AC97 emulation.
+Steps to reproduce:
+1. Use SerenityOS as of the above commit.
+2. Before building, include an audio file in Base/home/anon; most ordinary FLAC, WAV and MP3 files created without options with ffmpeg should work.
+3. Boot Serenity in QEMU on Windows without any special run configuration.
+4. Play the audio file with `aplay <filename>`, hear glitches.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1077 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1077
new file mode 100644
index 00000000..6b2d7336
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1077
@@ -0,0 +1 @@
+Qemu - Can't connect to ESXi guest
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1079 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1079
new file mode 100644
index 00000000..d54f05b1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1079
@@ -0,0 +1,32 @@
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Description of problem:
+I am trying to build `arm64` image on my `x86_64` machine using `buildx` and I have encountered `qemu: uncaught target signal 11 (Segmentation fault) - core dumped` Error. <br>
+#
+Steps to reproduce:
+1. Create a Dockerfile
+```
+FROM python:3.8-slim
+
+ENV PYTHONDONTWRITEBYTECODE=1
+
+# Install packages
+RUN apt update
+RUN apt-get install -y python3-pip
+```
+2. Run binfmt container
+```
+docker run --privileged --rm tonistiigi/binfmt --install all
+```
+3. Setup new builder
+```
+$ docker buildx create --name mybuilder
+$ docker buildx use mybuilder
+$ docker buildx inspect --bootstrap
+```
+4. Build Image
+```
+$ docker buildx build --platform linux/amd64,linux/arm64 --push -t user/failure-case .
+```
+#
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/108 b/gitlab/issues_text/target_missing/host_missing/accel_missing/108
new file mode 100644
index 00000000..57326b33
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/108
@@ -0,0 +1 @@
+Windows ME falsely detects qemu's videocards as Number Nine Imagine 128
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1080 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1080
new file mode 100644
index 00000000..24ae089b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1080
@@ -0,0 +1 @@
+Qemu build fails on Ubuntu
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1081 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1081
new file mode 100644
index 00000000..2c8768b8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1081
@@ -0,0 +1 @@
+A issue for QLIST_INSERT_BEFORE in include/qemu/queue.h
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1082 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1082
new file mode 100644
index 00000000..cdadc728
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1082
@@ -0,0 +1,92 @@
+Unable to compile QEMU in Ubuntu 22.04 LTS - libcommon.fa.p
+Description of problem:
+Since a couple of months ago I can not compile QEMU from its official GIT location anymore.
+I do everything described in the guide: https://wiki.qemu.org/Hosts/Linux 
+
+After the configure, the building resturn me this issue:
+```
+1155/9661] Compiling C object libcommon.fa.p/ui_vdagent.c.o
+FAILED: libcommon.fa.p/ui_vdagent.c.o
+cc -m64 -mcx16 -Ilibcommon.fa.p -I../common-user/host/x86_64 -I../linux-user/include/host/x86_64 -I../linux-user/include -I../slirp -I../slirp/src -I/usr/include/pixman-1 -I/usr/include/libpng16 -I/usr/local/include/spice-1 -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/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/harfbuzz -I/usr/include/fribidi -I/usr/include/atk-1.0 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/x86_64-linux-gnu -I/usr/include/vte-2.91 -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /home/andrea/qemu/linux-headers -isystem linux-headers -iquote . -iquote /home/andrea/qemu -iquote /home/andrea/qemu/include -iquote /home/andrea/qemu/disas/libvixl -iquote /home/andrea/qemu/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=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-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 -fPIE -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNCURSES_WIDECHAR=1 -MD -MQ libcommon.fa.p/ui_vdagent.c.o -MF libcommon.fa.p/ui_vdagent.c.o.d -o libcommon.fa.p/ui_vdagent.c.o -c ../ui/vdagent.c
+../ui/vdagent.c:82:6: error: ‘VD_AGENT_CAP_SPARSE_MONITORS_CONFIG’ undeclared here (not in a function); did you mean ‘VD_AGENT_CAP_MONITORS_CONFIG’?
+   82 |     [VD_AGENT_CAP_SPARSE_MONITORS_CONFIG]         = "sparse-monitors-config",
+      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+      |      VD_AGENT_CAP_MONITORS_CONFIG
+../ui/vdagent.c:82:6: error: array index in initializer not of integer type
+../ui/vdagent.c:82:6: note: (near initialization for ‘cap_name’)
+../ui/vdagent.c:83:6: error: ‘VD_AGENT_CAP_GUEST_LINEEND_LF’ undeclared here (not in a function)
+   83 |     [VD_AGENT_CAP_GUEST_LINEEND_LF]               = "guest-lineend-lf",
+      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../ui/vdagent.c:83:6: error: array index in initializer not of integer type
+../ui/vdagent.c:83:6: note: (near initialization for ‘cap_name’)
+../ui/vdagent.c:84:6: error: ‘VD_AGENT_CAP_GUEST_LINEEND_CRLF’ undeclared here (not in a function)
+   84 |     [VD_AGENT_CAP_GUEST_LINEEND_CRLF]             = "guest-lineend-crlf",
+      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../ui/vdagent.c:84:6: error: array index in initializer not of integer type
+../ui/vdagent.c:84:6: note: (near initialization for ‘cap_name’)
+../ui/vdagent.c:85:6: error: ‘VD_AGENT_CAP_MAX_CLIPBOARD’ undeclared here (not in a function); did you mean ‘VD_AGENT_CAP_CLIPBOARD’?
+   85 |     [VD_AGENT_CAP_MAX_CLIPBOARD]                  = "max-clipboard",
+      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~
+      |      VD_AGENT_CAP_CLIPBOARD
+../ui/vdagent.c:85:6: error: array index in initializer not of integer type
+../ui/vdagent.c:85:6: note: (near initialization for ‘cap_name’)
+../ui/vdagent.c:86:6: error: ‘VD_AGENT_CAP_AUDIO_VOLUME_SYNC’ undeclared here (not in a function)
+   86 |     [VD_AGENT_CAP_AUDIO_VOLUME_SYNC]              = "audio-volume-sync",
+      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../ui/vdagent.c:86:6: error: array index in initializer not of integer type
+../ui/vdagent.c:86:6: note: (near initialization for ‘cap_name’)
+../ui/vdagent.c:87:6: error: ‘VD_AGENT_CAP_MONITORS_CONFIG_POSITION’ undeclared here (not in a function); did you mean ‘VD_AGENT_CAP_MONITORS_CONFIG’?
+   87 |     [VD_AGENT_CAP_MONITORS_CONFIG_POSITION]       = "monitors-config-position",
+      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+      |      VD_AGENT_CAP_MONITORS_CONFIG
+../ui/vdagent.c:87:6: error: array index in initializer not of integer type
+../ui/vdagent.c:87:6: note: (near initialization for ‘cap_name’)
+../ui/vdagent.c:88:6: error: ‘VD_AGENT_CAP_FILE_XFER_DISABLED’ undeclared here (not in a function)
+   88 |     [VD_AGENT_CAP_FILE_XFER_DISABLED]             = "file-xfer-disabled",
+      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../ui/vdagent.c:88:6: error: array index in initializer not of integer type
+../ui/vdagent.c:88:6: note: (near initialization for ‘cap_name’)
+../ui/vdagent.c:89:6: error: ‘VD_AGENT_CAP_FILE_XFER_DETAILED_ERRORS’ undeclared here (not in a function)
+   89 |     [VD_AGENT_CAP_FILE_XFER_DETAILED_ERRORS]      = "file-xfer-detailed-errors",
+      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../ui/vdagent.c:89:6: error: array index in initializer not of integer type
+../ui/vdagent.c:89:6: note: (near initialization for ‘cap_name’)
+../ui/vdagent.c:109:6: error: ‘VD_AGENT_FILE_XFER_START’ undeclared here (not in a function)
+  109 |     [VD_AGENT_FILE_XFER_START]       = "file-xfer-start",
+      |      ^~~~~~~~~~~~~~~~~~~~~~~~
+../ui/vdagent.c:109:6: error: array index in initializer not of integer type
+../ui/vdagent.c:109:6: note: (near initialization for ‘msg_name’)
+../ui/vdagent.c:110:6: error: ‘VD_AGENT_FILE_XFER_STATUS’ undeclared here (not in a function)
+  110 |     [VD_AGENT_FILE_XFER_STATUS]      = "file-xfer-status",
+      |      ^~~~~~~~~~~~~~~~~~~~~~~~~
+../ui/vdagent.c:110:6: error: array index in initializer not of integer type
+../ui/vdagent.c:110:6: note: (near initialization for ‘msg_name’)
+../ui/vdagent.c:111:6: error: ‘VD_AGENT_FILE_XFER_DATA’ undeclared here (not in a function)
+  111 |     [VD_AGENT_FILE_XFER_DATA]        = "file-xfer-data",
+      |      ^~~~~~~~~~~~~~~~~~~~~~~
+../ui/vdagent.c:111:6: error: array index in initializer not of integer type
+../ui/vdagent.c:111:6: note: (near initialization for ‘msg_name’)
+../ui/vdagent.c:112:6: error: ‘VD_AGENT_CLIENT_DISCONNECTED’ undeclared here (not in a function)
+  112 |     [VD_AGENT_CLIENT_DISCONNECTED]   = "client-disconnected",
+      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../ui/vdagent.c:112:6: error: array index in initializer not of integer type
+../ui/vdagent.c:112:6: note: (near initialization for ‘msg_name’)
+../ui/vdagent.c:113:6: error: ‘VD_AGENT_MAX_CLIPBOARD’ undeclared here (not in a function); did you mean ‘VD_AGENT_CAP_CLIPBOARD’?
+  113 |     [VD_AGENT_MAX_CLIPBOARD]         = "max-clipboard",
+      |      ^~~~~~~~~~~~~~~~~~~~~~
+      |      VD_AGENT_CAP_CLIPBOARD
+../ui/vdagent.c:113:6: error: array index in initializer not of integer type
+../ui/vdagent.c:113:6: note: (near initialization for ‘msg_name’)
+../ui/vdagent.c:114:6: error: ‘VD_AGENT_AUDIO_VOLUME_SYNC’ undeclared here (not in a function)
+  114 |     [VD_AGENT_AUDIO_VOLUME_SYNC]     = "audio-volume-sync",
+      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~
+../ui/vdagent.c:114:6: error: array index in initializer not of integer type
+../ui/vdagent.c:114:6: note: (near initialization for ‘msg_name’)
+```
+
+I come from a Windows world, so I have no idea what is the "libcommon.fa.p" about.
+Can someone help here?
+Steps to reproduce:
+1. Follow the instruction in https://wiki.qemu.org/Hosts/Linux to compile QEMU
+Expected result: QEMU would compile correctly
+Observed result: Compilation errors.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1083 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1083
new file mode 100644
index 00000000..5b52ed3a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1083
@@ -0,0 +1 @@
+Qemu on Windows - Emulate 64Bit CPU
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1085 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1085
new file mode 100644
index 00000000..58535546
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1085
@@ -0,0 +1,40 @@
+QEMU 7.0.0 - NSIS installer issue
+Description of problem:
+Misisng info in QEMU.nsi file
+Steps to reproduce:
+The exe installer exe file properties has a lot of porpeties missing
+
+![image](/uploads/6838ee795b2fd215baff90b224529b9e/image.png)
+
+This is casued by mssing instruction like
+
+VIAddVersionKey "ProductName"        ""
+VIAddVersionKey "ProductVersion"     ""
+VIAddVersionKey "Comments"           ""
+VIAddVersionKey "CompanyName"        ""
+VIAddVersionKey "LegalTrademarks"    ""
+VIAddVersionKey "LegalCopyright"     ""
+VIAddVersionKey "FileVersion"        ""
+VIAddVersionKey "FileDescription"    ""
+
+VIAddVersionKey "InternalName"       ""
+VIAddVersionKey "OriginalFilename"   ""
+
+In Windows program òlist about uninstalle 
+
+the QEMU icon is not right (generic icon)
+The Is missing teh publisg
+
+![image](/uploads/7634b3618897f86c14e56fbdc23d98a5/image.png)
+
+This si due error on 
+
+!define MUI_UNICON "${SRCDIR}\pc-bios\qemu-nsis.ico"
+
+that probably point to an icon file not available
+
+and an misisng line that set Publisher info for uninstalelr
+
+WriteRegStr HKLM "${UNINST_KEY}" "Publisher"       ""
+
+Thanks. KR.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1088 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1088
new file mode 100644
index 00000000..17c4f9a0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1088
@@ -0,0 +1 @@
+QEMU 7.0.0 fails to build with linker that does not support --dynamic-list
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1089 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1089
new file mode 100644
index 00000000..7a714c80
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1089
@@ -0,0 +1,24 @@
+when I use memory balloon,the qemu process memory usage is displayed incorrectly
+Description of problem:
+My vm memory is 4GB,and use the balloon driver,the balloon value is also 4GB.
+I run a soft to consume memory in vm,I can see the memory usage rate is 15% in host. When I stop the soft in vm,the memory of free info in host and vm 
+become normal,but use "top -d 3 -Hp $qemu_pid" to query in host,the memory usage rate is also 15%.I need to modify the balloon value in a smaller values,the memory usage rate will reduce. why? 
+![image](/uploads/cb904692df89db633825da0609458c1f/image.png)
+Steps to reproduce:
+1.run a soft to consume memory in vm,and query top info,the qemu process memory usage:15%
+
+
+2.query free info in host and vm (reduce)
+
+
+3.stop sort in vm
+
+
+4.query free info in host and vm (recover)
+
+
+5.query top info again (also 15%)
+
+
+
+6.modify the balloon value in a smaller (modify the balloon value in a smaller values,the memory usage rate will reduce)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/109 b/gitlab/issues_text/target_missing/host_missing/accel_missing/109
new file mode 100644
index 00000000..0c69162b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/109
@@ -0,0 +1 @@
+Make Uninstall Rule Requested
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1090 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1090
new file mode 100644
index 00000000..fd38030c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1090
@@ -0,0 +1,15 @@
+can't create rocker device because setting device array properties on the command line is broken
+Description of problem:
+it does not accept the prop_array parameter:
+
+```
+qemu-system-x86_64 -enable-kvm -m 1g -cpu host -netdev socket,id=dev0,udp=10.10.10.227:30042,localaddr=:30042 -device rocker,len-ports=4,name=sw,len-ports=2,ports[0]=dev0
+qemu-system-x86_64: -device rocker,len-ports=4,name=sw,len-ports=2,ports[0]=dev0: Property 'rocker.ports[0]' not found
+```
+Steps to reproduce:
+1. just run the command
+Additional information:
+the latest qemu i find working is 6.1.1... if you start a fedora vm and `dnf install kernel-modules-internal` then the rocker ports appear and work properly...
+
+thanks,
+cs
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1094 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1094
new file mode 100644
index 00000000..5233e3d4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1094
@@ -0,0 +1,8 @@
+Ubuntu's 22.04 Qemu high RAM usage (memory leak maybe)
+Description of problem:
+After starting/using my VM for a while, RAM fills up to the 32gb maximum, and firefox starts closing tabs and etc. This didn't happen in ubuntu 21.10 or earlier ubuntus. I've been using virt-manager + qemu for years and only had this after upgrading to ubuntu 22.04.
+Steps to reproduce:
+1. Launch virt-manager ubuntu VM with 12gb ram maximum (as an example)
+2. RAM entire 32gb gets filled but nothing in gnome-system-monitor shows what is using all that RAM
+3. Firefox starts closing tabs because RAM is full. Remember that only a 12gb RAM vm and firefox with a few tabs are running, and it fills all 32gb of RAM. Ram starts filling slowly and in 1 hour it fills the entire 32gb. For some reason htop shows a smaller usage, but I'm pretty sure all 32gb are being used as the computer starts freezing and almost crashing (I think swap is being used so it slows down but do not crash)
+4. have to restart the computer for RAM to get normal again
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1095 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1095
new file mode 100644
index 00000000..a60021ed
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1095
@@ -0,0 +1 @@
+[QUESTION] What IF....
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1096 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1096
new file mode 100644
index 00000000..7608ebd8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1096
@@ -0,0 +1 @@
+New warning with GCC 13
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1099 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1099
new file mode 100644
index 00000000..306b3e6c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1099
@@ -0,0 +1 @@
+zlib: Concurrent modification is unsafe
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1100 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1100
new file mode 100644
index 00000000..fb77d819
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1100
@@ -0,0 +1 @@
+It riscv64 platform support user model??
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1101 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1101
new file mode 100644
index 00000000..9b627263
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1101
@@ -0,0 +1,12 @@
+QEMU 7.0.0 corrupts VHDX and VHD (VPC) files on write.
+Description of problem:
+QEMU writes to VHDX and VHD (VPC) files produce a corrupt/non-compliant image.
+QEMU appears to be able to read VHDX and VHD images correctly.
+
+This problem manifests in at least two cases
+1. When attaching a VHDX/VHD file to a QEMU machine.  A previously working OS image created using the Hyper-V and imaging tools boots properly, but writes that normally occur in the running VM are not written out correctly.  The image will fail to boot the next time due to corruption.
+2. Image conversion operations *TO* VHDX/VHD fail.  (note that QEMU correctly converts *FROM* VHDX/VHD assuming a well formed input image).  This implies that reads to VHDX/VHD are OK, but writes to VHDX/VHD are NOT OK.
+Steps to reproduce:
+1. See Above.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1102 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1102
new file mode 100644
index 00000000..ef455a73
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1102
@@ -0,0 +1,38 @@
+qemu-user: zero_bss might raise segfault when segment is not writable
+Description of problem:
+When a PT_LOAD segment with the following attributes presented in the user program,
+* MemSiz > FileSiz
+* NOT Writable
+
+qemu-aarch64 will crash with segment fault running it.
+
+
+
+
+in [linux-user/elfload.c: bss_zero](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c#L2097), the exceeded part is zero'ed without checking if it is writable
+```
+    if (host_start < host_map_start) {
+        memset((void *)host_start, 0, host_map_start - host_start);
+    }
+```
+Steps to reproduce:
+1. ./qemu-aarch64 ./X.so
+Additional information:
+readelf output of X.so
+```
+Program Headers:
+  Type           Offset             VirtAddr           PhysAddr                 FileSiz            MemSiz              Flags  Align
+  PHDR           0x0000000000000040 0x0000000000000040 0x0000000000000040       0x0000000000000230 0x0000000000000230  R E    0x8
+  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000       0x0000000000110270 0x00000000001c94e0  R E    0x10000
+  LOAD           0x0000000000129bd0 0x00000000001d9bd0 0x00000000001d9bd0       0x0000000000000438 0x00000000000004c0  RW     0x10000
+  LOAD           0x000000000013a008 0x00000000001ea008 0x00000000001ea008       0x0000000000017bd0 0x0000000000017bd0  RW     0x10000
+  LOAD           0x0000000000161bd8 0x0000000000211bd8 0x0000000000211bd8       0x000000000000f740 0x000000000000f740  RW     0x10000
+  DYNAMIC        0x0000000000161e60 0x0000000000211e60 0x0000000000211e60       0x00000000000001e0 0x00000000000001e0  RW     0x8
+  INTERP         0x0000000000089410 0x0000000000089410 0x0000000000089410       0x0000000000000015 0x0000000000000015  R      0x1
+      [Requesting program interpreter: /system/bin/linker64]
+  NOTE           0x000000000013dbc8 0x00000000001edbc8 0x00000000001edbc8       0x0000000000000011 0x0000000000000011  R      0x1
+  GNU_EH_FRAME   0x00000000001c86a4 0x00000000001c86a4 0x00000000001c86a4       0x00000000000002dc 0x00000000000002dc  R      0x4
+  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000       0x0000000000000000 0x0000000000000000  RW     0x10
+```
+
+X.so: https://drive.google.com/file/d/1A7mkWRcK2BKkpeevt8T6FVLg-t6mWdgi/view?usp=sharing
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1106 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1106
new file mode 100644
index 00000000..50faffbc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1106
@@ -0,0 +1,9 @@
+undefined address access cause failure
+Description of problem:
+Hi,
+I used serial device as below:
+qemu/hw/char/serial.c
+It defines only support 8 registers address space(offset 0x00-0x32). And in guest os, the hardware is synopsys dw_apb_uart which is compatible with 16550.
+when it access low 8 registers, it works ok. but it may access high address(0x8c) which serial.c not defined, then fail occur.
+
+Is there anyway to handle this, access address which device not defined, expect it no handle, but not cause system crash. like read is zero and write ignore.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1107 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1107
new file mode 100644
index 00000000..20015cf1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1107
@@ -0,0 +1,24 @@
+Virtual monitor heads are not "connected" until viewed in a front end
+Description of problem:
+When you attach a virtual GPU to a guest, qemu appears to only "attach" a virtual monitor to an output port when that virtual display is
+viewed using the GUI.  For example, when you boot using the above command line, there will be four displays in ```/sys/class/drm/``` on the guest,
+```card0-Virtual-1``` through to ```card0-Virtual-4```.  In each of these directories, there is an "enabled" file, which contains either
+"enabled" or "disabled".  These contain "disabled" until you switch tab/view to look at it using the GUI, at which point they change to "enabled".
+
+This causes a problem for us because Weston will not initialise displays that do not have a monitor attached, meaning the system we are trying
+to boot fails because not all the Weston display surfaces are available.
+
+There does not appear to be a command line option to force virtual monitors to be attached to virtual displays immediately.  Looking through the
+Gtk user interface code (and the other front ends) there does not appear to be a call into the qemu core that requests the connection of a virtual
+monitor to the virtual displays - my guess is that qemu only connects a monitor when a render request first happens (or similar), but I have not followed the code paths deeper than the source files in ```QEMU/ui/```.
+
+I also tried using the ```screengrab``` command to screenshot each head, but this does not need sufficient to cause the display to be marked
+enabled in the guest.
+
+While we could possibly automate the GUI using some external tool, we ultimately need to run this in a CI environment using
+```egl-headless``` or similar.
+Steps to reproduce:
+1. Launch qemu with virtio-gpu-gl setting max_outputs > 1
+2. On guest, ```cat /sys/drm/class/card0-Virtual-2``` - it reads "disabled"
+3. On host, switch the view to look at the second display ("virtio-gpu-gl-pci.1")
+4. On guest, ```cat /sys/drm/class/card0-Virtual-2``` - it now reads "enabled"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1108 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1108
new file mode 100644
index 00000000..e6ea9c68
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1108
@@ -0,0 +1 @@
+D-Bus display does fails to build if libgdm is not detected
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/111 b/gitlab/issues_text/target_missing/host_missing/accel_missing/111
new file mode 100644
index 00000000..c0763e63
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/111
@@ -0,0 +1 @@
+[OSS-Fuzz] Assertion Failure: !in6_zero(&ip_addr)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1110 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1110
new file mode 100644
index 00000000..a73239c4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1110
@@ -0,0 +1,3 @@
+Add vhost-user-gpu support for cross architecture emulation
+Additional information:
+host:Android 12 with Linux kernel 4.14.186+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1111 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1111
new file mode 100644
index 00000000..8548a6ee
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1111
@@ -0,0 +1,18 @@
+Calling FUTEX_LOCK_PI with qemu-x86_64-static caused ENOSYS error.
+Description of problem:
+When I executed the command "perf bench futex lock-pi" in amd64 docker image on s390x, I got the following error.
+```
+perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented
+perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented
+perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented
+perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented
+```
+
+I searched for this error message in the source code of perf-bench. I think that the following system call caused ENOSYS error.
+`  syscall(SYS_futex, uaddr, FUTEX_LOCK_PI | opflags, val, timeout, uaddr2, val3)`
+Steps to reproduce:
+1. Execute the command "perf bench futex lock-pi" in amd64 docker image on s390x
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1112 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1112
new file mode 100644
index 00000000..721cca9f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1112
@@ -0,0 +1 @@
+Heap-overflow in scsi_disk_emulate_write_same
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1113 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1113
new file mode 100644
index 00000000..cc38e828
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1113
@@ -0,0 +1,14 @@
+TMPDIR is not usable for snapshot-blockdevs, if not root
+Description of problem:
+for using static disk-content we're using `snapshot`-flag for certain disks and set `TMPDIR` to a VM-specific path.
+
+when started as root, all is ok.
+
+when started as non-root, `getenv(TMPDIR)` in function `get_tmp_filename()` in file `block.c` return `NULL`, because glibc handles `TMPDIR` as `UNSECURE_ENVVAR` (glibc-src: `sysdeps/generic/unsecvars.h`)
+
+well, we could compile qemu by ourself, but then we might miss important updates, so maybe this can be solved in main-source?
+
+possible solutions: 
+- additionally look at another var like `QEMU_TMPDIR`, if `getenv("TMPDIR")` results in `NULL`
+- add a global option to qemu like `--tmpdir=...`
+- add a device-specific option like `snapshotdir=...`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1114 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1114
new file mode 100644
index 00000000..21ee8c56
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1114
@@ -0,0 +1 @@
+Non-deterministic hang in libvfio-user:functional/test-client-server test causing timeout in CentOS 8 CI job
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1116 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1116
new file mode 100644
index 00000000..96bd5fed
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1116
@@ -0,0 +1,18 @@
+qemu/build/qemu-bundle/var/local/run is linked to qemu/qga/run which doesn't exist after building qemu
+Description of problem:
+A file qemu/build/qemu-bundle/var/local/run is generated after building qemu and this file is linked to qemu/qga/run which doesn't exist.
+
+[root@b49691d8db1c local]# ls /home/lxy/qemu/build/qemu-bundle/var/local -hl
+total 0
+lrwxrwxrwx. 1 root root 22 Jul 22 00:06 run -> /home/lxy/qemu/qga/run
+[root@b49691d8db1c local]# ls -hl /home/lxy/qemu/qga/run
+ls: cannot access '/home/lxy/qemu/qga/run': No such file or directory
+Steps to reproduce:
+1. git clone https://gitlab.com/qemu-project/qemu.git
+2. cd qemu/
+3. ./configure --target-list=x86_64-softmmu --enable-kvm
+4. make -j100 && make install
+5. ls ./build/qemu-bundle/var/local -hl
+6. ls -hl ./qga/run
+Additional information:
+![Capture](/uploads/aeb5a2bb75742b337940f1f0cfea647e/Capture.PNG)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1117 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1117
new file mode 100644
index 00000000..28648ef9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1117
@@ -0,0 +1,95 @@
+migration corrupts qcow2 metadata when "backing file: json:{" is involve
+Description of problem:
+the bug happens when you have a qcow2 with backing file in json format
+image: 2.qcow2
+[...]
+backing file: json:{"driver": "qcow2", "file": { "driver": "file", "filename": "1.qcow2"}}
+backing file format: qcow2
+[...]
+if you want to migrate a VM that have that kind of qcow2 attached, the migration is gonna corrupted qcow2 metadata in memory and info block will look like this
+json:{\"backing\": {\"backing\": {\"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"0.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"1.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"2.qcow2\"}}
+later if you execute blockdev-snapshot-sync, the corrupt json will be write to the new qcow2 resulting with a unusable qcow2
+Steps to reproduce:
+/opt/qemu-7.0.0/bin/qemu-img create -f qcow2 0.qcow2 64G
+/opt/qemu-7.0.0/bin/qemu-img create -F qcow2 -f qcow2 -b 'json:{"driver": "qcow2", "file": { "driver": "file", "filename": "0.qcow2"}}' 1.qcow2
+/opt/qemu-7.0.0/bin/qemu-img create -F qcow2 -f qcow2 -b 'json:{"driver": "qcow2", "file": { "driver": "file", "filename": "1.qcow2"}}' 2.qcow2
+
+#VM1
+/opt/qemu-7.0.0/bin/qemu-system-x86_64 -enable-kvm -drive if=virtio,file=2.qcow2,node-name=drive0 -qmp stdio -display none
+
+#VM2
+/opt/qemu-7.0.0/bin/qemu-system-x86_64 -enable-kvm -drive if=virtio,file=2.qcow2,node-name=drive0 -qmp stdio -display none -incoming tcp::8082
+
+
+#VM1 INFO BLOCK
+{"QMP": {"version": {"qemu": {"micro": 0, "minor": 0, "major": 7}, "package": ""}, "capabilities": ["oob"]}}
+{ "execute": "qmp_capabilities" }
+{"return": {}}
+{ "execute": "human-monitor-command", "arguments": {'command-line': 'info block'} }
+{"return": "virtio0 (drive0): 2.qcow2 (qcow2)\r\n    Attached to:      /machine/peripheral-anon/device[0]/virtio-backend\r\n    Cache mode:       writethrough\r\n    Backing file:     1.qcow2 (chain depth: 2)\r\n\r\nide1-cd0: [not inserted]\r\n    Attached to:      /machine/unattached/device[24]\r\n    Removable device: not locked, tray closed\r\n\r\nfloppy0: [not inserted]\r\n    Attached to:      /machine/unattached/device[17]\r\n    Removable device: not locked, tray closed\r\n\r\nsd0: [not inserted]\r\n    Removable device: not locked, tray closed\r\n"}
+
+#VM1 MIGRATE
+{ "execute": "migrate", "arguments": { "uri": "tcp:localhost:8082" } }
+{"return": {}}
+{"timestamp": {"seconds": 1658491019, "microseconds": 233177}, "event": "STOP"}
+
+
+#VM2 INFO BLOCK
+{"QMP": {"version": {"qemu": {"micro": 0, "minor": 0, "major": 7}, "package": ""}, "capabilities": ["oob"]}}
+{ "execute": "qmp_capabilities" }
+{"return": {}}
+{ "execute": "human-monitor-command", "arguments": {'command-line': 'info block'} }
+{"return": "virtio0 (drive0): 2.qcow2 (qcow2)\r\n    Attached to:      /machine/peripheral-anon/device[0]/virtio-backend\r\n    Cache mode:       writeback\r\n    Backing file:     1.qcow2 (chain depth: 2)\r\n\r\nide1-cd0: [not inserted]\r\n    Attached to:      /machine/unattached/device[24]\r\n    Removable device: not locked, tray closed\r\n\r\nfloppy0: [not inserted]\r\n    Attached to:      /machine/unattached/device[17]\r\n    Removable device: not locked, tray closed\r\n\r\nsd0: [not inserted]\r\n    Removable device: not locked, tray closed\r\n"}
+
+#VM2 MIGRATE
+{"timestamp": {"seconds": 1658491019, "microseconds": 249760}, "event": "RESUME"}
+
+#VM2 MIGRATION DONE, INFO BLOCK
+{ "execute": "human-monitor-command", "arguments": {'command-line': 'info block'} }
+{"return": "virtio0 (drive0): json:{\"backing\": {\"backing\": {\"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"0.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"1.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"2.qcow2\"}} (qcow2)\r\n    Attached to:      /machine/peripheral-anon/device[0]/virtio-backend\r\n    Cache mode:       writethrough\r\n    Backing file:     json:{\"backing\": {\"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"0.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"1.qcow2\"}} (chain depth: 2)\r\n\r\nide1-cd0: [not inserted]\r\n    Attached to:      /machine/unattached/device[24]\r\n    Removable device: not locked, tray closed\r\n\r\nfloppy0: [not inserted]\r\n    Attached to:      /machine/unattached/device[17]\r\n    Removable device: not locked, tray closed\r\n\r\nsd0: [not inserted]\r\n    Removable device: not locked, tray closed\r\n"}
+
+
+#VM2 SNAPSHOT AFTER MIGRATION
+{ "execute": "blockdev-snapshot-sync", "arguments": { "format": "qcow2", "snapshot-file": "3.qcow2", "node-name": "drive0", "snapshot-node-name": "drive0-snap" }}
+Formatting '3.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=68719476736 backing_file=json:{"backing": {"backing": {"driver": "qcow2",, "file": {"driver": "file",, "filename": "0.qcow2"}},, "driver": "qcow2",, "file": {"driver": "file",, "filename": "1.qcow2"}},, "driver": "qcow2",, "file": {"driver": "file",, "filename": "2.qcow2"}} backing_fmt=qcow2 lazy_refcounts=off refcount_bits=16
+{"return": {}}
+
+
+#VM2 INFO BLOCK AFTER SNAPSHOT
+{ "execute": "human-monitor-command", "arguments": {'command-line': 'info block'} }
+{"return": "virtio0 (drive0-snap): 3.qcow2 (qcow2)\r\n    Attached to:      /machine/peripheral-anon/device[0]/virtio-backend\r\n    Cache mode:       writethrough\r\n    Backing file:     json:{\"backing\": {\"backing\": {\"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"0.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"1.qcow2\"}}, \"driver\": \"qcow2\", \"file\": {\"driver\": \"file\", \"filename\": \"2.qcow2\"}} (chain depth: 3)\r\n\r\nide1-cd0: [not inserted]\r\n    Attached to:      /machine/unattached/device[24]\r\n    Removable device: not locked, tray closed\r\n\r\nfloppy0: [not inserted]\r\n    Attached to:      /machine/unattached/device[17]\r\n    Removable device: not locked, tray closed\r\n\r\nsd0: [not inserted]\r\n    Removable device: not locked, tray closed\r\n"}
+
+
+
+#INFO
+/opt/qemu-7.0.0/bin/qemu-img info --backing-chain 3.qcow2
+qemu-img: Could not open 'json:{"backing": {"backing": {"driver": "qcow2", "file": {"driver": "file", "filename": "0.qcow2"}}, "driver": "qcow2", "file": {"driver": "file", "filename": "1.qcow2"}}, "driver": "qcow2", "file": {"driver": "file", "filename": "2.qcow2"}}': Block format 'qcow2' does not support the option 'backing.backing.driver'
+Additional information:
+Even if the bug is scary it's very simple to fix it
+
+/opt/qemu-7.0.0/bin/qemu-img info --backing-chain 3.qcow2
+qemu-img: Could not open 'json:{"backing": {"backing": {"driver": "qcow2", "file": {"driver": "file", "filename": "0.qcow2"}}, "driver": "qcow2", "file": {"driver": "file", "filename": "1.qcow2"}}, "driver": "qcow2", "file": {"driver": "file", "filename": "2.qcow2"}}': Block format 'qcow2' does not support the option 'backing.backing.driver'
+
+root@lenovo2:/data# /opt/qemu-7.0.0/bin/qemu-img rebase -f qcow2 -F qcow2 -u -b 2.qcow2 3.qcow2
+root@lenovo2:/data# /opt/qemu-7.0.0/bin/qemu-img info --backing-chain 3.qcow2
+image: 3.qcow2
+file format: qcow2
+virtual size: 64 GiB (68719476736 bytes)
+disk size: 24 KiB
+cluster_size: 65536
+backing file: 2.qcow2
+backing file format: qcow2
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: false
+    refcount bits: 16
+    corrupt: false
+    extended l2: false
+
+image: 2.qcow2
+file format: qcow2
+virtual size: 64 GiB (68719476736 bytes)
+disk size: 24 KiB
+cluster_size: 65536
+[..........]
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1119 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1119
new file mode 100644
index 00000000..3c2c584f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1119
@@ -0,0 +1,15 @@
+end_code set incorrectly
+Description of problem:
+https://github.com/qemu/qemu/blob/c99e34e537f13a431a80e3e414e5904e9dd0a116/linux-user/flatload.c#L811
+
+This line says:
+
+```
+info->end_code = libinfo[0].start_code = libinfo[0].text_len;
+```
+
+but should be
+
+```
+info->end_code = libinfo[0].start_code + libinfo[0].text_len;
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/112 b/gitlab/issues_text/target_missing/host_missing/accel_missing/112
new file mode 100644
index 00000000..5c054716
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/112
@@ -0,0 +1 @@
+setting unsupported timeout for i6300esb watchdog causes hw reset
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1120 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1120
new file mode 100644
index 00000000..fd36aa92
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1120
@@ -0,0 +1,12 @@
+Multiboot direct loading broken.
+Description of problem:
+This is my kernel and it's multiboot loader. It passed the check of `grub-file`, but QEMU could not load it.
+```
+qemu-system-i386: Error loading uncompressed kernel without PVH ELF Note
+```
+
+When I add `-machine type=pc-i440fx-3.1`, QEMU shows `qemu: linux kernel too old to load a ram disk` or `qemu: invalid kernel header`.
+
+The multiboot file is linked with `ld.lld -s -o`.
+
+[toop](/uploads/7f230dc39d6a3a8c43c4c720d31878c6/toop)[multiboot](/uploads/59faa4607dc2837b54c89b35db6f206a/multiboot)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1125 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1125
new file mode 100644
index 00000000..9e8e624f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1125
@@ -0,0 +1,3 @@
+error on run qemu-system-aarch64 -smp 2
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1128 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1128
new file mode 100644
index 00000000..ebd6be40
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1128
@@ -0,0 +1,24 @@
+PPC: `spr_write_xer` doesn't set flag bits in `cpu_xer`
+Description of problem:
+`spr_write_xer()` does not set the `ca`, `ov`, `so`, `ca32`, `ov32` etc. flag bits in the `cpu_xer` variable.
+
+In fact it copies all bits from the source `GPR` and _excludes_ each flag bit.
+
+This is not a problem for execution since `spr_read_xer()` gets the flag bits from `cpu_ca/ov/so...` and not from `cpu_xer`.
+
+Nonetheless it is problem for tools which trace the execution in QEMU (e.g. https://github.com/BinaryAnalysisPlatform/qemu). 
+
+A fix would be to remove the `~` in https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L481
+Steps to reproduce:
+Haven't found out yet how to debug QEMU so the TCGv values can be investigated. But in general one need to:
+
+- Execute a binary which executes something like:
+```
+r4 = 0xffffffffffffffff
+mtxer r4
+```
+and check the `cpu_xer` value after the `xer` write.
+
+Checking the debug logs (`in_asm,cpu`) doesn't work, since the `xer` value in the logs is not taken directly from `cpu_xer`.
+Additional information:
+Code ref: https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L480-L483
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1129 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1129
new file mode 100644
index 00000000..a2ad2f24
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1129
@@ -0,0 +1,23 @@
+aarch64:qemu7.0.0 static compile error
+Description of problem:
+I'm trying to static compile qemu so I can chroot into different architectures and use podman for simulating amd64 containers.
+However, when I tried to configure using the command above, I got the following error:
+
+```
+FAILED: qemu-aarch64_be 
+c++  -o qemu-aarch64_be libcommon.fa.p/cpus-common.c.o libcommon.fa.p/page-vary-common.c.o libcommon.fa.p/disas_arm-a64.cc.o libcommon.fa.p/disas_libvixl_vixl_a64_decoder-a64.cc.o libcommon.fa.p/disas_libvixl_vixl_a64_disasm-a64.cc.o libcommon.fa.p/disas_libvixl_vixl_a64_instructions-a64.cc.o libcommon.fa.p/disas_libvixl_vixl_compiler-intrinsics.cc.o libcommon.fa.p/disas_libvixl_vixl_utils.cc.o libcommon.fa.p/disas_arm.c.o libcommon.fa.p/hw_core_cpu-common.c.o libcommon.fa.p/hw_core_machine-smp.c.o libcommon.fa.p/accel_accel-user.c.o libcommon.fa.p/common-user_safe-syscall.S.o libcommon.fa.p/common-user_safe-syscall-error.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_aarch64_signal.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_aarch64_cpu_loop.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_cpu.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_crypto_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_debug_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_gdbstub.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_iwmmxt_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_m_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_mve_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_neon_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_op_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_tlb_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-m-nocp.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-mve.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-neon.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-vfp.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_vec_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_vfp_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_cpu_tcg.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_kvm-stub.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_cpu64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_gdbstub64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_helper-a64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_mte_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_pauth_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_sve_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-a64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-sve.c.o libqemu-aarch64_be-linux-user.fa.p/trace_control-target.c.o libqemu-aarch64_be-linux-user.fa.p/cpu.c.o libqemu-aarch64_be-linux-user.fa.p/disas.c.o libqemu-aarch64_be-linux-user.fa.p/gdbstub.c.o libqemu-aarch64_be-linux-user.fa.p/page-vary.c.o libqemu-aarch64_be-linux-user.fa.p/semihosting_arm-compat-semi.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_optimize.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_region.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-common.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-op.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-op-gvec.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-op-vec.c.o libqemu-aarch64_be-linux-user.fa.p/fpu_softfloat.c.o libqemu-aarch64_be-linux-user.fa.p/accel_accel-common.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_tcg-all.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_cpu-exec-common.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_cpu-exec.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_tcg-runtime-gvec.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_tcg-runtime.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_translate-all.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_translator.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_user-exec.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_user-exec-stub.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_elfload.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_exit.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_fd-trans.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_linuxload.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_main.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_mmap.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_signal.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_strace.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_syscall.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_thunk.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_uaccess.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_uname.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_flatload.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_semihost.c.o libqemu-aarch64_be-linux-user.fa.p/meson-generated_.._aarch64_be-linux-user-gdbstub-xml.c.o -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libhwcore.fa libqom.fa -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -static-pie -fstack-protector-strong -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -Wp,-D_GLIBCXX_ASSERTIONS -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,--start-group libqemuutil.a libhwcore.fa libqom.fa /usr/lib/libz.a -lrt -lutil -lm -pthread -lgthread-2.0 -lglib-2.0 -lpcre -lsysprof-capture-4 -lstdc++ -Wl,--end-group
+/usr/bin/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../../lib/libglib-2.0.a(gutils.c.o): in function `g_get_user_database_entry':
+gutils.c:(.text+0x324): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+/usr/bin/ld: gutils.c:(.text+0xf4): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+/usr/bin/ld: gutils.c:(.text+0xe0): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+/usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../../lib/libc.a(init-first.o): in function `__libc_init_first':
+(.text+0x10): relocation truncated to fit: R_AARCH64_LD64_GOTPAGE_LO15 against symbol `__environ' defined in .bss section in /usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../../lib/libc.a(environ.o)
+/usr/bin/ld: (.text+0x10): warning: too many GOT entries for -fpic, please recompile with -fPIC
+collect2: error: ld returned 1 exit status
+ninja: build stopped: subcommand failed.
+make: *** [Makefile:163: run-ninja] Error 1
+```
+Same error for both mentioned kernels in different aarch64 hardwares.
+Steps to reproduce:
+1. Download the tarball from version 7.0.0
+2. Run the configure as mentioned on the above command
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/113 b/gitlab/issues_text/target_missing/host_missing/accel_missing/113
new file mode 100644
index 00000000..516a4e0c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/113
@@ -0,0 +1 @@
+missing manpage for bridge.conf
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1134 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1134
new file mode 100644
index 00000000..e24cc8aa
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1134
@@ -0,0 +1,3 @@
+Make ivshmem more generic not only a PCI device
+Additional information:
+It will also benefit from making it more portable, see https://gitlab.com/qemu-project/qemu/-/issues/666
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1138 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1138
new file mode 100644
index 00000000..ff7c5c3b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1138
@@ -0,0 +1 @@
+Not able to get KVM in qemu-system-s390x built from 6.2.0 source on Fedora 31
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1139 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1139
new file mode 100644
index 00000000..09b4e7c5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1139
@@ -0,0 +1,78 @@
+block/nbd.c and drive backup to a remote nbd server
+Description of problem:
+Good afternoon!
+
+I trying to copy attached drive content to remote NBD server via drive-backup QMP method. I'he tested two very similar ways but with very different performance. First is a backuping to exported NBD at another server. Second way is a backuping to same server but with connecting to /dev/nbd*. 
+
+Exporting qcow2 via nbd:
+```
+(nbd) ~ # qemu-nbd -p 12345 -x backup --cache=none --aio=native --persistent -f qcow2 backup.qcow2
+
+(qemu) ~ # qemu-img info nbd://10.0.0.1:12345/backup
+image: nbd://10.0.0.1:12345/backup
+file format: raw
+virtual size: 10 GiB (10737418240 bytes)
+disk size: unavailable
+```
+
+Starting drive backuping via QMP:
+
+```
+{
+	"execute": "drive-backup",
+	"arguments": {
+		"device": "disk",
+		"sync": "full",
+		"target": "nbd://10.0.0.1:12345/backup",
+		"mode": "existing"
+	}
+}
+```
+
+With process starting qemu notifying about warning:
+
+> warning: The target block device doesn't provide information about the block size and it doesn't have a backing file. The default block size of 65536 bytes is used. If the actual block size of the target exceeds this default, the backup may be unusable
+
+And backup process is limited by speed around 30MBps, watched by iotop
+
+
+Second way to creating backup
+
+Exporting qcow2 via nbd:
+```
+(nbd) ~ # qemu-nbd -p 12345 -x backup --cache=none --aio=native --persistent -f qcow2 backup.qcow2
+```
+
+```
+(qemu) ~ # qemu-img info nbd://10.0.0.1:12345/backup
+image: nbd://10.0.0.1:12345/backup
+file format: raw
+virtual size: 10 GiB (10737418240 bytes)
+disk size: unavailable
+(qemu) ~ # qemu-nbd -c /dev/nbd0 nbd://10.0.0.1:12345/backup
+(qemu) ~ # qemu-img info /dev/nbd0
+image: /dev/nbd0
+file format: raw
+virtual size: 10 GiB (10737418240 bytes)
+disk size: 0 B
+```
+
+Starting drive backuping via QMP to local nbd device:
+
+```
+{
+	"execute": "drive-backup",
+	"arguments": {
+		"device": "disk",
+		"sync": "full",
+		"target": "/dev/nbd0",
+		"mode": "existing"
+	}
+}
+```
+
+Backup process started without previous warning, and speed limited around 100MBps (network limit)
+
+So I have question: how I can get same performance without connection network device to local block nbd device at the qemu host?
+
+Kind regards
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/114 b/gitlab/issues_text/target_missing/host_missing/accel_missing/114
new file mode 100644
index 00000000..5d5f6f1d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/114
@@ -0,0 +1 @@
+the help message of the set_password subcommand of the qemu monitor isn't usable
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1140 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1140
new file mode 100644
index 00000000..eaa00ccc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1140
@@ -0,0 +1 @@
+High CPU usage on AMD after migrating guests
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1142 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1142
new file mode 100644
index 00000000..a4b69002
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1142
@@ -0,0 +1,46 @@
+Measurements fail with direct kernel boot for AMD SEV confidential virtualization with 7.1 machine type
+Description of problem:
+When booting the QEMU with the 'kernel-hashes:true' property set for 'sev-guest' confidential virtualization, the contents of the `-kernel` file are measured by the firmware.
+
+A remote tenant can then validate the measurement against its expected contents to see if the boot was trustworthy.
+
+With the pc-q35-7.1 machine type the measurement always fails to validate against expected state.
+
+Making the following code change 
+
+```
+diff --git a/hw/i386/pc.c b/hw/i386/pc.c
+index 7280c02ce3..3a4bf5cba3 100644
+--- a/hw/i386/pc.c
++++ b/hw/i386/pc.c
+@@ -1899,6 +1899,8 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
+     pcmc->rsdp_in_ram = true;
+     pcmc->smbios_defaults = true;
+     pcmc->smbios_uuid_encoded = true;
++    pcmc->legacy_no_rng_seed = true;
++
+     pcmc->gigabyte_align = true;
+     pcmc->has_reserved_memory = true;
+     pcmc->kvmclock_enabled = true;
+```
+
+results in successfully validating the measurement.
+
+THis is not surprising, the RNG seed patch introduced in 
+
+```
+commit 67f7e426e53833a5db75b0d813e8d537b8a75bd2
+Author: Jason A. Donenfeld <Jason@zx2c4.com>
+Date:   Thu Jul 21 14:56:36 2022 +0200
+
+    hw/i386: pass RNG seed via setup_data entry
+```
+
+intentionally modifies the contents of the kernel image before passing it to the firmware, to inject a random seed. This will ensure the boot measuremnts are different every time.
+
+This RNG seed functionality must NOT be used when AMD SEV is active.
+Steps to reproduce:
+1. Create an AMD SEV guest with kernel-hashes=true and pc-q35-7.1 machine type
+2. Attempt to validate the boot measurement
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1144 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1144
new file mode 100644
index 00000000..d1efc631
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1144
@@ -0,0 +1,13 @@
+Cannot install on ArcoLinux
+Description of problem:
+I tried to install with my package manager 
+```
+paru -S qemu-git
+```
+and got these errors
+```
+qemu-git: /usr/share/qemu/bios-microvm.bin exists in filesystem (owned by seabios)
+qemu-git: /usr/share/qemu/vgabios-ati.bin exists in filesystem (owned by seabios)
+```
+
+I tried searching around for a solution but I can't seem to find anything relevant to my situation.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1148 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1148
new file mode 100644
index 00000000..936dea8e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1148
@@ -0,0 +1,271 @@
+Support Octal SPI mode and commands for NOR SPI devices
+Additional information:
+A good example of the Octal SPI (OPI) protocol use is in https://www.st.com/resource/en/application_note/dm00407776-octospi-interface-on-stm32-microcontrollers-stmicroelectronics.pdf
+
+It is also supported by the concrete drivers in Linux kernel:
+- `drivers/mtd/spi-nor/core.c`
+- `drivers/mtd/spi-nor/micron-st.c`
+- `drivers/mtd/spi-nor/spansion.c`
+
+I tried to extract the Octal SPI part from that commit and got something like this, though obviously needs more cleaning up/improving:
+```patch
+---
+ hw/block/m25p80.c | 93 ++++++++++++++++++++++++++++++++++-------------
+ 1 file changed, 68 insertions(+), 25 deletions(-)
+
+diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
+index 7d3d8b12e0..0aa46bf280 100644
+--- a/hw/block/m25p80.c
++++ b/hw/block/m25p80.c
+@@ -361,6 +361,8 @@ typedef enum {
+     READ4 = 0x13,
+     FAST_READ = 0x0b,
+     FAST_READ4 = 0x0c,
++    O_FAST_READ = 0x9d,
++    O_FAST_READ4 = 0xfc,
+     DOR = 0x3b,
+     DOR4 = 0x3c,
+     QOR = 0x6b,
+@@ -369,6 +371,11 @@ typedef enum {
+     DIOR4 = 0xbc,
+     QIOR = 0xeb,
+     QIOR4 = 0xec,
++    OOR = 0x8b,
++    OOR4 = 0x8c,
++    OOR4_MT35X = 0x7c, /* according mt35x datasheet */
++    OIOR = 0xcb,
++    OIOR4 = 0xcc,
+ 
+     PP = 0x02,
+     PP4 = 0x12,
+@@ -379,6 +386,8 @@ typedef enum {
+     RDID_90 = 0x90,
+     RDID_AB = 0xab,
+     AAI_WP = 0xad,
++    OPP = 0x82,
++    OPP4 = 0x84,
+ 
+     ERASE_4K = 0x20,
+     ERASE4_4K = 0x21,
+@@ -422,6 +431,7 @@ typedef enum {
+     STATE_COLLECTING_DATA,
+     STATE_COLLECTING_VAR_LEN_DATA,
+     STATE_READING_DATA,
++    DUMMY_CYCLE_WAIT,
+ } CMDState;
+ 
+ typedef enum {
+@@ -654,12 +664,16 @@ static inline int get_addr_length(Flash *s)
+    case QPP_4:
+    case READ4:
+    case QIOR4:
++   case OIOR4:
+    case ERASE4_4K:
+    case ERASE4_32K:
+    case ERASE4_SECTOR:
+    case FAST_READ4:
++   case O_FAST_READ4:
+    case DOR4:
+    case QOR4:
++   case OOR4:
++   case OOR4_MT35X:
+    case DIOR4:
+        return 4;
+    default:
+@@ -670,6 +684,7 @@ static inline int get_addr_length(Flash *s)
+ static void complete_collecting_data(Flash *s)
+ {
+     int i, n;
++    bool dummy_state = false;
+ 
+     n = get_addr_length(s);
+     s->cur_addr = (n == 3 ? s->ear : 0);
+@@ -689,9 +704,12 @@ static void complete_collecting_data(Flash *s)
+     case DPP:
+     case QPP:
+     case QPP_4:
++    case OPP:
+     case PP:
++        s->state = STATE_PAGE_PROGRAM;
++        break;
++    case OPP4:
+     case PP4:
+-    case PP4_4:
+         s->state = STATE_PAGE_PROGRAM;
+         break;
+     case AAI_WP:
+@@ -702,16 +720,27 @@ static void complete_collecting_data(Flash *s)
+     case READ:
+     case READ4:
+     case FAST_READ:
+-    case FAST_READ4:
++    case O_FAST_READ:
+     case DOR:
+-    case DOR4:
+     case QOR:
+-    case QOR4:
++    case OOR:
+     case DIOR:
+-    case DIOR4:
+     case QIOR:
++    case OIOR:
++    case FAST_READ4:
++    case O_FAST_READ4:
++    case DOR4:
++    case QOR4:
++    case OOR4:
++    case OOR4_MT35X:
++    case DIOR4:
+     case QIOR4:
+-        s->state = STATE_READ;
++    case OIOR4:
++        if (dummy_state == false) {
++            s->state = STATE_READ;
++        } else {
++            s->state = DUMMY_CYCLE_WAIT;
++        }
+         break;
+     case ERASE_4K:
+     case ERASE4_4K:
+@@ -744,7 +773,6 @@ static void complete_collecting_data(Flash *s)
+             s->write_enable = false;
+         }
+         break;
+-    case BRWR:
+     case EXTEND_ADDR_WRITE:
+         s->ear = s->data[0];
+         break;
+@@ -1038,6 +1066,7 @@ static void decode_qio_read_cmd(Flash *s)
+         s->needed_bytes += 3;
+         break;
+     default:
++        s->needed_bytes += 5;
+         break;
+     }
+     s->pos = 0;
+@@ -1066,28 +1095,39 @@ static void decode_new_cmd(Flash *s, uint32_t value)
+                       "M25P80: Invalid cmd within AAI programming sequence");
+     }
+ 
++    s->needed_bytes = 0;
++
+     switch (value) {
+ 
++    case ERASE4_SECTOR:
++        if (s->four_bytes_address_mode == false) {
++            s->needed_bytes += 1;
++        }
+     case ERASE_4K:
+-    case ERASE4_4K:
+     case ERASE_32K:
+-    case ERASE4_32K:
+     case ERASE_SECTOR:
+-    case ERASE4_SECTOR:
++    case OPP:
+     case PP:
+-    case PP4:
++    case QOR:
++    case OOR:
++    case FAST_READ:
++    case O_FAST_READ:
++    case DOR:
+     case DIE_ERASE:
+     case RDID_90:
+     case RDID_AB:
+-        s->needed_bytes = get_addr_length(s);
++        s->needed_bytes += get_addr_length(s);
+         s->pos = 0;
+         s->len = 0;
+         s->state = STATE_COLLECTING_DATA;
+         break;
+-    case READ:
+     case READ4:
++        if (s->four_bytes_address_mode == false) {
++            s->needed_bytes += 1;
++        }
++    case READ:
+         if (get_man(s) != MAN_NUMONYX || numonyx_mode(s) == MODE_STD) {
+-            s->needed_bytes = get_addr_length(s);
++            s->needed_bytes += get_addr_length(s);
+             s->pos = 0;
+             s->len = 0;
+             s->state = STATE_COLLECTING_DATA;
+@@ -1098,7 +1138,7 @@ static void decode_new_cmd(Flash *s, uint32_t value)
+         break;
+     case DPP:
+         if (get_man(s) != MAN_NUMONYX || numonyx_mode(s) != MODE_QIO) {
+-            s->needed_bytes = get_addr_length(s);
++            s->needed_bytes += get_addr_length(s);
+             s->pos = 0;
+             s->len = 0;
+             s->state = STATE_COLLECTING_DATA;
+@@ -1110,8 +1150,11 @@ static void decode_new_cmd(Flash *s, uint32_t value)
+     case QPP:
+     case QPP_4:
+     case PP4_4:
++        if (s->four_bytes_address_mode == false) {
++            s->needed_bytes += 1;
++        }
+         if (get_man(s) != MAN_NUMONYX || numonyx_mode(s) != MODE_DIO) {
+-            s->needed_bytes = get_addr_length(s);
++            s->needed_bytes += get_addr_length(s);
+             s->pos = 0;
+             s->len = 0;
+             s->state = STATE_COLLECTING_DATA;
+@@ -1121,11 +1164,9 @@ static void decode_new_cmd(Flash *s, uint32_t value)
+         }
+         break;
+ 
+-    case FAST_READ:
+     case FAST_READ4:
+         decode_fast_read_cmd(s);
+         break;
+-    case DOR:
+     case DOR4:
+         if (get_man(s) != MAN_NUMONYX || numonyx_mode(s) != MODE_QIO) {
+             decode_fast_read_cmd(s);
+@@ -1134,14 +1175,13 @@ static void decode_new_cmd(Flash *s, uint32_t value)
+                           "QIO mode\n", s->cmd_in_progress);
+         }
+         break;
+-    case QOR:
+     case QOR4:
+-        if (get_man(s) != MAN_NUMONYX || numonyx_mode(s) != MODE_DIO) {
+-            decode_fast_read_cmd(s);
+-        } else {
+-            qemu_log_mask(LOG_GUEST_ERROR, "M25P80: Cannot execute cmd %x in "
+-                          "DIO mode\n", s->cmd_in_progress);
+-        }
++    case OOR4:
++    case OOR4_MT35X:
++        s->needed_bytes += 4;
++        s->pos = 0;
++        s->len = 0;
++        s->state = STATE_COLLECTING_DATA;
+         break;
+ 
+     case DIOR:
+@@ -1265,6 +1305,7 @@ static void decode_new_cmd(Flash *s, uint32_t value)
+         s->four_bytes_address_mode = false;
+         break;
+     case BRRD:
++        s->data_read_loop = false;
+     case EXTEND_ADDR_READ:
+         s->data[0] = s->ear;
+         s->pos = 0;
+@@ -1475,6 +1516,8 @@ static uint32_t m25p80_transfer8(SSIPeripheral *ss, uint32_t tx)
+         }
+         break;
+ 
++    case DUMMY_CYCLE_WAIT:
++        break;
+     default:
+     case STATE_IDLE:
+         decode_new_cmd(s, (uint8_t)tx);
+-- 
+```
+There is also missing **0xfd** command for the DDR Octal I/O Fast Read for Micron MT35X chips. I am not sure if it's the same as the **0xfc** command in the Xilinx code though.
+
+Since I am not the author of the original commit, maybe Xilinx folks could take my patch, update/improve it and send to the mailing list. It will reduce the amount of the changes you have to apply in your fork as well :smile:
+
+cc @alistair23
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1149 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1149
new file mode 100644
index 00000000..6f71d610
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1149
@@ -0,0 +1,9 @@
+Micron Xccela (MT35x) NOR Flash wrong implementation in `hw/block/m25p80.c`
+Additional information:
+I see that in the fork they introduced a new entry - `MAN_MICRON_OCTAL`: - https://github.com/Xilinx/qemu/blob/master/hw/block/m25p80.c
+
+Would be nice to make it more generic, probably to call just `MAN_MICRON` and set octal mode like quad mode in other flash implementations - via the configuration register flags, especially since they could be enabled and disabled on the fly.
+
+Also the 256 configuration registers: https://github.com/Xilinx/qemu/commit/9b2fe1e36bfd8849bb3538161279cdff6efea325
+
+cc @alistair23
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1150 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1150
new file mode 100644
index 00000000..3fa3ef7c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1150
@@ -0,0 +1,84 @@
+guest Linux Kernel hangs and reports CPU lockup/stuck (Qemu >= 6.0.1 regression)
+Description of problem:
+Since at least [qemu-6.0.1](https://download.qemu.org/qemu-6.0.1.tar.xz) my VM guest is having CPU problems. It looks like [qemu-6.0.0](https://download.qemu.org/qemu-6.0.0.tar.xz) is fine, but I can't confirm this 100 %.
+
+Problem: The guest hangs for about 30 seconds and dmesg reports errors.
+
+<details>
+<summary>dmesg</summary>
+
+```
+[  310.791732] watchdog: BUG: soft lockup - CPU#1 stuck for 25s! [swapper/1:0]
+[  310.791753] Modules linked in: ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter af_packet iscsi_ibft iscsi_boot_sysfs rfkill dm_crypt essiv authenc pktcdvd intel_rapl_msr intel_rapl_common kvm_intel kvm cirrus drm_kms_helper irqbypass cec pcspkr joydev rc_core syscopyarea sysfillrect sysimgblt virtio_balloon fb_sys_fops i2c_piix4 button nls_iso8859_1 nls_cp437 vfat fat drm fuse configfs ip_tables x_tables ext4 crc16 mbcache jbd2 hid_generic usbhid sd_mod t10_pi virtio_scsi virtio_net net_failover virtio_blk failover sr_mod cdrom ata_generic crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd xhci_pci xhci_pci_renesas xhci_hcd cryptd serio_raw ehci_pci uhci_hcd ehci_hcd usbcore ata_piix ahci libahci virtio_pci virtio_pci_modern_dev libata floppy qemu_fw_cfg dm_mirror dm_region_hash dm_log dm_mod sg scsi_mod
+[  310.792102] Supported: Yes
+[  310.792108] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.14.21-150400.22-default #1 SLE15-SP4 0b6a6578ade2de5c4a0b916095dff44f76ef1704
+[  310.792121] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
+[  310.792127] RIP: 0010:__do_softirq+0x6e/0x2bc
+[  310.792146] Code: 8b 70 2c 81 60 2c ff f7 ff ff 89 74 24 14 c7 44 24 10 0a 00 00 00 48 c7 c0 c0 30 03 00 65 66 c7 00 00 00 fb 66 0f 1f 44 00 00 <bb> ff ff ff ff 41 0f bc de 83 c3 01 89 1c 24 0f 84 92 00 00 00 49
+[  310.792154] RSP: 0018:ffffb9a8c00d0f98 EFLAGS: 00000206
+[  310.792163] RAX: 00000000000330c0 RBX: ffffb9a8c0093e18 RCX: 0000000034b47837
+[  310.792169] RDX: ffff9835c02dd100 RSI: 0000000004200042 RDI: 0000000000000040
+[  310.792175] RBP: 0000000000000022 R08: ffffb9a8c0093e18 R09: 0000000000000001
+[  310.792180] R10: 0000000000000002 R11: 0000000000000283 R12: 0000000000000001
+[  310.792185] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000
+[  310.792191] FS:  0000000000000000(0000) GS:ffff9836f7d00000(0000) knlGS:0000000000000000
+[  310.792197] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[  310.792203] CR2: 000055ed8cffbaf8 CR3: 00000001025c0001 CR4: 0000000000170ee0
+[  310.792216] Call Trace:
+[  310.792247]  <IRQ>
+[  310.792284]  irq_exit_rcu+0x9c/0xc0
+[  310.792305]  common_interrupt+0x5d/0xa0
+[  310.792331]  </IRQ>
+[  310.792335]  <TASK>
+[  310.792339]  asm_common_interrupt+0x1e/0x40
+[  310.792358] RIP: 0010:native_safe_halt+0xb/0x10
+[  310.792368] Code: f0 80 48 02 20 48 8b 00 a8 08 74 82 eb c1 cc eb 07 0f 00 2d 89 f3 5f 00 f4 c3 0f 1f 44 00 00 eb 07 0f 00 2d 79 f3 5f 00 fb f4 <c3> cc cc cc cc 0f 1f 44 00 00 65 8b 15 14 ee 60 69 0f 1f 44 00 00
+[  310.792375] RSP: 0018:ffffb9a8c0093ec8 EFLAGS: 00000212
+[  310.792382] RAX: ffffffff96a0ca50 RBX: 0000000000000001 RCX: ffff9835c49c3700
+[  310.792387] RDX: 00000000001df31e RSI: 0000000000000000 RDI: ffff9835c02a8000
+[  310.792392] RBP: ffffffff97d47120 R08: 00000000001df31e R09: 0000000000029800
+[  310.792397] R10: ffffb9a8c164bbe0 R11: 0000000000000198 R12: 0000000000000000
+[  310.792402] R13: 0000000000000000 R14: ffffffffffffffff R15: ffff9835c02a8000
+[  310.792409]  ? __sched_text_end+0x5/0x5
+[  310.792425]  default_idle+0xa/0x10
+[  310.792434]  default_idle_call+0x2d/0xe0
+[  310.792441]  do_idle+0x1ec/0x2d0
+[  310.792452]  cpu_startup_entry+0x19/0x20
+[  310.792460]  start_secondary+0x11c/0x160
+[  310.792475]  secondary_startup_64_no_verify+0xc2/0xcb
+[  310.792501]  </TASK>
+```
+
+```
+[  435.511342] BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 30s!
+[  435.511374] Showing busy workqueues and worker pools:
+[  435.511377] workqueue events: flags=0x0
+[  435.511380]   pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
+[  435.511385]     pending: vmstat_shepherd
+[  435.511395] workqueue events_power_efficient: flags=0x80
+[  435.511398]   pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256 refcnt=3
+[  435.511402]     pending: neigh_periodic_work, neigh_periodic_work
+[  435.511411] workqueue events_freezable_power_: flags=0x84
+[  435.511414]   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
+[  435.511417]     in-flight: 4783:disk_events_workfn
+[  435.511425] workqueue mm_percpu_wq: flags=0x8
+[  435.511428]   pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
+[  435.511431]     pending: vmstat_update
+[  435.511440] workqueue writeback: flags=0x4a
+[  435.511443]   pwq 4: cpus=0-1 flags=0x4 nice=0 active=1/256 refcnt=3
+[  435.511447]     pending: wb_workfn
+[  435.511453] workqueue kblockd: flags=0x18
+[  435.511455]   pwq 3: cpus=1 node=0 flags=0x0 nice=-20 active=3/256 refcnt=4
+[  435.511459]     pending: blk_mq_timeout_work, blk_mq_timeout_work, blk_mq_timeout_work
+[  435.511475] workqueue ata_sff: flags=0x8
+[  435.511479]   pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/512 refcnt=2
+[  435.511482]     pending: ata_sff_pio_task [libata]
+[  435.511538] pool 2: cpus=1 node=0 flags=0x0 nice=0 hung=30s workers=3 idle: 349 51
+```
+
+</details>
+
+It looks like the problem mostly appears if SSH is being used over a "user" network connection. A typical situation is when editing a file in Vim (compiled with X support) via SSH and using the X clipboard (`"+y"`). But the problem also happens in other situations with SSH, e. g. when using SSHFS.  
+The type of NIC doesn't seem to make a difference (tested `virtio` and `e1000`). But "tap" network connections don't show a problem.
+
+&nbsp;
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1156 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1156
new file mode 100644
index 00000000..8937c8c1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1156
@@ -0,0 +1 @@
+Incorrect implementation of vmsumudm instruction
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1157 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1157
new file mode 100644
index 00000000..ba2be02a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1157
@@ -0,0 +1,13 @@
+aarch64: enabling MMU causes instruction abort
+Description of problem:
+The title describes the problem pretty accurately, we get an instruction abort when enabling the MMU with a pretty simple set of page tables. This has been regressed from qemu 6.x.
+Steps to reproduce:
+1. Run the provided Kernel binary with the command line specified above.
+2. Notice the hang after 'Initialize MMU'. I traced it down to being an instructions abort after the write to the SCTLR_EL1 register.
+3. Try to run with qemu 6.x, and notice that it works.
+Additional information:
+This does work on actual hardware, so it has to be a qemu bug.
+
+A binary of the Serenity Kernel has been attached to the issue. The source of that binary can be found at commit ca0e32e59fcf67a662e5d3a994d44cd7c941624a of [SerenityOS](https://github.com/SerenityOS/serenity).
+
+[Kernel](/uploads/f731edbf81d8e575035e9693b0a51dbf/Kernel)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1158 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1158
new file mode 100644
index 00000000..fe02e26b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1158
@@ -0,0 +1 @@
+Error in setting VNC password
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1159 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1159
new file mode 100644
index 00000000..6275e1d5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1159
@@ -0,0 +1,32 @@
+Strange invalid access errors for very basic OS
+Description of problem:
+Currently I'm studying OS development. I found numerous guides on that topic, however [this one](https://github.com/cfenollosa/os-tutorial/tree/master/01-bootsector-barebones) is most close to what I have been doing.  
+When `.bin` file is launched with `-d guest_errors` flag, before any OS output exactly 512 error messages appear in logs, that look like that:
+```
+Invalid access at addr 0xFEBB0000, size 1, region '(null)', reason: rejected
+Invalid access at addr 0x0, size 1, region '(null)', reason: rejected
+Invalid access at addr 0xFEBB0001, size 1, region '(null)', reason: rejected
+Invalid access at addr 0x1, size 1, region '(null)', reason: rejected
+Invalid access at addr 0xFEBB0002, size 1, region '(null)', reason: rejected
+...
+and it goes up to
+...
+Invalid access at addr 0xFEBB00FE, size 1, region '(null)', reason: rejected
+Invalid access at addr 0xFE, size 1, region '(null)', reason: rejected
+Invalid access at addr 0xFEBB00FF, size 1, region '(null)', reason: rejected
+Invalid access at addr 0xFF, size 1, region '(null)', reason: rejected
+```
+Apparently, the OS boots normally after that. Should I be concerned about these messages or Should I just ignore them?
+That looks strange and confusing, not a piece of my code calls these addresses. Maybe I'm doing something wrong?
+Steps to reproduce:
+1. Install `nasm` compiler (nasm package for apt)
+2. Create a file named `os.asm` with exactly four lines:
+```asm
+loop:
+    jmp loop
+times 510-($-$$) db 0
+dw 0xaa55
+```
+3. Build it with `nasm -f bin os.asm -o os.bin`
+4. Run it with `qemu-system-i386 -d guest_errors -drive format=raw,file=./os.bin`
+5. ...enjoy error messages.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1161 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1161
new file mode 100644
index 00000000..f780b76f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1161
@@ -0,0 +1 @@
+revise docs/interop/virtio-balloon-stats.rst
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1162 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1162
new file mode 100644
index 00000000..a895e575
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1162
@@ -0,0 +1,12 @@
+`./configure` gives `big/little test failed` error when attempting to statically link on Fedora 36
+Description of problem:
+I'm having trouble attempting to build the QEMU System emulator statically linked. The error `./configure` gives `big/little test failed` with nothing else. I couldn't find any information relating to this. I'm not sure where to start fixing this. If anyone can help me with this, thanks!
+Steps to reproduce:
+1. `git clone https://gitlab.com/qemu-project/qemu.git`
+2. `cd qemu`
+3. `git submodule init`
+4. `git submodule update`
+5. `./configure --enable-kvm --enable-vnc --enable-vhost-net --enable-avx2 --enable-avx512f --target-list=x86_64-softmmu --static`
+6. Observe build error
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1165 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1165
new file mode 100644
index 00000000..639feea5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1165
@@ -0,0 +1,3 @@
+About support LoongArch architecture
+Additional information:
+Start from Linux 5.19, maybe can find the compatible source code for LoongArch in the Linux Kernel source code archive.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1169 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1169
new file mode 100644
index 00000000..af6a093a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1169
@@ -0,0 +1,3 @@
+rename snapshot by qemu-img
+Additional information:
+I have no idea to rename a snapshot which created by `qemu-img snapshot -c`, I think it is a useful function
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/117 b/gitlab/issues_text/target_missing/host_missing/accel_missing/117
new file mode 100644
index 00000000..29bca863
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/117
@@ -0,0 +1 @@
+nested 9p filesystem with security_model=mapped-xattr
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1170 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1170
new file mode 100644
index 00000000..ba43d33d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1170
@@ -0,0 +1,56 @@
+Unable to compile in Ubuntu 22.04, at compiling linux-user_arm_nwfpe_double_cpdo.c.o
+Description of problem:
+Compiling of QEMU 7.1.0-rc3 stops here for me:
+```
+[7172/9855] Compiling C object libqemu-armeb-linux-user.fa.p/linux-user_arm_nwfpe_double_cpdo.c.o
+FAILED: libqemu-armeb-linux-user.fa.p/linux-user_arm_nwfpe_double_cpdo.c.o 
+cc -m64 -mcx16 -Ilibqemu-armeb-linux-user.fa.p -I. -I.. -Itarget/arm -I../target/arm -I../common-user/host/x86_64 -I../linux-user/include/host/x86_64 -I../linux-user/include -Ilinux-user -I../linux-user -Ilinux-user/arm -I../linux-user/arm -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/capstone -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/andrea/Downloads/qemu-7.1.0-rc3/linux-headers -isystem linux-headers -iquote . -iquote /home/andrea/Downloads/qemu-7.1.0-rc3 -iquote /home/andrea/Downloads/qemu-7.1.0-rc3/include -iquote /home/andrea/Downloads/qemu-7.1.0-rc3/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=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-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 -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="armeb-linux-user-config-target.h"' '-DCONFIG_DEVICES="armeb-linux-user-config-devices.h"' -MD -MQ libqemu-armeb-linux-user.fa.p/linux-user_arm_nwfpe_double_cpdo.c.o -MF libqemu-armeb-linux-user.fa.p/linux-user_arm_nwfpe_double_cpdo.c.o.d -o libqemu-armeb-linux-user.fa.p/linux-user_arm_nwfpe_double_cpdo.c.o -c ../linux-user/arm/nwfpe/double_cpdo.c
+during RTL pass: expand
+../linux-user/arm/nwfpe/double_cpdo.c: In function ‘DoubleCPDO’:
+../linux-user/arm/nwfpe/double_cpdo.c:232:1: internal compiler error: Segmentation fault
+  232 | }
+      | ^
+0x7fe5b824251f ???
+	./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
+0x7fe5b8229d8f __libc_start_call_main
+	../sysdeps/nptl/libc_start_call_main.h:58
+0x7fe5b8229e3f __libc_start_main_impl
+	../csu/libc-start.c:392
+Please submit a full bug report,
+with preprocessed source if appropriate.
+Please include the complete backtrace with any bug report.
+See <file:///usr/share/doc/gcc-11/README.Bugs> for instructions.
+ninja: build stopped: subcommand failed.
+make[1]: *** [Makefile:162: run-ninja] Error 1
+make[1]: Leaving directory '/home/andrea/Downloads/qemu-7.1.0-rc3/build'
+make: *** [GNUmakefile:11: all] Error 2
+```
+
+Configure Output:
+[Configure_Output.txt](/uploads/40055846573b79cc2817d5cb338e18c1/Configure_Output.txt)
+
+Compiles on 7.0.0.
+Steps to reproduce:
+1. Run 'sudo apt purge qemu-kvm qemu-utils libvirt-daemon-system libvirt-clients bridge-utils virt-manager ovmf'
+2. Run 'sudo apt-get install git libglib2.0-dev libfdt-dev libpixman-1-dev zlib1g-dev ninja-build' ([Wiki](https://wiki.qemu.org/Hosts/Linux))
+3. Additional Packages:
+```
+sudo apt-get install git-email
+sudo apt-get install libaio-dev libbluetooth-dev libcapstone-dev libbrlapi-dev libbz2-dev
+sudo apt-get install libcap-ng-dev libcurl4-gnutls-dev libgtk-3-dev
+sudo apt-get install libibverbs-dev libjpeg8-dev libncurses5-dev libnuma-dev
+sudo apt-get install librbd-dev librdmacm-dev
+sudo apt-get install libsasl2-dev libsdl2-dev libseccomp-dev libsnappy-dev libssh-dev
+sudo apt-get install libvde-dev libvdeplug-dev libvte-2.91-dev libxen-dev liblzo2-dev
+sudo apt-get install valgrind xfslibs-dev 
+
+sudo apt-get install libnfs-dev libiscsi-dev
+```
+4. Build instructions for QEMU:
+```
+wget https://download.qemu.org/qemu-7.1.0-rc3.tar.xz
+tar xvJf qemu-7.1.0-rc3.tar.xz
+cd qemu-7.1.0-rc3
+./configure
+make
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1171 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1171
new file mode 100644
index 00000000..65d6dc5f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1171
@@ -0,0 +1,3 @@
+tulip: DMA reentrancy issue leads to stack overflow (CVE-2022-2962)
+Description of problem:
+A DMA reentrancy issue was found in the tulip emulation. When tulip reads or writes to  rx/tx descriptor ( tulip_desc_read/write ) or copies  rx/tx frame(tulip_copy_rx_bytes / tulip_copy_tx_buffers), it doesn't check whether the destination address is its own MMIO address. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition or, potentially, executing arbitrary code within the context of the QEMU process on the host.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1172 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1172
new file mode 100644
index 00000000..0d241faf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1172
@@ -0,0 +1,59 @@
+Make pixman an optional dependency
+Additional information:
+Only these files use pixman functions (excluding tests, of course):
+```
+meson.build
+contrib/vhost-user-gpu/vhost-user-gpu.c
+contrib/vhost-user-gpu/meson.build
+chardev/meson.build
+include/ui/spice-display.h
+include/ui/sdl2.h
+include/ui/gtk.h
+include/ui/qemu-pixman.h
+include/ui/console.h
+include/hw/display/xlnx_dp.h
+include/hw/virtio/virtio-gpu.h
+include/hw/virtio/virtio-gpu-pixman.h
+hw/display/vga.c
+hw/display/ramfb.c
+hw/display/vhost-user-gpu.c
+hw/display/virtio-gpu-gl.c
+hw/display/virtio-gpu-udmabuf.c
+hw/display/xenfb.c
+hw/display/ati_2d.c
+hw/display/meson.build
+hw/display/vmware_vga.c
+hw/display/qxl-render.c
+hw/display/xlnx_dp.c
+hw/display/bochs-display.c
+hw/display/sm501.c
+hw/display/virtio-gpu.c
+hw/vfio/display.c
+hw/s390x/meson.build
+ui/cocoa.m
+ui/console-gl.c
+ui/vnc.c
+ui/qemu-pixman.c
+ui/gtk.c
+ui/console.c
+ui/trace-events
+ui/meson.build
+ui/dbus-listener.c
+ui/vnc-enc-tight.c
+ui/vnc.h
+ui/spice-display.c
+ui/dbus-display1.xml
+ui/sdl2-2d.c
+```
+
+This code in `meson.build` always require **pixman** for building system emulators:
+```meson
+pixman = not_found
+if have_system or have_tools
+  pixman = dependency('pixman-1', required: have_system, version:'>=0.21.8',
+                      method: 'pkg-config', kwargs: static_kwargs)
+endif
+```
+https://gitlab.com/qemu-project/qemu/-/blob/master/meson.build#L520
+
+Most of the code could work without it.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1175 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1175
new file mode 100644
index 00000000..6f70a9e5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1175
@@ -0,0 +1,8 @@
+Crash / Assert in VVFAT.c while installaling WinXP from QEMU 7.0 running in Raspberry OS
+Description of problem:
+- Windows XP installation crashes QEMU with : 
+qemu-system-i386: ../block/vvfat.c:103: array_get: Assertion `index < array->next' failed.
+Steps to reproduce:
+Use command line above and run WindowsXP installation
+Additional information:
+Execution also leads to many "Invalid file name" being reported by QEMU
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1176 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1176
new file mode 100644
index 00000000..faa57b62
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1176
@@ -0,0 +1,7 @@
+VVFAT :rw writes from guest (ReactOS, windowsXP) not visible by host
+Description of problem:
+As described in https://jira.reactos.org/browse/CORE-18327
+While ./LMS is mounted as a :rw VVFAT drive, guest OS (ReactOS) is able to read files BUT when files are "written" from the guest, they are not visible on host side.
+QEMU execution is also massively polluted by "invalid file name" messages coming from https://git.qemu.org/?p=qemu.git;a=blob_plain;f=block/vvfat.c;hb=HEAD (but this is not specific to the use with ReactOS, as this is also observed with other guest : WXP, ...)
+
+See attached screenshot showing WXPSP3 as guest with file created in VVFAT drive while guest misses the newly created file.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1179 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1179
new file mode 100644
index 00000000..8375ca84
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1179
@@ -0,0 +1,65 @@
+qemu-img snapshot would break win8.1's system disk data
+Description of problem:
+`qemu-img snapshot` will cause a damage on windows 8.1 virtual machine
+Steps to reproduce:
+1.shutdown the virtual machine
+
+2.exec command
+```
+$ qemu-img snapshot -d standard /media/user/SSD_VM/disk/win8_1.qcow2
+...
+ERROR cluster 554329 refcount=0 reference=1
+ERROR cluster 554330 refcount=0 reference=1
+ERROR cluster 554331 refcount=0 reference=1
+ERROR cluster 554332 refcount=0 reference=1
+ERROR cluster 554333 refcount=0 reference=1
+ERROR cluster 554334 refcount=0 reference=1
+ERROR cluster 554335 refcount=0 reference=1
+Leaked cluster 557183 refcount=2 reference=1
+Leaked cluster 557472 refcount=2 reference=1
+Leaked cluster 564785 refcount=2 reference=1
+...
+Leaked cluster 580393 refcount=2 reference=1
+Leaked cluster 580434 refcount=2 reference=1
+Leaked cluster 580713 refcount=2 reference=1
+Leaked cluster 580718 refcount=2 reference=1
+Leaked cluster 580726 refcount=2 reference=1
+Leaked cluster 580965 refcount=2 reference=1
+Leaked cluster 581268 refcount=2 reference=1
+Leaked cluster 581280 refcount=2 reference=1
+Leaked cluster 581367 refcount=2 reference=1
+Leaked cluster 582743 refcount=2 reference=1
+Leaked cluster 582938 refcount=2 reference=1
+Leaked cluster 583026 refcount=2 reference=1
+Leaked cluster 583027 refcount=2 reference=1
+Leaked cluster 583028 refcount=2 reference=1
+Leaked cluster 583029 refcount=2 reference=1
+Rebuilding refcount structure
+Repairing cluster 547917 refcount=1 reference=0
+Repairing cluster 547936 refcount=1 reference=0
+Repairing cluster 547955 refcount=1 reference=0
+Repairing cluster 548069 refcount=1 reference=0
+Repairing cluster 548092 refcount=1 reference=0
+Repairing cluster 548115 refcount=1 reference=0
+Repairing cluster 548125 refcount=1 reference=0
+Repairing cluster 548128 refcount=1 reference=0
+Repairing cluster 548130 refcount=1 reference=0
+Repairing cluster 548144 refcount=1 reference=0
+Repairing cluster 548146 refcount=1 reference=0
+Repairing cluster 548150 refcount=1 reference=0
+Repairing cluster 548199 refcount=1 reference=0
+Repairing cluster 548201 refcount=1 reference=0
+Repairing cluster 548226 refcount=1 reference=0
+Repairing cluster 548234 refcount=1 reference=0
+Repairing cluster 548236 refcount=1 reference=0
+Repairing cluster 557073 refcount=1 reference=0
+Repairing cluster 557074 refcount=1 reference=0
+...
+
+```
+
+3.start the virtual machine , it shows blue screen error:
+`UNEXPECTED_STORE_EXCPETION`
+![Screenshot_20220828_131532](/uploads/d8c03c01deb9ae1183a4efd823850c7e/Screenshot_20220828_131532.png)
+Additional information:
+the windows virtual machine will automatically fix the damage that qemu-img caused on next restart .
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/118 b/gitlab/issues_text/target_missing/host_missing/accel_missing/118
new file mode 100644
index 00000000..9f79476a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/118
@@ -0,0 +1 @@
+USB device 1.1 not correctly passedthru from Linux host to Windows guest
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1180 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1180
new file mode 100644
index 00000000..6a2961f2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1180
@@ -0,0 +1,166 @@
+Assertion failure in usb_cancel_packet()
+Description of problem:
+When I ran hcd-ohci with dev-storage, I found an assertion failure in
+usb_cancel_packet() [1] due to p->state == USB_PACKET_COMPLETE. This is due to
+the inconsistency when resetting device.
+
+``` c
+static inline bool usb_packet_is_inflight(USBPacket *p)
+{
+    return (p->state == USB_PACKET_QUEUED ||
+            p->state == USB_PACKET_ASYNC);
+}
+
+void usb_cancel_packet(USBPacket * p)
+{
+    bool callback = (p->state == USB_PACKET_ASYNC);
+    assert(usb_packet_is_inflight(p)); // <------------------------------- [1]
+    usb_packet_set_state(p, USB_PACKET_CANCELED);
+    QTAILQ_REMOVE(&p->ep->queue, p, queue);
+    if (callback) {
+        usb_device_cancel_packet(p->ep->dev, p);
+    }
+}
+```
+Steps to reproduce:
+Step 1: download the prepared rootfs and the image.
+
+https://drive.google.com/file/d/1B95zWWcomvZt1wms31Ddc9Xwlq-bfqhq/view?usp=sharing
+
+https://drive.google.com/file/d/1pxFzn49MKYmMMIIsaL9aUkzebRSYfq3J/view?usp=sharing
+
+Step 2: run the following script.
+
+``` bash
+QEMU_PATH=../../../qemu/build/qemu-system-x86_64
+KERNEL_PATH=./bzImage
+ROOTFS_PATH=./rootfs.ext2
+$QEMU_PATH \
+    -M q35 -m 1G \
+    -kernel $KERNEL_PATH \
+    -drive file=$ROOTFS_PATH,if=virtio,format=raw \
+    -append "root=/dev/vda console=ttyS0" \
+    -net nic,model=virtio -net user \
+    -usb \
+    -device pci-ohci,num-ports=6 \
+    -drive file=null-co://,if=none,format=raw,id=disk0 \
+    -device usb-storage,port=1,drive=disk0 \
+    -nographic
+```
+
+Step 3: with spawned shell (the user is root and the password is empty), run
+`ohci-03`.
+Additional information:
+1 With crafted ED and TD, we can have the ohci->usb_packet's status to be
+USB_RET_ASYNC [5]. And thus ohci->async_td is not NULL anymore [2].
+
+```
+ed0 = { flags = 0x685f0900, tail = 0x0, head = &td0, next = 0 }
+
+td0 = { flags = 0x0, cbp = 0x1b8ffc, next = 0, be = 0x1b901a }
+# data from cbp to be
+55 53 42 43 00 00 00 00 00 00 00 00 00 00 00 03    USBC............
+e8 56 20 40 e8 56 20 40 e8 56 20 40 e8 56 20
+
+ed1 = { flags = 0x08303080, tail = 0x0, head = &td1, next = 0 }
+
+td1 = { flags = 0x90000000, cbp = 0x19affc, next = 0, be = 0x19b01a }
+# data from cbp to be
+55 53 42 43 00 00 00 00 00 00 00 00 00 00 00 03    USBC............
+e8 56 20 40 e8 56 20 40 e8 56 20 40 e8 56 20
+```
+
+``` c
+static int ohci_service_td(OHCIState *ohci, struct ohci_ed *ed)
+{
+        // ...
+        usb_handle_packet(dev, &ohci->usb_packet); // <------------------- [4]
+        if (ohci->usb_packet.status == USB_RET_ASYNC) {
+            usb_device_flush_ep_queue(dev, ep);
+            ohci->async_td = addr; // <----------------------------------- [2]
+            return 1;
+        }
+```
+
+At the same time, the dev-storage will ref the current usb_packet
+(ohci->usb_packet) [4][3].
+
+```
+static void usb_msd_handle_data(USBDevice *dev, USBPacket *p) {
+        // ...
+        s->packet = p; // <----------------------------------------------- [3]
+        p->status = USB_RET_ASYNC; // <----------------------------------- [5]
+        // ...
+}
+```
+
+2 We can first issue `MMIO_WRITE, 0xe0000054, 0x4, 0x4e33b4bf` to reset
+the dev-storage device. This will mark the state of ohci->usb_packet to
+USB_PACKET_COMPLETE and clear s->packet.
+
+```
+ohci_mem_write
+    ohci_port_set_status
+        usb_device_reset
+            usb_device_handle_reset
+                usb_msd_handle_reset
+                    usb_msd_packet_complete
+                        usb_packet_complete
+```
+
+3  We can then issue `MMIO_WRITE, 0xe0000004, 0x4, 0x3d8d323a` to reset the
+roothub and this will invoke ohci_stop_endpoints() where usb_cancel_packet()
+is invoked and thus [1] fails as the state of ohci->usb_packet has been changed
+to USB_PACKET_COMPLETE.
+
+```
+ohci_set_ctl
+    ohci_roothub_reset
+        ohci_stop_endpoints
+            if (ohci->async_td != NULL) usb_cancel_packet(&ohci->usb_packet);
+            assert(usb_packet_is_inflight(p)); // boom
+```
+
+The above callstack are simplified. The complete callstack is in the following.
+
+```
+ohci_set_ctl
+    ohci_roothub_reset
+        usb_port_reset
+            usb_detach
+                ohci_detach
+                    ohci_child_detach // <-------------------------------- [8]
+            usb_device_reset // <----------------------------------------- [6]
+                usb_device_handle_reset
+                    usb_msd_handle_reset
+                        usb_msd_packet_complete
+                            usb_packet_complete
+        ohci_stop_endpoints // <------------------------------------------ [7]
+            if (ohci->async_td != NULL) usb_cancel_packet(&ohci->usb_packet);
+            assert(usb_packet_is_inflight(p)); // boom
+```
+
+Interestingly, in ohci_roothub_reset(), usb_device_reset() is also invoked [6]
+just like what in step 2. I adjusted my PoC by removing step 2. However, I
+cannot reproduce this assertion failure. Therefore, there is something different
+bewteen [6] and step 2.
+
+Then, I found at [8], ohci_child_detach() cancels the ohci->usb_packet and reset
+ohci->async_td. With step 2, as the status of the ohci->usb_packet has changed
+to USB_PACKET_COMPLETE, usb_cancel_packet() will not be invoked. Without step 2,
+as the status of the ohci->usb_packet is still USB_PACKET_ASYNC,
+usb_cancel_packet() will be invoked and thus everything goes fine.
+
+```
+static void ohci_child_detach(USBPort *port1, USBDevice *dev)
+{
+    OHCIState *ohci = port1->opaque;
+
+    if (ohci->async_td &&
+        usb_packet_is_inflight(&ohci->usb_packet) &&
+        ohci->usb_packet.ep->dev == dev) {
+        usb_cancel_packet(&ohci->usb_packet);
+        ohci->async_td = 0;
+    }
+}
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1181 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1181
new file mode 100644
index 00000000..5fdbf4aa
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1181
@@ -0,0 +1 @@
+Question for AVR experts...
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1182 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1182
new file mode 100644
index 00000000..8f3a8541
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1182
@@ -0,0 +1,69 @@
+Hotplug device(device_add) immediately after starting a virtual machine triggers deadlock.
+Description of problem:
+Sometimes, hotplug device(device_add) immediately after starting a virtual machine triggers deadlock.
+
+Related commits: [7bed8995](https://gitlab.com/qemu-project/qemu/-/commit/7bed89958bfbf40df9ca681cefbdca63abdde39d)
+Steps to reproduce:
+1. start a virtual machine
+
+2. hotplug some device immediately(24 virtio-blk device etc.) 
+
+3. repert step 1 and step 2 for several times, as I tried, deadlock will happen within 100 times.
+Additional information:
+I found similar problem [Issues 650](https://gitlab.com/qemu-project/qemu/-/issues/650)，but problem seems different.
+
+When qemu_main_loop deal with qmp_device_add command which will add a bottom half structure to qemu_aio_context's bh_list. 
+
+At the same time,  UEFI loader writing something to pflash device, address_space_write function get rcu_read_lock and poll aio request. 
+
+Then, it will get the bottom half structure added by qemu_main_loop and go to qmp_device_add function. qmp_device_add function call drain_call_rcu function which will wait for all readers exit. Then it caused a deadlock.
+
+
+
+dead lock thread stack
+
+```
+#0  0x0000ffffb11e8ee4 in syscall () from target:/usr/lib64/libc.so.6
+#1  0x0000aaaadab2ce80 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /Images/jdx/code/qemu/include/qemu/futex.h:29
+#2  qemu_event_wait (ev=ev@entry=0xffff87bfd890) at ../util/qemu-thread-posix.c:429
+#3  0x0000aaaadab35ed0 in drain_call_rcu () at ../util/rcu.c:347
+#4  0x0000aaaada55fa94 in qmp_device_add (qdict=<optimized out>, ret_data=<optimized out>, errp=<optimized out>) at ../softmmu/qdev-monitor.c:866
+#5  0x0000aaaadab1f01c in do_qmp_dispatch_bh (opaque=0xffffaf987ec8) at ../qapi/qmp-dispatch.c:128
+#6  0x0000aaaadab3d1b4 in aio_bh_call (bh=0xffff382d8190) at ../util/async.c:150
+#7  aio_bh_poll (ctx=ctx@entry=0xaaaaf8836ac0) at ../util/async.c:178
+#8  0x0000aaaadab29010 in aio_poll (ctx=ctx@entry=0xaaaaf8836ac0, blocking=blocking@entry=true) at ../util/aio-posix.c:712
+#9  0x0000aaaadaa060e8 in bdrv_poll_co (s=0xffff87bfda58) at /Images/jdx/code/qemu/block/block-gen.h:44
+#10 0x0000aaaadaa07134 in blk_pwrite (blk=0xaaaaf8b82400, offset=offset@entry=197120, bytes=bytes@entry=512, buf=0xffff87c30200, flags=flags@entry=0) at block/block-gen.c:685
+#11 0x0000aaaada35c330 in pflash_update (pfl=pfl@entry=0xaaaaf8b474f0, offset=197120, offset@entry=197124, size=size@entry=4) at ../hw/block/pflash_cfi01.c:395
+#12 0x0000aaaada35e1f8 in pflash_write (be=0, width=4, value=299045890, offset=197124, pfl=0xaaaaf8b474f0) at ../hw/block/pflash_cfi01.c:523
+#13 pflash_mem_write_with_attrs (opaque=0xaaaaf8b474f0, addr=197124, value=299045890, len=4, attrs=...) at ../hw/block/pflash_cfi01.c:682
+#14 0x0000aaaada918cbc in access_with_adjusted_size (addr=addr@entry=197124, value=value@entry=0xffff87bfdbf8, size=4, access_size_min=<optimized out>, access_size_max=<optimized out>, 
+    access_fn=access_fn@entry=0xaaaada91b260 <memory_region_write_with_attrs_accessor>, mr=0xaaaaf8b478b0, attrs=...) at ../softmmu/memory.c:554
+#15 0x0000aaaada91cfc4 in memory_region_dispatch_write (mr=mr@entry=0xaaaaf8b478b0, addr=197124, data=<optimized out>, op=MO_32, attrs=attrs@entry=...) at ../softmmu/memory.c:1520
+#16 0x0000aaaada9245ec in flatview_write_continue (fv=fv@entry=0xffff38492110, addr=addr@entry=67305988, attrs=attrs@entry=..., ptr=ptr@entry=0xffffb1e13028, len=len@entry=4, addr1=<optimized out>, l=<optimized out>, 
+    mr=0xaaaaf8b478b0) at /Images/jdx/code/qemu/include/qemu/host-utils.h:166
+#17 0x0000aaaada924844 in flatview_write (fv=0xffff38492110, addr=addr@entry=67305988, attrs=attrs@entry=..., buf=buf@entry=0xffffb1e13028, len=len@entry=4) at ../softmmu/physmem.c:2867
+#18 0x0000aaaada92825c in address_space_write (len=4, buf=0xffffb1e13028, attrs=..., addr=67305988, as=0xaaaadb4a4670 <address_space_memory>) at ../softmmu/physmem.c:2963
+#19 address_space_rw (as=0xaaaadb4a4670 <address_space_memory>, addr=67305988, attrs=attrs@entry=..., buf=buf@entry=0xffffb1e13028, len=4, is_write=<optimized out>) at ../softmmu/physmem.c:2973
+#20 0x0000aaaada9c7754 in kvm_cpu_exec (cpu=cpu@entry=0xaaaaf8c80530) at ../accel/kvm/kvm-all.c:2954
+#21 0x0000aaaada9c8adc in kvm_vcpu_thread_fn (arg=arg@entry=0xaaaaf8c80530) at ../accel/kvm/kvm-accel-ops.c:49
+#22 0x0000aaaadab2ba98 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:504
+#23 0x0000ffffb118718c in ?? () from target:/usr/lib64/libc.so.6
+#24 0x0000ffffb11ed15c in ?? () from target:/usr/lib64/libc.so.6
+
+```
+
+call_rcu_thread stack
+```
+Thread 2 (Thread 0xffffb0196900 (LWP 1018210) "qemu-system-aar"):
+#0  0x0000ffffb11e8ee4 in syscall () from target:/usr/lib64/libc.so.6
+#1  0x0000aaaadab2ce80 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /Images/jdx/code/qemu/include/qemu/futex.h:29
+#2  qemu_event_wait (ev=ev@entry=0xaaaadb4c3bb8 <rcu_gp_event>) at ../util/qemu-thread-posix.c:429
+#3  0x0000aaaadab35ce8 in wait_for_readers () at ../util/rcu.c:138
+#4  synchronize_rcu () at ../util/rcu.c:174
+#5  0x0000aaaadab36160 in call_rcu_thread (opaque=opaque@entry=0x0) at ../util/rcu.c:268
+#6  0x0000aaaadab2ba98 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:504
+#7  0x0000ffffb118718c in ?? () from target:/usr/lib64/libc.so.6
+#8  0x0000ffffb11ed15c in ?? () from target:/usr/lib64/libc.so.6
+
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1183 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1183
new file mode 100644
index 00000000..fe5df95f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1183
@@ -0,0 +1,131 @@
+KVM crash due to qcow2 out of space condition during virsh-snapshot creation
+Description of problem:
+virsh snapshot failed due to out of space condition (into the qcow2 image ?)
+
+libvirt log:
+
+```
+2022-08-27T06:41:41.164368Z qemu-kvm-one: terminating on signal 15 from pid 1782 (/usr/sbin/libvirtd)
+2022-08-27T06:41:41.172667Z qemu-kvm-one: Failed to flush the L2 table cache: Input/output error
+2022-08-27T06:41:41.172692Z qemu-kvm-one: Failed to flush the refcount block cache: Input/output error
+```
+Steps to reproduce:
+1. not possible for that moment - i did resize/increase the qcow2 image - 
+now its running again.
+Additional information:
+as i saw - there was a very old qemu-snapshot, which was not properly deleted.
+After removing this snapshot, i did reszie the image.
+I do suppose, this could be one reason the image (qcow2) got full ?
+
+Because all is THIN  i was not aware of it (fs level ok, storage layer ok).
+Is there any tool, how free space in a thin qcow2 file can be monitored ?
+
+
+
+```
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+HOME=/var/lib/libvirt/qemu/domain-13-one-89 \
+XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-13-one-89/.local/share \
+XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-13-one-89/.cache \
+XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-13-one-89/.config \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-kvm-one \
+-name guest=one-89,debug-threads=on \
+-S \
+-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-one-89/master-key.aes \
+-machine pc-i440fx-rhel7.6.0,accel=kvm,usb=off,dump-guest-core=off \
+-cpu qemu64 \
+-m 8192 \
+-overcommit mem-lock=off \
+-smp 4,sockets=4,cores=1,threads=1 \
+-uuid 8c920c7f-f687-4c47-bfc7-671425c7436b \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=40,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-device virtio-scsi-pci,id=scsi0,num_queues=1,bus=pci.0,addr=0x4 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
+-blockdev '{"driver":"file","filename":"/var/lib/one//xxxx/disk.0","aio":"threads","node-name":"libvirt-3-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-3-format","read-only":false,"discard":"unmap","cache":{"direct":false,"no-flush":false},"driver":"qcow2","file":"libvirt-3-storage","backing":null}' \
+-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=libvirt-3-format,id=scsi0-0-0-0,bootindex=1,write-cache=off \
+-blockdev '{"driver":"file","filename":"/var/lib/one//xxxx/disk.1","aio":"threads","node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-2-format","read-only":false,"discard":"unmap","cache":{"direct":false,"no-flush":false},"driver":"qcow2","file":"libvirt-2-storage","backing":null}' \
+-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,device_id=drive-scsi0-0-1-0,drive=libvirt-2-format,id=scsi0-0-1-0,write-cache=off \
+-blockdev '{"driver":"file","filename":"/var/lib/one//xxxx/disk.2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-1-format","read-only":true,"driver":"raw","file":"libvirt-1-storage"}' \
+-device ide-cd,bus=ide.0,unit=0,drive=libvirt-1-format,id=ide0-0-0 \
+-netdev tap,fd=42,id=hostnet0 \
+-device e1000,netdev=hostnet0,id=net0,mac=02:00:c0:a8:02:17,bus=pci.0,addr=0x3 \
+-chardev socket,id=charchannel0,fd=43,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-vnc 0.0.0.0:89 \
+-device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
+```
+
+as the time of the crash the qcow2 status was:
+(so i'm not sure the issue is about a space problem or a bug in qemu):
+
+```
+qemu-img info xxx/0/xxx
+image: xxx/0/xxx
+file format: qcow2
+virtual size: 1.46 TiB (1610612736000 bytes)
+disk size: 988 GiB
+cluster_size: 65536
+Snapshot list:
+ID        TAG               VM SIZE                DATE     VM CLOCK     ICOUNT
+112       snap-111              0 B 2022-03-11 01:59:15 49:07:53.846
+282       snap-281              0 B 2022-08-20 01:59:17538:16:30.416
+283       snap-282              0 B 2022-08-21 01:59:16562:10:40.759
+284       snap-283              0 B 2022-08-22 01:59:16585:59:16.170
+285       snap-284              0 B 2022-08-23 01:59:16609:51:44.825
+286       snap-285              0 B 2022-08-24 01:59:16633:45:32.243
+287       snap-286              0 B 2022-08-25 01:59:16657:36:44.718
+288       snap-287              0 B 2022-08-26 01:59:16681:29:00.793
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: false
+    refcount bits: 16
+    corrupt: false
+    extended l2: false
+root@proxpve1:~#  qemu-img check xxxx/0/xxx
+No errors were found on the image.
+15252433/24576000 = 62.06% allocated, 6.32% fragmented, 0.00% compressed clusters
+Image end offset: 1062936117248
+
+1rst (OS) Disk on the VM:
+------------------------------------------
+file format: qcow2
+virtual size: 100 GiB (107374182400 bytes)
+disk size: 190 GiB
+cluster_size: 65536
+Snapshot list:
+ID        TAG               VM SIZE                DATE     VM CLOCK     ICOUNT
+282       snap-281          7.66 GiB 2022-08-20 01:59:17538:16:30.416
+283       snap-282          7.6 GiB 2022-08-21 01:59:16562:10:40.759
+284       snap-283          7.62 GiB 2022-08-22 01:59:16585:59:16.170
+285       snap-284          7.65 GiB 2022-08-23 01:59:16609:51:44.825
+286       snap-285          7.62 GiB 2022-08-24 01:59:16633:45:32.243
+287       snap-286          7.63 GiB 2022-08-25 01:59:16657:36:44.718
+288       snap-287          7.65 GiB 2022-08-26 01:59:16681:29:00.793
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: false
+    refcount bits: 16
+    corrupt: false
+    extended l2: false
+
+
+No errors were found on the image.
+782257/1638400 = 47.75% allocated, 22.16% fragmented, 0.00% compressed clusters
+Image end offset: 315680292864
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1185 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1185
new file mode 100644
index 00000000..8a905402
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1185
@@ -0,0 +1,5 @@
+./configure has unprefixed calls to pkg-config and clang breaking cross-compilation
+Description of problem:
+The configure script (as generated) includes some calls to the toolchain without including cross compiler prefixes. This can very easily break cross compilation. Here are the locations:
+
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1186 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1186
new file mode 100644
index 00000000..5d75aa24
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1186
@@ -0,0 +1,17 @@
+qos-test fails when built with LTO and gcc-12
+Description of problem:
+The issue is already discussed here [1]. I'm simply building latest QEMU release and running the test suite. I thought the issue was fixed in 7.0 but it has resurfaced. Do QEMU dev's not build with LTO? I'm not able to debug this but I can test any proposed fixes etc. Thanks.
+
+[1] https://lore.kernel.org/all/1d3bbff9e92e7c8a24db9e140dcf3f428c2df103.camel@suse.com/
+Steps to reproduce:
+1. Build QEMU with gcc-12 and LTO enabled
+2. Run make check
+3. Observe test suite failures in qos-test
+Additional information:
+```
+Summary of Failures:
+
+  2/265 qemu:qtest+qtest-aarch64 / qtest-aarch64/qos-test                  ERROR           0.59s   killed by signal 6 SIGABRT
+  3/265 qemu:qtest+qtest-i386 / qtest-i386/qos-test                        ERROR           0.22s   killed by signal 6 SIGABRT
+  7/265 qemu:qtest+qtest-x86_64 / qtest-x86_64/qos-test                    ERROR           0.40s   killed by signal 6 SIGABRT
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1187 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1187
new file mode 100644
index 00000000..6322ce70
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1187
@@ -0,0 +1 @@
+can not handler real-time signal (signal number > 30) by sigqueue on linux user mode
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1188 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1188
new file mode 100644
index 00000000..6cb0f38e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1188
@@ -0,0 +1,4 @@
+qapi: add support to default value for optional members
+Additional information:
+This is a proposal to the QAPI spec itself to have a simple way to express that
+an absent member defaults to a value.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1189 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1189
new file mode 100644
index 00000000..6ac75b29
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1189
@@ -0,0 +1 @@
+Cannot Resolve Names When Host Is Running Systemd-Resolved
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/119 b/gitlab/issues_text/target_missing/host_missing/accel_missing/119
new file mode 100644
index 00000000..88301171
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/119
@@ -0,0 +1 @@
+USB assert failure on hcd-uhci.c
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1190 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1190
new file mode 100644
index 00000000..b388b857
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1190
@@ -0,0 +1 @@
+compiling v7.1 with --static fails with "/usr/bin/ld: cannot find -lmount"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1191 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1191
new file mode 100644
index 00000000..e5acab8c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1191
@@ -0,0 +1,9 @@
+AC97+CoreAudio no audio when out frequency not 44,1KHz & always forces host to use 44,1KHz (or less if frequency not supported)
+Description of problem:
+AC97+CoreAudio outputs no audio when output frequency not 44,1KHz. Also always forces host to use 44,1KHz (or less if frequency not supported on host output)
+Steps to reproduce:
+1. Boot any OS with (only) AC97 audio on macOS
+2. Attempt to play audio with output frequency in guest set to 48KHz
+3. Observe lack of output
+Additional information:
+I'm using QEMU to test a Custom OS written by me, but this shouldn't be a code issue on our side, rather an issue with QEMU itself, if this is mistaken, please inform us.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1192 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1192
new file mode 100644
index 00000000..2400b01e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1192
@@ -0,0 +1,135 @@
+Abort in xhci_find_stream()
+Description of problem:
+I triggered an abort in xhci_find_stream() [1]. This is because the
+secondary stream arrays is enabled by setting linear stream array (LSA) bit (in
+endpoint context) to 0. We may show warnings and drop this operation.
+
+``` c
+static XHCIStreamContext *xhci_find_stream(XHCIEPContext *epctx,
+                                           unsigned int streamid,
+                                           uint32_t *cc_error)
+{
+    // ...
+    if (epctx->lsa) {
+        // ...
+    } else {
+        FIXME("secondary streams not implemented yet"); // <----------- [1]
+    }
+    // ...
+```
+Steps to reproduce:
+Step 1: download the prepared rootfs and the image.
+
+https://drive.google.com/file/d/10C2110VH-GrwACiPebC8-Vgcf5_Ny8Sd/view?usp=sharing
+https://drive.google.com/file/d/1jAMf8rtTM8p88gamhNk4HC5Z34XtjUHw/view?usp=sharing
+
+Step 2: run the following script.
+
+``` bash
+QEMU_PATH=../../../qemu/build/qemu-system-x86_64
+KERNEL_PATH=./bzImage
+ROOTFS_PATH=./rootfs.ext2
+$QEMU_PATH \
+    -M q35 -m 1G \
+    -kernel $KERNEL_PATH \
+    -drive file=$ROOTFS_PATH,if=virtio,format=raw \
+    -append "root=/dev/vda console=ttyS0" \
+    -net nic,model=virtio -net user \
+    -drive file=null-co://,if=none,format=raw,id=disk0 \
+    -device qemu-xhci,id=xhci -device usb-storage,drive=disk0 \
+    -device usb-bot -device usb-tablet,bus=xhci.0 \
+    -chardev null,id=cd0 -chardev null,id=cd1 \
+    -device usb-braille,chardev=cd0 -device usb-ccid -device usb-ccid \
+    -device usb-kbd -device usb-mouse -device usb-serial,chardev=cd1 \
+    -device usb-tablet -device usb-wacom-tablet -device usb-audio \
+    -nographic
+```
+
+Step 3: with spawned shell (the user is root and the password is empty), run
+`xhci-00`.
+Additional information:
+```
+root@5b4fda3ee725:~/videzzo/videzzo_qemu/out-san# DEFAULT_INPUT_MAXSIZE=10000000 /root/videzzo/videzzo_qemu/out-san/qemu-videzzo-i386-target-videzzo-fuzz-xhci  -max_len=10000000 -detect_leaks=0 poc-qemu-videzzo-i386-target-videzzo-fuzz-xhci-crash-4a11736abb111efe4b29a6931f403561f9a0f9ec
+==71545==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x55e05e05e640). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 2668437424
+INFO: Loaded 1 modules   (423456 inline 8-bit counters): 423456 [0x55e0606e8000, 0x55e06074f620), 
+INFO: Loaded 1 PC tables (423456 PCs): 423456 [0x55e060071ae0,0x55e0606e7ce0), 
+/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-i386-target-videzzo-fuzz-xhci: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+Matching objects by name , *capabilities*, *operational*, *runtime*, *doorbell*, *usb3 port*
+This process will fuzz the following MemoryRegions:
+  * usb3 port #1[0] (size 10)
+  * usb3 port #4[0] (size 10)
+  * capabilities[0] (size 40)
+  * usb3 port #3[0] (size 10)
+  * operational[0] (size 400)
+  * usb3 port #2[0] (size 10)
+  * runtime[0] (size 220)
+  * doorbell[0] (size 820)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * capabilities, EVENT_TYPE_MMIO_READ, 0xe0000000 +0x40, 4,4
+  * capabilities, EVENT_TYPE_MMIO_WRITE, 0xe0000000 +0x40, 4,4
+  * operational, EVENT_TYPE_MMIO_READ, 0xe0000040 +0x400, 4,8
+  * operational, EVENT_TYPE_MMIO_WRITE, 0xe0000040 +0x400, 4,8
+  * runtime, EVENT_TYPE_MMIO_READ, 0xe0001000 +0x220, 4,8
+  * runtime, EVENT_TYPE_MMIO_WRITE, 0xe0001000 +0x220, 4,8
+  * doorbell, EVENT_TYPE_MMIO_READ, 0xe0002000 +0x820, 4,4
+  * doorbell, EVENT_TYPE_MMIO_WRITE, 0xe0002000 +0x820, 4,4
+  * usb3 port #4, EVENT_TYPE_MMIO_READ, 0xe0000470 +0x10, 4,4
+  * usb3 port #4, EVENT_TYPE_MMIO_WRITE, 0xe0000470 +0x10, 4,4
+  * usb3 port #1, EVENT_TYPE_MMIO_READ, 0xe0000440 +0x10, 4,4
+  * usb3 port #1, EVENT_TYPE_MMIO_WRITE, 0xe0000440 +0x10, 4,4
+  * usb3 port #2, EVENT_TYPE_MMIO_READ, 0xe0000450 +0x10, 4,4
+  * usb3 port #2, EVENT_TYPE_MMIO_WRITE, 0xe0000450 +0x10, 4,4
+  * usb3 port #3, EVENT_TYPE_MMIO_READ, 0xe0000460 +0x10, 4,4
+  * usb3 port #3, EVENT_TYPE_MMIO_WRITE, 0xe0000460 +0x10, 4,4
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 197Mb
+Running: poc-qemu-videzzo-i386-target-videzzo-fuzz-xhci-crash-4a11736abb111efe4b29a6931f403561f9a0f9ec
+../hw/usb/hcd-xhci.c:1099:25: runtime error: shift exponent 156 is too large for 32-bit type 'int'
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/usb/hcd-xhci.c:1099:25 in 
+FIXME xhci_find_stream:998 secondary streams not implemented yet
+==71545== ERROR: libFuzzer: deadly signal
+    #0 0x55e05a7f874e in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
+    #1 0x55e05a7473c1 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x55e05a720c06 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:235:18
+    #3 0x55e05a720cd2 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:1
+    #4 0x55e05a720cd2 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:206:19
+    #5 0x7fa0b025c41f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f)
+    #6 0x7fa0b006e00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+    #7 0x7fa0b006e00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+    #8 0x7fa0b004d858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
+    #9 0x55e05a828c9a in __wrap_abort /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/less_crashes_wrappers.c:24:12
+    #10 0x55e05bd528c3 in xhci_find_stream /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/usb/hcd-xhci.c:998:9
+    #11 0x55e05bd46ca5 in xhci_kick_epctx /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/usb/hcd-xhci.c:1922:17
+    #12 0x55e05bd7d7ff in xhci_kick_ep /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/usb/hcd-xhci.c:1838:5
+    #13 0x55e05bd94ab9 in xhci_doorbell_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/usb/hcd-xhci.c:3163:13
+    #14 0x55e05cfed443 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5
+    #15 0x55e05cfecd81 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18
+    #16 0x55e05cfeb68c in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16
+    #17 0x55e05d0760be in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23
+    #18 0x55e05d06443b in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12
+    #19 0x55e05d063ef8 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18
+    #20 0x55e05a83813b in qemu_writel /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1072:5
+    #21 0x55e05a8365b5 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1197:28
+    #22 0x55e05e059fff in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5
+    #23 0x55e05e05137b in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9
+    #24 0x55e05e051250 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9
+    #25 0x55e05a83f17c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1472:12
+    #26 0x55e05e05e8e2 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18
+    #27 0x55e05a72173d in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:589:17
+    #28 0x55e05a7044c4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #29 0x55e05a70f43e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:882:19
+    #30 0x55e05a6fba46 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #31 0x7fa0b004f082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #32 0x55e05a6fba9d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-i386-target-videzzo-fuzz-xhci+0x265aa9d)
+
+NOTE: libFuzzer has rudimentary signal handlers.
+      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
+SUMMARY: libFuzzer: deadly signal
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1193 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1193
new file mode 100644
index 00000000..67f62c2a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1193
@@ -0,0 +1,16 @@
+io_uring / iothread regression 7.1.0
+Description of problem:
+After upgrading to 7.1.0, some of my libvirt VM's failed to boot. I have narrowed down the issue to the combination of:
+
+- io_uring
+- iothread
+Steps to reproduce:
+1. set up a VM with iothread and io_uring
+2. try to boot and watch it "hang"
+Additional information:
+Here's the relevant command line from the libvirt log:
+```
+-blockdev '{"driver":"file","filename":"/mnt/data/VMs/Arch-Linux-x86_64-basic.qcow2","aio":"io_uring","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \
+-device '{"driver":"virtio-blk-pci","iothread":"iothread1","bus":"pci.4","addr":"0x0","drive":"libvirt-1-format","id":"virtio-disk0","bootindex":1 }' \
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1194 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1194
new file mode 100644
index 00000000..65eb7ea2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1194
@@ -0,0 +1,15 @@
+Initialization of device virtio-net-pci failed: failed to find romfile "efi-virtio.rom"
+Description of problem:
+After executing the below command inside adb shell
+qemu-system-aarch64 -enable-kvm -nographic \
+-kernel Image -initrd ramdisk.img -m 512 -M virt -cpu host \
+
+I am getting the below error
+"qemu-system-aarch64: Initialization of device virtio-net-pci failed: failed to find romfile "efi-virtio.rom""
+Steps to reproduce:
+1. adb Push qemu-system-aarch64 inside system/bin
+2. Run 
+qemu-system-aarch64 -enable-kvm -nographic \
+-kernel Image -initrd ramdisk.img -m 512 -M virt -cpu host \
+Additional information:
+Kindly help me to proceed further
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1195 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1195
new file mode 100644
index 00000000..51cbde9b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1195
@@ -0,0 +1,18 @@
+Race condition during QEMU exit cleanup can lead to deadlock
+Description of problem:
+During the cleanup phase of QEMU exiting, there is a small race condition window that can lead QEMU to lock up completely:
+In the main QEMU thread, during the exit, the thread will execute the 'qemu_cleanup' function, which calls 'do_vm_stop', which calls 'pause_all_vcpus'. This method tries to (as the name suggests) stop/pause all the vcpu threads. At the same time, the vcpu thread might have just existed it's main mttcg exec loop, which means it will enter 'qemu_wait_io_event'. At this point, the following race condition can occur:
+- vcpu_thread - cpus.c:416 <= enters qemu_wait_io_event
+- shutdown_thread - cpus.c:555 <= enters pause_all_vcpus
+- vcpu_thread - cpus.c:418 <= cpu_thread_is_idle returns true, cpu->stop not set yet
+- shutdown_thread - cpus.c:560/561 <= sets cpu->stop and kicks the vcpu, but it's not waiting on cpu->halt_cond yet, so nothing happens
+- vcpu_thread - cpus.c:423 <= starts waiting on cpu->halt_cond
+- shutdown_thread - cpus.c:570 <= not all vcpus paused, so enters while loop
+- shutdown_thread - cpus.c:571 <= starts waiting on qemu_pause_cond
+- **deadlock**
+
+In my case, my plugin registers qemu_plugin_vcpu_idle_cb, so the race window is extended significantly in the vcpu thread (cpus.c:421) but I believe it can happen with the smaller race window as well.
+
+Note that this explanation is just based on my understanding of the code, and the final state of QEMU during the deadlock after I attached: The main thread (thread 1) was waiting on qemu_pause_cond in pause_all_vcpus, and the vcpu was waiting on cpu->halt_cond in qemu_wait_io_event, with no one else to wake either of them up. (This was following an exit that was triggered by a timeout signal)
+Steps to reproduce:
+This is a race condition, so I don't have a reliable reproducer.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1196 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1196
new file mode 100644
index 00000000..7862ffe2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1196
@@ -0,0 +1,12 @@
+Guest could not enable pci AtomicOp requests for passthrough device
+Description of problem:
+Guest could not enable pci AtomicOp requests for passthrough device. 
+
+sudo setpci -v -d *:706t 8c.b=40 // enable pci AtomicOp requests bit in the guest os.
+
+Host could not see the bit by command "sudo lspci -vvv -s 03:00.0".
+Steps to reproduce:
+1. sudo setpci -v -d *:706t 8c.b=40 // in the guest os
+2. sudo lspci -vvv -s 03:00.0 // in the host os
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1197 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1197
new file mode 100644
index 00000000..14878694
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1197
@@ -0,0 +1,815 @@
+Use libvirt to create a Windows virtual machine and load NVIDIA's GPU. Installing NVIDIA driver causes the physical machine to restart
+Description of problem:
+As described in the title, When I created a Windows virtual machine and used NVIDIA's GPU and installed NVIDIA's driver in Windows VM, however, the physical machine will be restart. In the same create time, if it is a linux  VM, It's ok! I don't know if there is a problem with my creation process or if the windows virtual machine is incompatible with NVIDIA graphics card.
+
+
+GPU INFO: 
+```
+81:00.0 VGA compatible controller: NVIDIA Corporation GP106GL [Quadro P2000] (rev a1)
+81:00.1 Audio device: NVIDIA Corporation GP106 High Definition Audio Controller (rev a1)
+```
+
+
+BR！
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+qemu info:
+```
+libvirt-daemon-driver-qemu-4.5.0-36.el7_9.5.x86_64
+ipxe-roms-qemu-20180825-3.git133f4c.el7.noarch
+qemu-kvm-common-1.5.3-175.el7_9.6.x86_64
+qemu-kvm-1.5.3-175.el7_9.6.x86_64
+qemu-img-1.5.3-175.el7_9.6.x86_64
+```
+
+
+
+```
+<domain type="kvm">
+  <name>win</name>
+  <uuid>a5efd8ed-fa6f-693c-2202-93183ec18b5e</uuid>
+  <description>None</description>
+  <memory unit="KiB">5242880</memory>
+  <currentMemory unit="KiB">5242880</currentMemory>
+  <vcpu placement="static">4</vcpu>
+  <os>
+    <type arch="x86_64" machine="pc-i440fx-rhel7.0.0">hvm</type>
+    <boot dev="hd"/>
+    <boot dev="cdrom"/>
+    <bootmenu enable="yes"/>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+    <pae/>
+  </features>
+  <cpu mode="host-passthrough" check="none"/>
+  <clock offset="utc"/>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>restart</on_crash>
+  <devices>
+    <emulator>/usr/libexec/qemu-kvm</emulator>
+    <disk type="file" device="disk">
+      <driver name="qemu" type="qcow2"/>
+      <source file="/opt/panafs/1374467833802939042/win.img"/>
+      <target dev="sda" bus="sata"/>
+      <address type="drive" controller="0" bus="0" target="0" unit="0"/>
+    </disk>
+    <disk type="file" device="cdrom">
+      <driver name="qemu" type="raw"/>
+      <source file="/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso"/>
+      <target dev="hda" bus="ide"/>
+      <readonly/>
+      <address type="drive" controller="0" bus="1" target="0" unit="1"/>
+    </disk>
+    <disk type="file" device="cdrom">
+      <driver name="qemu" type="raw"/>
+      <source file="/var/lib/libvirt/images/virtio-win-0.1.217.iso"/>
+      <target dev="hdb" bus="ide"/>
+      <readonly/>
+      <address type="drive" controller="0" bus="0" target="0" unit="1"/>
+    </disk>
+    <controller type="usb" index="0" model="piix3-uhci">
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x2"/>
+    </controller>
+    <controller type="pci" index="0" model="pci-root"/>
+    <controller type="ide" index="0">
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x1"/>
+    </controller>
+    <controller type="sata" index="0">
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x04" function="0x0"/>
+    </controller>
+    <controller type="virtio-serial" index="0">
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x05" function="0x0"/>
+    </controller>
+    <interface type="network">
+      <mac address="52:54:00:1d:d8:7d"/>
+      <source network="default"/>
+      <model type="virtio"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0"/>
+    </interface>
+    <interface type="network">
+      <mac address="52:54:00:09:bc:30"/>
+      <source network="default"/>
+      <model type="e1000"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x09" function="0x0"/>
+    </interface>
+    <serial type="pty">
+      <target type="isa-serial" port="0">
+        <model name="isa-serial"/>
+      </target>
+    </serial>
+    <console type="pty">
+      <target type="serial" port="0"/>
+    </console>
+    <channel type="unix">
+      <target type="virtio" name="org.qemu.guest_agent.0"/>
+      <address type="virtio-serial" controller="0" bus="0" port="2"/>
+    </channel>
+    <input type="mouse" bus="ps2"/>
+    <input type="tablet" bus="usb">
+      <address type="usb" bus="0" port="1"/>
+    </input>
+    <input type="keyboard" bus="ps2"/>
+    <graphics type="vnc" port="-1" autoport="yes">
+      <listen type="address"/>
+    </graphics>
+    <video>
+      <model type="cirrus" vram="16384" heads="1" primary="yes"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0"/>
+    </video>
+    <hostdev mode="subsystem" type="pci" managed="yes">
+      <source>
+        <address domain="0x0000" bus="0x81" slot="0x00" function="0x0"/>
+      </source>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/>
+    </hostdev>
+    <hostdev mode="subsystem" type="pci" managed="yes">
+      <source>
+        <address domain="0x0000" bus="0x81" slot="0x00" function="0x1"/>
+      </source>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x08" function="0x0"/>
+    </hostdev>
+    <memballoon model="virtio">
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x06" function="0x0"/>
+    </memballoon>
+  </devices>
+</domain>
+```
+
+
+
+part log of VM:
+
+```
+2022-09-05 07:12:51.328+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu
+-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name win \
+-S \
+-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \
+-cpu host \
+-m 5120 \
+-realtime mlock=off \
+-smp 4,sockets=4,cores=1,threads=1 \
+-uuid 49f538e1-4042-bbc4-1b2c-10f02219bba5 \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-win/monitor.sock,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot menu=on,strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
+-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-scsi0-0-0-0 \
+-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 \
+-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \
+-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \
+-netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:78:1a:32,bus=pci.0,addr=0x3 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-3-win/org.qemu.guest_agent.0,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-device usb-tablet,id=input1,bus=usb.0,port=1 \
+-vnc 0.0.0.0:0 \
+-vga cirrus \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-msg timestamp=on
+2022-09-05 07:12:51.328+0000: Domain id=3 is tainted: host-cpu
+char device redirected to /dev/pts/4 (label charserial0)
+qemu: terminating on signal 15 from pid 3723
+2022-09-05 07:14:02.309+0000: shutting down, reason=destroyed
+2022-09-05 07:14:35.696+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu
+-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name win \
+-S \
+-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \
+-cpu host \
+-m 5120 \
+-realtime mlock=off \
+-smp 4,sockets=4,cores=1,threads=1 \
+-uuid abcbac3c-fd61-57ac-f1ad-60387881c0a6 \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-win/monitor.sock,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot menu=on,strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 \
+-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-virtio-disk0 \
+-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \
+-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \
+-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \
+-netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:94:04:a7,bus=pci.0,addr=0x3 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-4-win/org.qemu.guest_agent.0,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-device usb-tablet,id=input1,bus=usb.0,port=1 \
+-vnc 0.0.0.0:0 \
+-vga cirrus \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-msg timestamp=on
+2022-09-05 07:14:35.696+0000: Domain id=4 is tainted: host-cpu
+char device redirected to /dev/pts/4 (label charserial0)
+qemu: terminating on signal 15 from pid 3723
+2022-09-05 07:15:54.690+0000: shutting down, reason=destroyed
+2022-09-05 07:16:18.098+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu
+-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name win \
+-S \
+-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \
+-cpu host \
+-m 5120 \
+-realtime mlock=off \
+-smp 4,sockets=4,cores=1,threads=1 \
+-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-win/monitor.sock,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot menu=on,strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-device ahci,id=sata0,bus=pci.0,addr=0x4 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
+-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \
+-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \
+-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \
+-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \
+-netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-5-win/org.qemu.guest_agent.0,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-device usb-tablet,id=input1,bus=usb.0,port=1 \
+-vnc 0.0.0.0:0 \
+-vga cirrus \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-msg timestamp=on
+2022-09-05 07:16:18.098+0000: Domain id=5 is tainted: host-cpu
+char device redirected to /dev/pts/4 (label charserial0)
+qemu: terminating on signal 15 from pid 3723
+2022-09-05 07:33:42.873+0000: shutting down, reason=destroyed
+2022-09-05 07:37:05.200+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu
+-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name win \
+-S \
+-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \
+-cpu host \
+-m 5120 \
+-realtime mlock=off \
+-smp 4,sockets=4,cores=1,threads=1 \
+-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-6-win/monitor.sock,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot menu=on,strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-device ahci,id=sata0,bus=pci.0,addr=0x4 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
+-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \
+-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \
+-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \
+-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \
+-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=32 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-6-win/org.qemu.guest_agent.0,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-device usb-tablet,id=input1,bus=usb.0,port=1 \
+-vnc 0.0.0.0:0 \
+-vga cirrus \
+-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \
+-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-msg timestamp=on
+2022-09-05 07:37:05.200+0000: Domain id=6 is tainted: host-cpu
+char device redirected to /dev/pts/4 (label charserial0)
+qemu: terminating on signal 15 from pid 3723
+2022-09-05 07:37:37.578+0000: shutting down, reason=destroyed
+2022-09-05 07:37:44.799+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu
+-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name win \
+-S \
+-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \
+-cpu host \
+-m 5120 \
+-realtime mlock=off \
+-smp 4,sockets=4,cores=1,threads=1 \
+-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-7-win/monitor.sock,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot menu=on,strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-device ahci,id=sata0,bus=pci.0,addr=0x4 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
+-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \
+-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \
+-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \
+-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \
+-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=32 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \
+-netdev tap,fd=33,id=hostnet1 \
+-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-7-win/org.qemu.guest_agent.0,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-device usb-tablet,id=input1,bus=usb.0,port=1 \
+-vnc 0.0.0.0:0 \
+-vga cirrus \
+-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \
+-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-msg timestamp=on
+2022-09-05 07:37:44.799+0000: Domain id=7 is tainted: host-cpu
+char device redirected to /dev/pts/4 (label charserial0)
+qemu: terminating on signal 15 from pid 3723
+2022-09-05 07:49:11.497+0000: shutting down, reason=destroyed
+2022-09-05 07:49:34.883+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu
+-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name win \
+-S \
+-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \
+-cpu host \
+-m 5120 \
+-realtime mlock=off \
+-smp 4,sockets=4,cores=1,threads=1 \
+-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-8-win/monitor.sock,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot menu=on,strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-device ahci,id=sata0,bus=pci.0,addr=0x4 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
+-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \
+-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \
+-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \
+-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \
+-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=32 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \
+-netdev tap,fd=33,id=hostnet1 \
+-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-8-win/org.qemu.guest_agent.0,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-device usb-tablet,id=input1,bus=usb.0,port=1 \
+-vnc 0.0.0.0:0 \
+-vga cirrus \
+-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \
+-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-msg timestamp=on
+2022-09-05 07:49:34.883+0000: Domain id=8 is tainted: host-cpu
+char device redirected to /dev/pts/4 (label charserial0)
+2022-09-05 08:08:31.206+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu
+-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name win \
+-S \
+-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \
+-cpu host \
+-m 5120 \
+-realtime mlock=off \
+-smp 4,sockets=4,cores=1,threads=1 \
+-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-win/monitor.sock,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot menu=on,strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-device ahci,id=sata0,bus=pci.0,addr=0x4 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
+-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \
+-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \
+-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \
+-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \
+-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \
+-netdev tap,fd=29,id=hostnet1 \
+-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-1-win/org.qemu.guest_agent.0,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-device usb-tablet,id=input1,bus=usb.0,port=1 \
+-vnc 0.0.0.0:0 \
+-vga cirrus \
+-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \
+-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-msg timestamp=on
+2022-09-05 08:08:31.206+0000: Domain id=1 is tainted: host-cpu
+char device redirected to /dev/pts/1 (label charserial0)
+qemu: terminating on signal 15 from pid 15043
+2022-09-06 02:39:26.089+0000: shutting down, reason=destroyed
+2022-09-06 02:39:32.783+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu
+-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name win \
+-S \
+-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \
+-cpu host \
+-m 5120 \
+-realtime mlock=off \
+-smp 4,sockets=4,cores=1,threads=1 \
+-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-7-win/monitor.sock,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot menu=on,strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-device ahci,id=sata0,bus=pci.0,addr=0x4 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
+-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \
+-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \
+-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-sata0-0-1,media=cdrom,readonly=on \
+-device ide-cd,bus=sata0.1,drive=drive-sata0-0-1,id=sata0-0-1,bootindex=2 \
+-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \
+-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 \
+-netdev tap,fd=31,id=hostnet0,vhost=on,vhostfd=33 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \
+-netdev tap,fd=34,id=hostnet1 \
+-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-7-win/org.qemu.guest_agent.0,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-device usb-tablet,id=input1,bus=usb.0,port=1 \
+-vnc 0.0.0.0:0 \
+-vga cirrus \
+-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \
+-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-msg timestamp=on
+2022-09-06 02:39:32.783+0000: Domain id=7 is tainted: host-cpu
+char device redirected to /dev/pts/1 (label charserial0)
+qemu: terminating on signal 15 from pid 15043
+2022-09-06 02:40:52.065+0000: shutting down, reason=destroyed
+2022-09-06 02:41:03.281+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu
+-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name win \
+-S \
+-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \
+-cpu host \
+-m 5120 \
+-realtime mlock=off \
+-smp 4,sockets=4,cores=1,threads=1 \
+-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-8-win/monitor.sock,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot menu=on,strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-device ahci,id=sata0,bus=pci.0,addr=0x4 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
+-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \
+-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \
+-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \
+-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \
+-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \
+-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \
+-netdev tap,fd=31,id=hostnet0,vhost=on,vhostfd=33 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \
+-netdev tap,fd=34,id=hostnet1 \
+-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-8-win/org.qemu.guest_agent.0,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-device usb-tablet,id=input1,bus=usb.0,port=1 \
+-vnc 0.0.0.0:0 \
+-vga cirrus \
+-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \
+-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-msg timestamp=on
+2022-09-06 02:41:03.281+0000: Domain id=8 is tainted: host-cpu
+char device redirected to /dev/pts/1 (label charserial0)
+2022-09-06 03:08:33.510+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu
+-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name win \
+-S \
+-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \
+-cpu host \
+-m 5120 \
+-realtime mlock=off \
+-smp 4,sockets=4,cores=1,threads=1 \
+-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \
+-display none \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-win/monitor.sock,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot menu=on,strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-device ahci,id=sata0,bus=pci.0,addr=0x4 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
+-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \
+-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \
+-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \
+-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \
+-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \
+-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \
+-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \
+-netdev tap,fd=29,id=hostnet1 \
+-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-1-win/org.qemu.guest_agent.0,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-device usb-tablet,id=input1,bus=usb.0,port=1 \
+-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \
+-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-msg timestamp=on
+2022-09-06 03:08:33.510+0000: Domain id=1 is tainted: host-cpu
+char device redirected to /dev/pts/1 (label charserial0)
+qemu: terminating on signal 15 from pid 15135
+2022-09-06 03:09:18.992+0000: shutting down, reason=destroyed
+2022-09-06 03:09:52.805+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu
+-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+QEMU_AUDIO_DRV=spice \
+/usr/libexec/qemu-kvm \
+-name win \
+-S \
+-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \
+-cpu host \
+-m 5120 \
+-realtime mlock=off \
+-smp 4,sockets=4,cores=1,threads=1 \
+-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-win/monitor.sock,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot menu=on,strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-device ahci,id=sata0,bus=pci.0,addr=0x4 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
+-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \
+-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \
+-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \
+-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \
+-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \
+-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \
+-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \
+-netdev tap,fd=29,id=hostnet1 \
+-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-2-win/org.qemu.guest_agent.0,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-device usb-tablet,id=input1,bus=usb.0,port=1 \
+-spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on \
+-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \
+-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-msg timestamp=on
+2022-09-06 03:09:52.805+0000: Domain id=2 is tainted: host-cpu
+char device redirected to /dev/pts/1 (label charserial0)
+
+(process:102539): Spice-WARNING **: 11:09:53.755: display-channel.c:2435:display_channel_validate_surface: canvas address is 0x55603dfbbb08 for 0 (and is NULL)
+
+
+(process:102539): Spice-WARNING **: 11:09:53.755: display-channel.c:2436:display_channel_validate_surface: failed on 0
+
+(process:102539): Spice-WARNING **: 11:09:53.755: red-worker.c:553:destroy_primary_surface: double destroy of primary surface
+
+(process:102539): Spice-WARNING **: 11:09:53.756: display-channel.c:2159:display_channel_create_surface: condition `!surface->context.canvas' failed
+main_channel_link: add main channel client
+main_channel_client_handle_pong: net test: latency 0.784000 ms, bitrate 50996015 bps (48.633590 Mbps)
+red_qxl_set_cursor_peer: 
+inputs_connect: inputs channel client create
+qemu: terminating on signal 15 from pid 15135
+2022-09-06 03:10:27.167+0000: shutting down, reason=destroyed
+2022-09-06 03:10:39.556+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu
+-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name win \
+-S \
+-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \
+-cpu host \
+-m 5120 \
+-realtime mlock=off \
+-smp 4,sockets=4,cores=1,threads=1 \
+-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-win/monitor.sock,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot menu=on,strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-device ahci,id=sata0,bus=pci.0,addr=0x4 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
+-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \
+-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \
+-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \
+-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \
+-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \
+-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \
+-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \
+-netdev tap,fd=29,id=hostnet1 \
+-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-3-win/org.qemu.guest_agent.0,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-device usb-tablet,id=input1,bus=usb.0,port=1 \
+-vnc 127.0.0.1:0 \
+-vga cirrus \
+-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \
+-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-msg timestamp=on
+2022-09-06 03:10:39.556+0000: Domain id=3 is tainted: host-cpu
+char device redirected to /dev/pts/1 (label charserial0)
+qemu: terminating on signal 15 from pid 15135
+2022-09-06 03:50:33.032+0000: shutting down, reason=destroyed
+2022-09-06 03:54:03.923+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu
+-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name win \
+-S \
+-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \
+-cpu host \
+-m 5120 \
+-realtime mlock=off \
+-smp 4,sockets=4,cores=1,threads=1 \
+-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-6-win/monitor.sock,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot menu=on,strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-device ahci,id=sata0,bus=pci.0,addr=0x4 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
+-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \
+-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \
+-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \
+-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \
+-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \
+-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \
+-netdev tap,fd=31,id=hostnet0,vhost=on,vhostfd=36 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \
+-netdev tap,fd=37,id=hostnet1 \
+-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-6-win/org.qemu.guest_agent.0,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-device usb-tablet,id=input1,bus=usb.0,port=1 \
+-vnc 127.0.0.1:0 \
+-vga cirrus \
+-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \
+-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-msg timestamp=on
+2022-09-06 03:54:03.923+0000: Domain id=6 is tainted: host-cpu
+char device redirected to /dev/pts/1 (label charserial0)
+2022-09-06 04:16:48.831+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu
+-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+QEMU_AUDIO_DRV=none \
+/usr/libexec/qemu-kvm \
+-name win \
+-S \
+-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \
+-cpu host \
+-m 5120 \
+-realtime mlock=off \
+-smp 4,sockets=4,cores=1,threads=1 \
+-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-win/monitor.sock,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot menu=on,strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-device ahci,id=sata0,bus=pci.0,addr=0x4 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
+-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \
+-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \
+-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \
+-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \
+-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \
+-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \
+-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \
+-netdev tap,fd=30,id=hostnet1 \
+-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-1-win/org.qemu.guest_agent.0,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-device usb-tablet,id=input1,bus=usb.0,port=1 \
+-vnc 127.0.0.1:0 \
+-vga cirrus \
+-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \
+-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-msg timestamp=on
+2022-09-06 04:16:48.831+0000: Domain id=1 is tainted: host-cpu
+char device redirected to /dev/pts/1 (label charserial0)
+qemu: terminating on signal 15 from pid 15130
+2022-09-06 07:52:07.759+0000: shutting down, reason=destroyed
+
+
+
+
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1199 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1199
new file mode 100644
index 00000000..ac6eaef1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1199
@@ -0,0 +1,10 @@
+Prevent virtual machine memory leakage
+Description of problem:
+The data written in the virtual machine does not clear the memory after the virtual machine is shut down. When the virtual machine with large memory is started, it may access the data of the previous virtual machine
+Steps to reproduce:
+1. create a virtual machine with large size memory( 80% of the host's Physical memory)
+2. Request all free memory and write the characteristic string in vm
+3. restart the vm
+4. Request all free memory and query the last character string written
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/120 b/gitlab/issues_text/target_missing/host_missing/accel_missing/120
new file mode 100644
index 00000000..64b1f1f6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/120
@@ -0,0 +1 @@
+Please provide an option to print the default hardware configuration as command-line options, to make -nodefaults easier to use
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1200 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1200
new file mode 100644
index 00000000..f04478dd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1200
@@ -0,0 +1,25 @@
+always zero when query-dirty-rate
+Description of problem:
+The creation of VM works well(by virt-install), and I can enter it by 'virsh console or ssh'.
+
+Now, I try to use qemu's feature: calc-dirty-rate.
+
+But, always get '"dirty-rate":0' when 'query-dirty-rate', occasionally '"dirty-rate":2'.
+
+At the same time, I run 'mbw'(mbw -t0 -n 1000000 1024 -q) in vm, a memcpy-intensive benchmark.
+
+
+I'm not sure if some configurations of QEMU/KVM are not enabled.
+
+looking forward to your reply!
+Steps to reproduce:
+```
+1. virsh qemu-monitor-command centos-huazhang '{"execute":"calc-dirty-rate", "arguments": {"calc-time": 1}}'
+
+   {"return":{},"id":"libvirt-16"}
+
+2. virsh qemu-monitor-command centos-huazhang1 '{"execute":"query-dirty-rate"}'
+   
+   {"return":{"status":"measured","sample-pages":512,"dirty-rate":0,"mode":"page-sampling","start-time":607266,"calc-time":1},"id":"libvirt-17"}
+
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1201 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1201
new file mode 100644
index 00000000..92b926cd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1201
@@ -0,0 +1,10 @@
+Qemu with Windows 10
+Description of problem:
+I see a colored screen with flashing cursor and cannot complete Windows installation.
+Steps to reproduce:
+1. Install `qemu-w64-setup-20220831.exe` on Windows 10 Pro for Workstations 21H2.
+2. `cd C:\Program Files\qemu`
+3. `qemu-img.exe create -f raw win.img 25600M`
+4. `qemu-system-i386w.exe -boot c -m 4096 -hda win.img -cdrom "C:\Users\me\Downloads\Win10_21H2_English_x64.iso"`
+Additional information:
+![xCeQH](/uploads/90a39994e020ffb174583fd3bafa520b/xCeQH.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1203 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1203
new file mode 100644
index 00000000..915e51d0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1203
@@ -0,0 +1,45 @@
+migrate with block-dirty-bitmap (disk size is big enough) can't be finished
+Description of problem:
+when disk size is big enough(this case using the 4T,related to the bandwith of migration), migrate the VM with block-dirty-bitmap , 
+the migration will not be finished!
+Steps to reproduce:
+1. **Start up the source VM,using the commands**: 
+
+/usr/libexec/qemu-kvm -name guest=i-00001C,debug-threads=on  -machine pc,accel=kvm,usb=off,dump-guest-core=off -cpu qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -smp 4,sockets=1,cores=4,threads=1   -uuid 991c2994-e1c9-48c0-9554-6b23e43900eb -smbios type=1,manufacturer=data,serial=7C1A9ABA-02DD-4E7D-993C-E1CDAB47A19B,family="Virtual Machine" -no-user-config -nodefaults -device sga  -rtc base=2022-09-09T02:54:38,clock=host,driftfix=slew -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,splash-time=0,strict=on -device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x6 -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.0,addr=0xa -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0xb -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0xc -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0xd -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0xe -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive if=none,id=drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -drive if=none,id=drive-fdc0-0-0,readonly=on  -drive file=/datastore/e88e2b29-cd39-4b21-9629-5ef2458f7ddd/c08fee8e-caf4-4217-ab4d-351a021c2c3d,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,num-queues=1,bus=pci.1,addr=0x1,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -device usb-tablet,id=input0,bus=usb.0,port=1     -device intel-hda,id=sound0,bus=pci.0,addr=0x3 -device hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox off -device pvpanic,ioport=1285 -msg timestamp=on -qmp tcp:127.0.0.1:4444,server,nowait 
+
+**Start the dst VM using commands as:**
+
+/usr/libexec/qemu-kvm -name guest=i-00001C,debug-threads=on  -machine pc,accel=kvm,usb=off,dump-guest-core=off -cpu qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -smp 4,sockets=1,cores=4,threads=1   -uuid 991c2994-e1c9-48c0-9554-6b23e43900eb -smbios type=1,manufacturer=data,serial=7C1A9ABA-02DD-4E7D-993C-E1CDAB47A19B,family="Virtual Machine" -no-user-config -nodefaults -device sga  -rtc base=2022-09-09T02:54:38,clock=host,driftfix=slew -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,splash-time=0,strict=on -device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x6 -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.0,addr=0xa -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0xb -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0xc -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0xd -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0xe -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive if=none,id=drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -drive if=none,id=drive-fdc0-0-0,readonly=on  -drive file=/datastore/e88e2b29-cd39-4b21-9629-5ef2458f7ddd/c08fee8e-caf4-4217-ab4d-351a021c2c3d,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,num-queues=1,bus=pci.1,addr=0x1,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -device usb-tablet,id=input0,bus=usb.0,port=1     -device intel-hda,id=sound0,bus=pci.0,addr=0x3 -device hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox off -device pvpanic,ioport=1285 -msg timestamp=on -qmp tcp:127.0.0.1:4444,server,nowait -incoming tcp:0:3333
+
+2. **image info as:**
+
+image: /datastore/e88e2b29-cd39-4b21-9629-5ef2458f7ddd/c08fee8e-caf4-4217-ab4d-351a021c2c3d
+
+file format: qcow2
+virtual size: 4.0T (4380866641920 bytes)
+disk size: 1.0M
+cluster_size: 65536
+
+Format specific information:
+    compat: 1.1
+    lazy refcounts: false
+    refcount bits: 16
+    corrupt: false
+
+3. **Add the bitmap :** {"execute":"block-dirty-bitmap-add","arguments":{"node":"drive-virtio-disk0", "name":"bitmap-2022-09-09-16-10-23"}}
+4. **set the dirty-bitmaps capability** :{ "execute": "migrate-set-capabilities" , "arguments":{"capabilities":[ {"capability":"dirty-bitmaps","state": true }]}}
+5. **start migrate ** { "execute": "migrate", "arguments": { "uri": "tcp:10.49.35.23:3333" } }
+6. **quert migrate parameters** {"execute":"query-migrate-parameters"} the retrun message :
+{"return": {"cpu-throttle-tailslow": false, "xbzrle-cache-size": 67108864, "cpu-throttle-initial": 20, "announce-max": 550, "decompress-threads": 2, "compress-threads": 8, "compress-level": 1, "multifd-channels": 2, "multifd-zstd-level": 1, "announce-initial": 50, "block-incremental": false, "compress-wait-thread": true, "downtime-limit": 300, "tls-authz": "", "multifd-compression": "none", "announce-rounds": 5, "announce-step": 100, "tls-creds": "", "multifd-zlib-level": 1, "max-cpu-throttle": 99, "max-postcopy-bandwidth": 0, "tls-hostname": "", "throttle-trigger-threshold": 50, "max-bandwidth": 134217728, "x-checkpoint-delay": 20000, "cpu-throttle-increment": 10}}
+
+7. **query-migrate-capabilities** ：
+{"execute":"query-migrate-capabilities"} the retrun message :
+{"return": [{"state": false, "capability": "xbzrle"}, {"state": false, "capability": "rdma-pin-all"}, {"state": false, "capability": "auto-converge"}, {"state": false, "capability": "zero-blocks"}, {"state": false, "capability": "compress"}, {"state": false, "capability": "events"}, {"state": false, "capability": "postcopy-ram"}, {"state": false, "capability": "x-colo"}, {"state": false, "capability": "release-ram"}, {"state": false, "capability": "return-path"}, {"state": false, "capability": "pause-before-switchover"}, {"state": false, "capability": "multifd"}, {"state": true, "capability": "dirty-bitmaps"}, {"state": false, "capability": "postcopy-blocktime"}, {"state": false, "capability": "late-block-activate"}, {"state": false, "capability": "x-ignore-shared"}, {"state": false, "capability": "validate-uuid"}, {"state": false, "capability": "background-snapshot"}]}
+
+8. **query the info of migrate** using the command {"execute":"query-migrate"}
+{"return": {"expected-downtime": 0, "status": "active", "setup-time": 64, "total-time": 1320361, "ram": {"total": 4295499776, "postcopy-requests": 0, "dirty-sync-count": 7909410, "multifd-bytes": 0, "pages-per-second": 80, "page-size": 4096, "remaining": 0, "mbps": 3.5006399999999998, "transferred": 430971236, "duplicate": 1048569, "dirty-pages-rate": 66, "skipped": 0, "normal-bytes": 357560320, "normal": 87295}}}
+
+**the state of migrate is always active ,no matter how long it takes.**
+The bug is : migration with big block dirty bitmap  can not be finished
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1205 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1205
new file mode 100644
index 00000000..0c3acf8c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1205
@@ -0,0 +1,7 @@
+Cannot use `-serial stdio` on macbook pro, apple silicon
+Description of problem:
+When I run the command above, it will show below:
+```
+(qemu) qemu-system-aarch64: -serial stdio: cannot use stdio by multiple character devices
+qemu-system-aarch64: -serial stdio: could not connect serial device to character backend 'stdio'
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1207 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1207
new file mode 100644
index 00000000..b12c9f6c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1207
@@ -0,0 +1,3 @@
+Cannot use qcow2 to create a VM on apple silicon macbook
+Description of problem:
+Nothing to output when I input the command above. And it seems not to boot successfully.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1209 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1209
new file mode 100644
index 00000000..f581594c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1209
@@ -0,0 +1,5 @@
+Optionally do not clear the screen when starting a VM
+Additional information:
+```
+QEMU emulator version 6.2.0 (qemu-6.2.0-14.fc36)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/121 b/gitlab/issues_text/target_missing/host_missing/accel_missing/121
new file mode 100644
index 00000000..4ebd41b9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/121
@@ -0,0 +1 @@
+multiprocess program gets incorrect results with qemu arm-linux-user
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1210 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1210
new file mode 100644
index 00000000..9211b62f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1210
@@ -0,0 +1,8 @@
+qemu segfaults on PNG screendump
+Description of problem:
+Attempting to produce a screendump via the monitor in the PNG format leads to a segmentation fault (but the screen dump is produced correctly).
+Steps to reproduce:
+1. Launch QEMU
+2. Go to the monitoring screen ()
+3. execute the command: `screendump /tmp/dump.png -f png`
+4. observe the crash (segfault)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1211 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1211
new file mode 100644
index 00000000..e8504f78
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1211
@@ -0,0 +1,7 @@
+Bad fonts in "cirrus" VGA card.
+Description of problem:
+Similar to #988. Fixed by set "no_bitblt" and "sw_cursor" in XF86Config file.
+Steps to reproduce:
+Similar to #988.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1212 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1212
new file mode 100644
index 00000000..8a123057
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1212
@@ -0,0 +1,9 @@
+A NULL pointer dereference issue in elf2dmp
+Description of problem:
+SIGSEGV in get_pml4e for it didn't handle NULL result properly.
+Steps to reproduce:
+1.launch qemu and running "gab attach -p $QEMU_PID", run "gcore" inside gdb to generate coredump
+2../elf2dmp ./core.111 ./out.dmp 
+3.get segemantation fault
+Additional information:
+![1](/uploads/39da5ed2da15b105664ee7ee05f69078/1.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1213 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1213
new file mode 100644
index 00000000..d9a485e7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1213
@@ -0,0 +1,43 @@
+7.1.0 - NSIS Installer file issues
+Description of problem:
+![image](/uploads/9d359265667c9640d184805ca09ab15c/image.png)
+
+Please check the screenshot relative to Window program list
+
+**Problem n. 1 (standard icon)**
+
+The icon rlative to QEMU is not graphic icon but starndrd udenfiend icon
+
+**Problem n. 2 (author missing)**
+
+Author info is missing
+
+**Problem n. 3 (installer date is not updated)**
+
+When you upgrade QEM the installation date not reflect last update but first installation (ex. version 7.1.0 with date of 2021).
+
+Note: all issues are relative to NSIS installer script.
+
+**Uninstaller icon**
+
+It seems that
+
+**!define MUI_UNICON "${SRCDIR}\pc-bios\qemu-nsis.ico"**__
+
+didn't work.
+
+Please check here
+
+https://nsis.sourceforge.io/Add_uninstall_information_to_Add/Remove_Programs
+
+Please try to add in uninsaller section
+
+    WriteRegStr HKLM "${UNINST_KEY}" "DisplayIcon" "${SRCDIR}\pc-bios\qemu-nsis.ico"
+
+**Missing author info in uninstall view**
+
+    ; Write the uninstall keys for Windows
+    WriteRegStr HKLM "${UNINST_KEY}" "DisplayName" "QEMU"
+    WriteRegStr HKLM "${UNINST_KEY}" "Publisher" "QEMU crew"
+
+Replace "QEMU crew" with text that you like.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1214 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1214
new file mode 100644
index 00000000..b547d0d5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1214
@@ -0,0 +1 @@
+qemu-riscv64 mmap  will exhaust all physical memory
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1215 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1215
new file mode 100644
index 00000000..f8467f76
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1215
@@ -0,0 +1,72 @@
+block-stream qmp command regression in 7.1.0
+Description of problem:
+After `block-stream` qmp commands, guest was hanged when using `iothread` option.  
+According to b1e1af3, there are some change at drain blockdev subtree and strong reference to base node.  
+We couldn't produce this issue when we reverted the commit.  
+It seems to be raised by racing acquiring aio_lock between iothread and main thread.
+Steps to reproduce:
+1. Start Guest with upper command.
+2. After started, operate `block-stream` command to qmp socket
+```
+echo '{"execute":"qmp_capabilities"}{
+   "execute":"block-stream",
+   "arguments":{
+      "job-id":"hangTest", 
+      "device":"vdaFile"    
+   }
+}' | sudo nc -U /var/run/monitor_a9b43742-9117-4aae-8887-24bdb017ec20 -N
+```
+Additional information:
+- gdb debug stack
+```
+Thread 1 (Thread 0x7fcfaed84600 (LWP 162409) "qemu-system-x86"):
+#0  0x00007fcfaf108e7e in __ppoll (fds=0x5634a9b6b240, nfds=1, timeout=<optimized out>, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:42
+#1  0x00005634a7be22dd in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:64
+#2  0x00005634a7bc02c9 in fdmon_poll_wait (ctx=0x5634a990eec0, ready_list=0x7ffcb2ce4fb8, timeout=-1) at ../util/fdmon-poll.c:80
+#3  0x00005634a7bbf9c9 in aio_poll (ctx=ctx@entry=0x5634a990eec0, blocking=blocking@entry=true) at ../util/aio-posix.c:660
+#4  0x00005634a7ac849d in bdrv_parent_drained_end_single (c=c@entry=0x5634a9b4bb30) at ../block/io.c:76
+#5  0x00005634a7a98240 in bdrv_replace_child_noperm (childp=0x5634a9b61240, new_bs=0x0, free_empty_child=<optimized out>) at ../block.c:2910
+#6  0x00005634a7a987fe in bdrv_replace_child_tran (childp=<optimized out>, new_bs=<optimized out>, tran=<optimized out>, free_empty_child=<optimized out>) at ../block.c:2444
+#7  0x00005634a7a988bc in bdrv_remove_file_or_backing_child (bs=bs@entry=0x5634a9b5d1f0, child=child@entry=0x5634a9b4bb30, tran=tran@entry=0x5634aa415fc0) at ../block.c:5155
+#8  0x00005634a7a9fac6 in bdrv_remove_file_or_backing_child (tran=0x5634aa415fc0, child=0x5634a9b4bb30, bs=0x5634a9b5d1f0) at ../block.c:5133
+#9  bdrv_set_file_or_backing_noperm (parent_bs=parent_bs@entry=0x5634a9b5d1f0, child_bs=child_bs@entry=0x0, is_backing=is_backing@entry=true, tran=tran@entry=0x5634aa415fc0, errp=errp@entry=0x7ffcb2ce5150) at ../block.c:3412
+#10 0x00005634a7a9fd04 in bdrv_set_backing_noperm (errp=0x7ffcb2ce5150, tran=0x5634aa415fc0, backing_hd=0x0, bs=0x5634a9b5d1f0) at ../block.c:3449
+#11 bdrv_set_backing_hd (bs=bs@entry=0x5634a9b5d1f0, backing_hd=backing_hd@entry=0x0, errp=errp@entry=0x7ffcb2ce5150) at ../block.c:3461
+#12 0x00005634a7b25e19 in stream_prepare (job=0x5634a9e83da0) at ../block/stream.c:85
+#13 0x00005634a7aa922e in job_prepare (job=0x5634a9e83da0) at ../job.c:837
+#14 job_txn_apply (fn=<optimized out>, job=0x5634a9e83da0) at ../job.c:158
+#15 job_do_finalize (job=0x5634a9e83da0) at ../job.c:854
+#16 0x00005634a7aa9726 in job_exit (opaque=0x5634a9e83da0) at ../job.c:941
+#17 0x00005634a7bd26b4 in aio_bh_call (bh=0x7fcfa0824010) at ../util/async.c:150
+#18 aio_bh_poll (ctx=ctx@entry=0x5634a990eec0) at ../util/async.c:178
+#19 0x00005634a7bbf602 in aio_dispatch (ctx=0x5634a990eec0) at ../util/aio-posix.c:421
+#20 0x00005634a7bd22f2 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:320
+#21 0x00007fcfaf3c0d1b in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
+#22 0x00005634a7bde7c0 in glib_pollfds_poll () at ../util/main-loop.c:297
+#23 os_host_main_loop_wait (timeout=114194793) at ../util/main-loop.c:320
+#24 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:596
+#25 0x00005634a784fdc3 in qemu_main_loop () at ../softmmu/runstate.c:734
+#26 0x00005634a769f9e0 in qemu_main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:38
+--Type <RET> for more, q to quit, c to continue without paging--
+#27 0x00007fcfaf019d90 in __libc_start_call_main (main=main@entry=0x5634a769b0c0 <main>, argc=argc@entry=56, argv=argv@entry=0x7ffcb2ce54c8) at ../sysdeps/nptl/libc_start_call_main.h:58
+#28 0x00007fcfaf019e40 in __libc_start_main_impl (main=0x5634a769b0c0 <main>, argc=56, argv=0x7ffcb2ce54c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcb2ce54b8) at ../csu/libc-start.c:392
+#29 0x00005634a769f905 in _start ()
+```
+- iothread gdb stack
+```
+Thread 3 (Thread 0x7fcfae47e640 (LWP 162411) "IO iothread1"):
+#0  futex_wait (private=0, expected=2, futex_word=0x5634a9b49620) at ../sysdeps/nptl/futex-internal.h:146
+#1  __GI___lll_lock_wait (futex=futex@entry=0x5634a9b49620, private=0) at ./nptl/lowlevellock.c:49
+#2  0x00007fcfaf0880dd in lll_mutex_lock_optimized (mutex=0x5634a9b49620) at ./nptl/pthread_mutex_lock.c:48
+#3  ___pthread_mutex_lock (mutex=mutex@entry=0x5634a9b49620) at ./nptl/pthread_mutex_lock.c:128
+#4  0x00005634a7bc25b8 in qemu_mutex_lock_impl (mutex=0x5634a9b49620, file=0x5634a7da2997 "../util/async.c", line=682) at ../util/qemu-thread-posix.c:88
+#5  0x00005634a7bd24a5 in aio_context_acquire (ctx=0x5634a9b495c0) at ../util/async.c:682
+#6  co_schedule_bh_cb (opaque=0x5634a9b495c0) at ../util/async.c:520
+#7  0x00005634a7bd26b4 in aio_bh_call (bh=0x5634a9b494a0) at ../util/async.c:150
+#8  aio_bh_poll (ctx=ctx@entry=0x5634a9b495c0) at ../util/async.c:178
+#9  0x00005634a7bbf754 in aio_poll (ctx=0x5634a9b495c0, blocking=blocking@entry=true) at ../util/aio-posix.c:712
+#10 0x00005634a7a9392a in iothread_run (opaque=opaque@entry=0x5634a9998700) at ../iothread.c:67
+#11 0x00005634a7bc21d1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:504
+#12 0x00007fcfaf084b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
+#13 0x00007fcfaf116a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1216 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1216
new file mode 100644
index 00000000..4aed8f36
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1216
@@ -0,0 +1,9 @@
+System crashes/hangs when running qemu-img convert
+Description of problem:
+**Upon running the above command, the Virtual Machine simply crashes and is irrecoverable**
+Steps to reproduce:
+1. **Start Ubuntu 20.04 or SIFT Workstation**
+2. **sudo apt-get install qemu**
+3. **qemu-img convert -O raw JEA.vmdk JEA.vmdk.raw**
+Additional information:
+I have also run this on macOS and it just hangs and never completes
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1218 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1218
new file mode 100644
index 00000000..a9667844
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1218
@@ -0,0 +1,20 @@
+bitmap lost when create snapshot using blockdev-snapshot-sync function
+Description of problem:
+bitmap will be lost when using the blockdev-snapshot-sync qmp command to create external snapshot.
+if we create snapshot with the bitmap ,we have to start our incremental backup chain from a new full-backup.
+Steps to reproduce:
+1. start the qemu :
+qemu-system-x86_64 -name guest=i-00001C,debug-threads=on  -machine pc,dump-guest-core=off -cpu qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -smp 4,sockets=1,cores=4,threads=1   -uuid 991c2994-e1c9-48c0-9554-6b23e43900eb -smbios type=1,manufacturer=data,serial=7C1A9ABA-02DD-4E7D-993C-E1CDAB47A19B,family="Virtual Machine" -no-user-config -nodefaults -device sga  -rtc base=2022-09-09T02:54:38,clock=host,driftfix=slew -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,splash-time=0,strict=on -device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x6 -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.0,addr=0xa -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x8 -device ich9-usb-ehci1,id=usb1,bus=pci.0,addr=0x9 -device piix4-usb-uhci,id=usb2,bus=pci.0,addr=0xb -device qemu-xhci,id=usb3,bus=pci.0,addr=0xc -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive if=none,id=drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -drive if=none,id=drive-fdc0-0-0,readonly=on  -drive file=/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,num-queues=1,bus=pci.1,addr=0x1,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -device usb-tablet,id=input0,bus=usb.0,port=1     -device intel-hda,id=sound0,bus=pci.0,addr=0x3 -device hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox off -device pvpanic,ioport=1285 -msg timestamp=on -qmp tcp:127.0.0.1:4444,server,nowait
+
+2. {"execute":"block-dirty-bitmap-add","arguments":{"node":"drive-virtio-disk0", "name":"bitmap-2022-09-19-16-10-23"}}
+
+3. {"execute":"query-block"} and the result:
+ {"return": [{"io-status": "ok", "device": "drive-ide0-1-1", "locked": false, "removable": true, "qdev": "ide0-1-1", "tray_open": false, "type": "unknown"}, {"device": "drive-fdc0-0-0", "locked": false, "removable": true, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 21474836480, "filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "cluster-size": 65536, "format": "qcow2", "actual-size": 200704, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "#block173", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "**dirty-bitmaps**": [{"name": "bitmap-2022-09-19-16-10-23", "recording": true, "persistent": false, "busy": false, "granularity": 65536, "count": 0}], "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": true, "writeback": true}, "file": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d"}, "qdev": "/machine/peripheral/virtio-disk0/virtio-backend", "type": "unknown"}]}
+
+4. {"execute":"blockdev-snapshot-sync","arguments":{"device": "drive-virtio-disk0", "snapshot-file": "/datastore/c08fee8e-caf4-4217-ab4d-351a021c2c3d-actice", "format": "qcow2"}}
+5. {"execute":"query-block"} and the result:
+ {"return": [{"io-status": "ok", "device": "drive-ide0-1-1", "locked": false, "removable": true, "qdev": "ide0-1-1", "tray_open": false, "type": "unknown"}, {"device": "drive-fdc0-0-0", "locked": false, "removable": true, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", "image": {"backing-image": {"virtual-size": 21474836480, "filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "cluster-size": 65536, "format": "qcow2", "actual-size": 200704, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "backing-filename-format": "qcow2", "virtual-size": 21474836480, "filename": "/datastore/c08fee8e-caf4-4217-ab4d-351a021c2c3d-actice", "cluster-size": 65536, "format": "qcow2", "actual-size": 200704, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "full-backing-filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "backing-filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "#block618", "backing_file_depth": 1, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "backing_file": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": true, "writeback": true}, "file": "/datastore/c08fee8e-caf4-4217-ab4d-351a021c2c3d-actice"}, "qdev": "/machine/peripheral/virtio-disk0/virtio-backend", "type": "unknown"}]}
+
+we lost the bitmap bitmap-2022-09-19-16-10-23
+Additional information:
+the bitmap attach the active bs, when changing the active bs ,the bitmap will be lost...
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1219 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1219
new file mode 100644
index 00000000..f6afdc78
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1219
@@ -0,0 +1,13 @@
+--enable-kvm not work for riscv64-softmmu
+Description of problem:
+I want to enable kvm for qemu-system-riscv64, so I compile it with `--enable-kvm` as above. But the log shows
+
+```sh
+  Targets and accelerators
+    KVM support                  : NO
+```
+
+And also compiled qemu-system-riscv64 does not support kvm.
+Steps to reproduce:
+1. clone the repo
+2. `./configure --target-list=riscv64-softmmu --enable-kvm`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/122 b/gitlab/issues_text/target_missing/host_missing/accel_missing/122
new file mode 100644
index 00000000..ed08f19f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/122
@@ -0,0 +1 @@
+linux-user does not check PROT_EXEC
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1220 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1220
new file mode 100644
index 00000000..e84c7177
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1220
@@ -0,0 +1,16 @@
+when migrate,I unplugged the disk, why can't I force cancel the job task use qmp
+Description of problem:
+when migrate,I unplugged the disk,the block job will hung,but why can't I force cancel the job task
+Steps to reproduce:
+1.migrate a guset to another host with non-share disk (iscsi)
+
+2.unplug the disk
+
+3.then force cancel the block job task
+
+
+but it not work,the cancle handle is not work
+
+![image](/uploads/e01464f45188df92abc1fe15ccd96777/image.png)
+
+![image](/uploads/0b8ebb654eae4feae06e7fa6dba071ea/image.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1221 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1221
new file mode 100644
index 00000000..f0c3614d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1221
@@ -0,0 +1,29 @@
+qga return "frozen" when vm just been created from snapfile
+Steps to reproduce:
+1. virsh create lisa.xml  
+Domain lisa created from lisa.xml
+
+2. virsh domblklist lisa  
+ vda      /mnt/a/b/srv.qcow2
+
+3. virsh snapshot-create-as lisa  --disk-only --diskspec vda,file=/tmp/f1,snapfile=/tmp/sp1  --no-metadata --quiesce  
+Domain snapshot 20220919165217 created
+
+4. virsh shutdown lisa  
+Domain lisa is being shutdown
+
+5. modify lisa.xml: replace /mnt/a/b/srv/qcow2 with /tmp/sp1
+
+6. virsh create lisa.xml  
+Domain lisa created from lisa.xml
+
+7. virsh domblklist lisa  
+ vda      /tmp/sp1
+ 
+8. virsh qemu-agent-command lisa '{"execute":"guest-fsfreeze-status"}'  
+{"return":"frozen"}
+
+9. virsh snapshot-create-as lisa  --disk-only --diskspec vda,file=/tmp/f2,snapfile=/tmp/sp2  --no-metadata --quiesce  
+error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': The command guest-fsfreeze-freeze has been disabled for this instance
+Additional information:
+Is "frozen" a normal value in step8? If not, what's the best way to avoid this?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1222 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1222
new file mode 100644
index 00000000..ed22b50b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1222
@@ -0,0 +1,21 @@
+/proc/self/exe not handled in execve
+Description of problem:
+I am submitting this issue to track an issue for which it seems there have been a couple of patchsets (unsuccessfully) submitted. I am not able to give a detailed analysis of the problem as I am not aware of exactly what the issue is - I am raising this issue to attempt to bring one of these changes upstream as it seems there is a genuine bug here (hence multiple attempts to fix) but no tracking bug or attention. It's also causing my project to require a custom fork of qemu just for this.
+
+My (laymans) understanding of the bug is that golang can escape the emulation environment when it execs something to do with `execve /proc/self/exe`. Here is an excerpt from my internal docs from someone who has left the project, sorry I cannot be of more use...
+
+> Unfortunately, to run podman/buildah/skopeo using qemu-user (which just runs a single binary
+> emulated, as opposed to qemu-system which runs an entire system but is harder to automate in
+> toolchains) we need these patches because of a peculiar thing many golang applications do. They
+> re-execute themselves using the execve syscall using /proc/self/exe as the executable. In
+> non-emulated contexts this is fine, but in emulated contexts /proc/self/exe is actually the
+> top-level emulator process and _not_ podman/buildah/skopeo. This causes all container storage
+> operations to mysteriously fail, because the wrong binary is being executed. This issue was quite
+> difficult to root cause.
+Additional information:
+Old patchsets that seem to be trying to fix this:
+- http://next.patchew.org/QEMU/20210531055019.10149-1-yamamoto@midokura.com/20210531055019.10149-2-yamamoto@midokura.com/
+- https://patchew.org/QEMU/20190916155545.29928-1-olivier.dion@polymtl.ca/
+- https://patchew.org/QEMU/20190807135458.32440-1-dion@linutronix.de/
+
+It seems that this github issue: https://github.com/golang/go/issues/42080 references the same issue.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1223 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1223
new file mode 100644
index 00000000..e4710f8d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1223
@@ -0,0 +1,11 @@
+When the disk is offline, why does the migration not time out and the virtual machine keeps hanging
+Description of problem:
+I want to the migrate end auto after the disk is offline
+Steps to reproduce:
+1.migrate to other host
+
+2.Manually construct disk offline when migrating
+
+3.the vm is hangs,and migrate wait for the disk recovery,i need to it timeout and report the failed migration 
+rather than hangs ,what should i do
+![image](/uploads/c1ec6e1f59524888ea8e5c1df131037e/image.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1225 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1225
new file mode 100644
index 00000000..bc74c022
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1225
@@ -0,0 +1 @@
+Can't update to Windows 11 22H2
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1226 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1226
new file mode 100644
index 00000000..affb40aa
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1226
@@ -0,0 +1,25 @@
+wheel-axis=false does not get applied at hardware init stage
+Description of problem:
+`-device virtio-tablet,id=touch0,wheel-axis=false` does not get applied at initalization stage, causing android to see it and treat the device as a pointer instead of a tablet. it seems to look for the prop at init stage, I have verified that this is an issue by fixing it with a quick hack below. ~~setting `-device virtio-tablet,id=touch0,wheel-axis=true` will still work fine and cause android to pick it up as a pointer again~~
+
+
+EDIT: It does not seem to work actually. if set when the default is set to false
+Steps to reproduce:
+1. Boot android based VM
+2. test an app that forces touch only over pointer
+Additional information:
+```
+diff --git a/hw/input/virtio-input-hid.c b/hw/input/virtio-input-hid.c
+index a7a244a95d..3175f9c7d5 100644
+--- a/hw/input/virtio-input-hid.c
++++ b/hw/input/virtio-input-hid.c
+@@ -477,7 +477,7 @@ static struct virtio_input_config virtio_tablet_config_v2[] = {
+ };
+ 
+ static Property virtio_tablet_properties[] = {
+-    DEFINE_PROP_BOOL("wheel-axis", VirtIOInputHID, wheel_axis, true),
++    DEFINE_PROP_BOOL("wheel-axis", VirtIOInputHID, wheel_axis, false),
+     DEFINE_PROP_END_OF_LIST(),
+ };
+ 
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1227 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1227
new file mode 100644
index 00000000..468b8b04
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1227
@@ -0,0 +1 @@
+Guest Agent not waiting for Linux services to stop during shutdown
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1228 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1228
new file mode 100644
index 00000000..42eb259b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1228
@@ -0,0 +1,43 @@
+-display curses only recognizes escape characters if pressed very quickly
+Description of problem:
+The system start and runs perfectly fine, but when I try to exit the escape commands does not seem to work.
+
+I have tried all the ones from here:
+https://www.qemu.org/docs/master/system/keys.html
+https://www.qemu.org/docs/master/system/mux-chardev.html
+
+When using the graphical display, the escape characters works as expected but when using -display curses, they do not.
+Steps to reproduce:
+1. Start qemu with the command provided 
+2. Try to exit using ctrl + x a - Not working
+3. Try to exit using alt + 2 - Not working
+
+The same issues occurs when running qemu on a Linux machine (Ubunt) via Visual Studio Code / ssh. 
+
+I'm guessing this is a macOS specific issue or maybe something to do with my Locale (sv-SE).
+Additional information:
+Linux 0.01 build:
+https://github.com/mariuz/linux-0.01
+
+**Tests using showkey**
+
+Alt + 2 from mobile ssh client (Terminus) -> Ubuntu machine
+```
+^[2      27 0033 0x1b
+         50 0062 0x32
+```
+
+Option + 2 from macOS Terminal + ssh -> Ubuntu machine
+```
+@ 	 64 0100 0x40
+```
+
+Esc + 2 from macOS Terminal + ssh -> Ubuntu machine
+```
+^[ 	 27 0033 0x1b
+2 	 50 0062 0x32
+```
+
+**Update**
+
+It seems to work if I press ESC + 2 at exactly the same time.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1229 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1229
new file mode 100644
index 00000000..dec12cd1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1229
@@ -0,0 +1,9 @@
+there is no Makefile.objs in migration dir，how can I do if I need to edit it?
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/123 b/gitlab/issues_text/target_missing/host_missing/accel_missing/123
new file mode 100644
index 00000000..8071656b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/123
@@ -0,0 +1 @@
+qemu-cris segfaults upon loading userspace binary
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1231 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1231
new file mode 100644
index 00000000..a60b1910
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1231
@@ -0,0 +1,13 @@
+Loading migration of VM in debug state fails (with potential solution)
+Description of problem:
+```
+qemu-system-x86_64: invalid runstate transition: 'inmigrate' -> 'debug'
+Aborted (core dumped)
+```
+Steps to reproduce:
+1. Start VM with gdbstub
+2. Pause VM via gdbstub
+3. Save migration snapshot via HMP: `migrate "exec: gzip -c > foo.gz"`
+4. Start new QEMU instance from snapshot by adding these args to whatever you used to launch QEMU: `-incoming "exec: gzip -c -d foo.gz"`
+Additional information:
+This can be fixed by adding `{ RUN_STATE_INMIGRATE, RUN_STATE_DEBUG },` to `runstate_transitions_def` in `softmmu/runstate.c`. It's not clear if there are any negative ramifications of this, but it seems to work for me?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1232 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1232
new file mode 100644
index 00000000..78c2bc96
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1232
@@ -0,0 +1,13 @@
+AArch64 virt can't write to memory related to gicv3
+Description of problem:
+According to the info in generated dtb, the memory-mapped registers of gicv3-distributor have a base addr, which is `0x0800_0000`.
+And I have checked the validity by reading `gicd_typer`, which means the base addr is right.
+
+But when I want to configure the gicv3-distributor (like changing `gicd_ctlr`), the value is not changed, keeping the default value. The same thing happens on any register of GICD in my machine.
+
+**Even I write to this memory by gdb `set` command, the value is also unchangeable.**
+
+The addr of `gicd_ctlr` should be `0x0800_0000`(offset=0), which should be readable and writable, isn't it?
+
+I try to modify the value of this addr in assembly as soon as the **machine starts, without enabling MMU**. 
+This problem should be easier to reproduce.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1233 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1233
new file mode 100644
index 00000000..2f5c1c83
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1233
@@ -0,0 +1 @@
+is there a roadmap about when riscv-v extension will be implemented??
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1234 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1234
new file mode 100644
index 00000000..11ee9212
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1234
@@ -0,0 +1,3 @@
+Migration: Device state not saved for msmouse/chardevs
+Additional information:
+This missing feature was discovered while fixing msmouse here: https://patchew.org/QEMU/20220908173120.16779-1-arwed.meyer@gmx.de/20220908173120.16779-2-arwed.meyer@gmx.de/
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1235 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1235
new file mode 100644
index 00000000..1ee5585a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1235
@@ -0,0 +1,180 @@
+Using packer and plugin qemu in the json file to create a RHEL 8.4 guest kvm vm, but ssh timeout error coming, but it is running fine in RHEL 7.9
+Description of problem:
+I have RHEL 8.5 as the KVM host. I want to create a guest vm of RHEL 8.4 through packer type qemu and have a json file where all the configurations are mentioned.
+
+{
+
+“builders”: [
+
+{
+
+“type”: “qemu”,
+
+“iso_url”: “/var/lib/libvirt/images/test.iso”,
+
+“iso_checksum”: “md5:3959597d89e8c20d58c4514a7cf3bc7f”,
+
+“output_directory”: “/var/lib/libvirt/images/iso-dir/test”,
+
+“disk_size”: “55G”,
+
+“headless”: “true”,
+
+“qemuargs”: [
+
+        [
+
+            "-m",
+
+            "4096"
+
+        ],
+
+        [
+
+            "-smp",
+
+            "2"
+
+        ]
+],
+
+“format”: “qcow2”,
+
+“shutdown_command”: “echo ‘nonrootuser’ | sudo -S shutdown -P now”,
+
+“accelerator”: “kvm”,
+
+“ssh_username”: “nonrootuser”,
+
+“ssh_password”: “********”,
+
+“ssh_timeout”: “20m”,
+
+“vm_name”: “test”,
+
+“net_device”: “virtio-net”,
+
+“disk_interface”: “virtio”,
+
+“http_directory”: “/home/azureuser/http”,
+
+“boot_wait”: “10s”,
+
+“boot_command”: [
+
+“e inst.ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/anaconda-ks.cfg”
+
+]
+
+}
+
+],
+
+“provisioners”:
+
+[
+
+{
+
+  "type": "file",
+
+  "source": "/home/azureuser/service_status_check.sh",
+
+  "destination": "/tmp/service_status_check.sh"
+
+},
+
+{
+
+  "type": "file",
+
+  "source": "/home/azureuser/service_check.sh",
+
+  "destination": "/tmp/service_check.sh"
+
+},  
+
+{
+
+  "type": "file",
+
+  "source": "/home/azureuser/azure.sh",
+
+  "destination": "/tmp/azure.sh"
+
+},
+
+{
+
+
+  "type": "file",
+
+  "source": "/home/azureuser/params.cfg",
+
+  "destination": "/tmp/params.cfg"
+
+},
+
+
+
+{ 
+
+  "type": "shell" ,
+
+
+
+  "execute_command": "echo 'siedgerexuser' | {{.Vars}} sudo -E -S bash '{{.Path}}'",
+
+
+
+  "inline": [
+"echo copying" , "cp /tmp/params.cfg  /root/",
+    "sudo ls -lrt /root/params.cfg",
+    "sudo ls -lrt /opt/scripts/"
+  ],
+
+
+    "inline_shebang": "/bin/sh -x"
+
+},
+
+{
+
+  "type": "shell",
+
+  "pause_before": "5s",
+  "expect_disconnect": true ,
+
+  "inline": [
+    "echo runningconfigurescript" , "sudo sh /opt/scripts/configure-env.sh"
+
+  ]
+
+},
+
+{
+
+  "type": "shell",
+
+  "pause_before": "200s",
+
+  "inline": [
+    
+    "sudo sh /tmp/service_check.sh",
+    "sudo sh /tmp/azure.sh"
+
+  ]
+
+}
+]
+
+}
+
+It is working fine in rhel 7.9, but the same thing giving ssh timeout error in RHEL 8.4.
+
+But when i am creating guest vm with virt-install it is able to create a vm and i am able to see it in cockpit web ui, but when i initiate packer build with qemu plugin then  giving ssh timeout error it is not visible in cockpit UI, so not able to see where the guest vm created get stuck.
+
+Can anyone please help me to fix this issue where why vm not able to come up and also why qemu created vm not visible in cockpit web ui as that will be really helpful while debugging
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1236 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1236
new file mode 100644
index 00000000..4247eab7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1236
@@ -0,0 +1,46 @@
+blockdev fixed vhdx trying to reserve space, also misleading error, Could not open file: Invalid argument
+Description of problem:
+The qemu-storage-daemon/other qemu commands will not start and will choke on requiring vhdx driver for the blockdev layer.
+Opening a fixed-virtual-disk like fixed-vhdx should not reserve extra space, and should only overwrite as all blocks are already allocated.
+Steps to reproduce:
+1. Ensure that a partition size is such that after deciding a fixed-vhdx size, the remainder space after creation of fixed-vhdx is less than the fixed-vhdx.
+2. Create a fixed-vhdx file 
+3. Try to start an nbd server with it
+the qemu-storage-daemon will not start
+Additional information:
+I want to mention that I am testing qemu-storage-daemon under windows/hyperv
+
+So far, I want to report that it has **worked** for rawimg and qcow2-fixed.  
+See comment of 20220926 https://github.com/cloudbase/wnbd/issues/63#issuecomment-1257148849 
+
+The driver parameter ```vhdx``` to the blockdev argument seems to struggle with it.
+
+I wanted to check if the vhdx blockdev driver has the same VHDX-related-bugs as qemu-nbd 
+- #727 VHDX is corrupted on expansion.
+- #806 Fixed VHDX inflates beyond its fixed size when data is copied onto it and also corrupts 
+
+Even the the blockdev reference entries seem to have VHDX all over the place
+- pg 318 https://readthedocs.org/projects/qemu/downloads/pdf/latest/
+- https://www.qemu.org/docs/master/system/qemu-block-drivers.html
+- except conspicuously here !! https://www.qemu.org/docs/master/interop/qemu-storage-daemon-qmp-ref.html?highlight=blockdev#qapidoc-265
+
+
+```
+C:\Windows\System32>qemu-storage-daemon --version
+qemu-storage-daemon version 7.1.0 (v7.1.0-11925-g4ec481870e-dirty)
+
+C:\Windows\System32>qemu-storage-daemon --blockdev driver=file,node-name=file,filename=H:\gkpics01.vhdx --blockdev driver=vhdx,node-name=vhdx,file=file --nbd-server addr.type=inet,addr.host=127.0.0.1,addr.port=10809 --export type=nbd,id=export,node-name=vhdx,name=gkpics01,writable=on
+qemu-storage-daemon: --blockdev driver=vhdx,node-name=vhdx,file=file: Could not open 'H:\gkpics01.vhdx': Invalid argument
+
+C:\Windows\System32>qemu-storage-daemon --blockdev driver=file,node-name=file,filename=H:\gkpics01.vhdx --blockdev driver=vhdx,node-name=vhdx,file=file,subformat=fixed --nbd-server addr.type=inet,addr.host=127.0.0.1,addr.port=10809 --export type=nbd,id=export,node-name=vhdx,name=gkpics01,writable=on
+qemu-storage-daemon: --blockdev driver=vhdx,node-name=vhdx,file=file,subformat=fixed: Parameter 'subformat' is unexpected
+
+C:\Windows\System32>dir H:\gkpics01.vhdx
+ Volume in drive H is CPERF0
+ Volume Serial Number is F196-DB9E
+ Directory of H:\
+09/29/2022  08:55 PM    99,727,966,208 gkpics01.vhdx
+               1 File(s) 99,727,966,208 bytes
+               0 Dir(s)   4,312,399,872 bytes free
+```
+##
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1237 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1237
new file mode 100644
index 00000000..b8fd8723
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1237
@@ -0,0 +1 @@
+after OS upgrade usb-redir connection broken during migration and qemu-kvm: terminating on signal 15
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1239 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1239
new file mode 100644
index 00000000..e9bf6159
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1239
@@ -0,0 +1,36 @@
+The help document of qemu-img misses some options
+Description of problem:
+The "--help" option of qemu-img misses the option "skip-broken-bitmaps" for convert , "image-opts" for bench, "object" for dd and "force-share" for measure.
+Steps to reproduce:
+1. For the option "skip-broken-bitmaps", the following code appears during option parsing for convert and modifies the skip_broken in qemu-img.c:2377-2379.
+
+```
+        case OPTION_SKIP_BROKEN:
+            skip_broken = true;
+            break;
+```
+
+2. For the option "image-opts", the following code appears during option parsing for bench and modifies the image_opts in qemu-img.c:4511-4513.
+
+```
+        case OPTION_IMAGE_OPTS:
+            image_opts = true;
+            break;
+```
+3. For the option "object", the following code appears during option parsing for dd and calls the user_creatable_process_cmdline in qemu-img.c:4980-4982.
+
+```
+        case OPTION_OBJECT:
+            user_creatable_process_cmdline(optarg);
+            break;
+```
+4. For the option "force-share", the following code appears during option parsing for measure and modifies the force_share in qemu-img.c:5237-5239.
+```
+        case 'U':
+            force_share = true;
+            break;
+```
+Additional information:
+But they do not appear in the document provided by "--help".
+
+It may prevent users from using the relevant function.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1240 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1240
new file mode 100644
index 00000000..24616c62
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1240
@@ -0,0 +1,15 @@
+The help document of qemu-nbd misses an option
+Description of problem:
+The "--help" option of qemu-nbd misses the option "tls-hostname".
+Steps to reproduce:
+1. For the option "tls-hostname", the following code appears during option parsing and modifies the tlshostname in qemu-nbd.c:760-762.
+
+```
+        case QEMU_NBD_OPT_TLSHOSTNAME:
+            tlshostname = optarg;
+            break;
+```
+Additional information:
+But it does not appear in the document provided by "--help".
+
+It may prevent users from using the relevant function.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1242 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1242
new file mode 100644
index 00000000..c5fd1c75
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1242
@@ -0,0 +1 @@
+unable to build in mac
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1243 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1243
new file mode 100644
index 00000000..30c1604c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1243
@@ -0,0 +1 @@
+Floating-point-exception in ide_set_sector
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1244 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1244
new file mode 100644
index 00000000..cc9f0a5c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1244
@@ -0,0 +1,45 @@
+macOS 12.x ld: warning: -undefined dynamic_lookup may not work with chained fixups
+Description of problem:
+Not sure if this is a serious or negligible problem and if it has any significant runtime implications but reporting it anyway:
+
+```
+$ ld -v
+@(#)PROGRAM:ld  PROJECT:ld64-819.6
+BUILD 14:58:44 Aug  5 2022
+configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
+LTO support using: LLVM version 14.0.0, (clang-1400.0.29.102) (static support for 29, runtime is 29)
+TAPI support using: Apple TAPI version 14.0.0 (tapi-1400.0.11)
+
+$ ninja -C build
+ninja: Entering directory `build'
+[314/2946] Linking static target libevent-loop-base.a
+warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: archive library: libevent-loop-base.a the table of contents is empty (no object file members in the library define global symbols)
+[2044/2946] Generating qemu-system-aarch64 with a custom command
+qemu-system-aarch64.tmp: replacing existing signature
+[2584/2946] Linking target tests/plugin/libempty.dylib
+ld: warning: -undefined dynamic_lookup may not work with chained fixups
+[2585/2946] Linking target tests/plugin/libbb.dylib
+ld: warning: -undefined dynamic_lookup may not work with chained fixups
+[2588/2946] Linking target tests/plugin/libinsn.dylib
+ld: warning: -undefined dynamic_lookup may not work with chained fixups
+[2589/2946] Linking target tests/plugin/libmem.dylib
+ld: warning: -undefined dynamic_lookup may not work with chained fixups
+[2592/2946] Linking target tests/plugin/libsyscall.dylib
+ld: warning: -undefined dynamic_lookup may not work with chained fixups
+[2946/2946] Linking target tests/qtest/test-arm-mptimer
+```
+
+I saw a similar discussions in Bazel building system, CPython, and Ruby:
+- https://github.com/bazelbuild/bazel/issues/16413
+- https://github.com/python/cpython/issues/97524
+- https://github.com/ruby/ruby/pull/6193
+- https://issues.guix.gnu.org/issue/57849
+Steps to reproduce:
+1. ` ./configure --target-list=aarch64-softmmu,arm-softmmu --enable-cocoa --enable-plugins` (note that target list is not that important in this case though)
+2. `ninja -C build`
+3. Observe the warnings
+Additional information:
+See "New Features" subsection under "Linking" section for chained fixup
+https://developer.apple.com/documentation/xcode-release-notes/xcode-13-release-notes for more information:
+
+> All programs and dylibs built with a deployment target of macOS 12 or iOS 15 or later now use the chained fixups format. This uses different load commands and LINKEDIT data, and won’t run or load on older OS versions. (49851380)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1246 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1246
new file mode 100644
index 00000000..228a147b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1246
@@ -0,0 +1 @@
+Win11_22H2_English_x64.iso won't boot
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1249 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1249
new file mode 100644
index 00000000..f413b970
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1249
@@ -0,0 +1 @@
+qemu-edid Division By Zero -- by misuse of the option "-d"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1250 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1250
new file mode 100644
index 00000000..1cbbb1c9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1250
@@ -0,0 +1,3 @@
+[RFE] on windows, attach any storport disk directly, not just physicaldrives
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1252 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1252
new file mode 100644
index 00000000..4298d324
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1252
@@ -0,0 +1,17 @@
+Debian Raspberry Pi images do not boot with version 7 and higher
+Description of problem:
+The Debian Bullseye RPi4 4GB image [here](https://raspi.debian.net/tested-images/) does not boot with versions 7 and higher, while it does boot with v6.2.0.  The Bookworm image works with v7.
+Steps to reproduce:
+0. `export DEB_VERS=5.10.0-11`
+1. `wget https://raspi.debian.net/tested/20220121_raspi_4_bullseye.img.xz`
+2. `dd if=/dev/null of=disk-$DEB_VERS.img bs=1M seek=10240`
+    * NB: This creates a 10 GB file 
+3. `xzcat $RPI_IMG | dd of=disk-$DEB_VERS.img conv=notrunc status=progress`
+4. `partx -a -v disk-$DEB_VERS.img`
+5. `mount /dev/loop0p1 /mnt`
+6. `cp /mnt/initrd.img-$DEB_VERS-arm64 .`
+7. `cp /mnt/vmlinuz-$DEB_VERS-arm64 .`
+8. `umount /mnt`
+9. `qemu-system-aarch64 -M virt -m 4096 -cpu max -drive format=raw,file=disk-$DEB_VERS.img -nographic -append "console=tty0 console=ttyAMA0,115200 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 cma=64M rootwait" -initrd initrd.img-$DEB_VERS-arm64 -kernel vmlinuz-$DEB_VERS-arm64`
+Additional information:
+The URL for the image in step 1 has been known to change, so if you get a 404, go to the URL above and find the correct one.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1253 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1253
new file mode 100644
index 00000000..b3e0d5b1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1253
@@ -0,0 +1 @@
+pull mirroring
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1254 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1254
new file mode 100644
index 00000000..4b1c1cdc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1254
@@ -0,0 +1,55 @@
+hw: misc: edu: two off-by-one errors
+Description of problem:
+In `hw/misc/edu.c`, `edu_check_range()` fails for boundary conditions where `size2 == 0` and `size2 == size1`.
+Steps to reproduce:
+Two ways to reproduce (attached test program, [foo.c](/uploads/9cbef4f72d175b8336b58f607e262d7b/foo.c))
+
+error:
+1. `gcc -o foo foo.c`
+2. `./foo`
+
+fix:
+1. `gcc -DFIXED -o foo foo.c`
+2. `./foo`
+
+Using `qtest`: (see "QEMU command line" above).
+Additional information:
+(output of `foo` without fix):
+```
+EDU: DMA range 0x0000000000000000-0x0000000000000fff out of bounds (0x0000000000000000-0xffffffffffffffff)!
+EDU: DMA range 0x0000000000000000-0x0000000000000fff out of bounds (0x0000000000000000-0x0000000000000fff)!
+```
+
+Output of `qtest` without the fix:
+```
+qemu: hardware error: EDU: DMA range 0x0000000000000000-0x0000000000000fff out of bounds (0x0000000000040000-0x0000000000040fff)!
+CPU #0:
+EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000663
+ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
+EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0000 00000000 0000ffff 00009300
+CS =f000 ffff0000 0000ffff 00009b00
+SS =0000 00000000 0000ffff 00009300
+DS =0000 00000000 0000ffff 00009300
+FS =0000 00000000 0000ffff 00009300
+GS =0000 00000000 0000ffff 00009300
+LDT=0000 00000000 0000ffff 00008200
+TR =0000 00000000 0000ffff 00008b00
+GDT=     00000000 0000ffff
+IDT=     00000000 0000ffff
+CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
+DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 
+DR6=ffff0ff0 DR7=00000400
+EFER=0000000000000000
+FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
+FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
+FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
+FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
+FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
+XMM00=0000000000000000 0000000000000000 XMM01=0000000000000000 0000000000000000
+XMM02=0000000000000000 0000000000000000 XMM03=0000000000000000 0000000000000000
+XMM04=0000000000000000 0000000000000000 XMM05=0000000000000000 0000000000000000
+XMM06=0000000000000000 0000000000000000 XMM07=0000000000000000 0000000000000000
+```
+
+Patch has been submitted to `qemu-devel`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1256 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1256
new file mode 100644
index 00000000..c6d4767f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1256
@@ -0,0 +1,22 @@
+Building installer fails on Windows 10 Msys2
+Description of problem:
+build fails with:
+```
+make[2]: Leaving directory '/c/Users/sxlga/source/repos/qemu/build'
+Traceback (most recent call last):
+  File "C:\Users\sxlga\source\repos\qemu\scripts\nsis.py", line 89, in <module>
+    main()
+  File "C:\Users\sxlga\source\repos\qemu\scripts\nsis.py", line 34, in main
+    with open(
+OSError: [Errno 22] Invalid argument: 'C:/Users/sxlga/AppData/Local/Temp/tmpinyvlwkoC:/msys64/qemu/system-emulations.nsh'
+ninja: build stopped: subcommand failed.
+make[1]: *** [Makefile:165: run-ninja] Error 1
+make[1]: Leaving directory '/c/Users/sxlga/source/repos/qemu/build'
+make: *** [GNUmakefile:11: installer] Error 2
+```
+Steps to reproduce:
+1. ./configure --target-list=arm-softmmu,aarch64-softmmu
+2. make all
+3. make installer
+Additional information:
+following https://wiki.qemu.org/Hosts/W32#Native_builds_with_MSYS2 to set up toolchain
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1257 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1257
new file mode 100644
index 00000000..7a79743a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1257
@@ -0,0 +1,3 @@
+Windows guest agent shutdown requires user response to complete
+Additional information:
+The shutdown operation triggered by the Windows Guest Agent should prevent the system from waiting for a user response concerning unsaved work of open desktop applications. Instead, applications and services should be closed as gracefully as possible automatically, in advance of  the power down event on the emulated hardware.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/126 b/gitlab/issues_text/target_missing/host_missing/accel_missing/126
new file mode 100644
index 00000000..dae4b3c5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/126
@@ -0,0 +1 @@
+qemu-input: Mouse stops working in Windows guest
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1262 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1262
new file mode 100644
index 00000000..387d6613
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1262
@@ -0,0 +1 @@
+avocado test framework fails to report when QEMU exits unexpectedly
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1264 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1264
new file mode 100644
index 00000000..d604b2f5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1264
@@ -0,0 +1 @@
+socket chardev loses data when remote end closes the connection
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1265 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1265
new file mode 100644
index 00000000..02df9d3a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1265
@@ -0,0 +1 @@
+avocado should log all the guest console output until QEMU exits, not disconnect early
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1266 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1266
new file mode 100644
index 00000000..728b93d1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1266
@@ -0,0 +1 @@
+Assert in resettable_phase_enter through virtio-scsi
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1268 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1268
new file mode 100644
index 00000000..b7762eb6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1268
@@ -0,0 +1 @@
+erst: undefined-behavior in memcpy in write_erst_record
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1270 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1270
new file mode 100644
index 00000000..b8f168bf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1270
@@ -0,0 +1,14 @@
+Guest freezes if memory backing using memfd/shared/
+Description of problem:
+Guest VM freezes with the following memory backing is set. Required to for virtiofs, but just setting the following the guest will freeze in around 2hours, no logs or errors generate.
+
+  <memoryBacking>
+    <source type='memfd'/>
+    <access mode='shared'/>
+  </memoryBacking>
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1272 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1272
new file mode 100644
index 00000000..65da4301
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1272
@@ -0,0 +1,50 @@
+qemu 7.1: assertion faillure with virtio-scsi in `blk_set_enable_write_cache`
+Description of problem:
+During the guest boot qemu crashes with the following error:
+
+> qemu-system-x86_64: ../src/block/block-backend.c:1949: blk_set_enable_write_cache: Assertion `qemu_in_main_thread()' failed.
+Steps to reproduce:
+1. Start a windows guest
+Additional information:
+Stacktrace:
+
+```
+#0  0x00007fd6c3515ce1 in raise () from /lib/x86_64-linux-gnu/libc.so.6
+#1  0x00007fd6c34ff537 in abort () from /lib/x86_64-linux-gnu/libc.so.6
+#2  0x00007fd6c34ff40f in ?? () from /lib/x86_64-linux-gnu/libc.so.6
+#3  0x00007fd6c350e662 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
+#4  0x000056149e2cea03 in blk_set_enable_write_cache (wce=true, blk=0x5614a01c27f0) at ../src/block/block-backend.c:1949
+#5  0x000056149e2d0a67 in blk_set_enable_write_cache (blk=0x5614a01c27f0, wce=<optimized out>) at ../src/block/block-backend.c:1951
+#6  0x000056149dfe9c59 in scsi_disk_apply_mode_select (p=0x7fd6b400c00e "\004", page=<optimized out>, s=<optimized out>) at ../src/hw/scsi/scsi-disk.c:1520
+#7  mode_select_pages (change=true, len=18, p=0x7fd6b400c00e "\004", r=0x7fd6b4001ff0) at ../src/hw/scsi/scsi-disk.c:1570
+#8  scsi_disk_emulate_mode_select (inbuf=<optimized out>, r=0x7fd6b4001ff0) at ../src/hw/scsi/scsi-disk.c:1640
+#9  scsi_disk_emulate_write_data (req=0x7fd6b4001ff0) at ../src/hw/scsi/scsi-disk.c:1934
+#10 0x000056149e18ff16 in virtio_scsi_handle_cmd_req_submit (req=<optimized out>, req=<optimized out>, s=0x5614a12f16b0) at ../src/hw/scsi/virtio-scsi.c:719
+#11 virtio_scsi_handle_cmd_vq (vq=0x7fd6bab92140, s=0x5614a12f16b0) at ../src/hw/scsi/virtio-scsi.c:761
+#12 virtio_scsi_handle_cmd (vq=<optimized out>, vdev=<optimized out>) at ../src/hw/scsi/virtio-scsi.c:775
+#13 virtio_scsi_handle_cmd (vdev=0x5614a12f16b0, vq=0x7fd6bab92140) at ../src/hw/scsi/virtio-scsi.c:765
+#14 0x000056149e1a8aa6 in virtio_queue_notify_vq (vq=0x7fd6bab92140) at ../src/hw/virtio/virtio.c:2365
+#15 0x000056149e3ccea5 in aio_dispatch_handler (ctx=ctx@entry=0x5614a01babe0, node=<optimized out>) at ../src/util/aio-posix.c:369
+#16 0x000056149e3cd868 in aio_dispatch_ready_handlers (ready_list=0x7fd6c09b2680, ctx=0x5614a01babe0) at ../src/util/aio-posix.c:399
+#17 aio_poll (ctx=0x5614a01babe0, blocking=blocking@entry=true) at ../src/util/aio-posix.c:713
+#18 0x000056149e2a7796 in iothread_run (opaque=opaque@entry=0x56149ffde500) at ../src/iothread.c:67
+#19 0x000056149e3d0859 in qemu_thread_start (args=0x7fd6c09b26f0) at ../src/util/qemu-thread-posix.c:504
+#20 0x00007fd6c36b9ea7 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
+#21 0x00007fd6c35d9aef in clone () from /lib/x86_64-linux-gnu/libc.so.6
+```
+
+The crash was bisected to:
+
+```
+commit b1c073490553f80594b903ceedfc7c1aef6b1b19
+Author: Hanna Reitz <hreitz@redhat.com>
+Date:   Tue Mar 29 11:35:45 2022 +0200
+
+    main-loop: Disable GLOBAL_STATE_CODE() assertions
+```
+
+I have not been able to reproduce the bug with a linux guest nor with a fresh windows installation.
+
+The crashes appears with either `writethrough` and `directsync` cache modes but not with `writeback` `none` and `unsafe`.
+
+Note: if needed I can extract (privately) provide a disk image demonstrating the behavior
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1273 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1273
new file mode 100644
index 00000000..46b1a7e5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1273
@@ -0,0 +1 @@
+QEMU log problem
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1275 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1275
new file mode 100644
index 00000000..3b816433
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1275
@@ -0,0 +1,9 @@
+javac command stuck forever in qemu vm which does not use hardware virtualization
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1276 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1276
new file mode 100644
index 00000000..aacb6a83
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1276
@@ -0,0 +1,15 @@
+[SDL] Fractional scaling is blurry
+Description of problem:
+The display looks blurry
+Steps to reproduce:
+1. Use a Wayland compositor (eg. Sway) with scale set to `1.25`
+2. Launch an Ubuntu guest with the SDL display
+3. Notice blurryness
+Additional information:
+https://github.com/libsdl-org/SDL/issues/6438
+
+Blurry display https://user-images.githubusercontent.com/67585967/197484538-fde750aa-8982-4ac2-9d83-3861f6411a31.png
+
+Display with 1.00 scale https://user-images.githubusercontent.com/67585967/197484417-afd1d1c5-5ea1-46ce-82c5-fa8d9b2df459.png
+
+It was suggested in the SDL issue (https://github.com/libsdl-org/SDL/issues/6438#issuecomment-1289513402) that it's caused by the `SDL_WINDOW_ALLOW_HIGHDPI` not being set. However, after setting that flag, the display is sharp again but it's not scaled properly (boxed) https://github.com/libsdl-org/SDL/issues/6438#issuecomment-1291663284, no idea what other changes need to be made.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1277 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1277
new file mode 100644
index 00000000..b0573ccc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1277
@@ -0,0 +1 @@
+two instructions has executed twice
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1278 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1278
new file mode 100644
index 00000000..9285e4ed
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1278
@@ -0,0 +1,6 @@
+Error creating encrypted qcow2 disk using qemu-img
+Description of problem:
+Error creating encrypted qcow2 disk using qemu-img:No crypto library supporting PBKDF in this build: Function not implemented
+![lQLPJxbQZxk1_S5mzQYqsIWtnD11kWWxA1aDadOATAA_1578_102](/uploads/7bc8327c1289a22839a3272eb1352bbb/lQLPJxbQZxk1_S5mzQYqsIWtnD11kWWxA1aDadOATAA_1578_102.png)
+Steps to reproduce:
+1.qemu-img create --object secret,id=sec0,data=123456 -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 base.qcow2 1G
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/128 b/gitlab/issues_text/target_missing/host_missing/accel_missing/128
new file mode 100644
index 00000000..7ebb0a81
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/128
@@ -0,0 +1 @@
+man page is missing suboptions for "-display"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1282 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1282
new file mode 100644
index 00000000..798e7727
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1282
@@ -0,0 +1,3 @@
+sdhci: DMA reentrancy issue leads to an infinite loop
+Description of problem:
+When sdhci transfers multiple blocks, it doesnot check if the dma-write buffer pointer overlaps with its MMIO region, crafted content can cause DoS because of infinite loop and CPU consumption.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1283 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1283
new file mode 100644
index 00000000..4d210525
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1283
@@ -0,0 +1,82 @@
+Live migration cause scsi_req_unref: Assertion `req->refcount > 0' failed
+Description of problem:
+During live migration, copy file from one folder to another. Migration can succeed. After a while, copy can't finish and in target host qemu crash:
+```
+qemu-system-x86_64: ../hw/scsi/scsi-bus.c:1366: scsi_req_unref: Assertion `req->refcount > 0' failed.
+2022-10-28 03:22:54.948+0000: shutting down, reason=crashed
+```
+libvirt configure related:
+```
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2'/>
+      <source file='/images/gen-l-vrt-295-008/swx-jd01-001-new.img'/>
+      <target dev='sda' bus='scsi'/>
+      <alias name='ua-box-volume-0'/>
+      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+    </disk>
+    <controller type='scsi' index='0' model='lsilogic'>
+      <address type='pci' domain='0x0000' bus='0x03' slot='0x01' function='0x0'/>
+    </controller>
+```
+If change `bus='scsi'` to `bus='sata'`, same test steps can pass.
+Steps to reproduce:
+1. Inside VM
+```
+fallocate -l 10G /tmp/test.img
+cp /tmp/test.img /
+```
+2. Same time, migrate VM to another server
+```
+virsh migrate --verbose --live --persistent swx-jd01-001 qemu+ssh://gen-l-vrt-294/system  --unsafe --auto-converge  --auto-converge-initial 60 --auto-converge-increment 20
+
+```
+3. After a while, cp can't finish and qemu crash on destination server with assert fail.
+Additional information:
+stack traces:
+```
+#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140544841483840) at ./nptl/pthread_kill.c:44
+#1  __pthread_kill_internal (signo=6, threadid=140544841483840) at ./nptl/pthread_kill.c:78
+#2  __GI___pthread_kill (threadid=140544841483840, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
+#3  0x00007fd3284f9476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
+#4  0x00007fd3284df7f3 in __GI_abort () at ./stdlib/abort.c:79
+#5  0x00007fd3284df71b in __assert_fail_base
+    (fmt=0x7fd328694150 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55791c97acbb "req->refcount > 0", file=0x55791c97ac7f "../hw/scsi/scsi-bus.c", line=1366, function=<optimized out>)
+    at ./assert/assert.c:92
+#6  0x00007fd3284f0e96 in __GI___assert_fail
+    (assertion=assertion@entry=0x55791c97acbb "req->refcount > 0", file=file@entry=0x55791c97ac7f "../hw/scsi/scsi-bus.c", line=line@entry=1366, function=function@entry=0x55791c97b2a0 <__PRETTY_FUNCTION__.14> "scsi_req_unref") at ./assert/assert.c:101
+#7  0x000055791c499a2e in scsi_req_unref (req=<optimized out>) at ../hw/scsi/scsi-bus.c:1366
+#8  0x000055791c49b61f in scsi_device_purge_requests (sdev=sdev@entry=0x55791e6e0c00, sense=...) at ../hw/scsi/scsi-bus.c:1639
+#9  0x000055791c49d704 in scsi_disk_reset (dev=0x55791e6e0c00) at ../hw/scsi/scsi-disk.c:2336
+#10 0x000055791c72a6ed in qdev_reset_one (dev=<optimized out>, opaque=<optimized out>) at ../hw/core/qdev.c:254
+#11 0x000055791c726fa9 in qbus_walk_children
+    (bus=<optimized out>, pre_devfn=0x55791c728770 <qdev_prereset>, pre_busfn=0x55791c7286a0 <qbus_prereset>, post_devfn=0x55791c72a6e0 <qdev_reset_one>, post_busfn=0x55791c728ae0 <qbus_reset_one>, opaque=0x0) at ../hw/core/bus.c:54
+#12 0x000055791c72a790 in qdev_walk_children
+    (opaque=0x0, post_busfn=0x55791c728ae0 <qbus_reset_one>, post_devfn=0x55791c72a6e0 <qdev_reset_one>, pre_busfn=0x55791c7286a0 <qbus_prereset>, pre_devfn=0x55791c728770 <qdev_prereset>, dev=0x55791ed2a430) at ../hw/core/qdev.c:413
+#13 qdev_reset_all (dev=0x55791ed2a430) at ../hw/core/qdev.c:272
+#14 0x000055791c688134 in memory_region_write_accessor (mr=mr@entry=0x55791ed2ae60, addr=20, value=value@entry=0x7fd32559f618, size=size@entry=1, shift=<optimized out>, mask=mask@entry=255, attrs=...)
+    at ../softmmu/memory.c:492
+#15 0x000055791c6858c6 in access_with_adjusted_size
+     (addr=addr@entry=20, value=value@entry=0x7fd32559f618, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55791c6880b0 <memory_region_write_accessor>, mr=0x55791ed2ae60, attrs=...) at ../softmmu/memory.c:554
+#16 0x000055791c689bf2 in memory_region_dispatch_write (mr=mr@entry=0x55791ed2ae60, addr=20, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../softmmu/memory.c:1521
+#17 0x000055791c690cf0 in flatview_write_continue (fv=fv@entry=0x55791e729ac0, addr=addr@entry=4257226772, attrs=...,
+    attrs@entry=..., ptr=ptr@entry=0x7fd328d36028, len=len@entry=1, addr1=<optimized out>, l=<optimized out>, mr=0x55791ed2ae60) at /opt/qemu/include/qemu/host-utils.h:166
+#18 0x000055791c690fb0 in flatview_write (fv=0x55791e729ac0, addr=addr@entry=4257226772, attrs=attrs@entry=..., buf=buf@entry=0x7fd328d36028, len=len@entry=1) at ../softmmu/physmem.c:2867
+#19 0x000055791c694799 in address_space_write (len=1, buf=0x7fd328d36028, attrs=..., addr=4257226772, as=0x55791d08a740 <address_space_memory>) at ../softmmu/physmem.c:2963
+#20 address_space_rw (as=0x55791d08a740 <address_space_memory>, addr=4257226772, attrs=attrs@entry=..., buf=buf@entry=0x7fd328d36028, len=1, is_write=<optimized out>) at ../softmmu/physmem.c:2973
+#21 0x000055791c71d19e in kvm_cpu_exec (cpu=cpu@entry=0x55791dc9d890) at ../accel/kvm/kvm-all.c:2954
+#22 0x000055791c71e6c5 in kvm_vcpu_thread_fn (arg=arg@entry=0x55791dc9d890) at ../accel/kvm/kvm-accel-ops.c:49
+#23 0x000055791c885be1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:504
+#24 0x00007fd32854bb43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
+#25 0x00007fd3285dcbb4 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100
+```
+Guest disk partition
+```
+root@swx-jd01-001:~# lsblk
+NAME                          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
+sda                             8:0    0   64G  0 disk 
+├─sda1                          8:1    0  512M  0 part /boot/efi
+├─sda2                          8:2    0    1K  0 part 
+└─sda5                          8:5    0 63.5G  0 part 
+  ├─vgwin--dbausdhrjgi-root   253:0    0 62.6G  0 lvm  /
+  └─vgwin--dbausdhrjgi-swap_1 253:1    0  980M  0 lvm  [SWAP]
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1284 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1284
new file mode 100644
index 00000000..a59cb93f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1284
@@ -0,0 +1,14 @@
+macOS QXL VGA not available
+Description of problem:
+```
+qemu-system-aarch64: QXL VGA not available
+```
+```
+qemu-system-aarch64: -device qxl-vga: 'qxl-vga' is not a valid device model name
+```
+Steps to reproduce:
+1. Build QEMU on macOS with SPICE support (meson)
+2. Run commands listed above
+3. Observe QXL not working
+Additional information:
+I'm wiring up QEMU SPICE support on Darwin for Nixpkgs. The same issue can be observed in macports qemu builds with spice. Could this be a packaging issue?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1285 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1285
new file mode 100644
index 00000000..1d54d4bc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1285
@@ -0,0 +1,20 @@
+Can't use spice-app on macOS because GIO can't find handler for spice+unix scheme
+Description of problem:
+```
+qemu-system-aarch64: info: Launching display with URI: spice+unix:///tmp/.U96NU1/spice.sock
+qemu-system-aarch64: warning: GLib-GIO: No default handler found for url scheme 'spice+unix'.
+qemu-system-aarch64: warning: GLib-GIO: No default handler found for url scheme 'spice+unix'.
+qemu-system-aarch64: Failed to launch spice+unix:///tmp/.U96NU1/spice.sock URI: Operation not supported
+qemu-system-aarch64: You need a capable Spice client, such as virt-viewer 8.0
+```
+
+```
+$ virt-viewer --version
+virt-viewer version 11.0
+```
+Steps to reproduce:
+1. Have virt-viewer in $PATH
+2. Run command above
+3. Observe error above
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1286 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1286
new file mode 100644
index 00000000..2c2a847b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1286
@@ -0,0 +1 @@
+netdev tftp option docs don't mention that the TFTP server is read-only
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1287 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1287
new file mode 100644
index 00000000..bd5cb113
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1287
@@ -0,0 +1,10 @@
+qemu-img info foo.qcow2 tries to get write lock
+Description of problem:
+When trying to run qemu-img info on an image which is used by QEMU qemu-img tries to acquire a write lock. Ideally this would not attempt to acquire a write lock and let qemu-img info succeed.
+```
+[jelle@t14s][/tmp]%qemu-img info /var/tmp/cockpit-qr_j3e_m.qcow2
+qemu-img: Could not open '/var/tmp/cockpit-qr_j3e_m.qcow2': Failed to get shared "write" lock
+Is another process using the image [/var/tmp/cockpit-qr_j3e_m.qcow2]?
+```
+Steps to reproduce:
+1. Run qemu-img on an image used by a QEMU process.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1288 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1288
new file mode 100644
index 00000000..2da59d85
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1288
@@ -0,0 +1,9 @@
+GPU passing through guest crashes
+Description of problem:
+First and foremost, I don't know if this is a QEMU, KVM or GPU driver issue.
+I began emailing libvirt project and they advised me to contact you, then KVM and then GPU driver developer(NVIDIA).
+Host is crashing from time to time. I have guest's kernel dumps(~2GB each).
+Steps to reproduce:
+Unfortunately, I don't have steps to reproduce.
+Additional information:
+I'm aware I'm not running the latest qmeu version but I'm willing to install developer version and try to reproduce or test patch if developer requires it.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1289 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1289
new file mode 100644
index 00000000..9a7e3266
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1289
@@ -0,0 +1 @@
+plugin get registers
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/129 b/gitlab/issues_text/target_missing/host_missing/accel_missing/129
new file mode 100644
index 00000000..73556468
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/129
@@ -0,0 +1,12 @@
+Build failure due to conflicts with the C++20 version header
+Steps to reproduce:
+qemu 5.2.0:
+```
+brew install -s qemu
+```
+
+qemu 6.0.0:
+```
+wget https://raw.githubusercontent.com/Homebrew/homebrew-core/02107501a48cc9d08480913ee1c79866dc60c23a/Formula/qemu.rb
+brew install -s qemu.rb
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1290 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1290
new file mode 100644
index 00000000..b89932ef
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1290
@@ -0,0 +1 @@
+IO alignment probing delivers incorrect results on Linux when used with e.g. dm-crypt
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1291 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1291
new file mode 100644
index 00000000..749609a2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1291
@@ -0,0 +1 @@
+--enable-jemalloc configure option is not covered in CI
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1292 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1292
new file mode 100644
index 00000000..3a8f71db
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1292
@@ -0,0 +1,3 @@
+Default jemalloc config doesn't work on Asahi Linux
+Description of problem:
+M1 Macs use 16KB pages, jemalloc builds with 4KB page by default.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1294 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1294
new file mode 100644
index 00000000..3f1c562e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1294
@@ -0,0 +1 @@
+pflash size check appears to be incompatible with OVMF on x86
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1295 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1295
new file mode 100644
index 00000000..2a587c59
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1295
@@ -0,0 +1,27 @@
+configure script can fail if compiler flag `-Wunused-parameter` is enabled
+Description of problem:
+`configure` fails with an error message:
+
+```
+ERROR: SafeStack is only supported by the coroutine backend ucontext
+```
+Steps to reproduce:
+1. Run `./configure --cross-prefix=x86_64-w64-mingw32- --disable-werror --extra-cflags=-Wunused-parameter`
+Additional information:
+Last part of `config.log`:
+
+```
+x86_64-w64-mingw32-gcc -m64 -mcx16 -I/mingw64/include -Wunused-parameter -fno-pie -mthreads -std=gnu11 -Wall -fno-pie -no-pie -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 -Werror -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -L/mingw64/lib -no-pie
+config-temp/qemu-conf.c: In function ‘main’:
+config-temp/qemu-conf.c:1:14: error: unused parameter ‘argc’ [-Werror=unused-parameter]
+    1 | int main(int argc, char *argv[])
+      |          ~~~~^~~~
+config-temp/qemu-conf.c:1:26: error: unused parameter ‘argv’ [-Werror=unused-parameter]
+    1 | int main(int argc, char *argv[])
+      |                    ~~~~~~^~~~~~
+cc1: all warnings being treated as errors
+```
+
+The configure script fails because it tries to compile small C programs with a main function which is declared with arguments `argc` and `argv` although those arguments are unused.
+
+Using the same compiler flag for a native build (`./configure --disable-werror --extra-cflags=-Wunused-parameter`) shows the same errors in `config.log`, but surprisingly does not fail.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1296 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1296
new file mode 100644
index 00000000..97f9ca2b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1296
@@ -0,0 +1,8 @@
+qemu hangs on start with a bridged NIC
+Description of problem:
+qemu hangs on start with a bridged NIC. And there is no difference exists the bridge or not. At the same with a user NIC (`-nic user`) everything works flawlessly. Also I tried to add `-enable-kvm` key and had no luck.
+Steps to reproduce:
+1. Run qemu with the specified command line.
+Additional information:
+I ran the strace: `strace -s 1024 -tt -ff -y -o qemu_bridge -- qemu-system-x86_64 -nic bridge`
+Here are the logs: [qemu-bridge-strace.zip](/uploads/ecf8a2ba9133279fdd6f88fda5dd9ff3/qemu-bridge-strace.zip)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1300 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1300
new file mode 100644
index 00000000..ae817905
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1300
@@ -0,0 +1,11 @@
+Build failure when configuring CONFIG_VHOST_USER_FS/CONFIG_VIRTIO
+Description of problem:
+Attempting to configure CONFIG_VHOST_USER_FS or CONFIG_VIRTIO results in a build failure. Complete build log (with configure output) is attached.
+Steps to reproduce:
+1. Add `CONFIG_VIRTIO` and `CONFIG_VHOST_USER_FS` (`y` *or* `n`) to `configs/devices/x86_64-softmmu/gentoo.mak` (done via the [ebuild](https://github.com/gentoo/gentoo/blob/master/app-emulation/qemu/qemu-7.1.0.ebuild))
+2. Configure with `--with-devices-x86_64=gentoo`
+3. Attempt building
+Additional information:
+[build.log](/uploads/72fc1284f5245d9384e521d3b1c65953/build.log)
+
+Reported downstream [here](https://bugs.gentoo.org/873190).
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1302 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1302
new file mode 100644
index 00000000..808f3772
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1302
@@ -0,0 +1,17 @@
+Per-thread logging flag must be made immutable
+Description of problem:
+The problem is that the code assumes it isn't possible to switch from global logging to per-thread logging and vice-versa per design, but it lags appropriate checks to enforce it. Enabling or disabling per-thread logging at runtime from the monitor causes unexpected results.
+Steps to reproduce:
+Enabling per-thread logging at runtime:
+
+1. Start QEMU : `./qemu-system-x86_64 -S -monitor stdio -D qemu.log.%d`
+2. Enable per-thread logging from the HMP monitor : `(qemu) log tid`
+3. Fails with `Filename template with '%d' required for 'tid'` even though such a template was passed with `-D`.
+
+Disabling per-thread logging at runtime:
+
+1. Start QEMU : `./qemu-system-x86_64 -S -monitor stdio -D qemu.log.%d -d tid,cpu_reset`
+2. Disable per-thread logging from the HMP monitor: `(qemu) log cpu_reset`
+3. QEMU creates a log file with a bogus `qemu.log.%d` name.
+Additional information:
+[Series](https://patchew.org/QEMU/20221104120059.678470-1-groug@kaod.org/) posted and already reviewed by @rth7680 .
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1304 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1304
new file mode 100644
index 00000000..e17491e1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1304
@@ -0,0 +1,9 @@
+loadvm for arm vexpress-a9
+Description of problem:
+
+Steps to reproduce:
+1. savevm test
+2. loadvm test
+3. After I execute savevm and loadvm,the guest is not responding
+Additional information:
+I have read this issue(https://github.com/panda-re/panda/issues/643). If secure is set to off,the guest works well. But I need to use  security extensions,so secure cannot be set to off.What do I need to do  to solve this problem？
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1305 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1305
new file mode 100644
index 00000000..044848f0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1305
@@ -0,0 +1,14 @@
+qemu will detach usbredir if backend chardev socket disconnect
+Description of problem:
+When using the usbredir device in the VM, initiate a hot migration to the VM.  
+After the migration is completed, the drive letter of the usb in the VM has changed.  
+Actually the device has been unplugged and re-plugged in the VM.  
+I think we should keep the plugged state of the device after the migration?
+Steps to reproduce:
+1. Start a usbredirserver `usbredirserver -p 7000 -v 4 5-2`;
+2. Start a VM with a usbredir device attached to it;
+3. Mount the usb device in the VM;
+4. Migrate the VM, after the migration done, wait a minute，the drive letter of the usb in the VM has changed.
+Additional information:
+I've found this bug https://bugzilla.redhat.com/show_bug.cgi?id=1254971, this is just to allow the chardev to be reconnected in time when it is disconnected.   
+Can we make chardev reconnect without unpluging the usbredir device?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1307 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1307
new file mode 100644
index 00000000..9e90d8ad
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1307
@@ -0,0 +1,72 @@
+query-named-block-nodes, without flat=true, is massively slow as number of block nodes increases
+Description of problem:
+The query-named-block-nodes command is insanely slow with deep backing chains when the flat=true arg is NOT given.
+
+```
+qemu-img create demo0.qcow2 1g
+j=0
+for i in `seq 1 199`
+do 
+    qemu-img create -f qcow2 -o backing_file=demo$j.qcow2 -o backing_fmt=qcow2 demo$i.qcow2
+    j=$i
+done
+```
+
+Now configure libvirt with
+
+```
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2' discard='unmap'/>
+      <source file='/var/lib/libvirt/images/demo199.qcow2'/>
+      <target dev='vdb' bus='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/>
+    </disk>
+```
+
+This results in `-blockdev` args
+
+```
+-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo0.qcow2","node-name":"libvirt-201-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-201-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-201-storage","backing":null}' \
+-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo1.qcow2","node-name":"libvirt-200-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-200-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-200-storage","backing":"libvirt-201-format"}' \
+-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo2.qcow2","node-name":"libvirt-199-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-199-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-199-storage","backing":"libvirt-200-format"}' \
+...snip...
+-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo197.qcow2","node-name":"libvirt-4-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-4-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-4-storage","backing":"libvirt-5-format"}' \
+-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo198.qcow2","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-3-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-3-storage","backing":"libvirt-4-format"}' \
+-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo199.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-1-format","read-only":false,"discard":"unmap","driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-3-format"}' \
+-device '{"driver":"virtio-blk-pci","bus":"pci.7","addr":"0x0","drive":"libvirt-1-format","id":"virtio-disk1"}' \
+```
+
+Now stop libvirt
+
+```
+systemctl stop libvirtd
+```
+
+And speak directly to QMP
+
+```
+$ time socat UNIX:/var/lib/libvirt/qemu/domain-158-fedora38/monitor.sock - > /dev/null 
+{ "execute": "qmp_capabilities", "arguments": { "enable": ["oob"] } }
+{ "execute": "query-named-block-nodes"}
+{ "execute": "quit" }
+
+real	2m19.276s
+user	0m0.006s
+sys	0m0.014s
+```
+
+If we save the 'query-named-block-nodes' output instead of sending it to /dev/null, we get a 86 MB file for the QMP response. This will break all known client apps since they limit QMP reply size.
+
+It appears to have a combinatorial expansion of block nodes in the output.
+
+Blocking the main event loop for 2 minutes is obviously not good either.
+
+If we use '"flat": true' parameter to query-named-block-nodes, the command completes in just 15 seconds, and produces a large, but more manageable 2.7 MB
+
+Since the non-flat  query-named-block-nodes output is so incredibly non-scalable, I think we should deprecate non-flat mode, and eventually make  flat the mandatory option.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1308 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1308
new file mode 100644
index 00000000..cffbaa93
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1308
@@ -0,0 +1 @@
+Qemu headless build process is stopped, complaining about a missing pixman.h
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1309 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1309
new file mode 100644
index 00000000..b5c69d10
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1309
@@ -0,0 +1 @@
+Heap-overflow in virtio_net_queue_enable
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1310 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1310
new file mode 100644
index 00000000..c07d208d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1310
@@ -0,0 +1,190 @@
+qemu-nbd export img and detect block if is zero with libnbd
+Description of problem:
+In our project,we use qemu-nbd to export a img,and use libnbd to read/write data.if the img is preallocated,we wonder the data block if is zero,we use api nbd_block_status in libnbd to get the block status,but it shows server does not support structured replies: Operation not supported.I know our qemu is too old.so,i want to know how can i know if the block in preallocated is zero or not in nbd client.
+Steps to reproduce:
+1.qemu-nbd -p 8889 -f raw a.img
+
+2.the nbd client use libnbd,code is:
+```c
+#include <config.h>
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <assert.h>
+#include <stdbool.h>
+#include <errno.h>
+
+#include <libnbd.h>
+
+static const char *bitmap;
+
+struct data {
+  bool req_one;    /* input: true if req_one was passed to request */
+  int count;       /* input: count of expected remaining calls */
+  bool fail;       /* input: true to return failure */
+  bool seen_base;  /* output: true if base:allocation encountered */
+  bool seen_dirty; /* output: true if qemu:dirty-bitmap encountered */
+};
+
+static int
+cb (void *opaque, const char *metacontext, uint64_t offset,
+    uint32_t *entries, size_t len, int *error)
+{
+  struct data *data = opaque;
+
+  /* libnbd does not actually verify that a server is fully compliant
+   * to the spec; the asserts marked [qemu-nbd] are thus dependent on
+   * the fact that qemu-nbd is compliant.  Furthermore, qemu 5.2 and
+   * 6.0 disagree on whether base:allocation includes the hole bit for
+   * the zeroes at 512k (both answers are compliant); but we care more
+   * that the zeroes show up in the dirty bitmap
+   */
+  assert (offset == 0);
+  assert (!*error || (data->fail && data->count == 1 && *error == EPROTO));
+  assert (data->count-- > 0); /* [qemu-nbd] */
+
+  if (strcmp (metacontext, LIBNBD_CONTEXT_BASE_ALLOCATION) == 0) {
+    assert (!data->seen_base); /* [qemu-nbd] */
+    data->seen_base = true;
+    if (data->req_one)
+      assert (len == 2); /* [qemu-nbd] */
+    else
+      assert ((len & 1) == 0 && len > 2); /* [qemu-nbd] */
+
+    /* Data block offset 0 size 128k */
+    assert (entries[0] == 131072); assert (entries[1] == 0);
+    if (!data->req_one) {
+      if (len == 4) {
+        /* hole|zero offset 128k size 896k */
+        assert (entries[2] == 917504);
+        assert (entries[3] == (LIBNBD_STATE_HOLE|
+                               LIBNBD_STATE_ZERO));
+      }
+      else {
+        assert (len == 8);
+        /* hole|zero offset 128k size 384k */
+        assert (entries[2] == 393216);
+        assert (entries[3] == (LIBNBD_STATE_HOLE|
+                               LIBNBD_STATE_ZERO));
+        /* allocated zero offset 512k size 64k */
+        assert (entries[4] ==  65536);
+        assert (entries[5] == LIBNBD_STATE_ZERO);
+        /* hole|zero offset 576k size 448k */
+        assert (entries[6] == 458752);
+        assert (entries[7] == (LIBNBD_STATE_HOLE|
+                               LIBNBD_STATE_ZERO));
+      }
+    }
+  }
+  else if (strcmp (metacontext, bitmap) == 0) {
+    assert (!data->seen_dirty); /* [qemu-nbd] */
+    data->seen_dirty = true;
+    assert (len == (data->req_one ? 2 : 10)); /* [qemu-nbd] */
+
+    assert (entries[0] ==  65536); assert (entries[1] == 0);
+    if (!data->req_one) {
+      /* dirty block offset 64K size 64K */
+      assert (entries[2] ==  65536); assert (entries[3] == 1);
+      assert (entries[4] == 393216); assert (entries[5] == 0);
+      /* dirty block offset 512K size 64K */
+      assert (entries[6] ==  65536); assert (entries[7] == 1);
+      assert (entries[8] == 458752); assert (entries[9] == 0);
+    }
+  }
+  else {
+    fprintf (stderr, "unexpected context %s\n", metacontext);
+    exit (EXIT_FAILURE);
+  }
+
+  if (data->fail) {
+    /* Something NBD servers can't send */
+    *error = data->count == 1 ? EPROTO : ECONNREFUSED;
+    return -1;
+  }
+  return 0;
+}
+
+int
+main (int argc, char *argv[])
+{
+  struct nbd_handle *nbd;
+  int64_t exportsize;
+  struct data data;
+  char c;
+
+  if (argc < 3) {
+    fprintf (stderr, "%s bitmap qemu-nbd [args ...]\n", argv[0]);
+    exit (EXIT_FAILURE);
+  }
+  bitmap = argv[1];
+
+  nbd = nbd_create ();
+  if (nbd == NULL) {
+    fprintf (stderr, "%s\n", nbd_get_error ());
+    exit (EXIT_FAILURE);
+  }
+
+  nbd_add_meta_context (nbd, LIBNBD_CONTEXT_BASE_ALLOCATION);
+  nbd_add_meta_context (nbd, bitmap);
+
+  if (nbd_connect_tcp (nbd, argv[2],argv[3]) == -1) {
+    fprintf (stderr, "%s\n", nbd_get_error ());
+    exit (EXIT_FAILURE);
+  }
+
+  exportsize = nbd_get_size (nbd);
+  if (exportsize == -1) {
+    fprintf (stderr, "%s\n", nbd_get_error ());
+    exit (EXIT_FAILURE);
+  }
+
+  data = (struct data) { .count = 2, };
+  if (nbd_block_status (nbd, exportsize, 0,
+                        (nbd_extent_callback) { .callback = cb, .user_data = &data },
+                        0) == -1) {
+    fprintf (stderr, "%s\n", nbd_get_error ());
+    exit (EXIT_FAILURE);
+  }
+  assert (data.seen_base && data.seen_dirty);
+
+  data = (struct data) { .req_one = true, .count = 2, };
+  if (nbd_block_status (nbd, exportsize, 0,
+                        (nbd_extent_callback) { .callback = cb, .user_data = &data },
+                        LIBNBD_CMD_FLAG_REQ_ONE) == -1) {
+    fprintf (stderr, "%s\n", nbd_get_error ());
+    exit (EXIT_FAILURE);
+  }
+  assert (data.seen_base && data.seen_dirty);
+
+  /* Trigger a failed callback, to prove connection stays up. */
+  data = (struct data) { .count = 2, .fail = true, };
+  if (nbd_block_status (nbd, exportsize, 0,
+                        (nbd_extent_callback) { .callback = cb, .user_data = &data },
+                        0) != -1) {
+    fprintf (stderr, "unexpected block status success\n");
+    exit (EXIT_FAILURE);
+  }
+  assert (nbd_get_errno () == EPROTO && nbd_aio_is_ready (nbd));
+  assert (data.seen_base && data.seen_dirty);
+
+  if (nbd_pread (nbd, &c, 1, 0, 0) == -1) {
+    fprintf (stderr, "%s\n", nbd_get_error ());
+    exit (EXIT_FAILURE);
+  }
+
+  if (nbd_shutdown (nbd, 0) == -1) {
+    fprintf (stderr, "%s\n", nbd_get_error ());
+    exit (EXIT_FAILURE);
+  }
+
+  nbd_close (nbd);
+
+  exit (EXIT_SUCCESS);
+}
+
+```
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1311 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1311
new file mode 100644
index 00000000..382158be
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1311
@@ -0,0 +1 @@
+riscv-qemu can't record interrupt
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1312 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1312
new file mode 100644
index 00000000..883708f9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1312
@@ -0,0 +1,11 @@
+TCP performance problems - GSO/TSO, MSS, 8139 related (Ignores lower MTU from PMTUD/MSS)
+Description of problem:
+MTU handling on guests using an RTL8139 virtualized NIC is broken; net/hw/8139.c works with a static MTU of 1500b for TCP offloading, leading to low throughput when clients connect from sub 1500MTU networks. PMTUD is ignored, and locking to a lower MTU in the OS mitigates the issue.
+Steps to reproduce:
+1. Create a guest with an RTL8139 nic
+2. Try to retrieve a file from a client behind a sub 1500 MTU link
+3. Observe low bandwidth due to retransmits
+Additional information:
+I just debugged this issue for an NGO which, for whatever reason, had an RTL8139 NIC in their guest. After i finally traced this to the RTL8139, i found this qemu-devel/netdev thread from six years ago, which apparently already debugged this issue and proposed a patch: https://lore.kernel.org/all/20161114162505.GD26664@stefanha-x1.localdomain/
+
+I did not test the patch proposed there, but note that `net/hw/8139.c` still looks as discussed in that qemu-devel/netdev thread. As i haven't found a bug report in the archives, i figured you might want to know.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1315 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1315
new file mode 100644
index 00000000..d4be1d04
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1315
@@ -0,0 +1 @@
+Assertion failure in vmxnet3_activate_device
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1316 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1316
new file mode 100644
index 00000000..95571fb6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1316
@@ -0,0 +1 @@
+qemu.qmp.protocol.ConnectError: Failed to establish connection: AF_UNIX path too long (on Darwin)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1317 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1317
new file mode 100644
index 00000000..1b402657
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1317
@@ -0,0 +1,49 @@
+"make-check avocado" doesn't work in ubuntu 1804 because of older versions of pip and setuputils
+Description of problem:
+make check-avocado tests don't run in Ubuntu 18.04, I get an error:
+
+`Command "python setup.py egg_info" failed with error code 1 in /qemu/python/`
+
+It looks like pip and setuputils are too old in 18.04 (which is still an active lts version supposedly).
+Steps to reproduce:
+Compile qemu in Ubuntu 18.04. This is an ad-hoc example with docker but I reproduced it in Ubuntu 18.04 VM too
+1. Create docker from Dockerfile [Dockerfile](/uploads/a5748cabca5319f467cbc0b803ed9104/Dockerfile):
+
+<code>FROM ubuntu:18.04
+RUN apt update
+RUN apt-get install -y git libglib2.0-dev libfdt-dev libpixman-1-dev zlib1g-dev ninja-build git-email libaio-dev libbluetooth-dev libcapstone-dev libbrlapi-dev libbz2-dev libcap-ng-dev libcurl4-gnutls-dev libgtk-3-dev libibverbs-dev libjpeg8-dev libncurses5-dev libnuma-dev librbd-dev librdmacm-dev libsasl2-dev libsdl2-dev libseccomp-dev libsnappy-dev libssh-dev libvde-dev libvdeplug-dev libvte-2.91-dev libxen-dev liblzo2-dev valgrind xfslibs-dev python3-venv</code>
+
+`docker build -t 1804qemuavocado .`
+
+2. Run shell inside of docker:
+
+`docker run -it 1804qemuavocado bash`
+
+3. Clone QEMU:
+
+`git clone --depth 1 https://github.com/qemu/qemu.git`
+
+4. Build QEMU (targets and parameters should not matter much):
+
+<code>cd qemu
+mkdir build
+cd build
+../configure --target-list=x86_64-softmmu
+ninja</code>
+
+5. Attempt to run tests:
+
+`make check-avocado`
+
+6. Get an error:
+
+<code>/usr/bin/python3 -B /qemu/meson/meson.py introspect --targets --tests --benchmarks | /usr/bin/python3 -B scripts/mtest2make.py > Makefile.mtest
+  GIT     ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc
+  GIT     ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc
+  VENV    /qemu/build/tests/venv
+  VENVPIP install -e /qemu/python/
+Command "python setup.py egg_info" failed with error code 1 in /qemu/python/
+/qemu/tests/Makefile.include:115: recipe for target '/qemu/build/tests/venv' failed
+make: *** [/qemu/build/tests/venv] Error 1</code>
+Additional information:
+As far as I understand, upgrading pip in system won't help, because venv creates an environment with base pip version (9 in case of Ubuntu 18.04). I tried creating a small patch [patch.diff](/uploads/0ae4883106773f0ea940d27b74219732/patch.diff) for tests/Makefile.include, that upgrades pip and setuputils in venv to the latest version, and it seem to help, but I don't know if it's the right solution to always have the latest version. Probably some LTS version should be chosen, if such thing exists for pip.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1318 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1318
new file mode 100644
index 00000000..768b1408
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1318
@@ -0,0 +1,19 @@
+vsock device fails with "qemu-system-x86_64: vhost_set_features failed: Operation not supported (95)" when queue_reset=true
+Description of problem:
+Immediately after guest vsock driver initialize, qemu prints error messages.  I'm not able to connect to the guest with vsock:
+
+```
+[    0.654463] Run /init as init process
+[    0.679778] NET: Registered PF_VSOCK protocol family
+qemu-system-x86_64: vhost_set_features failed: Operation not supported (95)
+qemu-system-x86_64: Error starting vhost: 95
+ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519 
+# 
+```
+Steps to reproduce:
+1. Clone `git://passt.top/passt`
+2. In `passt/test`, run `make mbuto.img`
+3. Run `qemu-system-x86_64 -enable-kvm -m 2048 -kernel KERNEL -initrd mbuto.img -nographic -serial stdio -nodefaults -append "console=ttyS0" -device vhost-vsock-pci,guest-cid=31415,queue_reset=true` replacing KERNEL with the host kernel image.
+Additional information:
+- Problem goes away if `queue_reset=false`, which means it goes away with default options prior to `69e1c14aa222` ("virtio: core: vq reset feature negotation support")
+- Occurs both with and without KVM
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1319 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1319
new file mode 100644
index 00000000..79f10594
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1319
@@ -0,0 +1,13 @@
+Build warnings when building qemu with 'disable-tcg' for ppc64-softmmu target
+Description of problem:
+Building recent upstream qemu (HEAD 2c8311241d) for 'ppc64-softmmu' target is failing due to following build warnings:
+
+<snip>
+ ../target/ppc/cpu_init.c:7018:13: error: 'ppc_restore_state_to_opc' defined but not used [-Werror=unused-function]
+ 7018 | static void ppc_restore_state_to_opc(CPUState *cs,
+<snip>
+Steps to reproduce:
+1. $ git clone --recurse-submodules https://gitlab.com/qemu-project/qemu.git 
+2. ./configure --target-list=ppc64-softmmu --disable-tcg && make
+Additional information:
+Patch for this issue has been posted and reviewed at https://lore.kernel.org/all/20221116131743.658708-1-vaibhav@linux.ibm.com/
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1321 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1321
new file mode 100644
index 00000000..613214ec
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1321
@@ -0,0 +1,8 @@
+qemu-system-i386 runs slow after upgrading legacy project from qemu 2.9.0  to 7.1.0
+Description of problem:
+Using several custom serial and irq devices including timers.
+The same code (after some customisation in order to compile with new 7.1.0 API and meson build system runs about 50% slower.
+We had to remove "-icount 4" switch which worked fine with 2.9.0 just to get to this point.
+Even running with multi-threaded tcg did not help.
+We don't use the new ptimer API but rather the old QEMUTimer.
+Any suggestions to why we encounter this vast performance degradation?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1322 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1322
new file mode 100644
index 00000000..9c5b8c36
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1322
@@ -0,0 +1 @@
+Unknown protocol 'ssh'
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1329 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1329
new file mode 100644
index 00000000..355cd0e0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1329
@@ -0,0 +1,12 @@
+Screen doesn't update until mouse pointer moves over it
+Description of problem:
+When changing the color scheme in CDE, the screen should change 
+color everywhere at once, but doesn't do so. It only updates 
+in the area where the mouse moves. And there it does so over 
+the whole width of the screen .
+Steps to reproduce:
+1. Change color scheme in CDE
+2. Move around mouse pointer
+Additional information:
+Screen capture of the problem
+https://youtu.be/qZJzACIxSuk
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/133 b/gitlab/issues_text/target_missing/host_missing/accel_missing/133
new file mode 100644
index 00000000..3f5ebd11
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/133
@@ -0,0 +1 @@
+Chardev websocket might not support pasting more than a few chars
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1330 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1330
new file mode 100644
index 00000000..2fa32996
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1330
@@ -0,0 +1,182 @@
+qemu-img finishes successfully while having errors in commit or bitmaps operations
+Description of problem:
+Problem raises when trying to merge two images with the top image almost
+full, and base image having stale bitmaps (bitmaps missing from
+the top image).
+In our usercase, the size of the LV that contains the base image is not
+accounting for the stale bitmaps, and therefore, when we run `commit` or
+`bitmap --merge`, it fails with:
+```
+qcow2_free_clusters failed: No space left on device
+qemu-img: Lost persistent bitmaps during inactivation of node '#block308': Failed to write bitmap 'stale-bitmap-002' to file: No space left on device
+qemu-img: Failed to flush the refcount block cache: No space left on device
+```
+However, in both cases `qemu-img` returned successfully,
+while having logs printed to `stderr`, and failing the merge.
+
+For commit operation, the data was commited successfully, it failed as it
+was adding the bitmaps.
+Still, the process exit with success.
+
+On the other hand, for bitmaps operation, since its main purpose is to
+manipulate bitmaps, and it failed, it should not return with code 0.
+The process shall return with error code.
+Also, bitmaps in the base image are left with the `in-use` flag set.
+Steps to reproduce:
+1. Create these lvs and chown them to the user
+```
+sudo lvcreate --name base.qcow2 --size 128m storage
+sudo chown $USER:$USER /dev/mapper/storage-base.qcow2
+sudo lvcreate --name top.qcow2 --size 128m storage
+sudo chown $USER:$USER /dev/mapper/storage-top.qcow2
+```
+2. Run this python script. Note the `STALE_BITMAPS` counter. Using 6, 11, or 13 stale
+   bitmaps, the `commit`, or the `bitmaps` operations shall fail.
+```
+# Reproduce ENOSPC error when merging into base image with lot of bitmaps.
+
+import json
+import subprocess
+
+IMG_SIZE = 1 << 30
+LV_SIZE = 128 << 20
+
+# Testing shows that we can merge successfully with 13 bitmaps, and require
+# size calculation is more strict, allowing up to 11 bitamps.
+STALE_BITMAPS = 11
+
+def run(*cmd):
+    subprocess.run(cmd, check=True)
+
+def output(cmd):
+    cp = subprocess.run(cmd, stdout=subprocess.PIPE, check=True)
+    return json.loads(cp.stdout)
+
+def info(img):
+    return output(["qemu-img", "info", "--output", "json", img])
+
+def measure(img):
+    return output(["qemu-img", "measure", "-f", "qcow2", "-O", "qcow2", "--output", "json", img])
+
+def check(img):
+    cmd = ["qemu-img", "check", "-f", "qcow2", "--output", "json", img]
+    cp = subprocess.run(cmd, stdout=subprocess.PIPE)
+    if cp.returncode not in (0, 3):
+        raise RuntimeError(f"Check failed")
+
+    return json.loads(cp.stdout)
+
+def indent(info):
+    return json.dumps(info, indent=2)
+
+base = "/dev/mapper/storage-base.qcow2"
+top = "/dev/mapper/storage-top.qcow2"
+
+# Start with clean lvs by discarding current data.
+run("blkdiscard", base)
+run("blkdiscard", top)
+
+print("Creating base")
+run("qemu-img", "create", "-f", "qcow2", base, str(IMG_SIZE))
+
+# Simulate stale bitmaps - missing in top.
+for i in range(STALE_BITMAPS):
+    bitmap = f"stale-bitmap-{i:03d}"
+    print(f"Creating stale bitmap {bitmap}")
+    run("qemu-img", "bitmap", "--add", base, bitmap)
+
+print("Info base before merge")
+base_info = info(base)
+print(indent(base_info))
+
+print("Check base before merge")
+base_check = check(base)
+print(indent(base_check))
+
+print("Measure base before merge")
+base_measure = measure(base)
+print(indent(base_measure))
+
+print("Creating top")
+run("qemu-img", "create", "-f", "qcow2", "-b", base, "-F", "qcow2", top)
+
+print("Adding good bitmap to top")
+run("qemu-img", "bitmap", "--add", top, "good-bitmap")
+
+print("Writing data to top")
+cmd = f"write -P {ord('B')} 0 126m"
+run("qemu-io", "-f", "qcow2", "-c", cmd, top)
+
+print("Info top before merge")
+top_info = info(top)
+print(indent(top_info))
+
+print("Check top before merge")
+top_check = check(top)
+print(indent(top_check))
+
+print("Measure top before merge")
+top_measure = measure(top)
+print(indent(top_measure))
+
+print("Commit top into base")
+run("qemu-img", "commit", "-f", "qcow2", "-t", "none", "-b", base, "-d", "-p", top)
+
+print("Add good bitmap to base")
+run("qemu-img", "bitmap", "--add", base, "good-bitmap")
+
+print("Merge good bitmap from top to base")
+run("qemu-img", "bitmap", "--merge", "good-bitmap", "-F", "qcow2", "-b", top,  base, "good-bitmap")
+
+print("Info base after merge")
+print(indent(info(base)))
+
+print("Check base after merge")
+print(indent(check(base)))
+
+print("Measure base after merge")
+print(indent(measure(base)))
+```
+Additional information:
+Example output of the script with 6 stale bitmaps:
+```
+Commit top into base
+    (100.00/100%)
+Image committed.
+Add good bitmap to base
+Merge good bitmap from top to base
+qcow2_free_clusters failed: No space left on device
+qemu-img: Lost persistent bitmaps during inactivation of node '#block159': Failed to write bitmap 'good-bitmap' to file: No space left on device
+qemu-img: Failed to flush the refcount block cache: No space left on device
+Info base after merge
+{
+  "virtual-size": 1073741824,
+  "filename": "/dev/mapper/storage-base.qcow2",
+  "cluster-size": 65536,
+  "format": "qcow2",
+  "actual-size": 0,
+  "format-specific": {
+    "type": "qcow2",
+    "data": {
+      "compat": "1.1",
+      "compression-type": "zlib",
+      "lazy-refcounts": false,
+      "bitmaps": [
+        ...
+        {
+          "flags": [
+            "in-use",
+            "auto"
+          ],
+          "name": "good-bitmap",
+          "granularity": 65536
+        }
+      ],
+      "refcount-bits": 16,
+      "corrupt": false,
+      "extended-l2": false
+    }
+  },
+  "dirty-flag": false
+}
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1334 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1334
new file mode 100644
index 00000000..3b2cd344
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1334
@@ -0,0 +1 @@
+qemu-img map qcow2 image,but can't get right zero area
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1335 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1335
new file mode 100644
index 00000000..23416da4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1335
@@ -0,0 +1 @@
+hot to dump bitmap to disk
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1336 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1336
new file mode 100644
index 00000000..e115cff7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1336
@@ -0,0 +1 @@
+QEMU qxl_phys2virt Unsafe Address Translation Lead to OOB Read
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1337 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1337
new file mode 100644
index 00000000..43bfefaa
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1337
@@ -0,0 +1,16 @@
+Incorrect warnings when using vhost without numa
+Description of problem:
+Part A: Misleading error message. Running the above command for any architecture fails to initialize vhost, and prints the following, incorrect advice
+```
+qemu-system-mips: Failed initializing vhost-user memory map, consider using -object memory-backend-file share=on
+qemu-system-mips: vhost_set_mem_table failed: Invalid argument (22)
+qemu-system-mips: Error starting vhost: 22
+```
+
+Since the command line already contains `-object memory-backend-file,id=mem1,mem-path=/tmp/mem,size=256M,share=on` this error message should not be printed. For x86_64, this can be resolved by adding `-numa node,memdev=mem0` to the command line. As such, I think this error message should instead guide a user to adding that argument.
+
+Part B: No documented configuration to run vhost-user for machines that don't support numa.
+The mips malta machine does not support the `-numa` flag. It is unclear if this means that `vhost` cannot be used with this platform or if a non-numa configuration with a memory-backend-file can be used.
+Steps to reproduce:
+1. Run `vhost-user-vsock --socket=/tmp/vhost4.socket --uds-path=/tmp/foo` from https://github.com/rust-vmm/vhost-device.
+1. Run the above QEMU command
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1338 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1338
new file mode 100644
index 00000000..33ec6075
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1338
@@ -0,0 +1 @@
+Remove gprof
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1340 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1340
new file mode 100644
index 00000000..e1ac8a56
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1340
@@ -0,0 +1,66 @@
+Static build fail with native aarch64 toolchain (ld failure at linking aarch64_be target)
+Description of problem:
+Do a static build on aarch64, with ArchlinuxARM native toolchain (gcc 12.1.0, binutils 2.38)
+Steps to reproduce:
+Do a static build using the following configs:
+
+```
+./configure \
+      --prefix=/usr \
+      --sysconfdir=/etc \
+      --libexecdir=/usr/lib/qemu \
+      --enable-attr \
+      --enable-linux-user \
+      --enable-tcg \
+      --disable-bpf \
+      --disable-bsd-user \
+      --disable-capstone \
+      --disable-docs \
+      --disable-fdt \
+      --disable-gcrypt \
+      --disable-glusterfs \
+      --disable-gnutls \
+      --disable-gtk \
+      --disable-install-blobs \
+      --disable-kvm \
+      --disable-libiscsi \
+      --disable-libnfs \
+      --disable-libssh \
+      --disable-linux-io-uring \
+      --disable-nettle \
+      --disable-opengl \
+      --disable-qom-cast-debug \
+      --disable-sdl \
+      --disable-system \
+      --disable-tools \
+      --disable-tpm \
+      --disable-vde \
+      --disable-vhost-crypto \
+      --disable-vhost-kernel \
+      --disable-vhost-net \
+      --disable-vhost-user \
+      --disable-vnc \
+      --disable-werror \
+      --disable-xen \
+      --disable-zstd \
+      --static
+```
+
+The build failure looks like this:
+
+```
+[466/2962] Linking target qemu-aarch64_be
+FAILED: qemu-aarch64_be
+c++  -o qemu-aarch64_be libcommon.fa.p/hw_core_cpu-common.c.o libcommon.fa.p/hw_core_machine-smp.c.o libcommon.fa.p/cpus-common.c.o libcommon.fa.p/page-vary-common.c.o libcommon.fa.p/accel_accel-user.c.o libcommon.fa.p/common-user_safe-syscall.S.o libcommon.fa.p/common-user_safe-syscall-error.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_aarch64_signal.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_aarch64_cpu_loop.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_cpu.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_crypto_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_debug_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_gdbstub.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_iwmmxt_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_m_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_mve_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_neon_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_op_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_tlb_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-m-nocp.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-mve.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-neon.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-vfp.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_vec_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_vfp_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_cpu_tcg.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_kvm-stub.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_cpu64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_gdbstub64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_helper-a64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_mte_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_pauth_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_sve_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_sme_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-a64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-sve.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-sme.c.o libqemu-aarch64_be-linux-user.fa.p/trace_control-target.c.o libqemu-aarch64_be-linux-user.fa.p/cpu.c.o libqemu-aarch64_be-linux-user.fa.p/disas.c.o libqemu-aarch64_be-linux-user.fa.p/gdbstub.c.o libqemu-aarch64_be-linux-user.fa.p/page-vary.c.o libqemu-aarch64_be-linux-user.fa.p/semihosting_guestfd.c.o libqemu-aarch64_be-linux-user.fa.p/semihosting_syscalls.c.o libqemu-aarch64_be-linux-user.fa.p/semihosting_arm-compat-semi.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_optimize.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_region.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-common.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-op.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-op-gvec.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-op-vec.c.o libqemu-aarch64_be-linux-user.fa.p/fpu_softfloat.c.o libqemu-aarch64_be-linux-user.fa.p/accel_accel-common.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_tcg-all.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_cpu-exec-common.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_cpu-exec.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_tcg-runtime-gvec.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_tcg-runtime.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_translate-all.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_translator.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_user-exec.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_user-exec-stub.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_elfload.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_exit.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_fd-trans.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_linuxload.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_main.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_mmap.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_signal.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_strace.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_syscall.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_thunk.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_uaccess.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_uname.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_flatload.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_semihost.c.o libqemu-aarch64_be-linux-user.fa.p/meson-generated_.._aarch64_be-linux-user-gdbstub-xml.c.o -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libhwcore.fa libqom.fa -Wl,--start-group libevent-loop-base.a -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -static-pie -fstack-protector-strong -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -Wp,-D_GLIBCXX_ASSERTIONS -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now libqemuutil.a libhwcore.fa libqom.fa /usr/lib/libz.a -lrt -lm -pthread -lgthread-2.0 -lglib-2.0 -lpcre2-8 -lsysprof-capture-4 -lstdc++ -Wl,--end-group
+/usr/bin/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../../lib/libglib-2.0.a(gutils.c.o): in function `g_get_user_database_entry':
+(.text+0x324): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+/usr/bin/ld: (.text+0xf4): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+/usr/bin/ld: (.text+0xe0): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+/usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../../lib/libc.a(init-first.o): in function `__libc_init_first':
+(.text+0x10): relocation truncated to fit: R_AARCH64_LD64_GOTPAGE_LO15 against symbol `__environ' defined in .bss section in /usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../../lib/libc.a(environ.o)
+/usr/bin/ld: (.text+0x10): warning: too many GOT entries for -fpic, please recompile with -fPIC
+collect2: error: ld returned 1 exit status
+distcc[61410] ERROR: compile (null) on localhost failed
+```
+Additional information:
+Full [meson-log.txt](/uploads/05059722cb81b10bd9977a17fd51f048/meson-log.txt) and [config.log](/uploads/1cbd8a5fe5c48c3af83e1cbba6a89ce8/config.log)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1341 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1341
new file mode 100644
index 00000000..f30172c0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1341
@@ -0,0 +1,78 @@
+Static build failure with clang (clang 14.0.6)
+Description of problem:
+Static build failure with redefinition of 'iovec'.
+
+The configure looks like this:
+
+```
+  export CC=clang
+  ../$pkgbase-$pkgver/configure \
+      --prefix=/usr \
+      --sysconfdir=/etc \
+      --libexecdir=/usr/lib/qemu \
+      --enable-attr \
+      --enable-linux-user \
+      --enable-tcg \
+      --disable-bpf \
+      --disable-bsd-user \
+      --disable-capstone \
+      --disable-docs \
+      --disable-fdt \
+      --disable-gcrypt \
+      --disable-glusterfs \
+      --disable-gnutls \
+      --disable-gtk \
+      --disable-install-blobs \
+      --disable-kvm \
+      --disable-libiscsi \
+      --disable-libnfs \
+      --disable-libssh \
+      --disable-linux-io-uring \
+      --disable-nettle \
+      --disable-opengl \
+      --disable-qom-cast-debug \
+      --disable-sdl \
+      --disable-system \
+      --disable-tools \
+      --disable-tpm \
+      --disable-vde \
+      --disable-vhost-crypto \
+      --disable-vhost-kernel \
+      --disable-vhost-net \
+      --disable-vhost-user \
+      --disable-vnc \
+      --disable-werror \
+      --disable-xen \
+      --disable-zstd \
+      --static
+```
+
+The compiling failure looks like this:
+```
+FAILED: libqom.fa.p/qom_object.c.o
+clang -Ilibqom.fa.p -I. -I../qemu-7.1.0 -Iqapi -Itrace -Iui/shader -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/adam/qemu-user-static/src/qemu-7.1.0/linux-headers -isystem linux-headers -iquote . -iquote /home/adam/qemu-user-static/src/qemu-7.1.0 -iquote /home/adam/qemu-user-static/src/qemu-7.1.0/include -iquote /home/adam/qemu-user-static/src/qemu-7.1.0/tcg/aarch64 -pthread -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-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -Wno-missing-braces -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fPIE -MD -MQ libqom.fa.p/qom_object.c.o -MF libqom.fa.p/qom_object.c.o.d -o libqom.fa.p/qom_object.c.o -c ../qemu-7.1.0/qom/object.c
+distcc[94580] (dcc_build_somewhere) Warning: failed to distribute, running locally instead
+clang-14: warning: argument unused during compilation: '-fstack-clash-protection' [-Wunused-command-line-argument]
+In file included from ../qemu-7.1.0/qom/object.c:13:
+/home/adam/qemu-user-static/src/qemu-7.1.0/include/qemu/osdep.h:517:8: error: redefinition of 'iovec'
+struct iovec {
+       ^
+/usr/include/bits/types/struct_iovec.h:26:8: note: previous definition is here
+struct iovec
+       ^
+In file included from ../qemu-7.1.0/qom/object.c:13:
+/home/adam/qemu-user-static/src/qemu-7.1.0/include/qemu/osdep.h:524:9: warning: 'IOV_MAX' macro redefined [-Wmacro-redefined]
+#define IOV_MAX 1024
+        ^
+/usr/include/bits/xopen_lim.h:66:10: note: previous definition is here
+# define IOV_MAX __IOV_MAX
+         ^
+1 warning and 1 error generated.
+distcc[94580] ERROR: compile ../qemu-7.1.0/qom/object.c on localhost failed
+ninja: build stopped: subcommand failed.
+```
+Steps to reproduce:
+1. Compile qemu using above configure and use clang as the compiler
+Additional information:
+Full meson log:
+[meson-log.txt](/uploads/a63d609852148140e8fa7210c6912982/meson-log.txt)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1342 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1342
new file mode 100644
index 00000000..47664e45
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1342
@@ -0,0 +1,24 @@
+Default machine setting of force-legacy=true causes problems for any modern VirtIO device using MMIO
+Description of problem:
+The default causes problems if you enable any non-legacy VirtIO device which has the VIRTIO_F_VERSION_1 feature bit will not properly read all feature bits. This is because reading VIRTIO_MMIO_VERSION returns VIRT_VERSION_LEGACY which in turn results in the driver not reading all feature bits, e.g. the qtest access:
+
+```
+static uint64_t qvirtio_mmio_get_features(QVirtioDevice *d)
+{
+    QVirtioMMIODevice *dev = container_of(d, QVirtioMMIODevice, vdev);
+    uint64_t lo;
+    uint64_t hi = 0;
+
+    qtest_writel(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES_SEL, 0);
+    lo = qtest_readl(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES);
+
+    if (dev->version >= 2) {
+        qtest_writel(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES_SEL, 1);
+        hi = qtest_readl(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES);
+    }
+
+    return (hi << 32) | lo;
+}
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1345 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1345
new file mode 100644
index 00000000..8a359338
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1345
@@ -0,0 +1 @@
+qemu-img manpage and  is missing info on compression_type option
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1346 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1346
new file mode 100644
index 00000000..5a4bee36
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1346
@@ -0,0 +1,35 @@
+simulate x86_64 virtio-gpu-gl qemu report error
+Description of problem:
+when I run the below command, it can run ok, and myos can get the virtio-gpu feature,but it less 3d feature.
+   ```
+   ./qemu-system-x86_64 -nographic -M q35 -m 1024 -cpu Nehalem -smp 8 -kernel myos -device virtio-gpu
+   ```
+so I delete ```-nographic``` and modify the device to :
+```
+-device virtio-gpu-gl -display sdl,gl=on
+```
+but qemu tells me ERROR:
+```
+qemu-system-x86_64: ../ui/console-gl.c:105: surface_gl_update_texture: Assertion `gls' failed.
+```
+Additional information:
+I modify the code qemu/ui/sdl2-gl.c function sdl2_gl_switch():
+
+`    
+#if 0
+if (is_placeholder(new_surface) && qemu_console_get_index(dcl->con)) {
+        qemu_gl_fini_shader(scon->gls);
+        scon->gls = NULL;
+        sdl2_window_destroy(scon);
+        return;
+    }
+#endif
+`
+and, qemu can run myos with ```-nographic```, and i can get 3d feature:
+   ```
+   ./qemu-system-x86_64 -nographic -M q35 -m 1024 -cpu Nehalem -smp 8 -kernel myos -device virtio-gpu-gl -display sdl,gl=on
+   ```
+
+I think there is something bug.
+
+thanks
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1349 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1349
new file mode 100644
index 00000000..af885029
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1349
@@ -0,0 +1,7 @@
+Windows Installer Error
+Description of problem:
+Windows Installer Barfs
+Steps to reproduce:
+1. Either run exe installer or do ```scoop update -g "qemu" ```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/135 b/gitlab/issues_text/target_missing/host_missing/accel_missing/135
new file mode 100644
index 00000000..f25fee50
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/135
@@ -0,0 +1 @@
+Cant compile qemu from source, get error about static declaration of memfd_create following non-static declaration
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1351 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1351
new file mode 100644
index 00000000..a8a26003
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1351
@@ -0,0 +1,5 @@
+qemu-system-x86_64  run win7 qcow2 got an exception
+Description of problem:
+when qemu-system-X86-64 run the win7 qcow2,  qemu got an exception
+
+\*\* ERROR:../target/i386/tcg/sysemu/excp_helper.c:517:raise_stage2: code should not be reached Aborted (核心已转储)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1352 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1352
new file mode 100644
index 00000000..a7049fdd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1352
@@ -0,0 +1 @@
+Building hw-display-virtio-*-gl modules with empty source set
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1354 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1354
new file mode 100644
index 00000000..212863b6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1354
@@ -0,0 +1 @@
+-device usb-tablet not working on android guest.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1355 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1355
new file mode 100644
index 00000000..10936852
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1355
@@ -0,0 +1 @@
+qemu-system-x86_64: Issue while setting TUNSETSTEERINGEBPF: Invalid argument with fd: 13, prog_fd: -1
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1356 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1356
new file mode 100644
index 00000000..d4e62b2d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1356
@@ -0,0 +1,17 @@
+"-set device" doesn't work with device specified in json
+Description of problem:
+The above QEMU command line results in:
+```
+qemu-system-x86_64: -set device.ua-igd.x-igd-gms=1: there is no device "ua-igd" defined
+```
+While the following command works:
+```
+qemu-system-x86_64 -accel kvm -m 8192 -nodefaults -display none -net none -device vfio-pci,host=0000:00:02.0,id=ua-igd -set device.ua-igd.x-igd-gms=1
+```
+libvirt has moved to the json device specification, therefore I can no longer associate use a <qemu:commandline> section to set driver options for a specific device with this broken id association.
+Steps to reproduce:
+1. Create a device with an ID and use -set device.$ID to set a driver option for the device
+2. Note failure when using json device format vs legacy device specification
+3. Profit
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1357 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1357
new file mode 100644
index 00000000..dbfcf753
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1357
@@ -0,0 +1,9 @@
+qemu-img should generate VMDK with an EOS marker when `has_marker` flag enabled
+Additional information:
+I generate a empty volume with capacity 1G and try to deploy it as a part of OVF. This would fail. 
+
+But when I append an EOS marker to that VMDK, which is actually a zeroed sector, the deployed procedure succeeded.
+
+This case merely happened if VMDK has data, since `qemu-img` always write at least one grain(64 KB). So the padding part will be recognized as  EOS marker.
+
+I have written a temporary patch for this and it works fine for me. I'm glad to send it for review.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1358 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1358
new file mode 100644
index 00000000..d7e54c54
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1358
@@ -0,0 +1 @@
+Remove CPUState::trace_dstate
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1359 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1359
new file mode 100644
index 00000000..793aa8fe
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1359
@@ -0,0 +1 @@
+open virtual format
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/136 b/gitlab/issues_text/target_missing/host_missing/accel_missing/136
new file mode 100644
index 00000000..7670ccaa
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/136
@@ -0,0 +1 @@
+windows qemu-img create vpc/vhdx error
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1360 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1360
new file mode 100644
index 00000000..1a5771e7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1360
@@ -0,0 +1,19 @@
+Starting using WSL fails even if the same image is valid when starting qemu directly from windows
+Description of problem:
+I'm trying to follow a rust tutorial on writing a custom OS in rust. https://os.phil-opp.com/minimal-rust-kernel/
+The problem occurse when trying to run qemu from wsl. If I run qemu from a windows command line everything works as expected. 
+If I run the os calling qemu (installed on windows) from wsl it fails with 
+
+```
+ERROR:../../../block.c:1715:bdrv_open_driver: assertion failed: (is_power_of_2(bs->bl.request_alignment))
+Bail out! ERROR:../../../block.c:1715:bdrv_open_driver: assertion failed: (is_power_of_2(bs->bl.request_alignment))
+```
+
+I also found an old bug report that seemed to be the same issue in the old issue tracker: https://bugs.launchpad.net/qemu/+bug/1893807
+Steps to reproduce:
+1. Sample code can be found at `https://github.com/phil-opp/blog_os` branch: `post-02`
+2. create wsl environment
+3. run `cargo install bootimage` only required on the once to install bootimage
+4. run `cargo build`
+5. run `cargo bootimage` to create the image
+6. `qemu-system-x86_64 -drive format=raw,file=target/x86_64-blog_os/debug/bootimage-blog-os.bin`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1362 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1362
new file mode 100644
index 00000000..4e8e4c4a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1362
@@ -0,0 +1,75 @@
+BLKZEROOUT ioct/write requests getting split a weird boundary (and for no apparent reason?)
+Description of problem:
+i was investigating into some performance weirdness with passthrough/directly-mapped SAS vs. SATA disk, which seems to relate to detect_zeroes feature (see https://forum.proxmox.com/threads/disk-passthrough-performance-weirdness.118943/#post-516599 ).
+
+apparently, writing zeroes to passtrough/direct-mapped sas disk ( ST4000NM0034 ) in virtual machine is MUCH slower then sata disk ( HGST HDN728080AL ). 
+
+with detect_zeroes=on (default in proxmox) , qemu converts writes of zeroes into BLKZEROOUT ioctl issued to the target disk, and my sas disk is much much slower with this (<80MB/s in comparison to the sata disk with 200MB/s). 
+
+i found that the sas disk needs 0.01s on average for this ioctl to finish, whereas sata disk needs 0.004s.   
+
+writing zeroes to the device directly is at about 200MB/s for both of them, so having detect_zeroes=on a default does not seem to be an advantage on all circumstances.
+
+anyway, i have made a weird observation during analysis:
+
+inside the virtual machine, i'm writing to the virtual disk like this:
+
+```
+dd if=/dev/zero of=/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 bs=1024k count=1024 oflag=direct 
+
+(scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 mapped to scsi-35000c500836b1c73 / SAS on the host, scsi-0QEMU_QEMU_HARDDISK_drive-scsi2 mapped to ata-HGST_HDN728080ALE604_VJGDNX5X )
+
+```
+
+on the HOST i'm attaching to the kvm process with strace , every time i issue the above dd inside VM, kvm/qemu process issues BLKZEROOUT to the device in a different way, i.e. either 
+
+- within a single ioctl at originating 1048576 byte size (=1024k)
+or
+- split into 2 ioctl with  1040384+8192(=1048576)
+or
+- split into 2 ioctl with 1044480+4096(=1048576)
+
+
+why does kvm/qemu sometimes split the write request and sometimes not ? and why at such a weird boundary just below 1Mb?
+
+
+i don't know if this is a bug, but at least it looks weird to me, that's why i'm reporting
+
+```
+
+root@pve:~/util-linux/sys-utils# strace -T -f -p 18897  -e trace=all 2>&1 |grep BLK|head
+[pid 65413] ioctl(19, BLKZEROOUT, [0, 1048576] <unfinished ...>
+[pid 65412] ioctl(19, BLKZEROOUT, [1048576, 1048576] <unfinished ...>
+[pid 65366] ioctl(19, BLKZEROOUT, [2097152, 1048576] <unfinished ...>
+[pid 65413] ioctl(19, BLKZEROOUT, [3145728, 1048576] <unfinished ...>
+[pid 65412] ioctl(19, BLKZEROOUT, [4194304, 1048576]) = 0 <0.011287>
+[pid 65366] ioctl(19, BLKZEROOUT, [5242880, 1048576]) = 0 <0.012025>
+[pid 65413] ioctl(19, BLKZEROOUT, [6291456, 1048576]) = 0 <0.011377>
+[pid 65412] ioctl(19, BLKZEROOUT, [7340032, 1048576] <unfinished ...>
+[pid 65366] ioctl(19, BLKZEROOUT, [8388608, 1048576] <unfinished ...>
+[pid 65413] ioctl(19, BLKZEROOUT, [9437184, 1048576]) = 0 <0.011705>
+
+# strace -T -f -p 18897  -e trace=all 2>&1 |grep BLK|head
+[pid 65878] ioctl(19, BLKZEROOUT, [0, 1040384] <unfinished ...>
+[pid 65413] ioctl(19, BLKZEROOUT, [1040384, 8192] <unfinished ...>
+[pid 65366] ioctl(19, BLKZEROOUT, [1048576, 1040384] <unfinished ...>
+[pid 65878] ioctl(19, BLKZEROOUT, [2088960, 8192] <unfinished ...>
+[pid 65413] ioctl(19, BLKZEROOUT, [2097152, 1040384] <unfinished ...>
+[pid 65366] ioctl(19, BLKZEROOUT, [3137536, 8192] <unfinished ...>
+[pid 65413] ioctl(19, BLKZEROOUT, [3145728, 1040384] <unfinished ...>
+[pid 65878] ioctl(19, BLKZEROOUT, [4186112, 8192] <unfinished ...>
+[pid 65366] ioctl(19, BLKZEROOUT, [4194304, 1040384] <unfinished ...>
+[pid 65413] ioctl(19, BLKZEROOUT, [5234688, 8192] <unfinished ...>
+
+root@pve:~/util-linux/sys-utils# strace -T -f -p 18897  -e trace=all 2>&1 |grep BLK|head
+[pid 66591] ioctl(19, BLKZEROOUT, [0, 1044480] <unfinished ...>
+[pid 66592] ioctl(19, BLKZEROOUT, [1044480, 4096] <unfinished ...>
+[pid 66593] ioctl(19, BLKZEROOUT, [1048576, 1044480] <unfinished ...>
+[pid 66584] ioctl(19, BLKZEROOUT, [2093056, 4096] <unfinished ...>
+[pid 66585] ioctl(19, BLKZEROOUT, [2097152, 1044480] <unfinished ...>
+[pid 66565] ioctl(19, BLKZEROOUT, [3141632, 4096] <unfinished ...>
+[pid 66591] ioctl(19, BLKZEROOUT, [3145728, 1044480] <unfinished ...>
+[pid 66592] ioctl(19, BLKZEROOUT, [4190208, 4096] <unfinished ...>
+[pid 66584] ioctl(19, BLKZEROOUT, [4194304, 1044480] <unfinished ...>
+[pid 66593] ioctl(19, BLKZEROOUT, [5238784, 4096] <unfinished ...
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1365 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1365
new file mode 100644
index 00000000..5a53908f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1365
@@ -0,0 +1,24 @@
+qemu on m1 mac loses network connection after some time running
+Description of problem:
+While running qemu with podman machine on m1 mac, after a while the network connections will stop answering.
+When running with the console window dmesg will start showing the following messages
+```
+uq: 0x1, name: output.0, 2263286224 uses ago
+[37689.0770611 virtio_net virtioo emposi: TX timeout on queue: 0, sq: output.o, uq: 0x1, name: output.0, 2268226224 uses ago
+[37693.7877481 virtio_net virtio@ emposi: TX timeout on queue: 0, sq: output.o, uq: 0x1, name: output.0, 2273326224 uses ago
+[37698.3116991 virtio_net virtioo emposi: TX timeout on queue: 0, sq: output.o, uq: 0x1, name: output.0, 2278226224 uses ago
+[37702.9616661 virtio_net virtioo emposi: TX timeout on queue: 0, sq: output.o, uq: 0x1, name: output.0, 2283266224 uses ago
+[37707.5462551 virtio_net virtiod empos1: IX timeout on queue: 0, sq: output.O, ug: Ox1, name: output.O, 2288226224 usecs ago
+[37712.205242) virtio_net virtio@ enposI: IX timeout on queue: 0, sq: output.o, uq: 0x1, name: output. 0, 2293276224 uses ago
+[37716.7708171 virtio_net virtiod enpOsi: IX timeout on queue: 0, sq: output.o, uq: 0x1, name: output. 0, 2298226224 uses ago
+
+```
+Steps to reproduce:
+1. Run `/opt/homebrew/bin/qemu-system-aarch64 -m 12048 -smp 8 -fw_cfg name=opt/com.coreos/config,file=$HOME/.config/containers/podman/machine/qemu/podman-machine-default.ign -qmp unix:$TEMP/podman/qmp_podman-machine-default.sock,server=on,wait=off -netdev socket,id=vlan,fd=3 -device virtio-net-pci,netdev=vlan,mac=5a:94:ef:e4:0c:ee -device virtio-serial -chardev socket,path=$TEMP/podman/podman-machine-default_ready.sock,server=on,wait=off,id=apodman-machine-default_ready -device virtserialport,chardev=apodman-machine-default_ready,name=org.fedoraproject.port.0 -pidfile $TEMP/podman/podman-machine-default_vm.pid -accel hvf -accel tcg -cpu host -M virt,highmem=on -drive file=/opt/homebrew/share/qemu/edk2-aarch64-code.fd,if=pflash,format=raw,readonly=on -drive file=$HOME/.local/share/containers/podman/machine/qemu/podman-machine-default_ovmf_vars.fd,if=pflash,format=raw -virtfs local,path=$HOME,mount_tag=vol0,security_model=mapped-xattr -drive if=virtio,file=$HOME/.local/share/containers/podman/machine/qemu/podman-machine-default_fedora-coreos-37.20221127.2.0-qemu.aarch64.qcow2`
+2. Keep using the system and eventually `ssh localhost
+3.
+Additional information:
+network configuration
+![image](/uploads/9ca7b1aa00aee2d3b9151881988ea393/image.png)
+
+I will try to add more info as I get them
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1366 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1366
new file mode 100644
index 00000000..b75affe7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1366
@@ -0,0 +1,84 @@
+Data inconsistency on LVM logical volume mounted as partition on ubuntu guest, when the written file's size is equal or greater than 27G.
+Description of problem:
+On the guest, writing a 27Gib file or larger result in inconsistent file checksum upon subsequent read.
+Steps to reproduce:
+**On the host**
+
+0. Create a LVM logical volume on a Linux RAID 1 (with 1 disk only)
+
+```
+ --- Logical volume ---
+  LV Path                /dev/davidahw2-vg4/lv0
+  LV Name                lv0
+  VG Name                davidahw2-vg4
+  LV UUID                5FbDcl-eSDe-7cXL-22tj-Lg6O-79AL-4Gq7gx
+  LV Write Access        read/write
+  LV Creation host, time davida-hw2, 2021-12-06 16:45:00 +0800
+  LV Status              available
+  # open                 1
+  LV Size                <7.28 TiB
+  Current LE             1907688
+  Segments               1
+  Allocation             inherit
+  Read ahead sectors     auto
+  - currently set to     256
+  Block device           253:4
+
+  --- Segments ---
+  Logical extents 0 to 1907687:
+    Type                linear
+    Physical volume     /dev/md4
+    Physical extents    0 to 1907687
+```
+
+1. Format the logical volume as ext4 
+
+```
+mkfs -t ext4 /dev/davidahw2-vg4/lv0
+```
+
+2. Create a libvirt x86 64bits Ubuntu 22.04 machine mounting a LVM logical volume
+
+```
+<controller type='scsi' index='1' model='virtio-scsi'><driver queues='8' iothread='2'/></controller>
+
+
+<disk type='block' device='disk'>
+      <driver name='qemu' type='raw'/>
+      <source dev='/dev/davidahw2-vg4/lv0'/>
+      <target dev='sdd' bus='scsi'/>
+      <blockio logical_block_size='512' physical_block_size='4096'/>
+      <address type='drive' controller='1' bus='0' target='1' unit='0'/>
+</disk>
+```
+
+
+**On the guest**
+
+3. Mount libvirt/qemu provided block device /dev/sdd as ext4 partition
+
+```
+mount /dev/sdd /mnt/test
+```
+
+4. Write **27G file** or larger **on the guest** causing the **2nd checksum to be different**
+
+```
+sync; head -c 27G </dev/urandom >myfile; sha256sum myfile; sha256sum myfile
+8d3b4b263961d2c510390f99879be89b4b9134dc588139ede75573be1590115b  myfile
+a8e886b3c39d9b4721e582c5e2ca25c76ff6561750ac6dc7aa7e70404661d1cf  myfile <== ERROR: Inconsistent checksum
+```
+
+5. Write **26G file** or larger **on the guest** and **both checksum are the same**
+
+```
+sync; head -c 26G </dev/urandom >myfile; sha256sum myfile; sha256sum myfile
+598ac5da9b5bfa14d0ee664ae2590e09da772cba64cbc83ec049a656223c9401  myfile
+598ac5da9b5bfa14d0ee664ae2590e09da772cba64cbc83ec049a656223c9401  myfile <== CORRECT: Consistent checksum
+```
+
+**Important**: 
+- With the VM shutdown, the same commands on the same mounted ext4 partition **on the host** has consistent checksum every time for file sizes from 20G to 40G.
+- The disk has no sign of failure (no badblocks reported to the filesystem, MD raid reports a healthy raid setup, smart reports on error)
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1367 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1367
new file mode 100644
index 00000000..eafc569f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1367
@@ -0,0 +1,5 @@
+Support MMIO devices in VFIO
+Additional information:
+- https://lore.kernel.org/qemu-devel/cover.1667542066.git.john.g.johnson@oracle.com/
+- https://github.com/nutanix/libvfio-user
+- It also *somewhat* related to supporting non-PCI devices in `ivshmem`: https://gitlab.com/qemu-project/qemu/-/issues/1134
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1369 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1369
new file mode 100644
index 00000000..9ae06b91
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1369
@@ -0,0 +1 @@
+'make vm-build-openbsd' fails to notice when QEMU fails to start
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/137 b/gitlab/issues_text/target_missing/host_missing/accel_missing/137
new file mode 100644
index 00000000..d51a9649
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/137
@@ -0,0 +1 @@
+Incompatibility with future VTE will breaks qemu monitor (::commit signal)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1378 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1378
new file mode 100644
index 00000000..39d0c151
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1378
@@ -0,0 +1,20 @@
+iSCSI causes memory corruption
+Description of problem:
+This is a compound problem, which most likely involves a combination of how TrueNAS SCALE handles iSCSI triggering a problem **and** some memory-handling issue in QEMU leading to a crash. In short any Linux machine started with iSCSI handled by QEMU directly leads to a hard crash within 30s-1h. I was able to find a pattern in logs:
+
+1. First, a message like `QEMU[53139]: kvm: iSCSI Busy/TaskSetFull/TimeOut (retry #1 in 0 ms): TASK_SET_FULL` is logged
+  - it is always `TASK_SET_FULL`
+  - it is always `retry #1 in ... ms`, where only number of miliseconds varies
+  - the line is repeated multiple times, sometimes 5x and sometimes >200x
+2. It is followed by a single line with one of the following:
+  - `double free or corruption (out)`
+  - `double free or corruption (!prev)`
+  - `kvm: ../block/block-backend.c:1567: blk_aio_write_entry: Assertion `!qiov || qiov->size == acb->bytes' failed.`
+  - `kvm: malloc.c:2379: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.`
+  - `kvm: iSCSI CheckCondition: SENSE KEY:UNIT_ATTENTION(6) ASCQ:BUS_RESET(0x2900)`
+  - `malloc(): invalid size (unsorted)`
+3. The virtual machine crashes
+Steps to reproduce:
+I don't have a specific concrete steps, only clues really. This problem started happening after TrueNAS SCALE updated their iSCSI code in Bluefin release to a new upstream version. That iSCSI server still works when iSCSI is mounted by the kernel and QEMU uses a normal `/dev` entry. While there's probably some problem with it, QEMU shouldn't probably crash with memory errors.
+Additional information:
+While I'm a software developer, I don't code in C on a daily basis. However, looking at the errors, I have a suspicion the problem may be somewhere in the `iscsi_co_generic_cb()`, as it seems the struct is getting damaged (out of bound write?) and causes explosion somewhere down the line.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1379 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1379
new file mode 100644
index 00000000..1702d6a6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1379
@@ -0,0 +1 @@
+dump memory read write operations
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/138 b/gitlab/issues_text/target_missing/host_missing/accel_missing/138
new file mode 100644
index 00000000..d0741e2e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/138
@@ -0,0 +1 @@
+Exclude keys from grab
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1380 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1380
new file mode 100644
index 00000000..d6721cf6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1380
@@ -0,0 +1,4 @@
+vdagent is not working properly after live migration
+Additional information:
+when validating on windows server 2016 Datacenter Evaluation, i found that if vdagent process or vdservice is restarted, copy/paste from host to guest or reverse will work again. i am wondering if we should send something(eg, a event?) to guest to let it reopen the port after live migration?
+![image](/uploads/706117c797b13bc8b9fe15d1e2cd81bd/image.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1381 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1381
new file mode 100644
index 00000000..cd14a192
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1381
@@ -0,0 +1,3 @@
+plugins: plugin_mem_cbs is not consistently NULL'ed when returning from execution
+Description of problem:
+This is an invariant that we should have been checking for; when returning from execution, cpu->plugin_mem_cbs should be NULL. Otherwise we open a door for a use-after-free; admittedly this door isn't that large (it requires a tb_flush to occur while we have the dangling plugin_mem_cbs), but at least one plugin user has encountered this problem: https://lists.nongnu.org/archive/html/qemu-devel/2022-11/msg02703.html
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1384 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1384
new file mode 100644
index 00000000..c9c3085e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1384
@@ -0,0 +1 @@
+Update libvfio-user to latest upstream
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1385 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1385
new file mode 100644
index 00000000..db55d641
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1385
@@ -0,0 +1 @@
+-net option doesn't work
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1386 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1386
new file mode 100644
index 00000000..8cb21776
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1386
@@ -0,0 +1,628 @@
+Qemu 7.2.0 - Failed compilation under Windows with MSYS (MINGW64)
+Description of problem:
+I follow the faq here
+
+https://wiki.qemu.org/Hosts/W32#Debian_based_cross_builds
+
+to compile qemu source under Windows with MSYS2 (MINGW64).
+Steps to reproduce:
+Follow the FAQ guide and I get
+
+```
+xxxx@DESKTOP-NBACH6G MINGW64 ~/qemu
+$ ./configure --enable-sdl --enable-gtk
+Using './build' as the directory for build output
+ln: failed to create symbolic link 'aarch64-softmmu/qemu-system-aarch64.exe': No such file or directory
+ln: failed to create symbolic link 'alpha-softmmu/qemu-system-alpha.exe': No such file or directory
+ln: failed to create symbolic link 'arm-softmmu/qemu-system-arm.exe': No such file or directory
+ln: failed to create symbolic link 'avr-softmmu/qemu-system-avr.exe': No such file or directory
+ln: failed to create symbolic link 'cris-softmmu/qemu-system-cris.exe': No such file or directory
+ln: failed to create symbolic link 'hppa-softmmu/qemu-system-hppa.exe': No such file or directory
+ln: failed to create symbolic link 'i386-softmmu/qemu-system-i386.exe': No such file or directory
+ln: failed to create symbolic link 'loongarch64-softmmu/qemu-system-loongarch64.exe': No such file or directory
+ln: failed to create symbolic link 'm68k-softmmu/qemu-system-m68k.exe': No such file or directory
+ln: failed to create symbolic link 'microblaze-softmmu/qemu-system-microblaze.exe': No such file or directory
+ln: failed to create symbolic link 'microblazeel-softmmu/qemu-system-microblazeel.exe': No such file or directory
+ln: failed to create symbolic link 'mips-softmmu/qemu-system-mips.exe': No such file or directory
+ln: failed to create symbolic link 'mips64-softmmu/qemu-system-mips64.exe': No such file or directory
+ln: failed to create symbolic link 'mips64el-softmmu/qemu-system-mips64el.exe': No such file or directory
+ln: failed to create symbolic link 'mipsel-softmmu/qemu-system-mipsel.exe': No such file or directory
+ln: failed to create symbolic link 'nios2-softmmu/qemu-system-nios2.exe': No such file or directory
+ln: failed to create symbolic link 'or1k-softmmu/qemu-system-or1k.exe': No such file or directory
+ln: failed to create symbolic link 'ppc-softmmu/qemu-system-ppc.exe': No such file or directory
+ln: failed to create symbolic link 'ppc64-softmmu/qemu-system-ppc64.exe': No such file or directory
+ln: failed to create symbolic link 'riscv32-softmmu/qemu-system-riscv32.exe': No such file or directory
+ln: failed to create symbolic link 'riscv64-softmmu/qemu-system-riscv64.exe': No such file or directory
+ln: failed to create symbolic link 'rx-softmmu/qemu-system-rx.exe': No such file or directory
+ln: failed to create symbolic link 's390x-softmmu/qemu-system-s390x.exe': No such file or directory
+ln: failed to create symbolic link 'sh4-softmmu/qemu-system-sh4.exe': No such file or directory
+ln: failed to create symbolic link 'sh4eb-softmmu/qemu-system-sh4eb.exe': No such file or directory
+ln: failed to create symbolic link 'sparc-softmmu/qemu-system-sparc.exe': No such file or directory
+ln: failed to create symbolic link 'sparc64-softmmu/qemu-system-sparc64.exe': No such file or directory
+ln: failed to create symbolic link 'tricore-softmmu/qemu-system-tricore.exe': No such file or directory
+ln: failed to create symbolic link 'x86_64-softmmu/qemu-system-x86_64.exe': No such file or directory
+ln: failed to create symbolic link 'xtensa-softmmu/qemu-system-xtensa.exe': No such file or directory
+ln: failed to create symbolic link 'xtensaeb-softmmu/qemu-system-xtensaeb.exe': No such file or directory
+The Meson build system
+Version: 0.64.1
+Source dir: C:/msys64/home/Roberto/qemu
+Build dir: C:/msys64/home/Roberto/qemu/build
+Build type: native build
+Project name: qemu
+Project version: 7.2.50
+C compiler for the host machine: cc -m64 -mcx16 (gcc 12.2.0 "cc (Rev6, Built by MSYS2 project) 12.2.0")
+C linker for the host machine: cc -m64 -mcx16 ld.bfd 2.39
+Host machine cpu family: x86_64
+Host machine cpu: x86_64
+Program scripts/symlink-install-tree.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/symlink-install-tree.py)
+Program sh found: YES (C:\msys64\usr\bin/sh.EXE)
+Program python3 found: YES (C:/msys64/mingw64/bin/python.exe)
+Program bzip2 found: YES (C:\msys64\mingw64\bin/bzip2.EXE)
+Program iasl found: NO
+Compiler for C supports link arguments -Wl,-z,relro: NO
+Compiler for C supports link arguments -Wl,-z,now: NO
+Compiler for C supports link arguments -Wl,--no-seh: YES
+Compiler for C supports link arguments -Wl,--nxcompat: YES
+C++ compiler for the host machine: c++ -m64 -mcx16 (gcc 12.2.0 "c++ (Rev6, Built by MSYS2 project) 12.2.0")
+C++ linker for the host machine: c++ -m64 -mcx16 ld.bfd 2.39
+Compiler for C++ supports link arguments -Wl,--warn-common: YES
+Program cgcc found: NO
+Library m found: YES
+Run-time dependency threads found: YES
+Library util found: NO
+Program midl found: NO
+Program widl found: YES
+Library pathcch found: YES
+Library ws2_32 found: YES
+Library winmm found: YES
+Windows resource compiler: GNU windres (GNU Binutils) 2.39
+Has header "WinHvPlatform.h" : YES
+Has header "WinHvEmulation.h" : YES
+Run-time dependency appleframeworks found: NO (tried framework)
+Found pkg-config: C:\msys64\mingw64\bin/pkg-config.EXE (1.8.0)
+Run-time dependency gio-2.0 found: YES 2.74.3
+Program C:/msys64/mingw64/bin/gdbus-codegen found: YES (C:/msys64/mingw64/bin/gdbus-codegen.exe)
+Run-time dependency gio-unix-2.0 found: NO (tried pkgconfig)
+Run-time dependency pixman-1 found: YES 0.42.2
+Run-time dependency zlib found: YES 1.2.13
+Has header "libaio.h" : NO
+Run-time dependency liburing found: NO (tried pkgconfig)
+Run-time dependency libnfs found: YES 5.0.2
+Has header "attr/xattr.h" : NO
+Run-time dependency appleframeworks found: NO (tried framework)
+Run-time dependency appleframeworks found: NO (tried framework)
+Run-time dependency libseccomp found: NO (tried pkgconfig)
+Has header "cap-ng.h" : NO
+Run-time dependency xkbcommon found: NO (tried pkgconfig)
+Run-time dependency slirp found: YES 4.7.0
+Has header "libvdeplug.h" : NO
+Run-time dependency jack found: NO (tried pkgconfig)
+Run-time dependency sndio found: NO (tried pkgconfig)
+Run-time dependency spice-protocol found: YES 0.14.4
+Run-time dependency spice-server found: YES 0.15.1
+Library rt found: NO
+Run-time dependency libiscsi found: NO (tried pkgconfig)
+Run-time dependency libzstd found: YES 1.5.2
+Run-time dependency virglrenderer found: NO (tried pkgconfig)
+Run-time dependency blkio found: NO (tried pkgconfig)
+Run-time dependency libcurl found: YES 7.86.0
+Run-time dependency ncurses found: NO (tried pkgconfig)
+Run-time dependency ncursesw found: YES 6.3.20211021
+Has header "brlapi.h" : NO
+Run-time dependency sdl2 found: YES 2.26.1
+Run-time dependency sdl2_image found: YES 2.6.2
+Library rados found: NO
+Has header "rbd/librbd.h" : NO
+Run-time dependency glusterfs-api found: NO (tried pkgconfig)
+Run-time dependency libssh found: YES 0.10.4
+Has header "bzlib.h" : YES
+Library bz2 found: YES
+Has header "lzfse.h" : NO
+Has header "sys/soundcard.h" : NO
+Has header "dsound.h" : YES
+Run-time dependency epoxy found: YES 1.5.10
+Has header "epoxy/egl.h" with dependency epoxy: NO
+Run-time dependency gnutls found: YES 3.7.8
+Run-time dependency gmp found: YES 6.2.1
+Run-time dependency gtk+-3.0 found: YES 3.24.35
+Run-time dependency gtk+-x11-3.0 found: NO (tried pkgconfig)
+Run-time dependency vte-2.91 found: NO (tried pkgconfig)
+Run-time dependency libpng found: YES 1.6.39
+Run-time dependency libjpeg found: YES 2.1.4
+Has header "sasl/sasl.h" : YES
+Library sasl2 found: YES
+Has header "security/pam_appl.h" : NO
+Has header "snappy-c.h" : YES
+Library snappy found: YES
+Has header "lzo/lzo1x.h" : YES
+Library lzo2 found: YES
+Has header "numa.h" : NO
+Library ibumad found: NO
+Has header "rdma/rdma_cma.h" : NO
+Library ibverbs found: NO
+Run-time dependency xencontrol found: NO (tried pkgconfig)
+Library xenstore found: NO
+Library xenctrl found: NO
+Library xendevicemodel found: NO
+Library xenforeignmemory found: NO
+Library xengnttab found: NO
+Library xenevtchn found: NO
+Library xentoolcore found: NO
+Run-time dependency libcacard found: NO (tried pkgconfig)
+Run-time dependency u2f-emu found: NO (tried pkgconfig)
+Run-time dependency canokey-qemu found: NO (tried pkgconfig)
+Run-time dependency libusbredirparser-0.5 found: YES 0.8.0
+Run-time dependency libusb-1.0 found: YES 1.0.26
+Run-time dependency libpmem found: NO (tried pkgconfig)
+Run-time dependency libdaxctl found: NO (tried pkgconfig)
+Run-time dependency libtasn1 found: YES 4.19.0
+Run-time dependency libkeyutils found: NO (tried pkgconfig)
+Checking for function "gettid" : NO
+Run-time dependency libselinux found: NO (tried pkgconfig)
+Run-time dependency fuse3 found: NO (tried pkgconfig)
+Run-time dependency libbpf found: NO (tried pkgconfig)
+Checking for function "pthread_fchdir_np" : NO
+Has header "sys/epoll.h" : NO
+Has header "linux/magic.h" : NO
+Has header "valgrind/valgrind.h" : NO
+Has header "linux/btrfs.h" : NO
+Has header "libdrm/drm.h" : NO
+Has header "pty.h" : NO
+Has header "sys/disk.h" : NO
+Has header "sys/ioccom.h" : NO
+Has header "sys/kcov.h" : NO
+Has header "afunix.h" : YES
+Checking for function "close_range" : NO
+Checking for function "accept4" : NO
+Checking for function "clock_adjtime" : NO
+Checking for function "dup3" : NO
+Checking for function "fallocate" : NO
+Checking for function "posix_fallocate" : NO
+Checking for function "posix_memalign" : NO
+Checking for function "_aligned_malloc" : YES
+Checking for function "valloc" : NO
+Checking for function "memalign" : NO
+Checking for function "ppoll" : NO
+Checking for function "preadv" : NO
+Checking for function "pthread_fchdir_np" : NO (cached)
+Checking for function "sendfile" : NO
+Checking for function "setns" : NO
+Checking for function "syncfs" : NO
+Checking for function "sync_file_range" : NO
+Checking for function "timerfd_create" : NO
+Checking for function "copy_file_range" : NO
+Checking for function "getifaddrs" : NO
+Checking for function "openpty" with dependency -lutil: NO
+Checking for function "strchrnul" : NO
+Checking for function "system" : YES
+Header "byteswap.h" has symbol "bswap_32" : NO
+Header "sys/epoll.h" has symbol "epoll_create1" : NO
+Header "linux/falloc.h" has symbol "FALLOC_FL_PUNCH_HOLE" : NO
+Header "linux/falloc.h" has symbol "FALLOC_FL_ZERO_RANGE" : NO
+Has header "linux/fiemap.h" : NO
+Checking for function "getrandom" : NO
+Header "sys/inotify.h" has symbol "inotify_init" : NO
+Header "sys/inotify.h" has symbol "inotify_init1" : NO
+Header "machine/bswap.h" has symbol "bswap32" : NO
+Header "sys/prctl.h" has symbol "PR_SET_TIMERSLACK" : NO
+Header "linux/rtnetlink.h" has symbol "IFLA_PROTO_DOWN" : NO
+Header "sys/sysmacros.h" has symbol "makedev" : NO
+Header "getopt.h" has symbol "optreset" : NO
+Header "netinet/in.h" has symbol "IPPROTO_MPTCP" : NO
+Header "sys/mount.h" has symbol "FSCONFIG_SET_FLAG" : NO
+Checking whether type "struct sigevent" has member "sigev_notify_thread_id" : NO
+Checking whether type "struct stat" has member "st_atim" : NO
+Checking for type "struct iovec" : NO
+Checking for type "struct utmpx" : NO
+Checking for type "struct mmsghdr" : NO
+Header "linux/vm_sockets.h" has symbol "AF_VSOCK" : NO
+Has header "vscoordint.h" : NO
+Checking if "_lock_file and _unlock_file" : links: YES
+Program scripts/minikconf.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/minikconf.py)
+Configuring aarch64-softmmu-config-target.h using configuration
+Configuring aarch64-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/aarch64-softmmu-config-devices.mak.d
+Configuring aarch64-softmmu-config-devices.h using configuration
+Configuring alpha-softmmu-config-target.h using configuration
+Configuring alpha-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/alpha-softmmu-config-devices.mak.d
+Configuring alpha-softmmu-config-devices.h using configuration
+Configuring arm-softmmu-config-target.h using configuration
+Configuring arm-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/arm-softmmu-config-devices.mak.d
+Configuring arm-softmmu-config-devices.h using configuration
+Configuring avr-softmmu-config-target.h using configuration
+Configuring avr-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/avr-softmmu-config-devices.mak.d
+Configuring avr-softmmu-config-devices.h using configuration
+Configuring cris-softmmu-config-target.h using configuration
+Configuring cris-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/cris-softmmu-config-devices.mak.d
+Configuring cris-softmmu-config-devices.h using configuration
+Configuring hppa-softmmu-config-target.h using configuration
+Configuring hppa-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/hppa-softmmu-config-devices.mak.d
+Configuring hppa-softmmu-config-devices.h using configuration
+Configuring i386-softmmu-config-target.h using configuration
+Configuring i386-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/i386-softmmu-config-devices.mak.d
+Configuring i386-softmmu-config-devices.h using configuration
+Configuring loongarch64-softmmu-config-target.h using configuration
+Configuring loongarch64-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/loongarch64-softmmu-config-devices.mak.d
+Configuring loongarch64-softmmu-config-devices.h using configuration
+Configuring m68k-softmmu-config-target.h using configuration
+Configuring m68k-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/m68k-softmmu-config-devices.mak.d
+Configuring m68k-softmmu-config-devices.h using configuration
+Configuring microblaze-softmmu-config-target.h using configuration
+Configuring microblaze-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/microblaze-softmmu-config-devices.mak.d
+Configuring microblaze-softmmu-config-devices.h using configuration
+Configuring microblazeel-softmmu-config-target.h using configuration
+Configuring microblazeel-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/microblazeel-softmmu-config-devices.mak.d
+Configuring microblazeel-softmmu-config-devices.h using configuration
+Configuring mips-softmmu-config-target.h using configuration
+Configuring mips-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/mips-softmmu-config-devices.mak.d
+Configuring mips-softmmu-config-devices.h using configuration
+Configuring mips64-softmmu-config-target.h using configuration
+Configuring mips64-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/mips64-softmmu-config-devices.mak.d
+Configuring mips64-softmmu-config-devices.h using configuration
+Configuring mips64el-softmmu-config-target.h using configuration
+Configuring mips64el-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/mips64el-softmmu-config-devices.mak.d
+Configuring mips64el-softmmu-config-devices.h using configuration
+Configuring mipsel-softmmu-config-target.h using configuration
+Configuring mipsel-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/mipsel-softmmu-config-devices.mak.d
+Configuring mipsel-softmmu-config-devices.h using configuration
+Configuring nios2-softmmu-config-target.h using configuration
+Configuring nios2-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/nios2-softmmu-config-devices.mak.d
+Configuring nios2-softmmu-config-devices.h using configuration
+Configuring or1k-softmmu-config-target.h using configuration
+Configuring or1k-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/or1k-softmmu-config-devices.mak.d
+Configuring or1k-softmmu-config-devices.h using configuration
+Configuring ppc-softmmu-config-target.h using configuration
+Configuring ppc-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/ppc-softmmu-config-devices.mak.d
+Configuring ppc-softmmu-config-devices.h using configuration
+Configuring ppc64-softmmu-config-target.h using configuration
+Configuring ppc64-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/ppc64-softmmu-config-devices.mak.d
+Configuring ppc64-softmmu-config-devices.h using configuration
+Configuring riscv32-softmmu-config-target.h using configuration
+Configuring riscv32-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/riscv32-softmmu-config-devices.mak.d
+Configuring riscv32-softmmu-config-devices.h using configuration
+Configuring riscv64-softmmu-config-target.h using configuration
+Configuring riscv64-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/riscv64-softmmu-config-devices.mak.d
+Configuring riscv64-softmmu-config-devices.h using configuration
+Configuring rx-softmmu-config-target.h using configuration
+Configuring rx-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/rx-softmmu-config-devices.mak.d
+Configuring rx-softmmu-config-devices.h using configuration
+Configuring s390x-softmmu-config-target.h using configuration
+Configuring s390x-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/s390x-softmmu-config-devices.mak.d
+Configuring s390x-softmmu-config-devices.h using configuration
+Configuring sh4-softmmu-config-target.h using configuration
+Configuring sh4-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/sh4-softmmu-config-devices.mak.d
+Configuring sh4-softmmu-config-devices.h using configuration
+Configuring sh4eb-softmmu-config-target.h using configuration
+Configuring sh4eb-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/sh4eb-softmmu-config-devices.mak.d
+Configuring sh4eb-softmmu-config-devices.h using configuration
+Configuring sparc-softmmu-config-target.h using configuration
+Configuring sparc-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/sparc-softmmu-config-devices.mak.d
+Configuring sparc-softmmu-config-devices.h using configuration
+Configuring sparc64-softmmu-config-target.h using configuration
+Configuring sparc64-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/sparc64-softmmu-config-devices.mak.d
+Configuring sparc64-softmmu-config-devices.h using configuration
+Configuring tricore-softmmu-config-target.h using configuration
+Configuring tricore-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/tricore-softmmu-config-devices.mak.d
+Configuring tricore-softmmu-config-devices.h using configuration
+Configuring x86_64-softmmu-config-target.h using configuration
+Configuring x86_64-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/x86_64-softmmu-config-devices.mak.d
+Configuring x86_64-softmmu-config-devices.h using configuration
+Configuring xtensa-softmmu-config-target.h using configuration
+Configuring xtensa-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/xtensa-softmmu-config-devices.mak.d
+Configuring xtensa-softmmu-config-devices.h using configuration
+Configuring xtensaeb-softmmu-config-target.h using configuration
+Configuring xtensaeb-softmmu-config-devices.mak with command
+Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/xtensaeb-softmmu-config-devices.mak.d
+Configuring xtensaeb-softmmu-config-devices.h using configuration
+Program scripts/make-config-poison.sh found: YES (sh C:/msys64/home/Roberto/qemu/scripts/make-config-poison.sh)
+Run-time dependency capstone found: YES 4.0.2
+Library fdt found: NO
+Configuring config-host.h using configuration
+Program scripts/hxtool found: YES (sh C:/msys64/home/Roberto/qemu/scripts/hxtool)
+Program scripts/shaderinclude.pl found: YES (perl C:/msys64/home/Roberto/qemu/scripts/shaderinclude.pl)
+Program scripts/qapi-gen.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/qapi-gen.py)
+Program scripts/qemu-version.sh found: YES (sh C:/msys64/home/Roberto/qemu/scripts/qemu-version.sh)
+Program scripts/decodetree.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/decodetree.py)
+Program ../scripts/modules/module_block.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/block/../scripts/modules/module_block.py)
+Program ../scripts/block-coroutine-wrapper.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/block/../scripts/block-coroutine-wrapper.
+py)
+Program scripts/modinfo-collect.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/modinfo-collect.py)
+Program scripts/modinfo-generate.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/modinfo-generate.py)
+Program nm found: YES
+Program scripts/undefsym.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/undefsym.py)
+Program scripts/feature_to_c.sh found: YES (sh C:/msys64/home/Roberto/qemu/scripts/feature_to_c.sh)
+Compiler for C supports link arguments -fstack-protector-all: YES
+Compiler for C supports link arguments -fstack-protector-strong: YES
+Compiler for C supports link arguments -Wl,--add-stdcall-alias: YES
+Compiler for C supports link arguments -Wl,--enable-stdcall-fixup: YES
+Library ole32 found: YES
+Library oleaut32 found: YES
+Library shlwapi found: YES
+Library uuid found: YES
+Library intl found: YES
+Program wixl found: NO
+Configuring 50-edk2-i386-secure.json using configuration
+Configuring 50-edk2-x86_64-secure.json using configuration
+Configuring 60-edk2-aarch64.json using configuration
+Configuring 60-edk2-arm.json using configuration
+Configuring 60-edk2-i386.json using configuration
+Configuring 60-edk2-x86_64.json using configuration
+Program qemu-keymap found: NO
+Program sphinx-build found: YES (C:\msys64\mingw64\bin/sphinx-build.EXE)
+../docs/meson.build:74: WARNING: Project targets '>=0.61.3' but uses feature deprecated since '0.60.0': install_subdir with empty directory. It worked by accide
+nt and is buggy. Use install_emptydir instead.
+Program diff found: YES (C:\msys64\usr\bin/diff.EXE)
+Program dbus-daemon found: NO
+Did not find CMake 'cmake'
+Found CMake: NO
+Run-time dependency gvnc-1.0 found: NO (tried pkgconfig and cmake)
+Program initrd-stress.sh found: YES (sh C:/msys64/home/Roberto/qemu/tests/migration/initrd-stress.sh)
+Program xgettext found: YES (C:\msys64\mingw64\bin/xgettext.EXE)
+Program msgfmt found: YES (C:\msys64\mingw64\bin/msgfmt.EXE)
+Program msginit found: YES (C:\msys64\mingw64\bin/msginit.EXE)
+Program msgmerge found: YES (C:\msys64\mingw64\bin/msgmerge.EXE)
+Program xgettext found: YES (C:\msys64\mingw64\bin/xgettext.EXE)
+Program scripts/nsis.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/nsis.py)
+Build targets in project: 639
+WARNING: Deprecated features used:
+ * 0.60.0: {'install_subdir with empty directory'}
+
+qemu 7.2.50
+
+  Directories
+    Install prefix               : C:/msys64/qemu
+    BIOS directory               : share/
+    firmware path                : share/qemu-firmware
+    binary directory             : C:/msys64/qemu/.
+    library directory            : C:/msys64/qemu/lib
+    module directory             : lib/
+    libexec directory            : C:/msys64/qemu/libexec
+    include directory            : C:/msys64/qemu/include
+    config directory             : C:/msys64/qemu/etc
+    local state directory        : queried at runtime
+    Doc directory                : C:/msys64/qemu/share/doc
+    Build directory              : C:/msys64/home/xxx/qemu/build
+    Source path                  : C:/msys64/home/xxx/qemu
+    GIT submodules               : ui/keycodemapdb tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc
+
+  Host binaries
+    git                          : git
+    make                         : make
+    python                       : C:/msys64/mingw64/bin/python.exe (version: 3.10)
+    sphinx-build                 : C:\msys64\mingw64\bin/sphinx-build.EXE
+    gdb                          : /mingw64/bin/gdb-multiarch
+    iasl                         : NO
+    genisoimage                  :
+    wixl                         : NO
+    smbd                         : NO
+
+  Configurable features
+    Documentation                : YES
+    system-mode emulation        : YES
+    user-mode emulation          : NO
+    block layer                  : YES
+    Install blobs                : YES
+    module support               : NO
+    fuzzing support              : NO
+    Audio drivers                : dsound sdl
+    Trace backends               : log
+    D-Bus display                : NO
+    QOM debugging                : NO
+    vhost-kernel support         : NO
+    vhost-net support            : NO
+    vhost-user support           : NO
+    vhost-user-crypto support    : NO
+    vhost-user-blk server support: NO
+    vhost-vdpa support           : NO
+    build guest agent            : YES
+
+  Compilation
+    host CPU                     : x86_64
+    host endianness              : little
+    C compiler                   : cc -m64 -mcx16
+    Host C compiler              : cc -m64 -mcx16
+    C++ compiler                 : c++ -m64 -mcx16
+    CFLAGS                       : -O2 -g
+    CXXFLAGS                     : -O2 -g
+    QEMU_CFLAGS                  : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-pie -no-pie -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prot
+otypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -W
+type-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallt
+hrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong
+    QEMU_CXXFLAGS                : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-pie -no-pie -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wundef -Wwri
+te-strings -fno-strict-aliasing -fno-common -fwrapv -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wendif-labels -W
+expansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong
+    QEMU_OBJCFLAGS               : -Wold-style-declaration -Wold-style-definition -Wtype-limits -Winit-self -Wempty-body -Wnested-externs -Wendif-labels -Wexpan
+sion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi
+    QEMU_LDFLAGS                 : -fstack-protector-strong -Wl,--no-seh -Wl,--nxcompat -Wl,--warn-common
+    profiler                     : NO
+    link-time optimization (LTO) : NO
+    PIE                          : NO
+    static build                 : NO
+    malloc trim support          : NO
+    membarrier                   : NO
+    debug stack usage            : NO
+    mutex debugging              : NO
+    memory allocator             : system
+    avx2 optimization            : YES
+    avx512f optimization         : NO
+    gprof enabled                : NO
+    gcov                         : NO
+    thread sanitizer             : NO
+    CFI support                  : NO
+    strip binaries               : NO
+    sparse                       : NO
+    mingw32 support              : YES
+
+  Cross compilers
+    x86_64                       : cc
+
+  Targets and accelerators
+    KVM support                  : NO
+    HAX support                  : YES
+    HVF support                  : NO
+    WHPX support                 : YES
+    NVMM support                 : NO
+    Xen support                  : NO
+    TCG support                  : YES
+    TCG backend                  : native (x86_64)
+    TCG plugins                  : NO
+    TCG debug enabled            : NO
+    target list                  : aarch64-softmmu alpha-softmmu arm-softmmu avr-softmmu cris-softmmu hppa-softmmu i386-softmmu loongarch64-softmmu m68k-softmmu
+ microblaze-softmmu microblazeel-softmmu mips-softmmu mips64-softmmu mips64el-softmmu mipsel-softmmu nios2-softmmu or1k-softmmu ppc-softmmu ppc64-softmmu riscv3
+2-softmmu riscv64-softmmu rx-softmmu s390x-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu sparc64-softmmu tricore-softmmu x86_64-softmmu xtensa-softmmu xtensae
+b-softmmu
+    default devices              : YES
+    out of process emulation     : NO
+    vfio-user server             : NO
+
+  Block layer support
+    coroutine backend            : win32
+    coroutine pool               : YES
+    Block whitelist (rw)         :
+    Block whitelist (ro)         :
+    Use block whitelist in tools : NO
+    VirtFS support               : NO
+    build virtiofs daemon        : NO
+    Live block migration         : YES
+    replication support          : YES
+    bochs support                : YES
+    cloop support                : YES
+    dmg support                  : YES
+    qcow v1 support              : YES
+    vdi support                  : YES
+    vvfat support                : YES
+    qed support                  : YES
+    parallels support            : YES
+    FUSE exports                 : NO
+    VDUSE block exports          : NO
+
+  Crypto
+    TLS priority                 : NORMAL
+    GNUTLS support               : YES 3.7.8
+      GNUTLS crypto              : YES
+    libgcrypt                    : NO
+    nettle                       : NO
+    AF_ALG support               : NO
+    rng-none                     : NO
+    Linux keyring                : NO
+
+  Dependencies
+    SDL support                  : YES
+    SDL image support            : YES 2.6.2
+    GTK support                  : YES
+    pixman                       : YES 0.42.2
+    VTE support                  : NO
+    slirp support                : YES 4.7.0
+    libtasn1                     : YES 4.19.0
+    PAM                          : NO
+    iconv support                : YES
+    curses support               : YES
+    virgl support                : NO
+    blkio support                : NO
+    curl support                 : YES 7.86.0
+    Multipath support            : NO
+    PNG support                  : YES 1.6.39
+    VNC support                  : YES
+    VNC SASL support             : YES
+    VNC JPEG support             : YES 2.1.4
+    DirectSound support          : YES
+    JACK support                 : NO
+    brlapi support               : NO
+    vde support                  : NO
+    netmap support               : NO
+    l2tpv3 support               : NO
+    Linux AIO support            : NO
+    Linux io_uring support       : NO
+    ATTR/XATTR support           : NO
+    RDMA support                 : NO
+    PVRDMA support               : NO
+    fdt support                  : internal
+    libcap-ng support            : NO
+    bpf support                  : NO
+    spice protocol support       : YES 0.14.4
+      spice server support       : YES 0.15.1
+    rbd support                  : NO
+    smartcard support            : NO
+    U2F support                  : NO
+    libusb                       : YES 1.0.26
+    usb net redir                : YES 0.8.0
+    OpenGL support (epoxy)       : NO
+    GBM                          : NO
+    libiscsi support             : NO
+    libnfs support               : YES 5.0.2
+    QGA VSS support              : YES
+    seccomp support              : NO
+    GlusterFS support            : NO
+    TPM support                  : NO
+    libssh support               : YES 0.10.4
+    lzo support                  : YES
+    snappy support               : YES
+    bzip2 support                : YES
+    lzfse support                : NO
+    zstd support                 : YES 1.5.2
+    NUMA host support            : NO
+    capstone                     : YES 4.0.2
+    libpmem support              : NO
+    libdaxctl support            : NO
+    libudev                      : NO
+    FUSE lseek                   : NO
+    selinux                      : NO
+
+  User defined options
+    Native files                 : config-meson.cross
+    bindir                       :
+    prefix                       : C:/msys64/qemu
+    werror                       : true
+    b_pie                        : false
+    gtk                          : enabled
+    qemu_suffix                  :
+    sdl                          : enabled
+    vfio_user_server             : disabled
+
+Found ninja-1.11.1 at C:/msys64/mingw64/bin/ninja.exe
+Running postconf script 'C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/symlink-install-tree.py'
+--- stdout ---
+
+--- stderr ---
+error making symbolic link C:/msys64/qemu/share/trace-events-all
+Traceback (most recent call last):
+  File "C:\msys64\home\Roberto\qemu\scripts\symlink-install-tree.py", line 33, in <module>
+    raise e
+  File "C:\msys64\home\Roberto\qemu\scripts\symlink-install-tree.py", line 29, in <module>
+    os.symlink(source, bundle_dest)
+OSError: [WinError 1314] Il privilegio richiesto non appartiene al client: 'C:/msys64/home/Roberto/qemu/build/trace/trace-events-all' -> 'qemu-bundle/msys64/qem
+u/share/trace-events-all'
+```
+Additional information:
+The line below ensures that proper tags are added to the issue.
+Please do not remove it.
+-->
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1387 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1387
new file mode 100644
index 00000000..c1bdaaa6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1387
@@ -0,0 +1,9 @@
+QEMU - Add in the FAQ info how to compile Windows x86/x64 installer under Linux Ubuntu
+Description of problem:
+Please add in the FAQ
+
+https://wiki.qemu.org/Hosts/W32#Debian_based_cross_builds
+
+detailed info step by stepo how to create windows x86 and x64 instalelr under Ubuntu
+Steps to reproduce:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1388 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1388
new file mode 100644
index 00000000..f9e00237
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1388
@@ -0,0 +1,14 @@
+QEMU 7.2.0 - Update file repository with x86/x64 Windows installer
+Description of problem:
+In file repository
+
+https://qemu.weilnetz.de/w32/
+https://qemu.weilnetz.de/w64/
+
+are not availble Windows installer for x86 and x64 platform and QEMU final 7.2.0.
+
+The latest version is 7.2.0.RC4 (08.12.2022).
+
+Thanks.
+Steps to reproduce:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1389 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1389
new file mode 100644
index 00000000..1dfcb22b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1389
@@ -0,0 +1,61 @@
+Qemu 7.2.0 My hobbby bootloader seemed to stop working
+Description of problem:
+I wrote a BIOS bootloader and OS, but updated to QEMU 7.2.0 and now I get an exception in my bootloader.
+Specifically I am getting a page fault on the first line of map_pd:
+```
+next_pdpt:
+    ; PDPT
+    mov [0xa000 + rdx * 8], rax ; PDPT[rdx] -> PD
+    and al, 0xfc ;; clear bits 1 and 2
+
+    mov rcx, 0
+map_pd:
+    mov [rax + rcx * 8], rdi ; PD[rcx] -> rax
+    add rdi, 0x200000 ; maps first 512 * 0x200000 or 1 GiB
+    sub rsi, 1
+    cmp rsi, 0
+    je done_map_rest
+
+    add rcx, 1
+    cmp rcx, 512
+    jb map_pd
+
+    add rdx, 1 ; do next GiB
+    add rax, 0x1000 ; next PD
+    or rax, (1 | 2)
+
+    jmp next_pdpt
+```
+I am getting the exception:
+```
+check_exception old: 0xffffffff new 0xe
+     0: v=0e e=0002 i=0 cpl=0 IP=0008:0000000000001311 pc=0000000000001311 SP=0010:0000000000007bf8 CR2=000000000020c000
+RAX=000000000020c000 RBX=00000000000b8040 RCX=0000000000000000 RDX=0000000000000201
+RSI=000000000003fe00 RDI=0000008040000083 RBP=0000000000000008 RSP=0000000000007bf8
+R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000
+R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000
+RIP=0000000000001311 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+CS =0008 0000000000000000 00000000 00209a00 DPL=0 CS64 [-R-]
+SS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+DS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+FS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+GS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
+TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
+GDT=     0000000000001888 00000018
+IDT=     0000000090909000 00000000
+CR0=80000011 CR2=000000000020c000 CR3=0000000000009000 CR4=00000020
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
+DR6=00000000ffff0ff0 DR7=0000000000000400
+CCS=0000000000000200 CCD=0000000000000000 CCO=LOGICB
+EFER=0000000000000500
+```
+
+I am able to read the 0x20c000 address with gdb
+Steps to reproduce:
+1. clone and build https://github.com/darbysauter/myOS
+2. run with `make run` on 7.0.0
+3. run with `make run` on 7.2.0 and there is an exception
+Additional information:
+I looked through the changelogs from 7.1 and 7.2 and nothing stood out to me. Not sure if some behaviour changed or some default changed.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/139 b/gitlab/issues_text/target_missing/host_missing/accel_missing/139
new file mode 100644
index 00000000..0295590c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/139
@@ -0,0 +1 @@
+kvm rbd driver (and maybe others, i.e. qcow2, qed and so on)  does not report DISCARD-ZERO flag
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1391 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1391
new file mode 100644
index 00000000..b601002c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1391
@@ -0,0 +1,28 @@
+virtio-blk: BDRV_REQ_REGISTERED_BUF optimization hint crashes on macOS
+Description of problem:
+When using QEMU 7.2.0 on macOS with the virtio-blk drive, the process will exit and QMP shows a `BLOCK_IO_ERROR` event. This appears to be caused by this line: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/block/virtio-blk.c#L405 introduced in https://gitlab.com/qemu-project/qemu/-/commit/baf422684d73c7bf38e2c18815e18d44fcf395b6
+
+Commenting that line out fixes the issue.
+Steps to reproduce:
+1. Run the QEMU command above with a Ubuntu 22.04 server ISO image.
+2. Follow the installer and try to get to the end.
+3. The process will crash before you can finish installing.
+Additional information:
+Following event appears on QMP:
+```
+{
+    data =     {
+        action = report;
+        device = "drive437EC806-41A4-4CCE-A747-713352E7C27C";
+        "node-name" = "#block785";
+        nospace = 0;
+        operation = write;
+        reason = "Invalid argument";
+    };
+    event = "BLOCK_IO_ERROR";
+    timestamp =     {
+        microseconds = 808474;
+        seconds = 1671867673;
+    };
+}
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1392 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1392
new file mode 100644
index 00000000..c0dd7085
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1392
@@ -0,0 +1,14 @@
+qemu 7.2.0 almalinux 9.1 guest  vda io error
+Description of problem:
+after update the qemu from 7.1.0 to 7.2.0 guest almalinux 9.1  have disk io error ,log :
+```log
+Dec 24 00:17:39 rlh1 kernel: I/O error, dev vda, sector 109770720 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
+Dec 24 00:17:42 rlh1 kernel: dm-0: writeback error on inode 33585275, offset 4096, sector 33359840
+Dec 24 00:17:42 rlh1 kernel: I/O error, dev vda, sector 109770776 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
+Dec 24 00:17:42 rlh1 kernel: dm-0: writeback error on inode 33585275, offset 4096, sector 33359896
+Dec 24 00:17:42 rlh1 kernel: I/O error, dev vda, sector 109770832 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
+```
+
+then I switch back to version 7.1.0  it work as normal
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1393 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1393
new file mode 100644
index 00000000..5f535120
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1393
@@ -0,0 +1,65 @@
+Abort in audio_calloc()  of ac97
+Description of problem:
+Section 5.10.2 of the AC97 specification (https://hands.com/~lkcl/ac97_r23.pdf)
+shows the feasibility to support for rates other than 48kHZ. Specifically,
+AC97_PCM_Front_DAC_Rate (reg 2Ch) should be from 8kHZ to 48kHZ.
+
+
+An adversary can leverage this to crash QEMU.
+
+A nornal 48kHZ setting is like this.
+
+```
+ac97_realize
+  open_voice
+    as->freq = 0xbb80 # 0xbb80=48000
+    AUD_open_out
+      audio_pcm_create_voice_pair_out (sw is NULL)
+        audio_pcm_sw_init_out
+          sw->info.freq = as->freq (in audio_pcm_init_info())
+          sw->ratio = ((int64_t) sw->hw->info.freq << 32) / sw->info.freq
+          samples = ((int64_t) sw->HWBUF->size << 32) / sw->ratio (in audio_pcm_sw_alloc_resources_out())
+```
+
+A non-48kHZ setting is like this. Since `as->freq` is too small, `sw->ratio` is
+too large. Finally, `samples` is zero, failing the audio_calloc() in
+audio_pcm_sw_alloc_resources_out().
+
+```
+nam_writew
+  open_voice
+    as->freq = 0x6
+    AUD_open_out
+      audio_pcm_sw_init_out (sw is not NULL)
+        sw->info.freq = as->freq (in audio_pcm_init_info())
+        sw->ratio = ((int64_t) sw->hw->info.freq << 32) / sw->info.freq
+        samples = ((int64_t) sw->HWBUF->size << 32) / sw->ratio (in audio_pcm_sw_alloc_resources_out())
+        audio_calloc(.., samples, ) (in audio_pcm_sw_alloc_resources_out())
+```
+Steps to reproduce:
+1. download the prepared rootfs and the image.
+
+    https://drive.google.com/file/d/1IfVCvn76HY-Eb4AZU7yvuyPzM3QC1q10/view?usp=sharing
+    https://drive.google.com/file/d/1JN6JgvOSI5aSLIdTEFKiskKbrGWFo0BO/view?usp=sharing
+
+2. run the following script.
+
+``` bash
+QEMU_PATH=../../../qemu-devel/build/x86_64-softmmu/qemu-system-x86_64
+KERNEL_PATH=./bzImage
+ROOTFS_PATH=./rootfs.ext2
+$QEMU_PATH \
+    -M q35 -m 1G \
+    -kernel $KERNEL_PATH \
+    -drive file=$ROOTFS_PATH,if=virtio,format=raw \
+    -append "root=/dev/vda console=ttyS0" \
+    -net nic,model=virtio -net user \
+    -device ac97,audiodev=snd0 -audiodev none,id=snd0 \
+    -nographic
+```
+
+3. with spawned shell (the user is root and the password is empty), run
+`ac97-00`.
+Additional information:
+In the latest QEMU, this issue was generally fixed by 12f4abf6a245c43d8411577fd400373c85f08c6b and 0cbc8bd4694f32687bf47c6da48efa48fac35fd2 that remove abort() from the source code. Even though, I still plan to send a
+patch so that the warning about the invalid freq will be gone.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1397 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1397
new file mode 100644
index 00000000..00aac181
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1397
@@ -0,0 +1 @@
+riscv: break, hbreak does not set a breakpoint on the correct address when providing symbols
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/140 b/gitlab/issues_text/target_missing/host_missing/accel_missing/140
new file mode 100644
index 00000000..4a7ae0af
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/140
@@ -0,0 +1 @@
+linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1401 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1401
new file mode 100644
index 00000000..288ef050
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1401
@@ -0,0 +1,20 @@
+configure uses break outside loop
+Description of problem:
+When running `configure` in version 7.2.0, the following message is printed multiple times:
+
+```
+qemu/configure: line 1885: break: only meaningful in a `for', `while', or `until' loop
+```
+Steps to reproduce:
+Running `configure` should be enough. My complete configure command is:
+
+```
+/bin/bash ./configure \
+    --prefix=$PREFIX/qemu --sysconfdir=/etc$PREFIX/qemu \
+    --includedir=$PREFIX/qemu/include --bindir=$PREFIX/qemu/bin \
+    --sbindir=$PREFIX/qemu/sbin --libdir=$PREFIX/qemu/lib/amd64 \
+    --libexecdir=$PREFIX/qemu/libexec/amd64 \
+    --localstatedir=/var$PREFIX/qemu
+```
+Additional information:
+The `configure` script has `break;` in a conditional, where `:` would suffice (or the conditional could just be negated)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1403 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1403
new file mode 100644
index 00000000..b43800f9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1403
@@ -0,0 +1 @@
+qemu 7.2: test-io-channel-command fails sporadically
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1404 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1404
new file mode 100644
index 00000000..1c180749
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1404
@@ -0,0 +1,14 @@
+qemu-7.2: virtio-blk-pci I/O errors with detect-zeroes=unmap
+Description of problem:
+Since upgrading from qemu-7.1 to qemu-7.2 I have seen many anomalies with VMs that use the virtio-blk-pci device for the root filesystem and the `detect-zeroes=unmap` option, typically in the form of I/O errors or huge decreases in read/write performance. This has been observed for both pre-existing Linux & Windows systems using the QCOW2 disk format, and a freshly created Linux system.
+
+* For an existing x86_64 Windows-10 guest system, hosted on Debian-11, the guest system takes many minutes to boot and Task Manager shows the virtual disk showing read/write latencies measured in seconds rather than milliseconds.
+* Attempts to create a new x86_64 Debian-11 guest on a Debian-11 host produce an input/output error when trying to partition the QCOW2 hard disk /dev/vda (as per attached screenshot) ![deb11-partition-error](/uploads/de743ef1fbaf84739943b2563cb429de/deb11-partition-error.png)
+* Using a pre-existing Debian-11 guest that works perfectly with qemu-7.1, fails to format a basic ext3 /dev/loop filesystem when this guest is booted with qemu-7.2, giving `mke2fs: Input/output error while writing out and closing file system`
+Steps to reproduce:
+(installer error)
+1. Create fresh QCOW2 image: `qemu-img create -f qcow2 deb11.img 8G`
+2. Run standard Debian-11 installer from ISO image and virtio-blk-pci drive and options `-drive if=none,media=disk,id=drive0,file=deb11.img,cache=writeback,discard=unmap,detect-zeroes=unmap`
+3. Use default options with "guided partitioning"
+Additional information:
+I'm not aware of any changes to the setup of my system that would account for these problems, and have successfully tried many similar experiments with QEMU version up to and including version 7.1. Obviously, I'm hoping there's some trivial configuration error I've overlooked in qemu-7.2 - any suggestions would be much appreciated.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1405 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1405
new file mode 100644
index 00000000..188dc33c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1405
@@ -0,0 +1,121 @@
+linux-user: calling SYS_get_thread_area and SYS_get_thread_area has incorrent result on multithread environment
+Description of problem:
+
+Steps to reproduce:
+1. Compile test.out by Command and source code: 
+```
+gcc -m32 -g test.c -lpthread -o test.out
+```
+```
+#include <sys/syscall.h>
+#include <unistd.h>
+#include <stdio.h>
+#include <pthread.h>
+#include <asm/ldt.h>
+
+static inline int set_thread_area( struct user_desc *ptr )
+{
+    return syscall( SYS_set_thread_area, ptr );
+}
+
+static inline int get_thread_area( struct user_desc *ptr )
+{
+    return syscall( SYS_get_thread_area, ptr );
+}
+
+static unsigned int entry_number;
+
+static void* start_routine(void* ptr) 
+{
+    struct user_desc user_desc0 = { entry_number };
+    struct user_desc user_desc1 = { entry_number };
+    struct user_desc user_desc2 = { entry_number };
+    get_thread_area(&user_desc0);
+    printf("child thread: %u\n", user_desc0.base_addr);
+
+    user_desc1.base_addr = 2;
+    user_desc1.limit     = 0xFFF;
+    user_desc1.seg_32bit = 1;
+    set_thread_area( &user_desc1 );
+
+    get_thread_area(&user_desc2);
+    printf("child thread: %u\n", user_desc2.base_addr);
+    return NULL;
+}
+
+int main(void) {
+    struct user_desc user_desc0 = { -1 }, user_desc1 = { 0 }, user_desc2 = { 0 };
+    user_desc0.seg_32bit = 1;
+    user_desc0.useable = 1;
+    set_thread_area( &user_desc0 );
+
+    entry_number = user_desc0.entry_number;
+
+    user_desc1.entry_number = entry_number;
+    user_desc1.base_addr = 1;
+    user_desc1.limit     = 0xFFF;
+    user_desc1.seg_32bit = 1;
+    set_thread_area( &user_desc1 );
+
+    pthread_t thread_id;
+    pthread_create(&thread_id, NULL, &start_routine, NULL);
+    pthread_join(thread_id, NULL);
+
+    user_desc2.entry_number = entry_number;
+    get_thread_area(&user_desc2);
+    printf("main  thread: %u\n", user_desc2.base_addr); // main  thread: 1
+    return 0;
+}
+ ```
+2. Correct Result:
+```
+child thread: 1
+child thread: 2
+main  thread: 1
+```
+qemu-i386 Print Result:
+```
+child thread: 1
+child thread: 2
+main  thread: 2
+```
+Additional information:
+patch for fix the bug: 
+
+https://lists.nongnu.org/archive/html/qemu-devel/2023-02/msg02203.html
+
+CPUX86State::gdt::base on differect threads must have different vaules, but it points to same memory.
+value of CPUX86State::gdt::base must be copied when clone thread.
+
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/tls.c
+
+SYS_set_thread_area call do_set_thread_area in kernel, it set user_desc to different memroy area on differernt threads. tls_array is in thread local memory.
+
+```
+static void set_tls_desc(struct task_struct *p, int idx,
+			 const struct user_desc *info, int n)
+{
+	struct thread_struct *t = &p->thread;
+	struct desc_struct *desc = &t->tls_array[idx - GDT_ENTRY_TLS_MIN];
+	int cpu;
+
+	/*
+	 * We must not get preempted while modifying the TLS.
+	 */
+	cpu = get_cpu();
+
+	while (n-- > 0) {
+		if (LDT_empty(info) || LDT_zero(info))
+			memset(desc, 0, sizeof(*desc));
+		else
+			fill_ldt(desc, info);
+		++info;
+		++desc;
+	}
+
+	if (t == &current->thread)
+		load_TLS(t, cpu);
+
+	put_cpu();
+}
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1406 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1406
new file mode 100644
index 00000000..9db9f7b3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1406
@@ -0,0 +1 @@
+WANTED: Schematics, Service, Tech Notes, .pdf  IBM Power4 970MP/FX Apple PowerMac G5 Early/Late 2005
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1409 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1409
new file mode 100644
index 00000000..a4c15d62
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1409
@@ -0,0 +1 @@
+make check failed about qemu@7.2.0on suse15_aarch64
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1411 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1411
new file mode 100644
index 00000000..3cf45ac3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1411
@@ -0,0 +1,455 @@
+QEMU 7.2.0 - Failed compilation under MacOS
+Description of problem:
+I downloaded and tried to build QEMU from git following the instructions from here:
+https://www.qemu.org/download/
+
+(I successfully installed QEMU with homebrew later, but I still want to figure out why my compilation failed.)
+Steps to reproduce:
+```
+git clone https://gitlab.com/qemu-project/qemu.git
+cd qemu
+git submodule init
+git submodule update --recursive
+./configure
+make
+```
+Additional information:
+With `./configure` I got:
+
+```
+Using './build' as the directory for build output
+Disabling PIE due to missing toolchain support
+The Meson build system
+Version: 0.61.5
+Source dir: /Users/xxx/qemu
+Build dir: /Users/xxx/qemu/build
+Build type: native build
+Project name: qemu
+Project version: 7.2.50
+C compiler for the host machine: cc (clang 14.0.0 "Apple clang version 14.0.0 (clang-1400.0.29.202)")
+C linker for the host machine: cc ld64 820.1
+Host machine cpu family: aarch64
+Host machine cpu: arm64
+Program scripts/symlink-install-tree.py found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/scripts/symlink-install-tree.py)
+Program sh found: YES (/bin/sh)
+Program python3 found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10)
+Program bzip2 found: YES (/usr/bin/bzip2)
+Program iasl found: NO
+Compiler for C supports link arguments -Wl,-z,relro: NO 
+Compiler for C supports link arguments -Wl,-z,now: NO 
+C++ compiler for the host machine: c++ (clang 14.0.0 "Apple clang version 14.0.0 (clang-1400.0.29.202)")
+C++ linker for the host machine: c++ ld64 820.1
+Compiler for C++ supports link arguments -Wl,--warn-common: NO 
+Objective-C compiler for the host machine: clang (clang 14.0.0)
+Objective-C linker for the host machine: clang ld64 820.1
+Program cgcc found: NO
+Library m found: YES
+Run-time dependency threads found: YES
+Library util found: YES
+Run-time dependency appleframeworks found: YES (CoreFoundation)
+Run-time dependency appleframeworks found: YES (IOKit)
+Run-time dependency appleframeworks found: YES (Hypervisor)
+Found pkg-config: /opt/homebrew/bin/pkg-config (0.29.2)
+Run-time dependency gio-2.0 found: YES 2.74.4
+Program /opt/homebrew/Cellar/glib/2.74.4/bin/gdbus-codegen found: YES (/opt/homebrew/Cellar/glib/2.74.4/bin/gdbus-codegen)
+Run-time dependency gio-unix-2.0 found: YES 2.74.4
+Run-time dependency pixman-1 found: YES 0.42.2
+Run-time dependency zlib found: YES 1.2.11
+Has header "libaio.h" : NO 
+Run-time dependency liburing found: NO (tried pkgconfig)
+Run-time dependency libnfs found: NO (tried pkgconfig)
+Has header "attr/xattr.h" : NO 
+Run-time dependency appleframeworks found: YES (Cocoa, CoreVideo)
+Run-time dependency appleframeworks found: YES (vmnet)
+Header <vmnet/vmnet.h> has symbol "VMNET_BRIDGED_MODE" with dependency appleframeworks: YES 
+Run-time dependency libseccomp found: NO (tried pkgconfig)
+Has header "cap-ng.h" : NO 
+Run-time dependency xkbcommon found: NO (tried pkgconfig)
+Run-time dependency slirp found: NO (tried pkgconfig)
+Has header "libvdeplug.h" : NO 
+Run-time dependency jack found: NO (tried pkgconfig)
+Run-time dependency sndio found: NO (tried pkgconfig)
+Run-time dependency spice-protocol found: NO (tried pkgconfig)
+Run-time dependency spice-server found: NO (tried pkgconfig)
+Library rt found: NO
+Run-time dependency libiscsi found: NO (tried pkgconfig)
+Run-time dependency libzstd found: NO (tried pkgconfig)
+Run-time dependency virglrenderer found: NO (tried pkgconfig)
+Run-time dependency blkio found: NO (tried pkgconfig)
+Run-time dependency libcurl found: YES 7.84.0
+Run-time dependency ncursesw found: YES 5.7.20081102
+Has header "brlapi.h" : NO 
+sdl2-config found: NO
+Run-time dependency sdl2 found: NO (tried pkgconfig, config-tool and framework)
+Library rados found: NO
+Has header "rbd/librbd.h" : NO 
+Run-time dependency glusterfs-api found: NO (tried pkgconfig)
+Run-time dependency libssh found: NO (tried pkgconfig)
+Has header "bzlib.h" : YES 
+Library bz2 found: YES
+Has header "lzfse.h" : NO 
+Has header "sys/soundcard.h" : NO 
+Run-time dependency appleframeworks found: YES (CoreAudio)
+Run-time dependency epoxy found: NO (tried pkgconfig)
+Has header "epoxy/egl.h" with dependency epoxy: NO 
+Run-time dependency gnutls found: NO (tried pkgconfig)
+Run-time dependency gnutls found: NO (tried pkgconfig)
+libgcrypt-config found: NO need ['>=1.8']
+Run-time dependency libgcrypt found: NO (tried config-tool)
+Run-time dependency nettle found: NO (tried pkgconfig)
+Run-time dependency gmp found: NO (tried pkgconfig)
+Run-time dependency gtk+-3.0 found: NO (tried pkgconfig)
+Run-time dependency libpng found: NO (tried pkgconfig)
+Run-time dependency libjpeg found: NO (tried pkgconfig)
+Has header "sasl/sasl.h" : YES 
+Library sasl2 found: YES
+Has header "security/pam_appl.h" : YES 
+Library pam found: YES
+Has header "snappy-c.h" : NO 
+Has header "lzo/lzo1x.h" : NO 
+Has header "numa.h" : NO 
+Library ibumad found: NO
+Has header "rdma/rdma_cma.h" : NO 
+Library ibverbs found: NO
+Run-time dependency xencontrol found: NO (tried pkgconfig)
+Library xenstore found: NO
+Library xenctrl found: NO
+Library xendevicemodel found: NO
+Library xenforeignmemory found: NO
+Library xengnttab found: NO
+Library xenevtchn found: NO
+Library xentoolcore found: NO
+Run-time dependency libcacard found: NO (tried pkgconfig)
+Run-time dependency u2f-emu found: NO (tried pkgconfig)
+Run-time dependency canokey-qemu found: NO (tried pkgconfig)
+Run-time dependency libusbredirparser-0.5 found: NO (tried pkgconfig)
+Run-time dependency libusb-1.0 found: NO (tried pkgconfig)
+Run-time dependency libpmem found: NO (tried pkgconfig)
+Run-time dependency libdaxctl found: NO (tried pkgconfig)
+Run-time dependency libkeyutils found: NO (tried pkgconfig)
+Checking for function "gettid" : NO 
+Run-time dependency libselinux found: NO (tried pkgconfig)
+Run-time dependency fuse3 found: NO (tried pkgconfig)
+Run-time dependency libbpf found: NO (tried pkgconfig)
+Has header "IOKit/storage/IOMedia.h" : YES 
+Checking for function "pthread_fchdir_np" : YES 
+Has header "sys/epoll.h" : NO 
+Has header "linux/magic.h" : NO 
+Has header "valgrind/valgrind.h" : NO 
+Has header "linux/btrfs.h" : NO 
+Has header "libdrm/drm.h" : NO 
+Has header "pty.h" : NO 
+Has header "sys/disk.h" : YES 
+Has header "sys/ioccom.h" : YES 
+Has header "sys/kcov.h" : NO 
+Checking for function "close_range" : NO 
+Checking for function "accept4" : NO 
+Checking for function "clock_adjtime" : NO 
+Checking for function "dup3" : NO 
+Checking for function "fallocate" : NO 
+Checking for function "posix_fallocate" : NO 
+Checking for function "posix_memalign" : YES 
+Checking for function "_aligned_malloc" : NO 
+Checking for function "valloc" : YES 
+Checking for function "memalign" : NO 
+Checking for function "ppoll" : NO 
+Checking for function "preadv" : YES 
+Checking for function "pthread_fchdir_np" : YES (cached)
+Checking for function "sendfile" : YES 
+Checking for function "setns" : NO 
+Checking for function "syncfs" : NO 
+Checking for function "sync_file_range" : NO 
+Checking for function "timerfd_create" : NO 
+Checking for function "copy_file_range" : NO 
+Checking for function "getifaddrs" : YES 
+Checking for function "openpty" with dependency -lutil: YES 
+Checking for function "strchrnul" : NO 
+Checking for function "system" : YES 
+Header <byteswap.h> has symbol "bswap_32" : NO 
+Header <sys/epoll.h> has symbol "epoll_create1" : NO 
+Header <linux/falloc.h> has symbol "FALLOC_FL_PUNCH_HOLE" : NO 
+Header <linux/falloc.h> has symbol "FALLOC_FL_ZERO_RANGE" : NO 
+Has header "linux/fiemap.h" : NO 
+Checking for function "getrandom" : NO 
+Header <sys/inotify.h> has symbol "inotify_init" : NO 
+Header <sys/inotify.h> has symbol "inotify_init1" : NO 
+Header <machine/bswap.h> has symbol "bswap32" : NO 
+Header <sys/prctl.h> has symbol "PR_SET_TIMERSLACK" : NO 
+Header <linux/rtnetlink.h> has symbol "IFLA_PROTO_DOWN" : NO 
+Header <sys/sysmacros.h> has symbol "makedev" : NO 
+Header <getopt.h> has symbol "optreset" : YES 
+Header <netinet/in.h> has symbol "IPPROTO_MPTCP" : NO 
+Header <sys/mount.h> has symbol "FSCONFIG_SET_FLAG" : NO 
+Checking whether type "struct sigevent" has member "sigev_notify_thread_id" : NO 
+Checking whether type "struct stat" has member "st_atim" : NO 
+Checking for type "struct iovec" : YES 
+Checking for type "struct utmpx" : YES 
+Checking for type "struct mmsghdr" : NO 
+Header <linux/vm_sockets.h> has symbol "AF_VSOCK" : NO 
+Program scripts/minikconf.py found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/scripts/minikconf.py)
+Configuring x86_64-softmmu-config-target.h using configuration
+Configuring x86_64-softmmu-config-devices.mak with command
+Reading depfile: /Users/xxx/qemu/build/meson-private/x86_64-softmmu-config-devices.mak.d
+Configuring x86_64-softmmu-config-devices.h using configuration
+Program scripts/make-config-poison.sh found: YES (/Users/xxx/qemu/scripts/make-config-poison.sh)
+Run-time dependency capstone found: NO (tried pkgconfig)
+Library fdt found: NO
+Configuring config-host.h using configuration
+Program scripts/hxtool found: YES (/Users/xxx/qemu/scripts/hxtool)
+Program scripts/shaderinclude.pl found: YES (/usr/bin/env perl /Users/xxx/qemu/scripts/shaderinclude.pl)
+Program scripts/qapi-gen.py found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/scripts/qapi-gen.py)
+Program scripts/qemu-version.sh found: YES (/Users/xxx/qemu/scripts/qemu-version.sh)
+Program scripts/decodetree.py found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/scripts/decodetree.py)
+Program ../scripts/modules/module_block.py found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/block/../scripts/modules/module_block.py)
+Program ../scripts/block-coroutine-wrapper.py found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/block/../scripts/block-coroutine-wrapper.py)
+Configuring qemu-plugins-ld64.symbols with command
+Program scripts/modinfo-collect.py found: YES (/Users/xxx/qemu/scripts/modinfo-collect.py)
+Program scripts/modinfo-generate.py found: YES (/Users/xxx/qemu/scripts/modinfo-generate.py)
+Program nm found: YES
+Program scripts/undefsym.py found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/scripts/undefsym.py)
+Program scripts/feature_to_c.sh found: YES (/bin/sh /Users/xxx/qemu/scripts/feature_to_c.sh)
+Program scripts/entitlement.sh found: YES (/Users/xxx/qemu/scripts/entitlement.sh)
+Configuring 50-edk2-i386-secure.json using configuration
+Configuring 50-edk2-x86_64-secure.json using configuration
+Configuring 60-edk2-aarch64.json using configuration
+Configuring 60-edk2-arm.json using configuration
+Configuring 60-edk2-i386.json using configuration
+Configuring 60-edk2-x86_64.json using configuration
+Program qemu-keymap found: NO
+Program sphinx-build-3 sphinx-build found: NO
+Program bash found: NO found 3.2.57 but need: '>= 4.0' (/bin/bash)
+Message: bash >= v4.0 not available ==> Disabled the qemu-iotests.
+Program diff found: YES (/usr/bin/diff)
+Program dbus-daemon found: NO
+Did not find CMake 'cmake'
+Found CMake: NO
+Run-time dependency gvnc-1.0 found: NO (tried pkgconfig, framework and cmake)
+Program initrd-stress.sh found: YES (/Users/xxx/qemu/tests/migration/initrd-stress.sh)
+Build targets in project: 499
+
+qemu 7.2.50
+
+  Directories
+    Install prefix               : /usr/local
+    BIOS directory               : share/qemu
+    firmware path                : share/qemu-firmware
+    binary directory             : /usr/local/bin
+    library directory            : /usr/local/lib
+    module directory             : lib/qemu
+    libexec directory            : /usr/local/libexec
+    include directory            : /usr/local/include
+    config directory             : /usr/local/etc
+    local state directory        : /var/local
+    Manual directory             : /usr/local/share/man
+    Doc directory                : /usr/local/share/doc
+    Build directory              : /Users/xxx/qemu/build
+    Source path                  : /Users/xxx/qemu
+    GIT submodules               : ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc
+
+  Host binaries
+    git                          : git
+    make                         : make
+    python                       : /opt/homebrew/opt/python@3.10/bin/python3.10 (version: 3.10)
+    sphinx-build                 : NO
+    iasl                         : NO
+    genisoimage                  : 
+
+  Configurable features
+    Documentation                : NO
+    system-mode emulation        : YES
+    user-mode emulation          : NO
+    block layer                  : YES
+    Install blobs                : YES
+    module support               : NO
+    fuzzing support              : NO
+    Audio drivers                : coreaudio
+    Trace backends               : log
+    D-Bus display                : NO
+    QOM debugging                : NO
+    vhost-kernel support         : NO
+    vhost-net support            : NO
+    vhost-user support           : NO
+    vhost-user-crypto support    : NO
+    vhost-user-blk server support: NO
+    vhost-vdpa support           : NO
+    build guest agent            : NO
+
+  Compilation
+    host CPU                     : aarch64
+    host endianness              : little
+    C compiler                   : cc
+    Host C compiler              : cc
+    C++ compiler                 : c++
+    Objective-C compiler         : clang
+    CFLAGS                       : -O2 -g
+    CXXFLAGS                     : -O2 -g
+    OBJCFLAGS                    : -O2 -g
+    QEMU_CFLAGS                  : -DOS_OBJECT_USE_OBJC=0 -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-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -Wno-gnu-variable-sized-type-not-at-end -fstack-protector-strong
+    QEMU_CXXFLAGS                : -DOS_OBJECT_USE_OBJC=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wundef -Wwrite-strings -fno-strict-aliasing -fno-common -fwrapv -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -Wno-gnu-variable-sized-type-not-at-end -fstack-protector-strong
+    QEMU_OBJCFLAGS               : -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -Wno-gnu-variable-sized-type-not-at-end
+    QEMU_LDFLAGS                 : -fstack-protector-strong
+    profiler                     : NO
+    link-time optimization (LTO) : NO
+    PIE                          : NO
+    static build                 : NO
+    malloc trim support          : NO
+    membarrier                   : NO
+    debug stack usage            : NO
+    mutex debugging              : NO
+    memory allocator             : system
+    avx2 optimization            : NO
+    avx512f optimization         : NO
+    gprof enabled                : NO
+    gcov                         : NO
+    thread sanitizer             : NO
+    CFI support                  : NO
+    strip binaries               : NO
+    sparse                       : NO
+    mingw32 support              : NO
+
+  Targets and accelerators
+    KVM support                  : NO
+    HAX support                  : NO
+    HVF support                  : NO
+    WHPX support                 : NO
+    NVMM support                 : NO
+    Xen support                  : NO
+    TCG support                  : YES
+    TCG backend                  : native (aarch64)
+    TCG plugins                  : YES
+    TCG debug enabled            : NO
+    target list                  : x86_64-softmmu
+    default devices              : YES
+    out of process emulation     : NO
+    vfio-user server             : NO
+
+  Block layer support
+    coroutine backend            : sigaltstack
+    coroutine pool               : YES
+    Block whitelist (rw)         : 
+    Block whitelist (ro)         : 
+    Use block whitelist in tools : NO
+    VirtFS support               : YES
+    build virtiofs daemon        : NO
+    Live block migration         : YES
+    replication support          : YES
+    bochs support                : YES
+    cloop support                : YES
+    dmg support                  : YES
+    qcow v1 support              : YES
+    vdi support                  : YES
+    vvfat support                : YES
+    qed support                  : YES
+    parallels support            : YES
+    FUSE exports                 : NO
+    VDUSE block exports          : NO
+
+  Crypto
+    TLS priority                 : NORMAL
+    GNUTLS support               : NO
+    libgcrypt                    : NO
+    nettle                       : NO
+    AF_ALG support               : NO
+    rng-none                     : NO
+    Linux keyring                : NO
+
+  Dependencies
+    Cocoa support                : YES
+    vmnet.framework support      : YES
+    SDL support                  : NO
+    SDL image support            : NO
+    GTK support                  : NO
+    pixman                       : YES 0.42.2
+    VTE support                  : NO
+    slirp support                : NO
+    libtasn1                     : NO
+    PAM                          : YES
+    iconv support                : YES
+    curses support               : YES
+    virgl support                : NO
+    blkio support                : NO
+    curl support                 : YES 7.84.0
+    Multipath support            : NO
+    PNG support                  : NO
+    VNC support                  : YES
+    VNC SASL support             : YES
+    VNC JPEG support             : NO
+    CoreAudio support            : YES
+    JACK support                 : NO
+    brlapi support               : NO
+    vde support                  : NO
+    netmap support               : NO
+    l2tpv3 support               : NO
+    Linux AIO support            : NO
+    Linux io_uring support       : NO
+    ATTR/XATTR support           : NO
+    RDMA support                 : NO
+    PVRDMA support               : NO
+    fdt support                  : internal
+    libcap-ng support            : NO
+    bpf support                  : NO
+    spice protocol support       : NO
+    rbd support                  : NO
+    smartcard support            : NO
+    U2F support                  : NO
+    libusb                       : NO
+    usb net redir                : NO
+    OpenGL support (epoxy)       : NO
+    GBM                          : NO
+    libiscsi support             : NO
+    libnfs support               : NO
+    seccomp support              : NO
+    GlusterFS support            : NO
+    TPM support                  : YES
+    libssh support               : NO
+    lzo support                  : NO
+    snappy support               : NO
+    bzip2 support                : YES
+    lzfse support                : NO
+    zstd support                 : NO
+    NUMA host support            : NO
+    capstone                     : NO
+    libpmem support              : NO
+    libdaxctl support            : NO
+    libudev                      : NO
+    FUSE lseek                   : NO
+    selinux                      : NO
+
+  User defined options
+    Native files                 : config-meson.cross
+    prefix                       : /usr/local
+    b_pie                        : false
+    vfio_user_server             : disabled
+
+Found ninja-1.11.1 at /opt/homebrew/bin/ninja
+Running postconf script '/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/scripts/symlink-install-tree.py'
+```
+
+
+With `make` I got:
+
+```
+changing dir to build for /Library/Developer/CommandLineTools/usr/bin/make ""...
+  GIT     ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc
+[1/75] Generating qemu-version.h with a custom command (wrapped by meson to capture output)
+changing dir to build for /Library/Developer/CommandLineTools/usr/bin/make ""...
+  GIT     ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc
+[1/75] Generating qemu-version.h with a custom command (wrapped by meson to capture output)
+changing dir to build for /Library/Developer/CommandLineTools/usr/bin/make ""...
+/opt/homebrew/bin/ninja  build.ninja && touch build.ninja.stamp
+ninja: no work to do.
+/opt/homebrew/bin/python3 -B /Users/xxx/qemu/meson/meson.py introspect --targets --tests --benchmarks | /opt/homebrew/bin/python3 -B scripts/mtest2make.py > Makefile.mtest
+  GIT     ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc
+  GIT     ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc
+[1/2455] Generating config-poison.h with a custom command (wrapped by meson to capture output)
+[2/2455] Compiling C object libfdt.a.p/dtc_libfdt_fdt.c.o
+[3/2455] Compiling C object libfdt.a.p/dtc_libfdt_fdt_ro.c.o
+[4/2455] Compiling C object libfdt.a.p/dtc_libfdt_fdt_wip.c.o
+[5/2455] Compiling C object libfdt.a.p/dtc_libfdt_fdt_sw.c.o
+... (no error)
+[2455/2455] Linking target tests/qtest/readconfig-test
+changing dir to build for /Library/Developer/CommandLineTools/usr/bin/make ""...
+  GIT     ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc
+[1/48] Generating qemu-version.h with a custom command (wrapped by meson to capture output)
+[2/34] Generating tests/include/QAPI test (include) with a custom command
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1413 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1413
new file mode 100644
index 00000000..a2f985fd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1413
@@ -0,0 +1,22 @@
+I tried to use qemu-nbd in the shell script, but it seems that qemu-nbd has some delay.
+Description of problem:
+
+Steps to reproduce:
+1.
+```
+cat ~/test.sh
+#!/bin/bash
+qemu-nbd -c /dev/nbd0 $1
+mount -t ntfs3 -o uid=1000,gid=1000 /dev/disk/by-label/OS /mnt/OS
+```
+2.
+```
+sudo ~/test.sh ~/VM/win7_i386.qcow2
+mount: /mnt/OS: special device /dev/disk/by-label/OS does not exist.
+       dmesg(1) may have more information after failed mount system call.
+
+```
+Additional information:
+But when I added a one-second delay between qemu-nbd and mount commands, the problem was solved.
+
+The qemu-img convert command also has a similar problem. It seems that these commands have a certain delay. Is this in line with expectations?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1414 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1414
new file mode 100644
index 00000000..67c49498
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1414
@@ -0,0 +1,20 @@
+Configure script fix for glib version
+Description of problem:
+Script "configure" uses "pkg-config" directly, at line 2420: https://gitlab.com/qemu-project/qemu/-/blob/f9f0e6173e1d570847930abfe2b4560c7b6a964a/configure#L2420
+
+Because of it, GLIB_VERSION in "config-host.mak" can be taken from host system, under some circumstances (if PKG_CONFIG_PATH is not defined).
+
+In case of cross-compilation, "**$pkg_config**" should be used instead of "pkg-config", to use pkg-config from cross-compilation toolchain and to take GLIB_VERSION of cross-compiled glib (as it is **correctly used at line 1476**: https://gitlab.com/qemu-project/qemu/-/blob/f9f0e6173e1d570847930abfe2b4560c7b6a964a/configure#L1476 ).
+Steps to reproduce:
+1. Do not define PKG_CONFIG_PATH environment variable, use PKG_CONFIG variable instead.
+2. Try to ./configure with cross-compiled glib.
+3. GLIB_VERSION in config-host.mak will be from host glib.
+Additional information:
+Change lihe 2420:<br>
+https://gitlab.com/qemu-project/qemu/-/blob/f9f0e6173e1d570847930abfe2b4560c7b6a964a/configure#L2420
+<br>
+echo "GLIB_VERSION=$(**pkg-config** --modversion glib-2.0)" >> $config_host_mak
+<br>to:<br>
+echo "GLIB_VERSION=$(**\$pkg_config** --modversion glib-2.0)" >> $config_host_mak
+
+P.s. Sorry for posting the patch here, GitLab requires signing with a key to push the commit, it's too complicated to post 2-bytes fix.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1418 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1418
new file mode 100644
index 00000000..16faa1d8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1418
@@ -0,0 +1,87 @@
+Underflow in xlnx_dp_aux_pop_tx_fifo()
+Description of problem:
+Pop from s->tx_fifo but s->tx_fifo has zero element.
+Steps to reproduce:
+```
+export QEMU=/path/to/qemu-system-aarch64
+
+cat << EOF | $QEMU \
+-machine xlnx-zcu102 -monitor none -serial none \
+-display none -nodefaults -qtest stdio
+writel 0xfd4a0100 0x19c4406f
+EOF
+```
+Additional information:
+```
++ DEFAULT_INPUT_MAXSIZE=10000000
++ ./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp -max_len=10000000 -detect_leaks=0 ./crash-c15714102f0b894dea5c22f38852311567380926.minimized
+==14660==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x55db5cf9b840). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 1977030529
+INFO: Loaded 1 modules   (618603 inline 8-bit counters): 618603 [0x55db600fa000, 0x55db6019106b), 
+INFO: Loaded 1 PC tables (618603 PCs): 618603 [0x55db5f788d60,0x55db600f9410), 
+./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+Matching objects by name , *.core*, *.v_blend*, *.av_buffer_manager*, *.audio*
+This process will fuzz the following MemoryRegions:
+  * xlnx.v-dp.core[0] (size 3b0)
+  * xlnx.v-dp.v_blend[0] (size 1e0)
+  * xlnx.v-dp.audio[0] (size 50)
+  * xlnx.v-dp.av_buffer_manager[0] (size 238)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * xlnx.v-dp.core, EVENT_TYPE_MMIO_READ, 0xfd4a0000 +0x3b0, 4,4
+  * xlnx.v-dp.core, EVENT_TYPE_MMIO_WRITE, 0xfd4a0000 +0x3b0, 4,4
+  * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_READ, 0xfd4aa000 +0x1e0, 4,4
+  * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_WRITE, 0xfd4aa000 +0x1e0, 4,4
+  * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_READ, 0xfd4ab000 +0x238, 4,4
+  * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_WRITE, 0xfd4ab000 +0x238, 4,4
+  * xlnx.v-dp.audio, EVENT_TYPE_MMIO_READ, 0xfd4ac000 +0x50, 1,4
+  * xlnx.v-dp.audio, EVENT_TYPE_MMIO_WRITE, 0xfd4ac000 +0x50, 1,4
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 488Mb
+Running: ./crash-c15714102f0b894dea5c22f38852311567380926.minimized
+aarch64: xlnx_dp_aux_pop_tx_fifo: TX_FIFO underflow
+==14660== ERROR: libFuzzer: deadly signal
+    #0 0x55db5837410e in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
+    #1 0x55db582c2d81 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x55db5829bcb6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18
+    #3 0x55db5829bd82 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1
+    #4 0x55db5829bd82 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19
+    #5 0x7f98a612541f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f)
+    #6 0x7f98a5f3700a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+    #7 0x7f98a5f3700a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+    #8 0x7f98a5f16858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
+    #9 0x55db583a465a in __wrap_abort /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/less_crashes_wrappers.c:24:12
+    #10 0x55db58cce4d8 in xlnx_dp_aux_pop_tx_fifo /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:476:9
+    #11 0x55db58cc9ee7 in xlnx_dp_aux_set_command /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:524:22
+    #12 0x55db58cc6a92 in xlnx_dp_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:800:9
+    #13 0x55db5bf4eec3 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5
+    #14 0x55db5bf4e801 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18
+    #15 0x55db5bf4d126 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16
+    #16 0x55db5bfdb2de in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23
+    #17 0x55db5bfc941b in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12
+    #18 0x55db5bfc8ed8 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18
+    #19 0x55db583b40cb in qemu_writel /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1088:5
+    #20 0x55db583b2544 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1229:28
+    #21 0x55db5cf971ff in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5
+    #22 0x55db5cf8e57b in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9
+    #23 0x55db5cf8e450 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9
+    #24 0x55db583bb10c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1504:12
+    #25 0x55db5cf9bae2 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18
+    #26 0x55db5829c826 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17
+    #27 0x55db5827f454 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #28 0x55db5828a3fe in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19
+    #29 0x55db582769e6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #30 0x7f98a5f18082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #31 0x55db58276a3d in _start (/root/bugs/metadata/xlnx_dp-06/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp+0x3291a3d)
+
+NOTE: libFuzzer has rudimentary signal handlers.
+      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
+SUMMARY: libFuzzer: deadly signal
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+0x1,0x9,0x0,0x1,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x6f,0x40,0xc4,0x19,0x0,0x0,0x0,0x0,
+\x01\x09\x00\x01J\xfd\x00\x00\x00\x00\x04\x00\x00\x00o@\xc4\x19\x00\x00\x00\x00
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1419 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1419
new file mode 100644
index 00000000..52b8ea54
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1419
@@ -0,0 +1,92 @@
+Overflow in xlnx_dp_aux_push_rx_fifo()
+Description of problem:
+Pushing stuff into s->rx_fifo many times make s->rx_fifo overflow.
+Steps to reproduce:
+```
+export QEMU=/path/to/qemu-system-aarch64
+
+cat << EOF | $QEMU \
+-machine xlnx-zcu102 -monitor none -serial none \
+-display none -nodefaults -qtest stdio
+writel 0xfd4a0100 0x7fb141e6
+writel 0xfd4a0100 0x7fb141e6
+writel 0xfd4a0100 0x7fb141e6
+EOF
+```
+Additional information:
+```
+root@3728b1f90dbd:~/bugs/metadata/xlnx_dp-03# bash -x xlnx_dp-03.videzzo 
++ DEFAULT_INPUT_MAXSIZE=10000000
++ ./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp -max_len=10000000 -detect_leaks=0 poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp-crash-a6a2bd23ff0408dd50652670fdcdf9f5ceaab95d.minimized
+==767==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x55d36d8b3870). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 1781001818
+INFO: Loaded 1 modules   (618604 inline 8-bit counters): 618604 [0x55d370a12000, 0x55d370aa906c), 
+INFO: Loaded 1 PC tables (618604 PCs): 618604 [0x55d3700a0ce0,0x55d370a113a0), 
+./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+Matching objects by name , *.core*, *.v_blend*, *.av_buffer_manager*, *.audio*
+This process will fuzz the following MemoryRegions:
+  * xlnx.v-dp.core[0] (size 3b0)
+  * xlnx.v-dp.v_blend[0] (size 1e0)
+  * xlnx.v-dp.audio[0] (size 50)
+  * xlnx.v-dp.av_buffer_manager[0] (size 238)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * xlnx.v-dp.core, EVENT_TYPE_MMIO_READ, 0xfd4a0000 +0x3b0, 4,4
+  * xlnx.v-dp.core, EVENT_TYPE_MMIO_WRITE, 0xfd4a0000 +0x3b0, 4,4
+  * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_READ, 0xfd4aa000 +0x1e0, 4,4
+  * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_WRITE, 0xfd4aa000 +0x1e0, 4,4
+  * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_READ, 0xfd4ab000 +0x238, 4,4
+  * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_WRITE, 0xfd4ab000 +0x238, 4,4
+  * xlnx.v-dp.audio, EVENT_TYPE_MMIO_READ, 0xfd4ac000 +0x50, 1,4
+  * xlnx.v-dp.audio, EVENT_TYPE_MMIO_WRITE, 0xfd4ac000 +0x50, 1,4
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 492Mb
+Running: poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp-crash-a6a2bd23ff0408dd50652670fdcdf9f5ceaab95d.minimized
+qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: ../util/fifo8.c:43: void fifo8_push_all(Fifo8 *, const uint8_t *, uint32_t): Assertion `fifo->num + num <= fifo->capacity' failed.
+==767== ERROR: libFuzzer: deadly signal
+    #0 0x55d368c8c10e in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
+    #1 0x55d368bdad81 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x55d368bb3cb6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18
+    #3 0x55d368bb3d82 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1
+    #4 0x55d368bb3d82 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19
+    #5 0x7f9897d8741f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f)
+    #6 0x7f9897b9900a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+    #7 0x7f9897b9900a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+    #8 0x7f9897b78858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
+    #9 0x7f9897b78728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3
+    #10 0x7f9897b89fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3
+    #11 0x55d36d56bff3 in fifo8_push_all /root/videzzo/videzzo_qemu/qemu/build-san-6/../util/fifo8.c:43:5
+    #12 0x55d3695e64d3 in xlnx_dp_aux_push_rx_fifo /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:436:5
+    #13 0x55d3695e1e9a in xlnx_dp_aux_set_command /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:513:13
+    #14 0x55d3695dea92 in xlnx_dp_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:805:9
+    #15 0x55d36c866ef3 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5
+    #16 0x55d36c866831 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18
+    #17 0x55d36c865156 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16
+    #18 0x55d36c8f330e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23
+    #19 0x55d36c8e144b in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12
+    #20 0x55d36c8e0f08 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18
+    #21 0x55d368ccc0cb in qemu_writel /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1088:5
+    #22 0x55d368cca544 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1229:28
+    #23 0x55d36d8af22f in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5
+    #24 0x55d36d8a65ab in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9
+    #25 0x55d36d8a6480 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9
+    #26 0x55d368cd310c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1504:12
+    #27 0x55d36d8b3b12 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18
+    #28 0x55d368bb4826 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17
+    #29 0x55d368b97454 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #30 0x55d368ba23fe in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19
+    #31 0x55d368b8e9e6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #32 0x7f9897b7a082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #33 0x55d368b8ea3d in _start (/root/bugs/metadata/xlnx_dp-03/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp+0x3291a3d)
+
+NOTE: libFuzzer has rudimentary signal handlers.
+      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
+SUMMARY: libFuzzer: deadly signal
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+0x1,0x9,0x0,0x1,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0xe6,0x41,0xb1,0x7f,0x0,0x0,0x0,0x0,0x1,0x9,0x0,0x1,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0xe6,0x41,0xb1,0x7f,0x0,0x0,0x0,0x0,0x1,0x9,0x0,0x1,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0xe6,0x41,0xb1,0x7f,0x0,0x0,0x0,0x0,
+\x01\x09\x00\x01J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\xe6A\xb1\x7f\x00\x00\x00\x00\x01\x09\x00\x01J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\xe6A\xb1\x7f\x00\x00\x00\x00\x01\x09\x00\x01J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\xe6A\xb1\x7f\x00\x00\x00\x00
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/142 b/gitlab/issues_text/target_missing/host_missing/accel_missing/142
new file mode 100644
index 00000000..a348f4be
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/142
@@ -0,0 +1 @@
+qemu -readconfig/-writeconfig cannot handle quotes in values
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1420 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1420
new file mode 100644
index 00000000..0ae97e28
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1420
@@ -0,0 +1,39 @@
+Missing path for pkg-config on amd64 debian based distros
+Description of problem:
+This error occurs when attempting to configure qemu from git :
+```error
+ERROR: glib-2.56 gthread-2.0 is required to compile QEMU
+```
+
+Although it seems to be as simple as "_just install the dev lib!!!_" it is not that simple.
+
+1. First of all, my system already has the library installed :
+   ```sh
+   dpkg -l | grep libglib2.0-dev
+   ii  libglib2.0-dev:amd64                          2.74.4-1                            amd64        Development files for the GLib library
+   ii  libglib2.0-dev-bin                            2.74.4-1                            amd64        Development utilities for the GLib library
+   ```
+1. Second, the file required by _pkg-config_ does exist aswell :
+   ```sh
+   ls /usr/lib/x86_64-linux-gnu/pkgconfig/gthread-2.0.pc -l
+   -rw-r--r-- 1 root root 240 dez 27 20:42 /usr/lib/x86_64-linux-gnu/pkgconfig/gthread-2.0.pc
+   ```
+1. Finally, the real problem is that pkg-config is not able to identify it **unless** you specify the _x86-64_ dir :
+   - Default usage. It fails.
+      ```sh
+      pkg-config --modversion gthread-2.0
+      Package gthread-2.0 was not found in the pkg-config search path.
+      Perhaps you should add the directory containing `gthread-2.0.pc'
+      to the PKG_CONFIG_PATH environment variable
+      Package 'gthread-2.0', required by 'virtual:world', not found
+      ```
+   - Fixed usage (temp)
+      ```sh
+      env PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/lib/x86_64-linux-gnu/pkgconfig/" pkg-config --modversion gthread-2.0
+      2.74.4
+      ```
+Steps to reproduce:
+1. clone qemu (master)
+2. try to run _configure_
+Additional information:
+Of course it seems to be a problem related to the program _pkg-config_ itself, or even by the distro's package, but it totally prevents any build of qemu in a debian-based distro, with architecture _amd64_.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1423 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1423
new file mode 100644
index 00000000..495d48ce
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1423
@@ -0,0 +1,13 @@
+QEMU 6.2.0 fullscreen problem
+Description of problem:
+After running the command above, clicking on "Try Ubuntu" and adjusting the guest display resolution in GNOME to the native resolution, pressing ctrl+alt+f yields a "fullscreen" that only covers the QEMU window but not the entire host screen. This is not the case when switching to fullscreen while the boot screen is active or running `qemu-system-x86_64 -display gtk,full-screen=on`. 
+
+The problem also occurs when replacing `-device qxl-vga` by `-device VGA,vgamem_mb=64`. The problem however does not occur when using `-device virtio-vga` instead of `-device qxl-vga` or `-display sdl` instead of `-display gtk`.
+Steps to reproduce:
+1. Run the command above
+2. Click "Try Ubuntu"
+3. Set guest resolution to native resolution (1920x1200 in my case)
+4. Move the window a bit off the corners to observe the effect
+5. Press ctrl+alt+f
+Additional information:
+The bug has also been [reported here](https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2000739).
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1426 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1426
new file mode 100644
index 00000000..72b5cdd9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1426
@@ -0,0 +1,38 @@
+On windows, display spice-app is not able to initialize, start spice-server and consequently can't use spice-client
+Description of problem:
+I want to try windows spice-client / virt-viewer.exe (v11.0.256) instead of gtk client.  
+Windows spice client virtviewer won't start like it does under Linux.  
+The error message indicaes that the spice-server itself failed to open spice sockets
+The registry to handle ```spice://``` URI handler is configured.
+Steps to reproduce:
+1. just run command
+Additional information:
+URI handler in registry is configure using a regestry import file ```spiceproto.reg```
+```
+Windows Registry Editor Version 5.00
+
+[HKEY_CLASSES_ROOT\spice]
+"URL Protocol"=""
+
+[HKEY_CLASSES_ROOT\spice\DefaultIcon]
+@="C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe,1"
+
+[HKEY_CLASSES_ROOT\spice\Extensions]
+[HKEY_CLASSES_ROOT\spice\shell]
+[HKEY_CLASSES_ROOT\spice\shell\open]
+[HKEY_CLASSES_ROOT\spice\shell\open\command] 
+@="\"C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe\" \"%1\""
+
+[HKEY_CLASSES_ROOT\spice+unix]
+"URL Protocol"=""
+
+[HKEY_CLASSES_ROOT\spice+unix\DefaultIcon]
+@="C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe,1"
+
+[HKEY_CLASSES_ROOT\spice+unix\Extensions]
+[HKEY_CLASSES_ROOT\spice+unix\shell]
+[HKEY_CLASSES_ROOT\spice+unix\shell\open]
+[HKEY_CLASSES_ROOT\spice+unix\shell\open\command] 
+@="\"C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe\" \"%1\""
+```
+This URI handler is working, and can be seen to work by typing ```spice://abcdefg``` in firefox.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1429 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1429
new file mode 100644
index 00000000..17918bae
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1429
@@ -0,0 +1,55 @@
+Out of bounds in xilinx_spips_write()
+Description of problem:
+The size of TYPE_XILINX_SPIPS's and TYPE_XILINX_QSPIPS's memory regions is
+0x100, but it is set to 0x200. UBSAN captures Out of bounds accesses.
+Steps to reproduce:
+```
+export QEMU=/path/to/qemu-system-aarch64
+export UBSAN_OPTIONS=halt_on_error=1:symbolize=1:print_stacktrace=1
+
+cat << EOF | $QEMU \
+-machine xlnx-zcu102 -monitor none -serial none \
+-display none -nodefaults -qtest stdio
+writew 0xff050108 0x29be
+EOF
+```
+Additional information:
+```
+==852678==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+[I 0.000001] OPENED
+pulseaudio: set_sink_input_volume() failed
+pulseaudio: Reason: Invalid argument
+pulseaudio: set_sink_input_mute() failed
+pulseaudio: Reason: Invalid argument
+qemu-system-aarch64: warning: nic cadence_gem.0 has no peer
+qemu-system-aarch64: warning: nic cadence_gem.1 has no peer
+qemu-system-aarch64: warning: nic cadence_gem.2 has no peer
+qemu-system-aarch64: warning: nic cadence_gem.3 has no peer
+[R +0.323364] writew 0xff050108 0x29be
+../hw/ssi/xilinx_spips.c:1031:22: runtime error: index 66 out of bounds for type 'uint32_t [64]'
+    #0 0x55b7450b6895 in xilinx_spips_write /home/liuqiang/project-videzzo/qemu-devel/build/../hw/ssi/xilinx_spips.c:1031:22
+    #1 0x55b747b29790 in memory_region_write_accessor /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/memory.c:493:5
+    #2 0x55b747b28c2d in access_with_adjusted_size /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/memory.c:555:18
+    #3 0x55b747b268f4 in memory_region_dispatch_write /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/memory.c:1515:16
+    #4 0x55b747c1a071 in flatview_write_continue /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/physmem.c:2825:23
+    #5 0x55b747c00d92 in flatview_write /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/physmem.c:2867:12
+    #6 0x55b747c007b8 in address_space_write /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/physmem.c:2963:18
+    #7 0x55b747c49f31 in qtest_process_command /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/qtest.c:528:13
+    #8 0x55b747c42f6e in qtest_process_inbuf /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/qtest.c:802:9
+    #9 0x55b747c5b783 in qtest_read /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/qtest.c:814:5
+    #10 0x55b748c6b602 in qemu_chr_be_write_impl /home/liuqiang/project-videzzo/qemu-devel/build/../chardev/char.c:201:9
+    #11 0x55b748c6b74a in qemu_chr_be_write /home/liuqiang/project-videzzo/qemu-devel/build/../chardev/char.c:213:9
+    #12 0x55b748c81f6a in fd_chr_read /home/liuqiang/project-videzzo/qemu-devel/build/../chardev/char-fd.c:72:9
+    #13 0x55b7481cbe66 in qio_channel_fd_source_dispatch /home/liuqiang/project-videzzo/qemu-devel/build/../io/channel-watch.c:84:12
+    #14 0x7fbad3de404d in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5204d)
+    #15 0x55b74923a917 in glib_pollfds_poll /home/liuqiang/project-videzzo/qemu-devel/build/../util/main-loop.c:297:9
+    #16 0x55b749238017 in os_host_main_loop_wait /home/liuqiang/project-videzzo/qemu-devel/build/../util/main-loop.c:320:5
+    #17 0x55b749237967 in main_loop_wait /home/liuqiang/project-videzzo/qemu-devel/build/../util/main-loop.c:606:11
+    #18 0x55b745858753 in qemu_main_loop /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/runstate.c:739:9
+    #19 0x55b74304cf34 in qemu_default_main /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/main.c:37:14
+    #20 0x55b74304cfd0 in main /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/main.c:48:12
+    #21 0x7fbad227a082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #22 0x55b742fa271d in _start (/home/liuqiang/project-videzzo/qemu-devel/build/qemu-system-aarch64+0x3dc371d)
+
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/ssi/xilinx_spips.c:1031:22 in
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/143 b/gitlab/issues_text/target_missing/host_missing/accel_missing/143
new file mode 100644
index 00000000..b0e822d9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/143
@@ -0,0 +1 @@
+xhci HCIVERSION register read emulation incorrectly handled
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1430 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1430
new file mode 100644
index 00000000..18ec2faf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1430
@@ -0,0 +1,110 @@
+Underflow in xlnx_dp_aux_push_rx_fifo()
+Description of problem:
+Pop two times from s->tx_fifo[2] but there is one element left. Since the fifo
+is not empty, the check at [1] will fail.
+
+```
+static void xilinx_spips_flush_txfifo(XilinxSPIPS *s)
+{
+    // ...
+    for (;;) {
+        // ...
+        if (fifo8_is_empty(&s->tx_fifo)) {   // ---------------> [1]
+            xilinx_spips_update_ixr(s);
+            return;
+        } else if (s->snoop_state == SNOOP_STRIPING ||
+                   s->snoop_state == SNOOP_NONE) {
+            for (i = 0; i < num_effective_busses(s); ++i) {
+                tx_rx[i] = fifo8_pop(&s->tx_fifo); // ---------> [2]
+            }
+            stripe8(tx_rx, num_effective_busses(s), false);
+        } else if (s->snoop_state >= SNOOP_ADDR) {
+        // ...
+```
+Steps to reproduce:
+```
+export QEMU=/path/to/qemu-system-aarch64
+
+cat << EOF | $QEMU \
+-machine xlnx-zcu102 -monitor none -serial none \
+-display none -nodefaults -qtest stdio
+writel 0xff0f00a0 0x74b13699
+readl 0xc1af068c
+EOF
+```
+Additional information:
+```
+==64457==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x55f8037f3440). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 1864808059
+INFO: Loaded 1 modules   (600775 inline 8-bit counters): 600775 [0x55f806e06000, 0x55f806e98ac7), 
+INFO: Loaded 1 PC tables (600775 PCs): 600775 [0x55f8064dab90,0x55f806e05800), 
+/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-qspips: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+Matching objects by name , *spi*, *lqspi*
+This process will fuzz the following MemoryRegions:
+  * spi[0] (size 200)
+  * spi[0] (size 200)
+  * lqspi[0] (size 2000000)
+  * spi[0] (size 200)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * spi, EVENT_TYPE_MMIO_READ, 0xff050000 +0x200, 1,4
+  * spi, EVENT_TYPE_MMIO_WRITE, 0xff050000 +0x200, 1,4
+  * spi, EVENT_TYPE_MMIO_READ, 0xff040000 +0x200, 1,4
+  * spi, EVENT_TYPE_MMIO_WRITE, 0xff040000 +0x200, 1,4
+  * spi, EVENT_TYPE_MMIO_READ, 0xff0f0000 +0x200, 1,4
+  * spi, EVENT_TYPE_MMIO_WRITE, 0xff0f0000 +0x200, 1,4
+  * lqspi, EVENT_TYPE_MMIO_READ, 0xc0000000 +0x2000000, 4,4
+  * lqspi, EVENT_TYPE_MMIO_WRITE, 0xc0000000 +0x2000000, 4,4
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 509Mb
+Running: /root/videzzo/videzzo_qemu/out-san/poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-qspips-crash-a2dce6d03fde8dc9cb50fb0c8708f307ca93d7c2.minimized
+qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-qspips: ../util/fifo8.c:62: uint8_t fifo8_pop(Fifo8 *): Assertion `fifo->num > 0' failed.
+==64457== ERROR: libFuzzer: deadly signal
+    #0 0x55f7fecb90fe in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
+    #1 0x55f7fec07d71 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x55f7febe0ca6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18
+    #3 0x55f7febe0d72 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1
+    #4 0x55f7febe0d72 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19
+    #5 0x7f67ea63a41f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f)
+    #6 0x7f67ea44c00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+    #7 0x7f67ea44c00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+    #8 0x7f67ea42b858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
+    #9 0x7f67ea42b728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3
+    #10 0x7f67ea43cfd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3
+    #11 0x55f803645699 in fifo8_pop /root/videzzo/videzzo_qemu/qemu/out-san/../util/fifo8.c:62:5
+    #12 0x55f8009d1ded in xilinx_spips_flush_txfifo /root/videzzo/videzzo_qemu/qemu/out-san/../hw/ssi/xilinx_spips.c:623:28
+    #13 0x55f8009dc092 in lqspi_load_cache /root/videzzo/videzzo_qemu/qemu/out-san/../hw/ssi/xilinx_spips.c:1194:9
+    #14 0x55f8009da069 in lqspi_read /root/videzzo/videzzo_qemu/qemu/out-san/../hw/ssi/xilinx_spips.c:1231:5
+    #15 0x55f80294a61a in memory_region_read_with_attrs_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:464:9
+    #16 0x55f802908961 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18
+    #17 0x55f8029060d8 in memory_region_dispatch_read1 /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1431:16
+    #18 0x55f802905468 in memory_region_dispatch_read /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1458:9
+    #19 0x55f802983a6d in flatview_read_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2892:23
+    #20 0x55f802985078 in flatview_read /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2934:12
+    #21 0x55f802984b38 in address_space_read_full /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2947:18
+    #22 0x55f7fecebb51 in address_space_read /root/videzzo/videzzo_qemu/qemu/include/exec/memory.h:2873:18
+    #23 0x55f7fecebb51 in qemu_readl /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1037:5
+    #24 0x55f7fece9c16 in dispatch_mmio_read /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1051:35
+    #25 0x55f8037ee8bf in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5
+    #26 0x55f8037e5c3d in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9
+    #27 0x55f8037e59e4 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9
+    #28 0x55f7fed0108c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12
+    #29 0x55f8037f370b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18
+    #30 0x55f7febe1816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17
+    #31 0x55f7febc4444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #32 0x55f7febcf3ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19
+    #33 0x55f7febbb9d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #34 0x7f67ea42d082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #35 0x55f7febbba2d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-qspips+0x3454a2d)
+
+NOTE: libFuzzer has rudimentary signal handlers.
+      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
+SUMMARY: libFuzzer: deadly signal
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+0x1,0xd,0xa0,0x0,0xf,0xff,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x99,0x36,0xb1,0x74,0x0,0x0,0x0,0x0,0x0,0xe,0x8c,0x6,0xaf,0xc1,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,
+\x01\x0d\xa0\x00\x0f\xff\x00\x00\x00\x00\x04\x00\x00\x00\x996\xb1t\x00\x00\x00\x00\x00\x0e\x8c\x06\xaf\xc1\x00\x00\x00\x00\x04\x00\x00\x00
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1431 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1431
new file mode 100644
index 00000000..f1d70adb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1431
@@ -0,0 +1,50 @@
+qemu spice support opengl
+Steps to reproduce:
+I wan to use spice support opengl, but my qemu seems not support,what can i do to support opengl for spice?
+
+qemu configure:
+```
+./configure --target-list=x86_64-softmmu --enable-kvm --enable-debug --enable-spice --enable-numa --enable-libusb --enable-curl --enable-usb-redir --enable-libiscsi  --enable-virglrenderer --enable-opengl  --enable-gtk --prefix="/usr"
+```
+
+xml:
+```xml
+<domain type='kvm'>
+    <name>test</name>
+    <memory>1048576</memory>
+    <currentMemory>1048576</currentMemory>
+    <vcpu>1</vcpu>
+    <os>
+      <type arch='x86_64' machine='pc'>hvm</type>
+    </os>
+   <cpu mode='custom' match='exact' check='full'>
+    <topology sockets='1' dies='1' cores='1' threads='1'/>
+  </cpu>
+   <features>
+     <acpi/>
+     <apic/>
+     <pae/>
+   </features>
+   <clock offset='localtime'/>
+   <on_poweroff>destroy</on_poweroff>
+   <on_reboot>restart</on_reboot>
+   <on_crash>destroy</on_crash>
+   <devices>
+     <emulator>/usr/bin/qemu-system-x86_64</emulator>
+     <disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2'/>
+       <source file='/root/kk.img'/>
+       <target dev='hda' bus='ide'/>
+     </disk>
+    <input type='mouse' bus='ps2'/>
+    <graphics type='spice'>
+      <listen type='none'/>
+      <gl enable='yes' rendernode='/dev/dri/renderD128'/>
+    </graphics>
+   </devices>
+</domain>
+```
+
+error report:
+
+![image](/uploads/74ecd52966d71bbbd2921f4c292002a9/image.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1432 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1432
new file mode 100644
index 00000000..241e8e81
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1432
@@ -0,0 +1,24 @@
+meson prints "Unknown TAP version. The first line MUST be `TAP version <int>`. Assuming version 12." for every test
+Description of problem:
+Run 'make check V=1' and observe that every test causes an warning message about an unknown TAP version
+
+```
+>>> G_TEST_SRCDIR=/home/berrange/src/virt/qemu/tests/unit MALLOC_PERTURB_=61 G_TEST_BUILDDIR=/home/berrange/src/virt/qemu/build/tests/unit /home/berrange/src/virt/qemu/build/tests/unit/test-shift128 --tap -k
+▶ 22/44 /host-utils/test_lshift                       OK            
+▶ 22/44 /host-utils/test_rshift                       OK            
+22/44 qemu:unit / test-shift128                       OK              0.01s   2 subtests passed
+
+Unknown TAP version. The first line MUST be `TAP version <int>`. Assuming version 12.
+
+```
+
+This message comes from inside meson
+
+```
+$ rpm -ql meson | xargs grep 'Unknown TAP version' 2>/dev/null
+/usr/lib/python3.11/site-packages/mesonbuild/mtest.py:            self.warnings.append('Unknown TAP version. The first line MUST be `TAP version <int>`. Assuming version 12.')
+```
+
+This is with meson-1.0.0-1.fc38.noarch
+Steps to reproduce:
+1. make check V=1
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1433 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1433
new file mode 100644
index 00000000..2e880f51
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1433
@@ -0,0 +1,157 @@
+Abort in lan9118_16bit_mode_[read|write]()
+Description of problem:
+[read|write][w|l] are allowed but [read|write]b are not allowed when mode_16bit is enabled.
+Steps to reproduce:
+```
+export QEMU=/path/to/qemu-system-arm
+
+cat << EOF | $QEMU \
+-machine smdkc210 -monitor none -serial none \
+-display none -qtest stdio
+readb 0x5000070
+EOF
+```
+Additional information:
+```
+==1940==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x5654b8eede90). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 3248453476
+INFO: Loaded 1 modules   (601357 inline 8-bit counters): 601357 [0x5654bbdd8000, 0x5654bbe6ad0d), 
+INFO: Loaded 1 PC tables (601357 PCs): 601357 [0x5654bb4aa340,0x5654bbdd7410), 
+./qemu-videzzo-arm-target-videzzo-fuzz-lan9118: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
+Matching objects by name , *lan9118-mmio*
+This process will fuzz the following MemoryRegions:
+  * lan9118-mmio[0] (size 100)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * lan9118-mmio, EVENT_TYPE_MMIO_READ, 0x5000000 +0x100, 1,4
+  * lan9118-mmio, EVENT_TYPE_MMIO_WRITE, 0x5000000 +0x100, 1,4
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 221Mb
+Running: ./crash-663e5408ee573b1e9d073c796ffbaaae9bd583cb
+qemu: hardware error: lan9118_read: Bad size 0x1
+
+CPU #0:
+R00=00000000 R01=00000000 R02=00000000 R03=00000000
+R04=00000000 R05=00000000 R06=00000000 R07=00000000
+R08=00000000 R09=00000000 R10=00000000 R11=00000000
+R12=00000000 R13=00000000 R14=00000000 R15=00000000
+PSR=400001d3 -Z-- A svc32
+s00=00000000 s01=00000000 d00=0000000000000000
+s02=00000000 s03=00000000 d01=0000000000000000
+s04=00000000 s05=00000000 d02=0000000000000000
+s06=00000000 s07=00000000 d03=0000000000000000
+s08=00000000 s09=00000000 d04=0000000000000000
+s10=00000000 s11=00000000 d05=0000000000000000
+s12=00000000 s13=00000000 d06=0000000000000000
+s14=00000000 s15=00000000 d07=0000000000000000
+s16=00000000 s17=00000000 d08=0000000000000000
+s18=00000000 s19=00000000 d09=0000000000000000
+s20=00000000 s21=00000000 d10=0000000000000000
+s22=00000000 s23=00000000 d11=0000000000000000
+s24=00000000 s25=00000000 d12=0000000000000000
+s26=00000000 s27=00000000 d13=0000000000000000
+s28=00000000 s29=00000000 d14=0000000000000000
+s30=00000000 s31=00000000 d15=0000000000000000
+s32=00000000 s33=00000000 d16=0000000000000000
+s34=00000000 s35=00000000 d17=0000000000000000
+s36=00000000 s37=00000000 d18=0000000000000000
+s38=00000000 s39=00000000 d19=0000000000000000
+s40=00000000 s41=00000000 d20=0000000000000000
+s42=00000000 s43=00000000 d21=0000000000000000
+s44=00000000 s45=00000000 d22=0000000000000000
+s46=00000000 s47=00000000 d23=0000000000000000
+s48=00000000 s49=00000000 d24=0000000000000000
+s50=00000000 s51=00000000 d25=0000000000000000
+s52=00000000 s53=00000000 d26=0000000000000000
+s54=00000000 s55=00000000 d27=0000000000000000
+s56=00000000 s57=00000000 d28=0000000000000000
+s58=00000000 s59=00000000 d29=0000000000000000
+s60=00000000 s61=00000000 d30=0000000000000000
+s62=00000000 s63=00000000 d31=0000000000000000
+FPSCR: 00000000
+CPU #1:
+R00=00000000 R01=00000000 R02=00000000 R03=00000000
+R04=00000000 R05=00000000 R06=00000000 R07=00000000
+R08=00000000 R09=00000000 R10=00000000 R11=00000000
+R12=00000000 R13=00000000 R14=00000000 R15=00000000
+PSR=400001d3 -Z-- A svc32
+s00=00000000 s01=00000000 d00=0000000000000000
+s02=00000000 s03=00000000 d01=0000000000000000
+s04=00000000 s05=00000000 d02=0000000000000000
+s06=00000000 s07=00000000 d03=0000000000000000
+s08=00000000 s09=00000000 d04=0000000000000000
+s10=00000000 s11=00000000 d05=0000000000000000
+s12=00000000 s13=00000000 d06=0000000000000000
+s14=00000000 s15=00000000 d07=0000000000000000
+s16=00000000 s17=00000000 d08=0000000000000000
+s18=00000000 s19=00000000 d09=0000000000000000
+s20=00000000 s21=00000000 d10=0000000000000000
+s22=00000000 s23=00000000 d11=0000000000000000
+s24=00000000 s25=00000000 d12=0000000000000000
+s26=00000000 s27=00000000 d13=0000000000000000
+s28=00000000 s29=00000000 d14=0000000000000000
+s30=00000000 s31=00000000 d15=0000000000000000
+s32=00000000 s33=00000000 d16=0000000000000000
+s34=00000000 s35=00000000 d17=0000000000000000
+s36=00000000 s37=00000000 d18=0000000000000000
+s38=00000000 s39=00000000 d19=0000000000000000
+s40=00000000 s41=00000000 d20=0000000000000000
+s42=00000000 s43=00000000 d21=0000000000000000
+s44=00000000 s45=00000000 d22=0000000000000000
+s46=00000000 s47=00000000 d23=0000000000000000
+s48=00000000 s49=00000000 d24=0000000000000000
+s50=00000000 s51=00000000 d25=0000000000000000
+s52=00000000 s53=00000000 d26=0000000000000000
+s54=00000000 s55=00000000 d27=0000000000000000
+s56=00000000 s57=00000000 d28=0000000000000000
+s58=00000000 s59=00000000 d29=0000000000000000
+s60=00000000 s61=00000000 d30=0000000000000000
+s62=00000000 s63=00000000 d31=0000000000000000
+FPSCR: 00000000
+==1940== ERROR: libFuzzer: deadly signal
+    #0 0x5654b48090fe in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
+    #1 0x5654b4757d71 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x5654b4730ca6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18
+    #3 0x5654b4730d72 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1
+    #4 0x5654b4730d72 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19
+    #5 0x7fb6db17941f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f)
+    #6 0x7fb6daf8b00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+    #7 0x7fb6daf8b00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+    #8 0x7fb6daf6a858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
+    #9 0x5654b483964a in __wrap_abort /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/less_crashes_wrappers.c:24:12
+    #10 0x5654b6a64d84 in hw_error /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/cpus.c:128:5
+    #11 0x5654b5ac50c7 in lan9118_16bit_mode_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/net/lan9118.c:1319:5
+    #12 0x5654b7ee045b in memory_region_read_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:440:11
+    #13 0x5654b7ea0761 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18
+    #14 0x5654b7e9db2c in memory_region_dispatch_read1 /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1424:16
+    #15 0x5654b7e9d268 in memory_region_dispatch_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1457:9
+    #16 0x5654b7f1946d in flatview_read_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2892:23
+    #17 0x5654b7f1aa78 in flatview_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2934:12
+    #18 0x5654b7f1a538 in address_space_read_full /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2947:18
+    #19 0x5654b483a7ea in address_space_read /root/videzzo/videzzo_qemu/qemu/include/exec/memory.h:2869:18
+    #20 0x5654b483a7ea in qemu_readb /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1010:5
+    #21 0x5654b483997e in dispatch_mmio_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1034:35
+    #22 0x5654b8ee984f in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5
+    #23 0x5654b8ee0bcb in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9
+    #24 0x5654b8ee0aa0 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9
+    #25 0x5654b48500fc in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1497:12
+    #26 0x5654b8eee132 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18
+    #27 0x5654b4731816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17
+    #28 0x5654b4714444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #29 0x5654b471f3ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19
+    #30 0x5654b470b9d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #31 0x7fb6daf6c082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #32 0x5654b470ba2d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-lan9118+0x300da2d)
+
+NOTE: libFuzzer has rudimentary signal handlers.
+      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
+SUMMARY: libFuzzer: deadly signal
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+0x4,0x2,0x29,0x92,0xa,0x0,0x0,0x0,0x0,0x0,0x0,0x8,0x70,0x0,0x0,0x5,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x1,0x9,0x48,0x0,0x0,0x5,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x29,0x1f,0x8e,0x23,0x0,0x0,0x0,0x0,
+\x04\x02)\x92\x0a\x00\x00\x00\x00\x00\x00\x08p\x00\x00\x05\x00\x00\x00\x00\x01\x00\x00\x00\x01\x09H\x00\x00\x05\x00\x00\x00\x00\x04\x00\x00\x00)\x1f\x8e#\x00\x00\x00\x00
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1438 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1438
new file mode 100644
index 00000000..88ef2cda
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1438
@@ -0,0 +1,7 @@
+Allow to use QEMU sockets as a CAN bus backend
+Additional information:
+Good possible example how it can be done is via UDP multicast in `python-can` library:
+- https://python-can.readthedocs.io/en/master/interfaces/udp_multicast.html
+
+Another option, with less features is using a simple serial/character device like in:
+- https://python-can.readthedocs.io/en/master/interfaces/serial.html
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1439 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1439
new file mode 100644
index 00000000..d3b6abb5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1439
@@ -0,0 +1,11 @@
+QEMU crashes when there is an "[accel]" section in the config file
+Description of problem:
+QEMU crashes with a segmentation fault if there is a "[accel]" section in the config file with a type="kvm" entry. It would be maybe still be OK if there was an error message instead, but it should certainly not crash.
+Steps to reproduce:
+```
+$ cat > /tmp/config <<EOF
+[accel]
+type = "kvm"
+EOF
+$ qemu-system-x86_64 -readconfig /tmp/config
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/144 b/gitlab/issues_text/target_missing/host_missing/accel_missing/144
new file mode 100644
index 00000000..9a0915ae
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/144
@@ -0,0 +1 @@
+Passthrough USB Host Keyboard doesn't work on Q35 platform on boot-up
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1440 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1440
new file mode 100644
index 00000000..1e505afb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1440
@@ -0,0 +1 @@
+block/curl.c uses curl features deprecated in curl 7.55.0 and 7.85.0
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1442 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1442
new file mode 100644
index 00000000..4dc69b57
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1442
@@ -0,0 +1 @@
+RISC-V qemu, get cpu tick
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1443 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1443
new file mode 100644
index 00000000..fc03f8a0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1443
@@ -0,0 +1 @@
+site download.qemu.org | non-adequate function applied for sorting by date-time
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1445 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1445
new file mode 100644
index 00000000..bdebf625
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1445
@@ -0,0 +1,127 @@
+Negative-size-param in nand_blk_load_512()
+Description of problem:
+Found a way to trigger negative-size-param when calling memcpy in
+nand_blk_load_512() called by nand_getio(). Specifically, the offset can
+be larger than NAND_PAGE_SIZE + OOB_SIZE, e.g., 0x211.
+
+``` c
+    if (s->blk) {
+        // ...
+    } else {
+        memcpy(s->io, s->storage + PAGE_START(s->addr) +
+                        // offset=0x211
+                        offset, NAND_PAGE_SIZE + OOB_SIZE - offset);
+        s->ioaddr = s->io;
+    }
+```
+Steps to reproduce:
+```
+export QEMU=/path/to/qemu-system-arm
+
+cat << EOF | $QEMU \
+-machine tosa -monitor none -serial none \
+-display none -qtest stdio
+write 0x10000104 0x1 0x7f
+write 0x10000111 0x1 0x52
+read 0x10005200 0x1
+read 0x10005200 0x1
+read 0x10005200 0x1
+read 0x10005200 0x1
+read 0x10005200 0x1
+read 0x10005200 0x1
+read 0x10005200 0x1
+read 0x10005200 0x1
+read 0x10005200 0x1
+read 0x10005200 0x1
+read 0x10005200 0x1
+read 0x10005200 0x1
+read 0x10005200 0x1
+read 0x10005200 0x1
+read 0x10005200 0x1
+read 0x10005200 0x1
+write 0x10005204 0x1 0x15
+write 0x10005201 0x1 0x70
+write 0x10005202 0x1 0x50
+read 0x10005203 0x1
+read 0x10005203 0x1
+EOF
+```
+Additional information:
+```
+=20435==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x5645f46c0ac0). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 3601248722
+INFO: Loaded 1 modules   (601321 inline 8-bit counters): 601321 [0x5645f75ae000, 0x5645f7640ce9), 
+INFO: Loaded 1 PC tables (601321 PCs): 601321 [0x5645f6c801e0,0x5645f75ad070), 
+/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+Matching objects by name , *tc6393xb*
+This process will fuzz the following MemoryRegions:
+  * tc6393xb.vram[0] (size 100000)
+  * tc6393xb[0] (size 10000)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * tc6393xb.vram, EVENT_TYPE_MMIO_READ, 0x10100000 +0x100000, 1,4
+  * tc6393xb.vram, EVENT_TYPE_MMIO_WRITE, 0x10100000 +0x100000, 1,4
+  * tc6393xb, EVENT_TYPE_MMIO_READ, 0x10000000 +0x10000, 1,1
+  * tc6393xb, EVENT_TYPE_MMIO_WRITE, 0x10000000 +0x10000, 1,1
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 280Mb
+Running: poc-qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb-crash-55c2b01921c18ce020fa35319af4632834e116be.minimized
+=================================================================
+==20435==ERROR: AddressSanitizer: negative-size-param: (size=-1)
+    #0 0x5645effd2656 in __asan_memcpy /root/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3
+    #1 0x5645f040b342 in nand_blk_load_512 /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:794:9
+    #2 0x5645f03f1f64 in nand_getio /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:601:9
+    #3 0x5645f08acc9a in tc6393xb_nand_readb /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:359:20
+    #4 0x5645f08a53fc in tc6393xb_readb /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:500:21
+    #5 0x5645f36b308b in memory_region_read_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:440:11
+    #6 0x5645f3673391 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18
+    #7 0x5645f367075c in memory_region_dispatch_read1 /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1424:16
+    #8 0x5645f366fe98 in memory_region_dispatch_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1457:9
+    #9 0x5645f36ec09d in flatview_read_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2892:23
+    #10 0x5645f36ed6a8 in flatview_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2934:12
+    #11 0x5645f36ed168 in address_space_read_full /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2947:18
+    #12 0x5645f000e7ea in address_space_read /root/videzzo/videzzo_qemu/qemu/include/exec/memory.h:2869:18
+    #13 0x5645f000e7ea in qemu_readb /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1017:5
+    #14 0x5645f000d97e in dispatch_mmio_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1041:35
+    #15 0x5645f46bc47f in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5
+    #16 0x5645f46b37fb in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9
+    #17 0x5645f46b36d0 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9
+    #18 0x5645f00240fc in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1504:12
+    #19 0x5645f46c0d62 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18
+    #20 0x5645eff05816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17
+    #21 0x5645efee8444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #22 0x5645efef33ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19
+    #23 0x5645efedf9d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #24 0x7fbc03b97082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #25 0x5645efedfa2d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb+0x300ea2d)
+
+0x7fbbf45ffa11 is located 529 bytes inside of 69206016-byte region [0x7fbbf45ff800,0x7fbbf87ff800)
+allocated by thread T0 here:
+    #0 0x5645effd36cf in malloc /root/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
+    #1 0x7fbc04e4ee98 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e98)
+    #2 0x5645f3a1bdcb in device_set_realized /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/qdev.c:553:13
+    #3 0x5645f3a53a6b in property_set_bool /root/videzzo/videzzo_qemu/qemu/build-san-6/../qom/object.c:2273:5
+    #4 0x5645f3a4c99d in object_property_set /root/videzzo/videzzo_qemu/qemu/build-san-6/../qom/object.c:1408:5
+    #5 0x5645f3a60329 in object_property_set_qobject /root/videzzo/videzzo_qemu/qemu/build-san-6/../qom/qom-qobject.c:28:10
+    #6 0x5645f3a4d6fd in object_property_set_bool /root/videzzo/videzzo_qemu/qemu/build-san-6/../qom/object.c:1477:15
+    #7 0x5645f3a0d5c2 in qdev_realize /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/qdev.c:333:12
+    #8 0x5645f03f3f30 in nand_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:646:5
+    #9 0x5645f08a44c2 in tc6393xb_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:558:16
+    #10 0x5645f27b7822 in tosa_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/arm/tosa.c:250:12
+    #11 0x5645f05dc5d7 in machine_run_board_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/machine.c:1400:5
+    #12 0x5645f2269aab in qemu_init_board /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:2485:5
+    #13 0x5645f22697bc in qmp_x_exit_preconfig /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:2581:5
+    #14 0x5645f2270d3f in qemu_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:3584:9
+    #15 0x5645f00223f3 in LLVMFuzzerInitialize /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1761:5
+    #16 0x5645efeeffab in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:664:29
+    #17 0x5645efedf9d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #18 0x7fbc03b97082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+
+SUMMARY: AddressSanitizer: negative-size-param /root/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 in __asan_memcpy
+==20435==ABORTING
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1446 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1446
new file mode 100644
index 00000000..10797d6d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1446
@@ -0,0 +1,175 @@
+Heap buffer overflow in nand_blk_write_512()
+Description of problem:
+I captured the negative-size-param (memcpy) in nand_blk_load_512() like below.
+
+```
+diff --git a/hw/block/nand.c b/hw/block/nand.c
+index 8bc80e351..f68b23d05 100644
+--- a/hw/block/nand.c
++++ b/hw/block/nand.c
+@@ -790,6 +790,10 @@ static void glue(nand_blk_load_, NAND_PAGE_SIZE)(NANDFlashState *s,
+             s->ioaddr = s->io + (PAGE_START(addr) & 0x1ff) + offset;
+         }
+     } else {
++        int size = NAND_PAGE_SIZE + OOB_SIZE - offset;
++        if (size < 0) {
++            return;
++        }
+         memcpy(s->io, s->storage + PAGE_START(s->addr) +
+                         offset, NAND_PAGE_SIZE + OOB_SIZE - offset);
+         s->ioaddr = s->io;
+
+```
+
+Then, I triggered an integer overflow in nand_blk_write_512() resulting in a
+heap buffer overflow. Specifically, s->iolen is a signed integer[1], but based
+on the function signature of mem_and(), s->iolen will be casted to an unsigned
+integer[2]. Asan then captures a heap buffer overflow[3].
+
+```
+static void glue(nand_blk_write_, NAND_PAGE_SIZE)(NANDFlashState *s)
+{
+    // ...
+    if (!s->blk) {
+        mem_and(s->storage + PAGE_START(s->addr) + (s->addr & PAGE_MASK) +
+                        s->offset, s->io, s->iolen); // <--------------- [1]
+    } else if (s->mem_oob) {
+    // ...
+
+static void mem_and(uint8_t *dest, const uint8_t *src, size_t n) // <--- [2]
+{
+    int i;
+    for (i = 0; i < n; i++) {
+        dest[i] &= src[i]; // <----------------------------------------- [3]
+    }
+}
+```
+Steps to reproduce:
+Please patch your hw/block/nand.c first.
+
+```
+export QEMU=/path/to/qemu-system-arm
+
+cat << EOF | $QEMU \
+-machine tosa -monitor none -serial none \
+-display none -qtest stdio
+write 0x10000111 0x1 0xca
+write 0x10000104 0x1 0x47
+write 0x1000ca04 0x1 0xd7
+write 0x1000ca01 0x1 0xe0
+write 0x1000ca04 0x1 0x71
+write 0x1000ca00 0x1 0x50
+write 0x1000ca04 0x1 0xd7
+read 0x1000ca02 0x1
+write 0x1000ca01 0x1 0x10
+EOF
+```
+Additional information:
+```
+==15750==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x560e65814d70). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 4218744906
+INFO: Loaded 1 modules   (601336 inline 8-bit counters): 601336 [0x560e68702000, 0x560e68794cf8), 
+INFO: Loaded 1 PC tables (601336 PCs): 601336 [0x560e67dd42a0,0x560e68701220), 
+/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+Matching objects by name , *tc6393xb*
+This process will fuzz the following MemoryRegions:
+  * tc6393xb.vram[0] (size 100000)
+  * tc6393xb[0] (size 10000)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * tc6393xb.vram, EVENT_TYPE_MMIO_READ, 0x10100000 +0x100000, 1,4
+  * tc6393xb.vram, EVENT_TYPE_MMIO_WRITE, 0x10100000 +0x100000, 1,4
+  * tc6393xb, EVENT_TYPE_MMIO_READ, 0x10000000 +0x10000, 1,1
+  * tc6393xb, EVENT_TYPE_MMIO_WRITE, 0x10000000 +0x10000, 1,1
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 281Mb
+Running: /root/videzzo/videzzo_qemu/out-san/poc-qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb-crash-35f3f537422c4e74ce65177b3d6369045e60b47f.minimized
+=================================================================
+==15750==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61f000000de0 at pc 0x560e61557210 bp 0x7ffcfc4a59f0 sp 0x7ffcfc4a59e8
+READ of size 1 at 0x61f000000de0 thread T0
+    #0 0x560e6155720f in mem_and /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:101:20
+    #1 0x560e6155ac9c in nand_blk_write_512 /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:663:9
+    #2 0x560e61544200 in nand_command /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:293:13
+    #3 0x560e6153cc83 in nand_setio /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:520:13
+    #4 0x560e61a0a69e in tc6393xb_nand_writeb /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:380:13
+    #5 0x560e619f9bf7 in tc6393xb_writeb /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:524:9
+    #6 0x560e647c7d03 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5
+    #7 0x560e647c7641 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18
+    #8 0x560e647c5f66 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16
+    #9 0x560e6485409e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23
+    #10 0x560e648421eb in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12
+    #11 0x560e64841ca8 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18
+    #12 0x560e61170162 in qemu_writeb /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1080:5
+    #13 0x560e6116eef7 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1227:28
+    #14 0x560e6581072f in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5
+    #15 0x560e65807aab in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9
+    #16 0x560e65807980 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9
+    #17 0x560e611780fc in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1504:12
+    #18 0x560e65815012 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18
+    #19 0x560e61059816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17
+    #20 0x560e6103c444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #21 0x560e610473ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19
+    #22 0x560e610339d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #23 0x7f79587d0082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #24 0x560e61033a2d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb+0x300fa2d)
+
+0x61f000000de0 is located 0 bytes to the right of 3424-byte region [0x61f000000080,0x61f000000de0)
+allocated by thread T0 here:
+    #0 0x560e611276cf in malloc /root/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
+    #1 0x7f7959a87e98 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e98)
+    #2 0x560e64b98871 in object_new /root/videzzo/videzzo_qemu/qemu/build-san-6/../qom/object.c:749:12
+    #3 0x560e64b5d1a1 in qdev_new /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/qdev.c:153:19
+    #4 0x560e61547ea5 in nand_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:639:11
+    #5 0x560e619f8772 in tc6393xb_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:558:16
+    #6 0x560e6390bad2 in tosa_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/arm/tosa.c:250:12
+    #7 0x560e61730887 in machine_run_board_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/machine.c:1400:5
+    #8 0x560e633bdd5b in qemu_init_board /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:2485:5
+    #9 0x560e633bda6c in qmp_x_exit_preconfig /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:2581:5
+    #10 0x560e633c4fef in qemu_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:3584:9
+    #11 0x560e611763f3 in LLVMFuzzerInitialize /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1761:5
+    #12 0x560e61043fab in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:664:29
+    #13 0x560e610339d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #14 0x7f79587d0082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+
+SUMMARY: AddressSanitizer: heap-buffer-overflow /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:101:20 in mem_and
+Shadow bytes around the buggy address:
+  0x0c3e7fff8160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c3e7fff8170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c3e7fff8180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c3e7fff8190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c3e7fff81a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+=>0x0c3e7fff81b0: 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa
+  0x0c3e7fff81c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c3e7fff81d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c3e7fff81e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c3e7fff81f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c3e7fff8200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+Shadow byte legend (one shadow byte represents 8 application bytes):
+  Addressable:           00
+  Partially addressable: 01 02 03 04 05 06 07 
+  Heap left redzone:       fa
+  Freed heap region:       fd
+  Stack left redzone:      f1
+  Stack mid redzone:       f2
+  Stack right redzone:     f3
+  Stack after return:      f5
+  Stack use after scope:   f8
+  Global redzone:          f9
+  Global init order:       f6
+  Poisoned by user:        f7
+  Container overflow:      fc
+  Array cookie:            ac
+  Intra object redzone:    bb
+  ASan internal:           fe
+  Left alloca redzone:     ca
+  Right alloca redzone:    cb
+  Shadow gap:              cc
+==15750==ABORTING
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+0x1,0xb,0x12,0x1,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0xca,0x4f,0x4d,0x5f,0x0,0x0,0x0,0x0,0x1,0xb,0x4,0x1,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x47,0xf0,0xc8,0x58,0x0,0x0,0x0,0x0,0x1,0xb,0x4,0xa1,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0xd7,0x38,0xfc,0x29,0x0,0x0,0x0,0x0,0x1,0xb,0x1,0x9a,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0xe0,0xb0,0x63,0x62,0x0,0x0,0x0,0x0,0x1,0xb,0x4,0x8a,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x71,0xaa,0x20,0x60,0x0,0x0,0x0,0x0,0x1,0xb,0x0,0x5,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x50,0x9f,0x0,0x40,0x0,0x0,0x0,0x0,0x1,0xb,0x4,0xa1,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0xd7,0x38,0xfc,0x29,0x0,0x0,0x0,0x0,0x0,0xa,0x2,0x24,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x1,0xb,0x1,0xc5,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x10,0x8b,0x36,0x70,0x0,0x0,0x0,0x0,
+\x01\x0b\x12\x01\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\xcaOM_\x00\x00\x00\x00\x01\x0b\x04\x01\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00G\xf0\xc8X\x00\x00\x00\x00\x01\x0b\x04\xa1\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\xd78\xfc)\x00\x00\x00\x00\x01\x0b\x01\x9a\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\xe0\xb0cb\x00\x00\x00\x00\x01\x0b\x04\x8a\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00q\xaa `\x00\x00\x00\x00\x01\x0b\x00\x05\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00P\x9f\x00@\x00\x00\x00\x00\x01\x0b\x04\xa1\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\xd78\xfc)\x00\x00\x00\x00\x00\x0a\x02$\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\x01\x0b\x01\xc5\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\x10\x8b6p\x00\x00\x00\x00
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/145 b/gitlab/issues_text/target_missing/host_missing/accel_missing/145
new file mode 100644
index 00000000..64f67892
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/145
@@ -0,0 +1 @@
+Issues with qemu-img, libgfapi, and encryption at rest
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1450 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1450
new file mode 100644
index 00000000..da42fe2c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1450
@@ -0,0 +1 @@
+ERROR: meson setup failed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1451 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1451
new file mode 100644
index 00000000..fad83005
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1451
@@ -0,0 +1 @@
+Assertion failure: virtio_net_get_subqueue(nc)->async_tx.elem failed.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1455 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1455
new file mode 100644
index 00000000..c32a78bc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1455
@@ -0,0 +1,3 @@
+copy-paste not working
+Description of problem:
+copy-paste not working under Sway (wayland - wlroots) when I use `-display gtk`. This was broken recently. I have `spice-vdagent` as well as `spice-vdagentd` running properly in the guest, still copy-paste not working.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1457 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1457
new file mode 100644
index 00000000..ac0548f1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1457
@@ -0,0 +1 @@
+ide: assertion `bmdma->bus->retry_unit != (uint8_t)-1' failed.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1458 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1458
new file mode 100644
index 00000000..7a8b493c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1458
@@ -0,0 +1,27 @@
+ns16550a reg-shift incorrect for qemu-system-riscv64
+Description of problem:
+Missing reg-shift 0 on the ns16550n in qemu-system-riscv64 creates an impossible assumption case.
+Steps to reproduce:
+1. qemu-system-riscv64 -M virt,dumpdtb=dtb
+2. dtc dtb | less
+
+                serial@10000000 {
+                        interrupts = <0x0a>;
+                        interrupt-parent = <0x03>;
+                        clock-frequency = "\08@";
+                        reg = <0x00 0x10000000 0x00 0x100>;
+                        compatible = "ns16550a";
+                };
+
+Generally, ns16550a has a default reg-shift of 0 on x86,x86_64 for compatibility reasons.  All other architectures have an assumed reg-shift of 2 (or having the reg-shift assumption overridden by fdt providing a reg-shift property)
+
+Beyond the above, anything non-standard is assumed to be specified by the "reg-shift" property fdt.
+
+qemu-system-riscv64 seems to "assume" a reg-shift of 0.  Other riscv64 devices don't supply "reg-shift" (SiFive Unmatched) and "assume" 2.
+The above means driver writers don't actually know what to "assume" on riscv64 ns16550a when no reg-shift is present.
+
+
+Essentially, qemu-system-riscv64 needs to do one of the following:
+
+* If serial ns16550a with a uart reg-shift of 0 is intentional, qemu needs to advertise the deviance via "reg-shift 0"
+* If serial ns16550a with a uart reg-shift of 0 is unintentional, it needs updated to 2 so drivers can assume 2 on riscv64.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1459 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1459
new file mode 100644
index 00000000..3f5312c0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1459
@@ -0,0 +1,35 @@
+analyze-migration.py doesn't account for saved blocks
+Description of problem:
+
+Steps to reproduce:
+1. Make a migration snapshot that includes incremental block device (from HMP: `migrate -i "exec: cat > snap"`)
+2. Load the snapshot: `scripts/analyze-migration.py -f snap` 
+
+
+```
+Traceback (most recent call last):
+  File "scripts/analyze-migration.py", line 605, in <module>
+    dump.read(dump_memory = args.memory)
+  File "scripts/analyze-migration.py", line 539, in read
+    classdesc = self.section_classes[section_key]
+KeyError: ('block', 0)
+```
+Additional information:
+Here's pseudocode derived from `block_load` in `migration/block.c`:
+
+```
+N blocks of the following:
+
+  read 64 bits: sector number and flags
+    (blk->sector << BDRV_SECTOR_BITS) | flags
+
+  if flags & BLK_MIG_FLAG_EOS:
+    break
+  if flags & BLK_MIG_FLAG_PROGRESS
+    continue
+  if flags & BLK_MIG_FLAG_DEVICE_BLOCK
+    byte: name length
+    length bytes: device name string
+    if not flags & BLK_MIG_FLAG_ZERO_BLOCK:
+      read (1 << 20) bytes 
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/146 b/gitlab/issues_text/target_missing/host_missing/accel_missing/146
new file mode 100644
index 00000000..052c97f5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/146
@@ -0,0 +1 @@
+macOS Guest Reading USB 3.0 Bus as USB 2.0
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1460 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1460
new file mode 100644
index 00000000..fe07e0d5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1460
@@ -0,0 +1,5 @@
+block_load fails if last block is included in snapshot and block device isn't multiple of BLK_MIG_BLOCK_SIZE
+Description of problem:
+The `block_load` function in `migration/block.c` has a bug where `blk_pwrite` or `blk_pwrite_zeroes` always write `cluster_size` bytes. If the underlying device is not a multiple of `BLK_MIG_BLOCK_SIZE`, the write will fail with -EIO when trying to write past the end of the device, as `blk_check_byte_request` checks the length of the device.
+
+This can be fixed by ensuring that `cur_addr` + write length passed to `blk_pwrite`/`blk_pwrite_zeroes` never exceeds the total length of the block device.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1461 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1461
new file mode 100644
index 00000000..46117847
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1461
@@ -0,0 +1 @@
+Virgl on Upstream windows builds?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1463 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1463
new file mode 100644
index 00000000..89f7ce3b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1463
@@ -0,0 +1,41 @@
+VM with ivshmem and host pci device does not boot
+Description of problem:
+The boot aborts early if ivshmem and host-pci devices are used at the same time.
+Steps to reproduce:
+1. use a recent host kernel => 6.1.8
+2. use qemu from bullseye-backports (7.2)
+3. use a recent edk2 bios with 4M secure boot + SMM
+4. add ivshmem with e.g.: -chardev socket,path=/tmp/shared_mem,id=shared_mem -device ivshmem-doorbell,chardev=shared_mem,vectors=1
+5. add a host-pci device to the VM
+6. try to boot he VM
+Additional information:
+Observations:
+always add ivshmem with: -chardev socket,path=/tmp/shared_mem,id=shared_mem -device ivshmem-doorbell,chardev=shared_mem,vectors=1
+- a) no   host-pci device + edk2 with secure boot    => works
+- b) with host-pci device + non edk2                 => works
+- c) with host-pci device + edk2 with secure boot    => does not work
+- d) with host-pci device + edk2 with secure boot + but without ivshmem => works
+
+
+I have compiled a debug version of qemu und added some prints to the linux kernel.
+
+Qemu log shows:
+```
+2023-01-25T23:30:47.128716Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument
+2023-01-25T23:30:47.128741Z qemu-system-x86_64: vfio_dma_map(0x55cee4bf7b20, 0x385000000000, 0x2000000, 0x7fd7253ff000) = -2 (No such file or directory)
+qemu: hardware error: vfio: DMA mapping failed, unable to continue
+```
+
+Kernel log prints in vfio_iommu_iova_dma_valid@drivers/vfio/vfio_iommu_type1.c - if (start >= node->start && end <= node->end):
+```
+[ 1156.241294] DEBUG valid 1048576 >= 0 && 2147483647 <= 4276092927
+[ 1156.269472] DEBUG valid 1048576 >= 0 && 2130706431 <= 4276092927
+[ 1156.477577] DEBUG valid 3221225472 >= 0 && 3229614079 <= 4276092927
+[ 1156.478889] DEBUG valid 3254779904 >= 0 && 3254845439 <= 4276092927
+[ 1156.481226] DEBUG valid 3254779904 >= 0 && 3255042047 <= 4276092927
+[ 1156.482864] DEBUG valid 3221225472 >= 0 && 3229614079 <= 4276092927
+[ 1156.502867] DEBUG valid 61916248539136 >= 0 && 61916282093567 <= 4276092927
+[ 1156.502870] DEBUG valid 61916248539136 >= 4277141504 && 61916282093567 <= 549755813887
+```
+
+The vfio_dma_map ioctl request from qemu to the kernel seems to fail because 0x385000000000 from qemu is not in any iova range known by the kernel.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1464 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1464
new file mode 100644
index 00000000..c2dafd10
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1464
@@ -0,0 +1,3 @@
+qemu-img resize fails due to inconsistent bitmap(s)
+Additional information:
+This is on a oVirt env
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1465 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1465
new file mode 100644
index 00000000..02ee7049
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1465
@@ -0,0 +1 @@
+MBR/Partition table corruption/loss , probably related to virtual sata disks and backup
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1466 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1466
new file mode 100644
index 00000000..3d15787e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1466
@@ -0,0 +1,7 @@
+GTK: mouse position incorrect in HiDPI environment
+Description of problem:
+With `usb-tablet` mode the guest cursor position should be consistent with the host cursor since QEMU can position the mouse absolutely.
+The guest position is off from the host cursor position, it seems the position is not being divided by the scaling factor before it is passed on to the guest.
+Steps to reproduce:
+1. Run any guest with a graphical interface (e.g. Fedora Workstation or Windows 10)
+2. Notice how the guest mouse is not consistent with the host mouse at all
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1467 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1467
new file mode 100644
index 00000000..7481f23f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1467
@@ -0,0 +1 @@
+guest agent file filtering
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1468 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1468
new file mode 100644
index 00000000..342b9d95
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1468
@@ -0,0 +1,6 @@
+qemu hangs on white windows when connecting to virtual port using -serial option when using Windows OS
+Description of problem:
+I was trying to connect windbg with a qemu vm. 
+First I try using named pipes but all the tutorials I found online result in the qemu windows not even showing. So I give up and trying to use virtual COMs to connect the qemu machine with  windbg over serial port. So I created using professional Virtual come driver a link between COM2 and COM4. Now I run qemu with  -serial COM2 and I do not run windbg than it run correctly and no problem is present. As soon as I run windbg qemu hangs at startup just after the main window is created. The qemu window remains white and windows shows the normal "The application is not responding". It's like the program is in a infinite loop situation. 
+Also I noted that If I run qemu and not windbg as soon as the other COM port is connected qemu would stop working and remain frozed. Again showing the "The application is not responding".
+If instead of qemu I use other "commercial" software with the same setup (of course there I could use named pipes anyway) I can connect windbg with the machine and do the debug session.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1469 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1469
new file mode 100644
index 00000000..f7f2b885
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1469
@@ -0,0 +1,48 @@
+QEMU 7.2.0 - make install fail
+Description of problem:
+`[10055/10057] Generating docs/QEMU manual with a custom command
+[10056/10057] Generating docs/QEMU man pages with a custom command
+[10056/10057] Installing files.
+Traceback (most recent call last):
+  File "/home/clive/.local/bin/meson", line 5, in <module>
+    from mesonbuild.mesonmain import main
+ModuleNotFoundError: No module named 'mesonbuild'
+FAILED: meson-internal__install 
+/home/clive/.local/bin/meson install --no-rebuild
+ninja: build stopped: subcommand failed.
+make: *** [Makefile:165: run-ninja] Error 1
+[clive@localhost build]$ 
+`
+Steps to reproduce:
+1. as user in shell
+2. `wget https://download.qemu.org/qemu-7.2.0.tar.xz`
+2. `tar xvJf qemu-7.2.0.tar.xz`
+3. `cd qemu-7.2.0`
+4. `./configure`
+5. `make install`
+Additional information:
+installed meson via `pip3 --user`
+
+`pip3 --list` **Output** `meson version 1.0.0`
+
+**Using** - python version 3.11.1
+
+`ninja-build` installed via package manager `dnf` 
+
+**Using** - ninja-build version 1.8.2
+
+Used `dnf builddep` on `ninja-build`, `meson`, and `qemu-kvm` before and after installation confirming I have dependencies.
+
+ File "/home/clive/.local/bin/meson" contains
+```
+#!/usr/local/bin/python3.11
+# -*- coding: utf-8 -*-
+import re
+import sys
+from mesonbuild.mesonmain import main
+if __name__ == '__main__':
+    sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])
+    sys.exit(main())
+
+
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/147 b/gitlab/issues_text/target_missing/host_missing/accel_missing/147
new file mode 100644
index 00000000..74677b79
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/147
@@ -0,0 +1 @@
+Interacting with NetBSD serial console boot blocks no longer works
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1470 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1470
new file mode 100644
index 00000000..675b1dac
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1470
@@ -0,0 +1,9 @@
+Mouse cursor disappeared for WfW 3.11
+Description of problem:
+I've been using the "GD5434 v1.25f, 1280x1024x64K Smlfnt" driver (from sp2904.exe, https://archive.org/download/Windows-3.1-WING-doom inside cirrus.zip) with Fedora's qemu build for years, which is the best version of that driver that I could find, and which works quite nicely apart from a font problem right after startup, and is a lot faster than the standard (patched) SVGA driver. Opening and closing File Manager will get rid of the font corruption. After an upgrade to Fedora 37, I noticed that the mouse cursor was not displayed anymore, which I bisected to this git commit: cb8962c146
+Steps to reproduce:
+1. Run the image (boots right into Windows)
+2. Note the missing cursor
+3.
+Additional information:
+Image for easy testing (IBM DOS 5, 1024x768) is here: https://drive.google.com/file/d/1_5-gGXEahPOPvgG436WbKM9dnOr7Z8zo/view?usp=sharing (4.4 MB)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1474 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1474
new file mode 100644
index 00000000..8949d1e4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1474
@@ -0,0 +1,8 @@
+qemu stuck at creating vm when enabling sgx feature
+Description of problem:
+After execute the command line, qemu stucked.
+
+![image](/uploads/f6e8fad068fd9d9af510dea68986a5e6/image.png)
+
+
+After the info in the png, qemu clear the screen and then nothing happend.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1475 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1475
new file mode 100644
index 00000000..9e5b4268
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1475
@@ -0,0 +1,14 @@
+qemu-img: GLib: g_hash_table_foreach_remove: assertion 'hash_table != NULL' failed
+Description of problem:
+Mixing driver=https with an http URL gives this assert fail in glib2:
+
+```
+$ ~/d/qemu/build/qemu-img convert -p -W -f qcow2 'json:{ "file.readahead": 67108864, "file.driver": "https", "file.url": "http://web/tmp/jammy-server-cloudimg-amd64.qcow2", "file.timeout":2000 }' -O raw jammy-server-cloudimg-amd64.img.raw 
+qemu-img: GLib: g_hash_table_foreach_remove: assertion 'hash_table != NULL' failed
+qemu-img: GLib: g_hash_table_destroy: assertion 'hash_table != NULL' failed
+qemu-img: Could not open 'json:{ "file.readahead": 67108864, "file.driver": "https", "file.url": "http://web/tmp/jammy-server-cloudimg-amd64.qcow2", "file.timeout":2000 }': https curl driver cannot handle the URL 'http://oirase.annexia.org/tmp/jammy-server-cloudimg-amd64.qcow2' (does not start with 'https://')
+```
+
+(It seems to be a warning rather than a crash)
+Steps to reproduce:
+1. Run the command above.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1477 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1477
new file mode 100644
index 00000000..e5c65e3a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1477
@@ -0,0 +1,291 @@
+hot-plugged interface are not working after live migration
+Description of problem:
+After a live migration are perform for a vm then hot-plug interface pci didn't show up, but did found a SCSI storage controller is created. I checked libvirt did send qmp command to qemu `[pid 320011] 1673945683.378537 write(42, "{"execute":"device_add","arguments":{"driver":"virtio-net-pci","netdev":"hostua-test","id":"ua-test","mac":"00:e0:4c:6a:3b:51","bus":"pci.7","addr":"0x0"},"id":"libvirt-200"}rn", 176) = 176
+`
+Steps to reproduce:
+1. Perform a live migration by issue command `virsh migrate --live --persistent --verbose --unsafe --p2p demo-vm qemu+tls://node8/system?pkipath=/etc/pki/libvirt/private/`
+2. Then on the destination node that vm moved, create a bridge deivce `ip link add br-test1 type bridge`
+3. Create a tap.xml file with following code
+   ```
+   <interface type='bridge'>
+     <mac address='00:e0:4c:6a:3b:51'/>
+     <source bridge='br-test1'/>
+     <model type="virtio"/>
+     <alias name='ua-test'/>
+   </interface>
+   ```
+4. Save origin pci information
+```
+$ virsh console demo-vm
+# Save origin pci information 
+[root@demo-vm ~]# lshw > before
+```
+5. Hot-plug an interface `virsh attach-device demo-vm tap.xml-backup --live --config`
+6. Dumpxml of demo-vm
+```
+<domain type='kvm' id='226'>
+  <name>demo-vm</name>
+  <uuid>cc74b867-3fb4-5e4f-bbce-33df21a89416</uuid>
+  <metadata>
+    <kubevirt xmlns="http://kubevirt.io">
+      <uid>79db3d82-ce8f-44e8-96a5-940cc37c0064</uid>
+      <graceperiod>
+        <deletionGracePeriodSeconds>30</deletionGracePeriodSeconds>
+      </graceperiod>
+    </kubevirt>
+  </metadata>
+  <maxMemory slots='16' unit='KiB'>134217728</maxMemory>
+  <memory unit='KiB'>1048576</memory>
+  <currentMemory unit='KiB'>1048576</currentMemory>
+  <vcpu placement='static' current='1'>128</vcpu>
+  <iothreads>1</iothreads>
+  <resource>
+    <partition>/machine</partition>
+  </resource>
+  <sysinfo type='smbios'>
+    <system>
+      <entry name='uuid'>cc74b867-3fb4-5e4f-bbce-33df21a89416</entry>
+    </system>
+  </sysinfo>
+  <os>
+    <type arch='x86_64' machine='pc-q35-rhel8.6.0'>hvm</type>
+    <smbios mode='sysinfo'/>
+  </os>
+  <features>
+    <acpi/>
+  </features>
+  <cpu mode='custom' match='exact' check='full'>
+    <model fallback='forbid'>Skylake-Server-IBRS</model>
+    <vendor>Intel</vendor>
+    <topology sockets='128' dies='1' cores='1' threads='1'/>
+    <feature policy='require' name='ss'/>
+    <feature policy='require' name='vmx'/>
+    <feature policy='require' name='pdcm'/>
+    <feature policy='require' name='hypervisor'/>
+    <feature policy='require' name='tsc_adjust'/>
+    <feature policy='require' name='clflushopt'/>
+    <feature policy='require' name='umip'/>
+    <feature policy='require' name='pku'/>
+    <feature policy='require' name='md-clear'/>
+    <feature policy='require' name='stibp'/>
+    <feature policy='require' name='arch-capabilities'/>
+    <feature policy='require' name='ssbd'/>
+    <feature policy='require' name='xsaves'/>
+    <feature policy='require' name='ibpb'/>
+    <feature policy='require' name='ibrs'/>
+    <feature policy='require' name='amd-stibp'/>
+    <feature policy='require' name='amd-ssbd'/>
+    <feature policy='require' name='skip-l1dfl-vmentry'/>
+    <feature policy='require' name='pschange-mc-no'/>
+    <feature policy='disable' name='mpx'/>
+    <numa>
+      <cell id='0' cpus='0-127' memory='1048576' unit='KiB'/>
+    </numa>
+  </cpu>
+  <clock offset='utc'/>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>destroy</on_crash>
+  <devices>
+    <emulator>/usr/libexec/qemu-kvm</emulator>
+    <disk type='network' device='disk' model='virtio-non-transitional'>
+      <driver name='qemu' type='raw' error_policy='stop' discard='unmap'/>
+      <auth username='rbd-provisioner'>
+        <secret type='ceph' uuid='8fedf300-282c-4531-a66d-ca2691aaa88b'/>
+      </auth>
+      <source protocol='rbd' name='demo-pool/vol-5e83bed9-a2a3-11ed-bee4-3cfdfee07278' index='2'>
+        <host name='xx.xx.xx.xx' port='6789'/>
+        <host name='xx.xx.xx.xx' port='6789'/>
+        <host name='xx.xx.xx.xx' port='6789'/>
+      </source>
+      <target dev='vda' bus='virtio'/>
+      <boot order='1'/>
+      <alias name='ua-bootdisk'/>
+      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
+    </disk>
+    <disk type='file' device='disk' model='virtio-non-transitional'>
+      <driver name='qemu' type='raw' cache='writethrough' error_policy='stop' discard='unmap'/>
+      <source file='/var/run/kubevirt-ephemeral-disks/cloud-init-data/demo-vm/configdrive.iso' index='1'/>
+      <backingStore/>
+      <target dev='vdb' bus='virtio'/>
+      <alias name='ua-cloudinitdisk'/>
+      <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
+    </disk>
+    <controller type='usb' index='0' model='none'>
+      <alias name='usb'/>
+    </controller>
+    <controller type='scsi' index='0' model='virtio-non-transitional'>
+      <alias name='scsi0'/>
+      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
+    </controller>
+    <controller type='virtio-serial' index='0' model='virtio-non-transitional'>
+      <alias name='virtio-serial0'/>
+      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
+    </controller>
+    <controller type='pci' index='0' model='pcie-root'>
+      <alias name='pcie.0'/>
+    </controller>
+    <controller type='pci' index='1' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='1' port='0x10'/>
+      <alias name='pci.1'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
+    </controller>
+    <controller type='pci' index='2' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='2' port='0x11'/>
+      <alias name='pci.2'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
+    </controller>
+    <controller type='pci' index='3' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='3' port='0x12'/>
+      <alias name='pci.3'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
+    </controller>
+    <controller type='pci' index='4' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='4' port='0x13'/>
+      <alias name='pci.4'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
+    </controller>
+    <controller type='pci' index='5' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='5' port='0x14'/>
+      <alias name='pci.5'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
+    </controller>
+    <controller type='pci' index='6' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='6' port='0x15'/>
+      <alias name='pci.6'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
+    </controller>
+    <controller type='pci' index='7' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='7' port='0x16'/>
+      <alias name='pci.7'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/>
+    </controller>
+    <controller type='pci' index='8' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='8' port='0x18'/>
+      <alias name='pci.8'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/>
+    </controller>
+    <controller type='pci' index='9' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='9' port='0x19'/>
+      <alias name='pci.9'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/>
+    </controller>
+    <controller type='pci' index='10' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='10' port='0x1a'/>
+      <alias name='pci.10'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x2'/>
+    </controller>
+    <controller type='pci' index='11' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='11' port='0x1b'/>
+      <alias name='pci.11'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x3'/>
+    </controller>
+    <controller type='pci' index='12' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='12' port='0x1c'/>
+      <alias name='pci.12'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x4'/>
+    </controller>
+    <controller type='sata' index='0'>
+      <alias name='ide'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
+    </controller>
+    <interface type='ethernet'>
+      <mac address='00:00:00:6a:d3:bc'/>
+      <target dev='e6250550b78a43a' managed='yes'/>
+      <model type='virtio'/>
+      <mtu size='1500'/>
+      <alias name='ua-attachnet1'/>
+      <rom enabled='no'/>
+      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
+    </interface>
+    <interface type='bridge'>
+      <mac address='00:e0:4c:6a:3b:51'/>
+      <source bridge='br-test1'/>
+      <target dev='vnet5'/>
+      <model type='virtio'/>
+      <alias name='ua-test'/>
+      <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/>
+    </interface>
+    <serial type='pty'>
+      <source path='/dev/pts/31'/>
+      <log file='/var/log/vm/79db3d82-ce8f-44e8-96a5-940cc37c0064/console.log' append='off'/>
+      <target type='isa-serial' port='0'>
+        <model name='isa-serial'/>
+      </target>
+      <alias name='serial0'/>
+    </serial>
+    <console type='pty' tty='/dev/pts/31'>
+      <source path='/dev/pts/31'/>
+      <log file='/var/log/vm/79db3d82-ce8f-44e8-96a5-940cc37c0064/console.log' append='off'/>
+      <target type='serial' port='0'/>
+      <alias name='serial0'/>
+    </console>
+    <channel type='unix'>
+      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-226-demo-vm/org.qemu.guest_agent.0'/>
+      <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/>
+      <alias name='channel0'/>
+      <address type='virtio-serial' controller='0' bus='0' port='1'/>
+    </channel>
+    <input type='mouse' bus='ps2'>
+      <alias name='input0'/>
+    </input>
+    <input type='keyboard' bus='ps2'>
+      <alias name='input1'/>
+    </input>
+    <graphics type='vnc' port='5920' autoport='yes' listen='0.0.0.0'>
+      <listen type='address' address='0.0.0.0'/>
+    </graphics>
+    <audio id='1' type='none'/>
+    <video>
+      <model type='vga' vram='16384' heads='1' primary='yes'/>
+      <alias name='video0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
+    </video>
+    <memballoon model='virtio-non-transitional'>
+      <alias name='balloon0'/>
+      <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
+    </memballoon>
+  </devices>
+  <seclabel type='dynamic' model='dac' relabel='yes'>
+    <label>+107:+107</label>
+    <imagelabel>+107:+107</imagelabel>
+  </seclabel>
+</domain>
+``` 
+7. Console to vm and check pci
+```
+$ virsh console demo-vm
+# no additional nic found in `ip a` list
+[root@demo-vm ~]# ip a
+# Compare pci
+[root@demo-vm ~]# lshw > after
+# instead of a virtio network pci i saw a virtio SCSI is created
+[root@demo-vm ~]# diff before after
+# output
+  *-scsi                    
+       description: SCSI storage controller
+       product: Virtio SCSI
+       vendor: Red Hat, Inc.
+       physical id: 0
+       bus info: pci@0000:02:00.0
+       version: 01
+       width: 64 bits
+       clock: 33MHz
+       capabilities: scsi msix pm pciexpress bus_master cap_list
+       configuration: driver=virtio-pci latency=0
+       resources: irq:22 memory:fe600000-fe600fff memory:fc400000-fc403fff
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1479 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1479
new file mode 100644
index 00000000..f12e11fa
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1479
@@ -0,0 +1 @@
+system/arm/cpu-features.html : text describing options is misrendered
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/148 b/gitlab/issues_text/target_missing/host_missing/accel_missing/148
new file mode 100644
index 00000000..3f19dfbd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/148
@@ -0,0 +1 @@
+Please solve graceful (ACPI) poweroff issue, using signals, most importantly SIGTERM
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1480 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1480
new file mode 100644
index 00000000..9bdcf4b5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1480
@@ -0,0 +1 @@
+-cpu <whatever>,help should print the options available for that CPU type
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1481 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1481
new file mode 100644
index 00000000..1a2e4cd3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1481
@@ -0,0 +1 @@
+How to create Rootfs for sifive_u machine
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1482 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1482
new file mode 100644
index 00000000..31b71581
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1482
@@ -0,0 +1,15 @@
+Network failed in qemu-7.2.0
+Description of problem:
+After I created and installed Ubuntu 20.04 img in qemu virtual machine from Ubuntu 20.04 iso, I found that the network could not work normally, the network settings wasn't right yet.
+Steps to reproduce:
+1. Download the source code of qemu-7.2.0 using command "wget https://download.qemu.org/qemu-7.2.0.tar.xz";
+2. Untar using command "tar Jxvf qemu-7.2.0.tar.xz";
+3. Configure with command "./configure --target-list=x86_64-softmmu" under root of qemu source code;
+4. Build with command "make";
+5. Install with command "make install" or "sudo make install";
+5. Create image with command "qemu-img create -f qcow2 Ubuntu2004.img 40G";
+5. Launch and install guest with ubuntu 20.04 iso using command "qemu-system-x86_64 -enable-kvm -m 8G -smp 4 -boot once=d -cdrom ../iso_images/Ubuntu-20.04.5-desktop-amd.iso -drive file=./Ubuntu2004.img -device ac97";
+6. After system installed, launch guest with command "qemu-system-x86_64 -enable-kvm -m 8G -smp 4 -drive file=./Ubuntu2004.img -device ac97"
+Additional information:
+1. When I used qemu version 7.1.0, that is qemu-7.1.0, and go through the same steps above, then the network worked normally, and the network setting was right.
+2. Windows images from Windows iso(s) had the same phenomenon.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1483 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1483
new file mode 100644
index 00000000..03b47749
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1483
@@ -0,0 +1 @@
+Failed to mount pmem device in qemu
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1485 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1485
new file mode 100644
index 00000000..0da0412a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1485
@@ -0,0 +1,12 @@
+hw/at24c : not support 1 byte-address with eeprom size less than 256 byte
+Description of problem:
+I created the new platform base on aspeed/fuji,
+that uses the virtual eeprom (at24c), some eeprom used 24c02, which size 256 bytes.
+but when using /hw/at24c.c, the result will not same the real device.
+Steps to reproduce:
+1. create a machine with EEPROM size less then or equal 256 bytes
+2. start the qemu
+3. use i2cget/i2cset/i2cdump to write and display eeprom data
+Additional information:
+I fixed and validated, refer
+https://gitlab.com/ssinprem/qemu/-/tree/at24c-1-byte-address-mode
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1486 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1486
new file mode 100644
index 00000000..7d85ff5f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1486
@@ -0,0 +1,89 @@
+LXD fails to create VM with QEMU 7.2.0: "../../net/net.c:1106: net_client_init1: Assertion `nc' failed."
+Description of problem:
+Beginning with QEMU 7.2.0, LXD is unable to launch virtual machines using the default network profile, which breaks the out-of-box experience if a user wishes to create a virtual machine. This worked correctly with QEMU 7.1.0.
+
+Multiple users across different Linux distributions are reporting this issue:
+- https://discuss.linuxcontainers.org/t/failed-adding-nic-netdev-monitor-is-disconnected/15946
+- https://forums.gentoo.org/viewtopic-p-8774212.html
+- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030365
+
+```
+gibmat@tharkun:~$ lxc launch images:debian/sid debian-sid-vm --vm
+Creating debian-sid-vm
+Starting debian-sid-vm                        
+Error: Failed setting up device via monitor: Failed setting up device "eth0": Failed adding NIC netdev: Monitor is disconnected
+Try `lxc info --show-log local:debian-sid-vm` for more info
+gibmat@tharkun:~$ lxc info --show-log local:debian-sid-vm
+Name: debian-sid-vm
+Status: STOPPED
+Type: virtual-machine
+Architecture: x86_64
+Created: 2023/02/10 23:47 UTC
+
+Log:
+
+warning: tap: open vhost char device failed: Permission denied
+warning: tap: open vhost char device failed: Permission denied
+qemu-system-x86_64: ../../net/net.c:1106: net_client_init1: Assertion `nc' failed.
+
+```
+
+```
+gibmat@tharkun:~$ qemu-system-x86_64 --version
+QEMU emulator version 7.2.0 (Debian 1:7.2+dfsg-2)
+Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
+gibmat@tharkun:~$ lxc version
+Client version: 5.0.2
+Server version: 5.0.2
+```
+Steps to reproduce:
+1. Install LXD and QEMU 7.2.0
+2. `lxc launch images:debian/sid debian-sid-vm --vm`
+  - This will fail as reported above
+3. Downgrade to QEMU 7.1.0 (such as from https://snapshot.debian.org/package/qemu/1%3A7.1%2Bdfsg-2/)
+4. `lxc launch images:debian/sid debian-sid-vm --vm`
+  - Now VM creation is successful
+    ```
+    gibmat@tharkun:~$ lxc launch images:debian/sid debian-sid-vm --vm
+    Creating debian-sid-vm
+    Starting debian-sid-vm
+    gibmat@tharkun:~$ lxc list
+    +---------------+---------+------+-----------------------------------------------+-----------------+-----------+
+    |     NAME      |  STATE  | IPV4 |                     IPV6                      |      TYPE       | SNAPSHOTS |
+    +---------------+---------+------+-----------------------------------------------+-----------------+-----------+
+    | debian-sid-vm | RUNNING |      | fd42:ea61:feb4:55ef:216:3eff:feb8:2e8c (eth0) | VIRTUAL-MACHINE | 0         |
+    +---------------+---------+------+-----------------------------------------------+-----------------+-----------+
+    gibmat@tharkun:~$ lxc info --show-log local:debian-sid-vm
+    Name: debian-sid-vm
+    Status: RUNNING
+    Type: virtual-machine
+    Architecture: x86_64
+    PID: 2502
+    Created: 2023/02/11 15:08 UTC
+    Last Used: 2023/02/11 15:08 UTC
+    
+    Resources:
+      Processes: -1
+      Network usage:
+        eth0:
+          Type: broadcast
+          State: UP
+          Host interface: tap5efa7582
+          MAC address: 00:16:3e:b8:2e:8c
+          MTU: 1500
+          Bytes received: 3.13kB
+          Bytes sent: 164B
+          Packets received: 12
+          Packets sent: 2
+          IP addresses:
+            inet6: fd42:ea61:feb4:55ef:216:3eff:feb8:2e8c/64 (global)
+    
+    Log:
+    
+    warning: tap: open vhost char device failed: Permission denied
+    warning: tap: open vhost char device failed: Permission denied
+    
+    gibmat@tharkun:~$ qemu-system-x86_64 --version
+    QEMU emulator version 7.1.0 (Debian 1:7.1+dfsg-2+b3)
+    Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
+    ```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1487 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1487
new file mode 100644
index 00000000..c83f01c1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1487
@@ -0,0 +1,5 @@
+Mac OS X 10.4-10.6 i386/x86_64 not working on Apple Silicon
+Description of problem:
+Mac OS X panics early in the boot process. There are no issues using later versions of macOS or the PPC architecture
+Steps to reproduce:
+1. trying to boot 10.4/10.5/10.6 using i368/x86_64 emulation on apple silicon
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1489 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1489
new file mode 100644
index 00000000..96f7d5c5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1489
@@ -0,0 +1,94 @@
+Breakpoints set at wrong addresses in `test-gdbstub.py` for some Linux kernels guest images
+Description of problem:
+The script `tests/guest-debug/test-gdbstub.py` for testing QEMU's GDB
+stub on Linux kernel guests sets breakpoints on `kernel_init()` and
+`wait_for_completion()`. As the script is coded, breakpoints are set
+(implicitly) not at the functions' start addresses, but at the end of
+the functions' prologues.
+
+For some Linux kernel builds in which `kernel_init()` and
+`wait_for_completion()` get compiled with a function prologue, the
+script fails to detect breakpoint hits in `check_hbreak()` and
+`check_break()` because it compares the stopped address (i.e. the end of
+the function's prologue) with the function's start address, and they
+differ. To observe the difference in GDB:
+
+```sh
+$ gdb -q --nx vmlinux
+Reading symbols from vmlinux...
+(gdb) b kernel_init
+Breakpoint 1 at 0xffff800008fbeb28: file init/main.c, line 1497.    # <- prologue start
+(gdb) b *kernel_init
+Breakpoint 2 at 0xffff800008fbeb18: file init/main.c, line 1491.    # <- function start
+```
+
+In my tests, the issue doesn't occur with standard Linux kernels builds
+(e.g. compiled on Linux hosts with GCC) because typically both
+`kernel_init()` and `wait_for_completion()` seem to be without
+prologues.
+Steps to reproduce:
+The issue has so far been encountered only with arm64 Linux kernel
+guests compiled on macOS arm64 with
+[mac-linux-kdk](https://github.com/GayPizzaSpecifications/mac-linux-kdk).
+
+1. Compile a recent arm64 Linux kernel on macOS arm64 with debugging
+   information (first `make defconfig`, then `make menuconfig` and set
+   `Kernel hacking / Compile-time checks and compiler options / Debug
+   information / Rely on toolchain's implicit default DWARF version`)
+
+    ```sh
+    $ file /tmp/linux-5.19/arch/arm64/boot/Image
+    /tmp/linux-5.19/arch/arm64/boot/Image: Linux kernel ARM64 boot executable Image, little-endian, 4K pages
+    $ file /tmp/linux-5.19/vmlinux
+    /tmp/linux-5.19/vmlinux: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), statically linked, BuildID[sha1]=bf9e422d48e0aded5859fe34d6de2c174ef3a20b, with debug_info, not stripped
+    ```
+
+2. Start QEMU waiting for GDB to connect:
+
+    ```sh
+    $ ./qemu-system-aarch64 -smp 1 -M virt -cpu cortex-a57 -kernel /tmp/linux-5.19/arch/arm64/boot/Image -append nokaslr -s -S
+    ```
+
+3. Execute the `test-gdbstub.py` script (as described in the script file
+   itself):
+
+    ```sh
+    $ gdb /tmp/linux-5.19/vmlinux -x tests/guest-debug/test-gdbstub.py
+    ```
+
+    The script then hangs.
+
+Tested both on a macOS host and a Linux host.
+Additional information:
+The proposed fix is to explicitly disable GDB's prologue decoder and set
+the two breakpoints at the functions' start addresses [by adding an
+asterisk before the function
+name](https://stackoverflow.com/a/31451340):
+
+```diff
+diff --git a/tests/guest-debug/test-gdbstub.py b/tests/guest-debug/test-gdbstub.py
+index 98a5df4d4..6202d17c3 100644
+--- a/tests/guest-debug/test-gdbstub.py
++++ b/tests/guest-debug/test-gdbstub.py
+@@ -31,7 +31,7 @@ def check_step():
+ def check_break(sym_name):
+     "Setup breakpoint, continue and check we stopped."
+     sym, ok = gdb.lookup_symbol(sym_name)
+-    bp = gdb.Breakpoint(sym_name)
++    bp = gdb.Breakpoint("*%s" % (sym_name))
+
+     gdb.execute("c")
+
+@@ -48,7 +48,7 @@ def check_break(sym_name):
+ def check_hbreak(sym_name):
+     "Setup hardware breakpoint, continue and check we stopped."
+     sym, ok = gdb.lookup_symbol(sym_name)
+-    gdb.execute("hbreak %s" % (sym_name))
++    gdb.execute("hbreak *%s" % (sym_name))
+     gdb.execute("c")
+
+     # hopefully we came back
+```
+
+This change shouldn't impact the Linux kernel guests for which the
+script is already working as intended.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/149 b/gitlab/issues_text/target_missing/host_missing/accel_missing/149
new file mode 100644
index 00000000..c0a441cb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/149
@@ -0,0 +1 @@
+vmxnet3 unable to send IPv6 ESP packets
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1490 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1490
new file mode 100644
index 00000000..052dfe94
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1490
@@ -0,0 +1,61 @@
+Keystrokes for F13-24 are not forwarded by an evdev input device
+Description of problem:
+Currently, keystrokes for F13-F24 are not forwarded by an evdev input device.
+Steps to reproduce:
+```
+/usr/bin/qemu-system-x86_64 \
+-name guest=win10,debug-threads=on \
+-S \
+-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-11-win10/master-key.aes"}' \
+-machine pc-q35-7.2,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram \
+-accel kvm \
+-cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff \
+-m 4096 \
+-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":4294967296}' \
+-overcommit mem-lock=off \
+-smp 4,sockets=1,dies=1,cores=4,threads=1 \
+-uuid ca2e9d01-6e02-4aa7-9feb-7846499f7d8a \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=33,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=localtime,driftfix=slew \
+-global kvm-pit.lost_tick_policy=delay \
+-no-hpet \
+-no-shutdown \
+-global ICH9-LPC.disable_s3=1 \
+-global ICH9-LPC.disable_s4=1 \
+-boot strict=on \
+-device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \
+-device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \
+-device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \
+-device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \
+-device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \
+-device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \
+-device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \
+-device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \
+-device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \
+-device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \
+-device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \
+-device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \
+-device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \
+-device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \
+-device '{"driver":"qemu-xhci","id":"usb","bus":"pci.1","addr":"0x0"}' \
+-blockdev '{"driver":"file","filename":"/tmp/win10.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \
+-device '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":2}' \
+-object '{"qom-type":"input-linux","id":"input2","evdev":"/dev/input/by-id/usb-04d9_f50e-event-mouse"}' \
+-object '{"qom-type":"input-linux","id":"input3","evdev":"/dev/input/by-id/usb-0c45_6515-event-kbd","repeat":true,"grab_all":true,"grab-toggle":"scrolllock"}' \
+-audiodev '{"id":"audio1","driver":"spice"}' \
+-spice port=5900,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on \
+-device '{"driver":"qxl-vga","id":"video0","max_outputs":1,"ram_size":67108864,"vram_size":67108864,"vram64_size_mb":0,"vgamem_mb":16,"bus":"pcie.0","addr":"0x1"}' \
+-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.2","addr":"0x0"}' \
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
+```
+
+This is probably not a minimal example, but I didn't know how to generate one. I think the only relevant lines are these:
+```
+-object '{"qom-type":"input-linux","id":"input2","evdev":"/dev/input/by-id/usb-04d9_f50e-event-mouse"}' \
+-object '{"qom-type":"input-linux","id":"input3","evdev":"/dev/input/by-id/usb-0c45_6515-event-kbd","repeat":true,"grab_all":true,"grab-toggle":"scrolllock"}'
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1495 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1495
new file mode 100644
index 00000000..1b81ad75
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1495
@@ -0,0 +1,6 @@
+MacOS fails check-unit for test-io-channel-command for some reason
+Description of problem:
+While adding the socat dependency to the CI system it triggers a failure on the ARM MacOS build, eg: https://gitlab.com/stsquad/qemu/-/jobs/3769189709
+Steps to reproduce:
+1. install socat
+2. make check-unit
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1496 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1496
new file mode 100644
index 00000000..231ebb14
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1496
@@ -0,0 +1,27 @@
+Multiple issues detected by the thread sanitizer build
+Description of problem:
+Switching the tsan build in the CI from benchmark to check-unit revealed a bunch of issues even in our most basic tests.
+Steps to reproduce:
+1. configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp
+2. make check-unit
+3. recoil in horror at the failures
+Additional information:
+From: https://gitlab.com/stsquad/qemu/-/jobs/3779216892
+
+```
+Summary of Failures:
+27/95 qemu:unit / rcutorture                  ERROR           3.83s   exit status 66
+28/95 qemu:unit / test-rcu-list               ERROR           5.28s   exit status 66
+29/95 qemu:unit / test-rcu-simpleq            ERROR           5.07s   exit status 66
+30/95 qemu:unit / test-rcu-tailq              ERROR           5.12s   exit status 66
+32/95 qemu:unit / test-rcu-slist              ERROR           5.07s   exit status 66
+40/95 qemu:unit / test-logging                ERROR           2.50s   exit status 66
+52/95 qemu:unit / test-aio-multithread        ERROR           9.53s   exit status 66
+54/95 qemu:unit / test-thread-pool            ERROR           7.22s   exit status 66
+55/95 qemu:unit / test-bdrv-drain             ERROR           2.37s   exit status 66
+58/95 qemu:unit / test-blockjob               ERROR           2.04s   exit status 66
+60/95 qemu:unit / test-block-iothread         ERROR           2.08s   exit status 66
+74/95 qemu:unit / test-io-channel-command     ERROR           0.10s   killed by signal 13 SIGPIPE
+90/95 qemu:unit / test-replication            ERROR          25.03s   exit status 66
+93/95 qemu:unit / test-util-filemonitor       ERROR           2.61s   exit status 66
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1497 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1497
new file mode 100644
index 00000000..f7acbb54
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1497
@@ -0,0 +1,3 @@
+no documentation on plugins with mem_cb in their name
+Additional information:
+I'm especially interested in how vector ops under mask report their memory traffic
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1504 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1504
new file mode 100644
index 00000000..b30110f8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1504
@@ -0,0 +1 @@
+Implement Synopsys DesignWare PCI-I2C adapter model
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1505 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1505
new file mode 100644
index 00000000..774b1686
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1505
@@ -0,0 +1 @@
+guest agent: add --allow-rpcs / whitelist mode
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1507 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1507
new file mode 100644
index 00000000..f2ff7579
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1507
@@ -0,0 +1,37 @@
+export/fuse/fuse.c:fuse_fallocate does not do anything but returns success
+Description of problem:
+block/export/fuse.c:fuse_fallocate with `FALLOC_FL_PUNCH_HOLE` does not do anything even though it returns 0 (success). A later read incorrectly returns old data instead of zeros. 
+Should probably return EOPNOTSUPP.
+
+FALLOC_FL_PUNCH_HOLE:
+>Within the specified range, partial filesystem blocks are zeroed,
+and whole filesystem blocks are removed from the file.  After a
+successful call, subsequent reads from this range will return
+zeros.
+https://man7.org/linux/man-pages/man2/fallocate.2.html
+Steps to reproduce:
+```sh
+touch /tmp/data /tmp/fuse_exp 
+dd if=/dev/random of=/tmp/data count=1000 bs=1M
+qemu-storage-daemon --blockdev node-name=node0,driver=raw,file.driver=file,file.filename=/tmp/data --export type=fuse,id=node0-export,node-name=node0,mountpoint=/tmp/fuse_exp,writable=on
+
+hexdump /tmp/fuse_exp -n 16
+# 0000000 4d5f db2d 57ab 02f6 f9c2 d2f1 0c1b 4b86
+fallocate -l 1G --punch-hole /tmp/fuse_exp
+echo $?
+# 0
+hexdump /tmp/fuse_exp -n 16
+# 0000000 4d5f db2d 57ab 02f6 f9c2 d2f1 0c1b 4b86
+
+
+hexdump /tmp/data -n 16
+# 0000000 4d5f db2d 57ab 02f6 f9c2 d2f1 0c1b 4b86
+fallocate -l 1G --punch-hole /tmp/data
+hexdump /tmp/data -n 16
+# 0000000 0000 0000 0000 0000 0000 0000 0000 0000
+
+# sudo bpftrace -e 'uretprobe:/usr/bin/qemu-storage-daemon:blk_co_pdiscard { printf("ret=%d\n",retval); }'
+# ret=0
+# sudo bpftrace -e 'kretfunc:fuse_file_fallocate { printf("len=%d \t mode=%d ret=%d\n", args->length , args->mode,retval); }'
+# len=1073741824   mode=3 ret=0
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1508 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1508
new file mode 100644
index 00000000..688369c7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1508
@@ -0,0 +1,91 @@
+vfio-pci 0000:00:02.1: VF token required to access device
+Description of problem:
+I'm trying to use SR-IOV on an i5-12400 trying to create VFs for my UHD Graphics 730.
+
+I had to build this DKMS module for it to work:
+https://github.com/strongtz/i915-sriov-dkms
+
+So far I have managed to have 7 VFs created per the dmsg:
+```
+[root@fedora ~]# dmesg | grep -i vf
+[    0.000000] Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.1.13-200.fc37.x86_64 root=UUID=a1ec5891-71c6-44ea-9beb-c4f1cde55c0e ro rootflags=subvol=root rhgb quiet intel_iommu=on iommu=pt split_lock_detect=off i915.enable_guc=7 video=vesafb:off video=efifb:off initcall_blacklist=sysfb_init vfio-pci.disable_vga=1 vfio-pci.enable_sriov=1 vfio-pci.ids=8086:4692,8086:7ad0
+[    0.074362] Kernel command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.1.13-200.fc37.x86_64 root=UUID=a1ec5891-71c6-44ea-9beb-c4f1cde55c0e ro rootflags=subvol=root rhgb quiet intel_iommu=on iommu=pt split_lock_detect=off i915.enable_guc=7 video=vesafb:off video=efifb:off initcall_blacklist=sysfb_init v
+io-pci.disable_vga=1 vfio-pci.enable_sriov=1 vfio-pci.ids=8086:4692,8086:7ad0
+[    0.288336] pci 0000:00:02.0: VF(n) BAR0 space: [mem 0x60e0000000-0x60e6ffffff 64bit] (contains BAR0 for 7 VFs)
+[    0.288339] pci 0000:00:02.0: VF(n) BAR2 space: [mem 0x6000000000-0x60dfffffff 64bit pref] (contains BAR2 for 7 VFs)
+[    0.293518] pci 0000:01:00.0: VF(n) BAR0 space: [mem 0xa1330000-0xa134ffff 64bit] (contains BAR0 for 8 VFs)
+[    0.336464] VFS: Disk quotas dquot_6.6.0
+[    0.336470] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
+[    1.028560] VFIO - User Level meta-driver version: 0.3
+[    1.039931] vfio-pci 0000:00:02.0: vgaarb: deactivate vga console
+[    1.039933] vfio-pci 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
+[    1.040007] vfio_pci: add [8086:4692[ffffffff:ffffffff]] class 0x000000/00000000
+[    1.040140] vfio_pci: add [8086:7ad0[ffffffff:ffffffff]] class 0x000000/00000000
+[    3.373977] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 655360 ms ovfl timer
+[   45.696323] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.1 driver_override
+[   45.696356] vfio-pci 0000:00:02.1: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none
+[   45.696598] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.2 driver_override
+[   45.696609] vfio-pci 0000:00:02.2: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none
+[   45.696724] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.3 driver_override
+[   45.696734] vfio-pci 0000:00:02.3: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none
+[   45.696811] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.4 driver_override
+[   45.696825] vfio-pci 0000:00:02.4: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none
+[   45.696947] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.5 driver_override
+[   45.696958] vfio-pci 0000:00:02.5: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none
+[   45.697050] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.6 driver_override
+[   45.697060] vfio-pci 0000:00:02.6: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none
+[   45.697127] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.7 driver_override
+[   45.697137] vfio-pci 0000:00:02.7: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none
+```
+I've blacklisted these modules:
+```
+blacklist igb
+blacklist i915
+blacklist snd_hda_intel
+blacklist snd_sof_pci_intel_tgl
+```
+And loaded these modules:
+```
+vfio
+vfio-pci
+vfio_virqfd
+vfio_iommu_type1
+```
+Kernel args:
+```
+GRUB_CMDLINE_LINUX="rhgb quiet intel_iommu=on iommu=pt split_lock_detect=off i915.enable_guc=7 video=vesafb:off video=efifb:off initcall_blacklist=sysfb_init vfio-pci.disable_vga=1 vfio-pci.enable_sriov=1 vfio-pci.ids=8086:4692,8086:7ad0"
+```
+
+**Error shown:**
+```
+[root@fedora ~]# ./test.sh
+QEMU 7.0.0 monitor - type 'help' for more information
+(qemu) qemu-system-x86_64: -device vfio-pci,host=0000:02.2,multifunction=on,bus=pcie.1,addr=0x00,x-vga=on: vfio 0000:00:02.2: error getting device from group 14: Permission denied
+Verify all devices in group 14 are bound to vfio-<bus> or pci-stub and not already in use
+```
+**DMESG shows:**
+```
+[ 2160.408395] vfio-pci 0000:00:02.2: VF token required to access device
+```
+
+This lead me to this conversation / thread:
+
+https://inbox.dpdk.org/dev/CALBAE1MrEoCc8Ch6MNUNTsOcZyJnhr+z+iD0VWjHagQsEdBWCw@mail.gmail.com/#t
+
+Quote: "Something needs to be sorted with the QEMU community."
+
+In fact, something needs to be sorted. **It seems there's no way to specify this VF token anywhere from the CLI args**, so I'm reporting this as a bug (or feature not developed yet?? any ETA?)
+
+**Additional information:** It seems that QEMU might require a patch or a change to allow this VF token to be passed through. It seems that DPDK and other similar projects have already implemented this (it seems Linux has it since Kernel 5.7 - Maybe I'm missing something to pass this token with QEMU considering how old that kernel is? I'd expect this flag to be here in QEMU already)
+
+**Useful code / info:**
+* https://patches.dpdk.org/project/dpdk/patch/20200529013710.72302-3-haiyue.wang@intel.com/
+* https://github.com/intel/pf-bb-config/blob/master/README.md#usage-example
+* https://support.hpe.com/hpesc/public/docDisplay?docId=sd00001790en_us&docLocale=en_US&page=GUID-1D5D76F8-522A-47F5-922B-142BD5177033.html
+
+Thanks,
+
+-Alemar
+Steps to reproduce:
+1. See description
+2. Run QEMU as described
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/151 b/gitlab/issues_text/target_missing/host_missing/accel_missing/151
new file mode 100644
index 00000000..55700434
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/151
@@ -0,0 +1 @@
+virtio-net ignores the absence of the VIRTIO_NET_F_CTRL_VQ feature bit
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1510 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1510
new file mode 100644
index 00000000..f8ec3938
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1510
@@ -0,0 +1,92 @@
+LibFuzzer: Deadly Signals
+Description of problem:
+```
+INFO: libFuzzer ignores flags that start with '--'
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 1075449567
+INFO: Loaded 1 modules   (323687 inline 8-bit counters): 323687 [0x558e9ece6000, 0x558e9ed35067), 
+INFO: Loaded 1 PC tables (323687 PCs): 323687 [0x558e9e7f5680,0x558e9ece5cf0), 
+./qemu-fuzz-i386: Running 1 inputs 1 time(s) each.
+Running: crash-11075f8b34e355e114f92367a5e8b9bbb36a352d
+Matching objects by name *usb*
+Matching objects by name *ohci*
+This process will try to fuzz the following MemoryRegions:
+  * bus master container[0] (size 0xffffffffffffffff)
+  * ohci[0] (size 0x100)
+  * bus master[0] (size 0xffffffffffffffff)
+qemu-fuzz-i386: ../hw/usb/core.c:744: struct USBEndpoint *usb_ep_get(USBDevice *, int, int): Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed.
+==1763255== ERROR: libFuzzer: deadly signal
+    #0 0x558e9ad46cb1 in __sanitizer_print_stack_trace (/home/hyper/qemu/build/qemu-fuzz-i386+0x1f71cb1) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+    #1 0x558e9acb9548 in fuzzer::PrintStackTrace() (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ee4548) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+    #2 0x558e9ac9efc3 in fuzzer::Fuzzer::CrashCallback() (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ec9fc3) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+    #3 0x7faa5444251f  (/lib/x86_64-linux-gnu/libc.so.6+0x4251f) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
+    #4 0x7faa54496a7b in __pthread_kill_implementation nptl/./nptl/pthread_kill.c:43:17
+    #5 0x7faa54496a7b in __pthread_kill_internal nptl/./nptl/pthread_kill.c:78:10
+    #6 0x7faa54496a7b in pthread_kill nptl/./nptl/pthread_kill.c:89:10
+    #7 0x7faa54442475 in gsignal signal/../sysdeps/posix/raise.c:26:13
+    #8 0x7faa544287f2 in abort stdlib/./stdlib/abort.c:79:7
+    #9 0x7faa5442871a in __assert_fail_base assert/./assert/assert.c:92:3
+    #10 0x7faa54439e95 in __assert_fail assert/./assert/assert.c:101:3
+    #11 0x558e9b6c89d9 in usb_ep_get /home/hyper/qemu/build/../hw/usb/core.c:744:5
+    #12 0x558e9b701fa4 in ohci_service_td /home/hyper/qemu/build/../hw/usb/hcd-ohci.c:957:14
+    #13 0x558e9b701fa4 in ohci_service_ed_list /home/hyper/qemu/build/../hw/usb/hcd-ohci.c:1122:21
+    #14 0x558e9b6fa47b in ohci_frame_boundary /home/hyper/qemu/build/../hw/usb/hcd-ohci.c:1192:9
+    #15 0x558e9cbe8b9c in timerlist_run_timers /home/hyper/qemu/build/../util/qemu-timer.c:576:9
+    #16 0x558e9c2a9c7d in qtest_clock_warp /home/hyper/qemu/build/../softmmu/qtest.c:358:9
+    #17 0x558e9c2a6411 in qtest_process_command /home/hyper/qemu/build/../softmmu/qtest.c:751:9
+    #18 0x558e9c2a1f98 in qtest_process_inbuf /home/hyper/qemu/build/../softmmu/qtest.c:802:9
+    #19 0x558e9c2a1db3 in qtest_server_inproc_recv /home/hyper/qemu/build/../softmmu/qtest.c:933:9
+    #20 0x558e9c932980 in qtest_sendf /home/hyper/qemu/build/../tests/qtest/libqtest.c:600:5
+    #21 0x558e9c932a84 in qtest_clock_step_next /home/hyper/qemu/build/../tests/qtest/libqtest.c:955:5
+    #22 0x558e9ad86fed in generic_fuzz /home/hyper/qemu/build/../tests/qtest/fuzz/generic_fuzz.c:715:17
+    #23 0x558e9ad7aae3 in LLVMFuzzerTestOneInput /home/hyper/qemu/build/../tests/qtest/fuzz/fuzz.c:152:5
+    #24 0x558e9aca0553 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ecb553) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+    #25 0x558e9ac8a2cf in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/hyper/qemu/build/qemu-fuzz-i386+0x1eb52cf) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+    #26 0x558e9ac90026 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ebb026) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+    #27 0x558e9acb9e42 in main (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ee4e42) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+    #28 0x7faa54429d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
+    #29 0x7faa54429e3f in __libc_start_main csu/../csu/libc-start.c:392:3
+    #30 0x558e9ac84b94 in _start (/home/hyper/qemu/build/qemu-fuzz-i386+0x1eafb94) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+
+NOTE: libFuzzer has rudimentary signal handlers.
+      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
+SUMMARY: libFuzzer: deadly signal
+qemu-fuzz-i386: ../hw/usb/core.c:744: struct USBEndpoint *usb_ep_get(USBDevice *, int, int): Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed.
+==1763258== ERROR: libFuzzer: deadly signal
+    #0 0x558e9ad46cb1 in __sanitizer_print_stack_trace (/home/hyper/qemu/build/qemu-fuzz-i386+0x1f71cb1) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+    #1 0x558e9acb9548 in fuzzer::PrintStackTrace() (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ee4548) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+    #2 0x558e9ac9efc3 in fuzzer::Fuzzer::CrashCallback() (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ec9fc3) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+    #3 0x7faa5444251f  (/lib/x86_64-linux-gnu/libc.so.6+0x4251f) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
+    #4 0x7faa54496a7b in __pthread_kill_implementation nptl/./nptl/pthread_kill.c:43:17
+    #5 0x7faa54496a7b in __pthread_kill_internal nptl/./nptl/pthread_kill.c:78:10
+    #6 0x7faa54496a7b in pthread_kill nptl/./nptl/pthread_kill.c:89:10
+    #7 0x7faa54442475 in gsignal signal/../sysdeps/posix/raise.c:26:13
+    #8 0x7faa544287f2 in abort stdlib/./stdlib/abort.c:79:7
+    #9 0x7faa5442871a in __assert_fail_base assert/./assert/assert.c:92:3
+    #10 0x7faa54439e95 in __assert_fail assert/./assert/assert.c:101:3
+    #11 0x558e9b6c89d9 in usb_ep_get /home/hyper/qemu/build/../hw/usb/core.c:744:5
+    #12 0x558e9b701fa4 in ohci_service_td /home/hyper/qemu/build/../hw/usb/hcd-ohci.c:957:14
+    #13 0x558e9b701fa4 in ohci_service_ed_list /home/hyper/qemu/build/../hw/usb/hcd-ohci.c:1122:21
+    #14 0x558e9b6fa47b in ohci_frame_boundary /home/hyper/qemu/build/../hw/usb/hcd-ohci.c:1192:9
+    #15 0x558e9cbe8b9c in timerlist_run_timers /home/hyper/qemu/build/../util/qemu-timer.c:576:9
+    #16 0x558e9c2a9c7d in qtest_clock_warp /home/hyper/qemu/build/../softmmu/qtest.c:358:9
+    #17 0x558e9c2a6411 in qtest_process_command /home/hyper/qemu/build/../softmmu/qtest.c:751:9
+    #18 0x558e9c2a1f98 in qtest_process_inbuf /home/hyper/qemu/build/../softmmu/qtest.c:802:9
+    #19 0x558e9c2a1db3 in qtest_server_inproc_recv /home/hyper/qemu/build/../softmmu/qtest.c:933:9
+    #20 0x558e9c932980 in qtest_sendf /home/hyper/qemu/build/../tests/qtest/libqtest.c:600:5
+    #21 0x558e9c932a84 in qtest_clock_step_next /home/hyper/qemu/build/../tests/qtest/libqtest.c:955:5
+    #22 0x558e9ad86fed in generic_fuzz /home/hyper/qemu/build/../tests/qtest/fuzz/generic_fuzz.c:715:17
+    #23 0x558e9ad7aae3 in LLVMFuzzerTestOneInput /home/hyper/qemu/build/../tests/qtest/fuzz/fuzz.c:152:5
+    #24 0x558e9aca0553 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ecb553) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+    #25 0x558e9aca1175 in fuzzer::Fuzzer::TryDetectingAMemoryLeak(unsigned char const*, unsigned long, bool) (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ecc175) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+    #26 0x558e9ac8a317 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/hyper/qemu/build/qemu-fuzz-i386+0x1eb5317) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+    #27 0x558e9ac90026 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ebb026) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+    #28 0x558e9acb9e42 in main (/home/hyper/qemu/build/qemu-fuzz-i386+0x1ee4e42) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+    #29 0x7faa54429d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
+    #30 0x7faa54429e3f in __libc_start_main csu/../csu/libc-start.c:392:3
+    #31 0x558e9ac84b94 in _start (/home/hyper/qemu/build/qemu-fuzz-i386+0x1eafb94) (BuildId: 49539853a6c034db6a511d608192f681fdffa439)
+```
+Steps to reproduce:
+1. ./qemu-fuzz-i386 --fuzz-target=generic-fuzz-ohci
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1511 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1511
new file mode 100644
index 00000000..9b97d6b6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1511
@@ -0,0 +1 @@
+Please a CPU model for ABI version for x86_64 i386 according to   x86-64 psABI
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1512 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1512
new file mode 100644
index 00000000..4778bb04
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1512
@@ -0,0 +1 @@
+AVX/AVX2 not correcly detected in user mode
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1513 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1513
new file mode 100644
index 00000000..961fa124
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1513
@@ -0,0 +1 @@
+CPU flags should be better documented
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1515 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1515
new file mode 100644
index 00000000..e973926e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1515
@@ -0,0 +1,18 @@
+qemu have  the way to change the windows sid?
+Description of problem:
+I want to change the guest of windows sid after clone guest, have  the way to change it before new guest start? "virt-sysprep" Seems impossible to do it. Although it can be done manually as follow:
+
+[change sid in windows system](https://www.heelpbook.net/2019/microsoft-changing-sid-of-cloned-vms/)
+
+query windows sid:
+cmd: whoami /user
+
+
+step:
+1.clone a new windows guest vm_new
+
+2.change the sid of vm_new  (step2 I don't know how to do that)
+
+3.start vm_new
+
+4.query the vm_new's sid is change
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1516 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1516
new file mode 100644
index 00000000..4e5213df
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1516
@@ -0,0 +1,39 @@
+QEMU does not reload kernel image on guest reboot (direct kernel boot)
+Description of problem:
+I am using virtiofs as root filesystem with QEMU direct kernel boot. The kernel is loaded from the guests directory structure that is exported from the host.
+
+The problem is that QEMU does not reload the kernel image file from disk during a guest reboot. This means it is not possible to update the kernel from inside the guest and do a simple reboot to load it. A full power cycle of the guest is required to load the updated kernel image.
+Steps to reproduce:
+1. Migrate a Linux guest to virtiofs as root fs. 
+2. Enable QEMU direct kernel boot and point to guest's kernel in the exported root filesystem. 
+3. Boot. 
+4. Update the kernel inside the guest. Overwrite the existing kernel image
+5. Issue `reboot` inside the guest. 
+6. When the guest reboots, the old kernel is still booted, even though the image file was overwritten. 
+7. Issue `poweroff` inside the guest. 
+8. Issue `virsh start <guest-vm>`
+9. Now the new kernel image is booted.
+Additional information:
+XML:
+```
+<type arch='x86_64' machine='pc-q35-7.0'>hvm</type>
+    <kernel>/media/vm/libvirt/images/alpine-q/root/boot/vmlinuz-virt</kernel>
+    <initrd>/media/vm/libvirt/images/alpine-q/root/boot/initramfs-virt</initrd>
+    <cmdline>rootfstype=virtiofs root=root rw</cmdline>
+    <boot dev='hd'/>
+    <bootmenu enable='no'/>
+  </os>
+
+...
+
+    <filesystem type='mount' accessmode='passthrough'>
+      <driver type='virtiofs'/>
+      <binary path='/usr/libexec/virtiofsd' xattr='on'>
+        <cache mode='always'/>
+        <lock posix='on' flock='on'/>
+      </binary>
+      <source dir='/media/vm/libvirt/images/alpine-q/root'/>
+      <target dir='root'/>
+      <address type='pci' domain='0x0000' bus='0x09' slot='0x00' function='0x0'/>
+    </filesystem>
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1518 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1518
new file mode 100644
index 00000000..bf9df59b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1518
@@ -0,0 +1,90 @@
+qemu tests/unit/test-vmstate crashes in g_tree_foreach
+Description of problem:
+qemu test suite crashes with the latest Fedora Rawhide.
+Downstream issue: https://bugzilla.redhat.com/show_bug.cgi?id=2173639
+Steps to reproduce:
+1. Compile and test qemu from source as normal.
+
+```
+214/658 qemu:unit / test-vmstate                                                  ERROR           0.22s   killed by signal 11 SIGSEGV
+317/658 qemu:qtest+qtest-i386 / qtest-i386/rtl8139-test                           ERROR           0.28s   2 subtests passed
+588/658 qemu:qtest+qtest-x86_64 / qtest-x86_64/rtl8139-test                       ERROR           0.45s   2 subtests passed
+```
+
+The stack trace from the test is:
+
+```
+#0  g_tree_foreach (user_data=0x7fffa23ccbc0, func=0x55a834fe3770 <diff_tree>, 
+    tree=<optimized out>) at ../glib/gtree.c:1132
+#1  g_tree_foreach (tree=<optimized out>, func=0x55a834fe3770 <diff_tree>, 
+    user_data=0x7fffa23ccbc0) at ../glib/gtree.c:1117
+#2  0x000055a834fe382c in compare_trees (tree1=0x55a836723bf0, 
+    tree2=0x55a836723f50, 
+    function=function@entry=0x55a834fe3570 <match_interval_mapping_node>)
+    at ../tests/unit/test-vmstate.c:1085
+#3  0x000055a834fee265 in diff_domain (d2=0x55a836709310, d1=0x55a836708fd0)
+    at ../tests/unit/test-vmstate.c:1093
+#4  test_gtree_load_domain () at ../tests/unit/test-vmstate.c:1138
+#5  0x00007f0eef39d32e in test_case_run (tc=0x55a836724150)
+    at ../glib/gtestutils.c:3108
+#6  g_test_run_suite_internal (suite=suite@entry=0x55a8367056e0, 
+    path=path@entry=0x0) at ../glib/gtestutils.c:3203
+#7  0x00007f0eef39cf03 in g_test_run_suite_internal (
+    suite=suite@entry=0x55a836705090, path=path@entry=0x0)
+    at ../glib/gtestutils.c:3222
+#8  0x00007f0eef39cf03 in g_test_run_suite_internal (
+    suite=suite@entry=0x55a8366ff670, path=path@entry=0x0)
+    at ../glib/gtestutils.c:3222
+#9  0x00007f0eef39cf03 in g_test_run_suite_internal (
+    suite=suite@entry=0x55a836700140, path=path@entry=0x0)
+#10 0x00007f0eef39d8c2 in g_test_run_suite (suite=0x55a836700140)
+    at ../glib/gtestutils.c:3302
+#11 0x00007f0eef397c40 in g_test_run () at ../glib/gtestutils.c:2409
+#12 g_test_run () at ../glib/gtestutils.c:2396
+#13 0x000055a834fe2645 in main (argc=<optimized out>, argv=<optimized out>)
+    at ../tests/unit/test-vmstate.c:1523
+```
+
+This can also be reproduced in gdb using a command similar to:
+
+```
+$ MALLOC_PERTURB_=175 G_TEST_SRCDIR=/home/rjones/d/qemu/tests/unit G_TEST_BUILDDIR=/home/rjones/d/qemu/build/tests/unit gdb --args /home/rjones/d/qemu/build/tests/unit/test-vmstate --tap -k
+...
+(gdb) run
+Thread 1 "test-vmstate" received signal SIGSEGV, Segmentation fault.
+g_tree_foreach (user_data=0x7fffffffd3e0, func=0x555555568770 <diff_tree>, tree=<optimized out>) at ../glib/gtree.c:1132
+1132	      if ((*func) (node->key, node->value, user_data))
+(gdb) bt
+#0  g_tree_foreach (user_data=0x7fffffffd3e0, func=0x555555568770 <diff_tree>, 
+    tree=<optimized out>) at ../glib/gtree.c:1132
+#1  g_tree_foreach (tree=<optimized out>, func=0x555555568770 <diff_tree>, 
+    user_data=0x7fffffffd3e0) at ../glib/gtree.c:1117
+#2  0x000055555556882c in compare_trees (tree1=0x5555555ccdb0, 
+    tree2=0x5555555cd110, 
+    function=function@entry=0x555555568570 <match_interval_mapping_node>)
+    at ../tests/unit/test-vmstate.c:1085
+#3  0x0000555555573265 in diff_domain (d2=0x5555555b3310, d1=0x5555555b2fd0)
+    at ../tests/unit/test-vmstate.c:1093
+#4  test_gtree_load_domain () at ../tests/unit/test-vmstate.c:1138
+#5  0x00007ffff7eb132e in test_case_run (tc=0x5555555cd310)
+    at ../glib/gtestutils.c:3108
+#6  g_test_run_suite_internal (suite=suite@entry=0x5555555af6e0, 
+    path=path@entry=0x0) at ../glib/gtestutils.c:3203
+#7  0x00007ffff7eb0f03 in g_test_run_suite_internal (
+    suite=suite@entry=0x5555555af090, path=path@entry=0x0)
+    at ../glib/gtestutils.c:3222
+#8  0x00007ffff7eb0f03 in g_test_run_suite_internal (
+    suite=suite@entry=0x5555555a9670, path=path@entry=0x0)
+    at ../glib/gtestutils.c:3222
+#9  0x00007ffff7eb0f03 in g_test_run_suite_internal (
+    suite=suite@entry=0x5555555aa140, path=path@entry=0x0)
+    at ../glib/gtestutils.c:3222
+#10 0x00007ffff7eb18c2 in g_test_run_suite (suite=0x5555555aa140)
+    at ../glib/gtestutils.c:3302
+#11 0x00007ffff7eabc40 in g_test_run () at ../glib/gtestutils.c:2409
+#12 g_test_run () at ../glib/gtestutils.c:2396
+#13 0x0000555555567645 in main (argc=<optimized out>, argv=<optimized out>)
+    at ../tests/unit/test-vmstate.c:1523
+```
+
+Unfortunately so much is "optimized out" that it's hard to tell what's going wrong.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1519 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1519
new file mode 100644
index 00000000..a3990753
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1519
@@ -0,0 +1,12 @@
+audio recording not working on qemu
+Description of problem:
+QEMU fails to record audio from the guest even when the device options hda-duplex and hda-micro options are used. Tried using the other available audio backends (alsa and sdl) but recording on the guest still fails
+Steps to reproduce:
+1. run the qemu command line above with any of the available audio backends
+2. record audio on the guest 
+3. arecord -vv -d 5 recordng.wav
+4. there's an attempt to record but it hangs
+5. play recorded audio, there's no output
+6. aplay recordng.wav
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/152 b/gitlab/issues_text/target_missing/host_missing/accel_missing/152
new file mode 100644
index 00000000..1ef0bcb0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/152
@@ -0,0 +1 @@
+qemu-img compare -m option is missing
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1520 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1520
new file mode 100644
index 00000000..78abbaa6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1520
@@ -0,0 +1,49 @@
+x86 TCG acceleration running on s390x with -smp > host cpus slowed down by x10
+Description of problem:
+This boots up a trivial guest using OVMF, when the conditions below are given it runs ~10x slower.
+
+I have found this breaking our tests of qemu 7.2 [(which due to Debian adding the offending change as backport is affected)](https://salsa.debian.org/qemu-team/qemu/-/blob/master/debian/patches/master/acpi-cpuhp-fix-guest-visible-maximum-access-size-to-.patch) by runnig an order of magnitude slower.
+
+
+I was tracing it down (insert a long strange trip here) and found that it occurs:
+- only with patch dab30fb "acpi: cpuhp: fix guest-visible maximum access size to the legacy reg block" applied
+  - latest master is still affetced
+- only with s390x running emulation of x86
+  - emulating x86 on ppc64 didn't show the same behavior
+- only with -smp > host cpus
+  - smp 2 with 1 host cpu => slow
+  - smp 4 with 2 host cpu => slow
+  - any case where host cpu >= smp => fast
+
+On average good cases are on a 2964 s390x machine taking ~5-6 seconds for the good case.
+The bad case is close to 60s which is the timeout of the automated tests.
+
+We all know -smp shouldn't be >host-cpus, and I totally admit that this is the definition of an edge case.
+But I do not know what else might be affected and this just happened to be what the test does by default - and a slowdown by x10 seems too much even for edge cases to be just ignored.
+And while we could just bump up the timeout (and probably will as an interim workaround) I wanted to file it here for your awareness.
+Steps to reproduce:
+You can recreate the same by using the commandline above and timing things on your own.
+
+Or you can use the [autopkgtest of edk2 in Ubuntu](https://git.launchpad.net/ubuntu/+source/edk2/tree/debian/tests/shell.py#n214) which have [shown this](https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/s390x/e/edk2/20230224_094012_c95f4@/log.gz) first.
+Additional information:
+Only signed OVMF cases are affected, while aavmf and other OVMF are more or less on the same speed.
+
+```
+1 CPU / 1GB Memory
+7.0     7.2
+6.54s   58.32s test_ovmf_ms
+6.72s   56.96s test_ovmf_4m_ms
+7.54s   55.47s test_ovmf_4m_secboot
+7.56s   49.88s test_ovmf_secboot
+7.01s   39.79s test_ovmf32_4m_secboot
+7.38s    7.43s  test_aavmf32
+7.27s    7.30s  test_aavmf
+7.26s    7.26s  test_aavmf_snakeoil
+5.83s    5.95s  test_ovmf_4m
+5.61s    5.81s  test_ovmf_q35
+5.51s    5.64s  test_ovmf_pc
+5.26s    5.42s  test_ovmf_snakeoil
+```
+
+Highlighting @cborntra since it is somewhat s390x related and @mjt0k as the patch is applied as backport in Debian.
+I didn't find the handle of Laszlo (Author) to highlight him as well.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1521 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1521
new file mode 100644
index 00000000..cd5e6ccb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1521
@@ -0,0 +1 @@
+USB HID not using the keycodemapdb and thus lacking new entries
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1522 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1522
new file mode 100644
index 00000000..1f5bfa89
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1522
@@ -0,0 +1,40 @@
+Floppy controller returns the wrong thing for multitrack reads which span tracks
+Description of problem:
+I've just discovered that the Minix 1 and 2 operating systems no longer boot on qemu.
+
+Investigation reveals the following:
+
+- when Minix reads a 1024-byte block from disk, it issues a two-sector multitrack read to the FDC.
+- if the FDC runs out of sectors when it's on head 0, it automatically switches to head 1 (this is correct).
+- if the FDC runs out of sectors when it's on head 1, it stops the transfer (which is what is supposed to happen).
+
+What qemu does for the latter case is that it will automatically seek to the next track and switch to head 0. It then sets the SEEK COMPLETE bit in the status register. Minix sees this but isn't expecting it, because this shouldn't be emitted for reads and writes, and fails thinking it's an error.
+
+For example, here's the logging for such a transfer:
+
+```
+FLOPPY: Start transfer at 0 1 4f 11 (2878)
+FLOPPY: direction=1 (1024 - 10240)
+FLOPPY: copy 512 bytes (1024 0 10240) 0 pos 1 4f (17-0x00000b3e 0x00167c00)
+FLOPPY: seek to next sector (1 4f 11 => 2878)     <--- reads the last sector of head 1 track 0x4f
+FLOPPY: copy 512 bytes (1024 512 10240) 0 pos 1 4f (18-0x00000b3f 0x00167e00)
+FLOPPY: seek to next sector (1 4f 12 => 2879)     <--- attempt to move to the next sector, which fails
+FLOPPY: seek to next track (0 50 01 => 2879)      <--- moved to next track, which shouldn't happen
+FLOPPY: end transfer 1024 1024 10240
+FLOPPY: transfer status: 00 00 00 (20)            <--- status report
+```
+
+Transfer status 20 is the SEEK COMPLETE bit. For a normal head switch, that should be 04 (with the NOW ON HEAD 1 bit set).
+
+For reference, see page 5-13 of the uPD765 datasheet here: https://www.cpcwiki.eu/imgs/f/f3/UPD765_Datasheet_OCRed.pdf It says:
+
+> IF MT is high, a multitrack operation is performed.
+> If MT = 1 after finishing read/write operation on side 0,
+> FDC will automatically start command searching for sector
+> 1 on side 1
+Steps to reproduce:
+1. `qemu-system-i386 --fda images/minix-2.0-root-720kB.img`
+2. Press = to boot.
+3. Observe the 'Unrecoverable Read` errors as the ramdisk is loaded. (The system will still boot, but will then crash if you try to do anything due to a corrupt ramdisk.)
+
+[minix-2.0-root-720kB.img.bz2](/uploads/77d34db96f353d92cdb2d01928b8fc01/minix-2.0-root-720kB.img.bz2)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1526 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1526
new file mode 100644
index 00000000..d89fa5a7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1526
@@ -0,0 +1 @@
+hw/vfio/trace-events incorrect format
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1527 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1527
new file mode 100644
index 00000000..81d85c82
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1527
@@ -0,0 +1,3 @@
+-blockdev option missing host_device documenation and command line help support
+Additional information:
+We recommend -blockdev in the documentation as the preferred way to configure storage backends but the online help isn't useful. We also seem to be missing information for some of the blockdev drivers, for example host_device.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1529 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1529
new file mode 100644
index 00000000..a6582996
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1529
@@ -0,0 +1 @@
+Documentation refers to Windows Hypervisor Platform as wphx instead of whpx
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/153 b/gitlab/issues_text/target_missing/host_missing/accel_missing/153
new file mode 100644
index 00000000..7c008537
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/153
@@ -0,0 +1 @@
+SLIRP SMB silently fails with MacOS smbd
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1530 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1530
new file mode 100644
index 00000000..8a03a3ef
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1530
@@ -0,0 +1,11 @@
+Problem with sdl,gl=on windows 10
+Description of problem:
+sdl window opens with black screen, freezes, then crashes
+Steps to reproduce:
+1. run the command
+Additional information:
+- Works fine with just `sdl`, running `gtk,gl=on` outputs `opengl is not supported by the display`
+- tried with both `-vga virtio` and `vga std`, same result
+- tried with SVM turned on and off (AMD cpu, ryzen 2600x), same result
+- built the project `./configure --enable-gtk --enable-sdl --enable-opengl, saw the `OK` for all 3
+- have opengl ver 4.6
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1532 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1532
new file mode 100644
index 00000000..f31f98f6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1532
@@ -0,0 +1,503 @@
+libivrtd fork qemu to create vm ,which start with ceph rbd device, after vm status:runing , the qemu stuck at booting from hard disk....
+Description of problem:
+[root@ceph-client ceph]# virsh list --all
+ Id    Name                           State
+----------------------------------------------------
+ 19    c7_ceph                        running
+
+the vm qemu stuck at booting from hard disk.....
+Steps to reproduce:
+1. use ceph-deploy deploy a ceph distribute storage, which use to store vm's qcow2 files,this ceph has 3 osd node 
+2. refer the link https://docs.ceph.com/en/quincy/rbd/libvirt/  create a ceph user :client.libvirt 
+3. import a exists qcow2 file into ceph libvit-pool, then start vm
+
+[root@ceph-1 ~]# ceph -s
+  cluster:
+    id:     3fbbf51f-88fd-4883-9f24-595bf853c5f2
+    health: HEALTH_OK
+ 
+  services:
+    mon: 1 daemons, quorum ceph-1
+    mgr: ceph-1(active)
+    osd: 3 osds: 3 up, 3 in
+ 
+  data:
+    pools:   1 pools, 128 pgs
+    objects: 940  objects, 3.6 GiB
+    usage:   31 GiB used, 209 GiB / 240 GiB avail
+    pgs:     128 active+clean
+
+[root@ceph-1 ~]#ceph auth ls  
+client.libvirt
+	key: AQD/XwFkq7kHMhAA1OmPtKPVno6gjmZleOevOA==
+	caps: [mon] allow r
+	caps: [osd] allow class-read object_prefix rbd_children, allow rwx pool=libvirt-pool
+
+[root@ceph-client ceph]# cat ceph.conf 
+[global]
+fsid = 3fbbf51f-88fd-4883-9f24-595bf853c5f2
+mon_initial_members = ceph-1
+mon_host = 172.24.193.62
+auth_cluster_required = cephx
+auth_service_required = cephx
+auth_client_required = cephx
+
+osd_pool_default_size = 2
+[root@ceph-client ceph]# 
+
+[root@ceph-client ceph]# virsh start c7_ceph
+Domain c7_ceph started
+
+[root@ceph-client ceph]# 
+[root@ceph-client ceph]# virsh list --all
+ Id    Name                           State
+----------------------------------------------------
+ 19    c7_ceph                        running
+
+
+    <emulator>/usr/local/qemu-3.0/bin/qemu-system-x86_64</emulator>
+    <disk type='network' device='disk'>
+      <driver name='qemu' type='raw' cache='writeback'/>
+      <auth username='libvirt'>
+        <secret type='ceph' uuid='fb57a2a3-8cdf-44cb-afc1-2d8bdc0fc5d0'/>
+      </auth>
+      <source protocol='rbd' name='libvirt-pool/root-vsys_c5.qcow2'>
+        <host name='172.24.193.62' port='6789'/>
+        <host name='172.24.193.63' port='6789'/>
+        <host name='172.24.193.64' port='6789'/>
+      </source>
+      <target dev='vda' bus='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
+    </disk>
+
+========================
+[root@ceph-client ceph]# cat /run/libvirt/qemu/c7_ceph.xml 
+
+
+<domstatus state='running' reason='booted' pid='57437'>
+  <monitor path='/var/lib/libvirt/qemu/domain-19-c7_ceph/monitor.sock' json='1' type='unix'/>
+  <namespaces>
+    <mount/>
+  </namespaces>
+  <vcpus>
+    <vcpu id='0' pid='57487'/>
+    <vcpu id='1' pid='57488'/>
+  </vcpus>
+  <qemuCaps>
+    <flag name='kvm'/>
+    <flag name='no-hpet'/>
+    <flag name='spice'/>
+    <flag name='boot-index'/>
+    <flag name='hda-duplex'/>
+    <flag name='ccid-emulated'/>
+    <flag name='ccid-passthru'/>
+    <flag name='virtio-tx-alg'/>
+    <flag name='virtio-blk-pci.ioeventfd'/>
+    <flag name='sga'/>
+    <flag name='virtio-blk-pci.event_idx'/>
+    <flag name='virtio-net-pci.event_idx'/>
+    <flag name='piix3-usb-uhci'/>
+    <flag name='piix4-usb-uhci'/>
+    <flag name='usb-ehci'/>
+    <flag name='ich9-usb-ehci1'/>
+    <flag name='vt82c686b-usb-uhci'/>
+    <flag name='pci-ohci'/>
+    <flag name='usb-redir'/>
+    <flag name='usb-hub'/>
+    <flag name='ich9-ahci'/>
+    <flag name='no-acpi'/>
+    <flag name='virtio-blk-pci.scsi'/>
+    <flag name='scsi-disk.channel'/>
+    <flag name='scsi-block'/>
+    <flag name='transaction'/>
+    <flag name='block-job-async'/>
+    <flag name='scsi-cd'/>
+    <flag name='ide-cd'/>
+    <flag name='hda-micro'/>
+    <flag name='dump-guest-memory'/>
+    <flag name='nec-usb-xhci'/>
+    <flag name='balloon-event'/>
+    <flag name='lsi'/>
+    <flag name='virtio-scsi-pci'/>
+    <flag name='blockio'/>
+    <flag name='disable-s3'/>
+    <flag name='disable-s4'/>
+    <flag name='usb-redir.filter'/>
+    <flag name='ide-drive.wwn'/>
+    <flag name='scsi-disk.wwn'/>
+    <flag name='seccomp-sandbox'/>
+    <flag name='reboot-timeout'/>
+    <flag name='seamless-migration'/>
+    <flag name='block-commit'/>
+    <flag name='vnc'/>
+    <flag name='drive-mirror'/>
+    <flag name='usb-redir.bootindex'/>
+    <flag name='usb-host.bootindex'/>
+    <flag name='blockdev-snapshot-sync'/>
+    <flag name='qxl'/>
+    <flag name='VGA'/>
+    <flag name='cirrus-vga'/>
+    <flag name='vmware-svga'/>
+    <flag name='device-video-primary'/>
+    <flag name='usb-serial'/>
+    <flag name='usb-net'/>
+    <flag name='add-fd'/>
+    <flag name='nbd-server'/>
+    <flag name='virtio-rng'/>
+    <flag name='rng-random'/>
+    <flag name='rng-egd'/>
+    <flag name='megasas'/>
+    <flag name='tpm-passthrough'/>
+    <flag name='tpm-tis'/>
+    <flag name='pci-bridge'/>
+    <flag name='vfio-pci'/>
+    <flag name='vfio-pci.bootindex'/>
+    <flag name='scsi-generic'/>
+    <flag name='scsi-generic.bootindex'/>
+    <flag name='mem-merge'/>
+    <flag name='vnc-websocket'/>
+    <flag name='drive-discard'/>
+    <flag name='mlock'/>
+    <flag name='device-del-event'/>
+    <flag name='dmi-to-pci-bridge'/>
+    <flag name='i440fx-pci-hole64-size'/>
+    <flag name='q35-pci-hole64-size'/>
+    <flag name='usb-storage'/>
+    <flag name='usb-storage.removable'/>
+    <flag name='ich9-intel-hda'/>
+    <flag name='kvm-pit-lost-tick-policy'/>
+    <flag name='boot-strict'/>
+    <flag name='pvpanic'/>
+    <flag name='spice-file-xfer-disable'/>
+    <flag name='spiceport'/>
+    <flag name='usb-kbd'/>
+    <flag name='msg-timestamp'/>
+    <flag name='active-commit'/>
+    <flag name='change-backing-file'/>
+    <flag name='memory-backend-ram'/>
+    <flag name='numa'/>
+    <flag name='memory-backend-file'/>
+    <flag name='usb-audio'/>
+    <flag name='rtc-reset-reinjection'/>
+    <flag name='splash-timeout'/>
+    <flag name='iothread'/>
+    <flag name='migrate-rdma'/>
+    <flag name='ivshmem'/>
+    <flag name='drive-iotune-max'/>
+    <flag name='VGA.vgamem_mb'/>
+    <flag name='vmware-svga.vgamem_mb'/>
+    <flag name='qxl.vgamem_mb'/>
+    <flag name='pc-dimm'/>
+    <flag name='machine-vmport-opt'/>
+    <flag name='aes-key-wrap'/>
+    <flag name='dea-key-wrap'/>
+    <flag name='pci-serial'/>
+    <flag name='vhost-user-multiqueue'/>
+    <flag name='migration-event'/>
+    <flag name='ioh3420'/>
+    <flag name='x3130-upstream'/>
+    <flag name='xio3130-downstream'/>
+    <flag name='rtl8139'/>
+    <flag name='e1000'/>
+    <flag name='virtio-net'/>
+    <flag name='gic-version'/>
+    <flag name='incoming-defer'/>
+    <flag name='virtio-gpu'/>
+    <flag name='virtio-keyboard'/>
+    <flag name='virtio-mouse'/>
+    <flag name='virtio-tablet'/>
+    <flag name='virtio-input-host'/>
+    <flag name='chardev-file-append'/>
+    <flag name='ich9-disable-s3'/>
+    <flag name='ich9-disable-s4'/>
+    <flag name='vserport-change-event'/>
+    <flag name='virtio-balloon-pci.deflate-on-oom'/>
+    <flag name='mptsas1068'/>
+    <flag name='qxl.vram64_size_mb'/>
+    <flag name='chardev-logfile'/>
+    <flag name='debug-threads'/>
+    <flag name='secret'/>
+    <flag name='pxb'/>
+    <flag name='pxb-pcie'/>
+    <flag name='device-tray-moved-event'/>
+    <flag name='nec-usb-xhci-ports'/>
+    <flag name='virtio-scsi-pci.iothread'/>
+    <flag name='name-guest'/>
+    <flag name='qxl.max_outputs'/>
+    <flag name='spice-unix'/>
+    <flag name='drive-detect-zeroes'/>
+    <flag name='tls-creds-x509'/>
+    <flag name='intel-iommu'/>
+    <flag name='smm'/>
+    <flag name='virtio-pci-disable-legacy'/>
+    <flag name='query-hotpluggable-cpus'/>
+    <flag name='virtio-net.rx_queue_size'/>
+    <flag name='virtio-vga'/>
+    <flag name='drive-iotune-max-length'/>
+    <flag name='ivshmem-plain'/>
+    <flag name='ivshmem-doorbell'/>
+    <flag name='query-qmp-schema'/>
+    <flag name='gluster.debug_level'/>
+    <flag name='drive-iotune-group'/>
+    <flag name='query-cpu-model-expansion'/>
+    <flag name='virtio-net.host_mtu'/>
+    <flag name='nvdimm'/>
+    <flag name='pcie-root-port'/>
+    <flag name='query-cpu-definitions'/>
+    <flag name='block-write-threshold'/>
+    <flag name='query-named-block-nodes'/>
+    <flag name='cpu-cache'/>
+    <flag name='qemu-xhci'/>
+    <flag name='kernel-irqchip'/>
+    <flag name='kernel-irqchip.split'/>
+    <flag name='intel-iommu.intremap'/>
+    <flag name='intel-iommu.caching-mode'/>
+    <flag name='intel-iommu.eim'/>
+    <flag name='intel-iommu.device-iotlb'/>
+    <flag name='virtio.iommu_platform'/>
+    <flag name='virtio.ats'/>
+    <flag name='loadparm'/>
+    <flag name='vnc-multi-servers'/>
+    <flag name='virtio-net.tx_queue_size'/>
+    <flag name='chardev-reconnect'/>
+    <flag name='virtio-gpu.max_outputs'/>
+    <flag name='vxhs'/>
+    <flag name='virtio-blk.num-queues'/>
+    <flag name='vmcoreinfo'/>
+    <flag name='numa.dist'/>
+    <flag name='disk-share-rw'/>
+    <flag name='iscsi.password-secret'/>
+    <flag name='isa-serial'/>
+    <flag name='dump-completed'/>
+    <flag name='qcow2-luks'/>
+    <flag name='pcie-pci-bridge'/>
+    <flag name='seccomp-blacklist'/>
+    <flag name='query-cpus-fast'/>
+    <flag name='disk-write-cache'/>
+    <flag name='nbd-tls'/>
+    <flag name='tpm-crb'/>
+    <flag name='pr-manager-helper'/>
+    <flag name='qom-list-properties'/>
+    <flag name='memory-backend-file.discard-data'/>
+    <flag name='sdl-gl'/>
+    <flag name='screendump_device'/>
+    <flag name='hda-output'/>
+    <flag name='blockdev-del'/>
+    <flag name='vmgenid'/>
+    <flag name='vhost-vsock'/>
+    <flag name='chardev-fd-pass'/>
+    <flag name='tpm-emulator'/>
+    <flag name='mch'/>
+    <flag name='mch.extended-tseg-mbytes'/>
+    <flag name='usb-storage.werror'/>
+    <flag name='egl-headless'/>
+    <flag name='vfio-pci.display'/>
+  </qemuCaps>
+  <devices>
+    <device alias='rng0'/>
+    <device alias='virtio-disk0'/>
+    <device alias='virtio-serial0'/>
+    <device alias='video0'/>
+    <device alias='serial0'/>
+    <device alias='balloon0'/>
+    <device alias='channel0'/>
+    <device alias='net0'/>
+    <device alias='input0'/>
+    <device alias='scsi0'/>
+    <device alias='usb'/>
+  </devices>
+  <libDir path='/var/lib/libvirt/qemu/domain-19-c7_ceph'/>
+  <channelTargetDir path='/var/lib/libvirt/qemu/channel/target/domain-19-c7_ceph'/>
+  <cpu mode='custom' match='exact' check='partial'>
+    <model fallback='forbid'>Broadwell</model>
+  </cpu>
+  <chardevStdioLogd/>
+  <allowReboot value='yes'/>
+  <blockjobs active='no'/>
+  <domain type='kvm' id='19'>
+    <name>c7_ceph</name>
+    <uuid>ff08671e-824c-4939-80ec-602235c0662e</uuid>
+    <memory unit='KiB'>4194304</memory>
+    <currentMemory unit='KiB'>4194304</currentMemory>
+    <vcpu placement='static'>2</vcpu>
+    <resource>
+      <partition>/machine</partition>
+    </resource>
+    <os>
+      <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type>
+      <boot dev='hd'/>
+    </os>
+    <features>
+      <acpi/>
+      <apic/>
+    </features>
+    <cpu mode='custom' match='exact' check='full'>
+      <model fallback='forbid'>Broadwell</model>
+      <feature policy='require' name='vme'/>
+      <feature policy='require' name='f16c'/>
+      <feature policy='require' name='rdrand'/>
+      <feature policy='require' name='hypervisor'/>
+      <feature policy='require' name='arat'/>
+      <feature policy='disable' name='erms'/>
+      <feature policy='require' name='xsaveopt'/>
+      <feature policy='require' name='abm'/>
+    </cpu>
+    <clock offset='utc'>
+      <timer name='rtc' tickpolicy='catchup'/>
+      <timer name='pit' tickpolicy='delay'/>
+      <timer name='hpet' present='no'/>
+    </clock>
+    <on_poweroff>destroy</on_poweroff>
+    <on_reboot>restart</on_reboot>
+    <on_crash>destroy</on_crash>
+    <pm>
+      <suspend-to-mem enabled='no'/>
+      <suspend-to-disk enabled='no'/>
+    </pm>
+    <devices>
+      <emulator>/usr/local/qemu-3.0/bin/qemu-system-x86_64</emulator>
+      <disk type='network' device='disk'>
+        <driver name='qemu' type='raw' cache='writeback'/>
+        <auth username='libvirt'>
+          <secret type='ceph' uuid='fb57a2a3-8cdf-44cb-afc1-2d8bdc0fc5d0'/>
+        </auth>
+        <source protocol='rbd' name='libvirt-pool/root-vsys_c5.qcow2' tlsFromConfig='0'>
+          <host name='172.24.193.62' port='6789'/>
+          <host name='172.24.193.63' port='6789'/>
+          <host name='172.24.193.64' port='6789'/>
+          <privateData>
+            <objects>
+              <secret type='auth' alias='virtio-disk0-secret0'/>
+            </objects>
+          </privateData>
+        </source>
+        <target dev='vda' bus='virtio'/>
+        <alias name='virtio-disk0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
+      </disk>
+      <controller type='usb' index='0' model='ich9-ehci1'>
+        <alias name='usb'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x7'/>
+      </controller>
+      <controller type='usb' index='0' model='ich9-uhci1'>
+        <alias name='usb'/>
+        <master startport='0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/>
+      </controller>
+      <controller type='usb' index='0' model='ich9-uhci2'>
+        <alias name='usb'/>
+        <master startport='2'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/>
+      </controller>
+      <controller type='usb' index='0' model='ich9-uhci3'>
+        <alias name='usb'/>
+        <master startport='4'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x2'/>
+      </controller>
+      <controller type='pci' index='0' model='pci-root'>
+        <alias name='pci.0'/>
+      </controller>
+      <controller type='virtio-serial' index='0'>
+        <alias name='virtio-serial0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
+      </controller>
+      <controller type='scsi' index='0' model='lsilogic'>
+        <alias name='scsi0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
+      </controller>
+      <controller type='ide' index='0'>
+        <alias name='ide'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
+      </controller>
+      <interface type='bridge'>
+        <mac address='52:54:00:2e:e1:1f'/>
+        <source bridge='virbr0'/>
+        <target dev='vnet0'/>
+        <model type='virtio'/>
+        <alias name='net0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+      </interface>
+      <serial type='pty'>
+        <source path='/dev/pts/2'/>
+        <target type='isa-serial' port='0'>
+          <model name='isa-serial'/>
+        </target>
+        <alias name='serial0'/>
+      </serial>
+      <console type='pty' tty='/dev/pts/2'>
+        <source path='/dev/pts/2'/>
+        <target type='serial' port='0'/>
+        <alias name='serial0'/>
+      </console>
+      <channel type='unix'>
+        <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-19-c7_ceph/org.qemu.guest_agent.0'/>
+        <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/>
+        <alias name='channel0'/>
+        <address type='virtio-serial' controller='0' bus='0' port='1'/>
+      </channel>
+      <input type='tablet' bus='usb'>
+        <alias name='input0'/>
+        <address type='usb' bus='0' port='1'/>
+      </input>
+      <input type='mouse' bus='ps2'>
+        <alias name='input1'/>
+      </input>
+      <input type='keyboard' bus='ps2'>
+        <alias name='input2'/>
+      </input>
+      <graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0'>
+        <listen type='address' address='0.0.0.0' fromConfig='0' autoGenerated='no'/>
+      </graphics>
+      <video>
+        <model type='cirrus' vram='16384' heads='1' primary='yes'/>
+        <alias name='video0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+      </video>
+      <memballoon model='virtio'>
+        <alias name='balloon0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
+      </memballoon>
+      <rng model='virtio'>
+        <backend model='random'>/dev/urandom</backend>
+        <alias name='rng0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
+      </rng>
+    </devices>
+    <seclabel type='dynamic' model='selinux' relabel='yes'>
+      <label>system_u:system_r:svirt_t:s0:c99,c659</label>
+      <imagelabel>system_u:object_r:svirt_image_t:s0:c99,c659</imagelabel>
+    </seclabel>
+    <seclabel type='dynamic' model='dac' relabel='yes'>
+      <label>+107:+107</label>
+      <imagelabel>+107:+107</imagelabel>
+    </seclabel>
+  </domain>
+</domstatus>
+[root@ceph-client ceph]# 
+
+/usr/local/qemu-3.0/bin/qemu-system-x86_64 which is build by qemu-3.0 source code , first i build qemu-3.0 source with --enable-rbd ,
+later i rebuild qemu-3.0 source with more config paramter from centos7-2009 qemu, those config paramter from qemu-kvm-1.5.3-175.el7.src.rpm ,which has those paramters:
+# QEMU configure log Fri Mar  3 18:22:31 CST 2023
+# Configured with: './configure' '--prefix=/usr' '--libdir=/usr/lib64' '--sysconfdir=/etc' '--interp-prefix=/usr/qemu-%M' '--audio-drv-list=pa,alsa' '--with-confsuffix=/qemu-kvm' '--localstatedir=/var' '--libexecdir=/usr/libexec' '--wit
+h-pkgversion=qemu-kvm-1.5.3-175.el7' '--disable-strip' '--disable-qom-cast-debug' '--extra-ldflags=-Wl,--build-id -pie -Wl,-z,relro -Wl,-z,now' '--extra-cflags=-O2 -g -pipe -Wall  -fexceptions -fstack-protector-strong --param=ssp-buffer
+-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIE -DPIE' '--enable-trace-backend=dtrace' '--enable-werror' '--disable-xen' '--disable-virtfs' '--enable-kvm' '--enable-libusb' '--enable-spice' '--enable-seccomp' '--disable-fdt' '--
+enable-docs' '--disable-sdl' '--disable-debug-tcg' '--disable-sparse' '--disable-brlapi' '--disable-bluez' '--disable-vde' '--disable-curses' '--enable-curl' '--enable-libssh2' '--enable-vnc-tls' '--enable-vnc-sasl' '--enable-linux-aio'
+ '--enable-smartcard-nss' '--enable-lzo' '--enable-snappy' '--enable-usb-redir' '--enable-vnc-png' '--disable-vnc-jpeg' '--enable-vnc-ws' '--enable-uuid' '--disable-vhost-scsi' '--disable-guest-agent' '--disable-live-block-ops' '--disab
+le-live-block-migration' '--enable-rbd' '--enable-glusterfs' '--enable-tcmalloc' '--block-drv-rw-whitelist=qcow2,raw,file,host_device,blkdebug,nbd,iscsi,gluster,rbd' '--block-drv-ro-whitelist=vmdk,vhdx,vpc,ssh,https' '--iasl=/bin/false'
+ '--target-list=x86_64-softmmu'
+
+
+,   after rebuild the qemu-system-x86_64 : 
+
+virsh start c7_ceph 
+[root@ceph-client ceph]# virsh list --all
+ Id    Name                           State
+----------------------------------------------------
+ 19    c7_ceph                        running
+
+qemu still stuck at booting from hard disk...
+
+
+
+to my surprised if the libvirtd xml file if i replace /usr/local/qemu-3.0/bin/qemu-system-x86_64 with /usr/libexec/bin/qemu-kvm , then the vm
+can start successfully .
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1537 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1537
new file mode 100644
index 00000000..9f58396d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1537
@@ -0,0 +1,11 @@
+One-floppy windows 3.11  file manager does not work in tcg mode
+Description of problem:
+When I try to boot mini win 3.11 from https://archive.org/details/mwin-3 it boots into desktop ok, but double-clicking on file manager icon  result in black window/GPF (briefly flashing text I can't fully read).
+
+Starting it with boot choice 2 - with emm386 - same action result in machine reboot.
+
+Using same disk with kvm works for choice #2 (boot with emm386)
+Steps to reproduce:
+1. Download IMG file from Arhivce org
+2. Run it like I shown above
+3. Any (out of two) boot choices lead to same outcome - desktop and say ms-dos console works, but launching file manager gives you black screen/error
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1538 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1538
new file mode 100644
index 00000000..f162f646
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1538
@@ -0,0 +1 @@
+igd.c gives up IGD legacy mode if no option ROM found
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/154 b/gitlab/issues_text/target_missing/host_missing/accel_missing/154
new file mode 100644
index 00000000..44cb36c3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/154
@@ -0,0 +1 @@
+readlink(2) returns incorrect size for /proc/self/exe
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1541 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1541
new file mode 100644
index 00000000..7b712df8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1541
@@ -0,0 +1,32 @@
+Invalid position of G_NORETURN in clang v15
+Description of problem:
+Order of `G_NORETURN` used in https://gitlab.com/qemu-project/qemu/-/blob/0f3de970febd2c9b29dccecb63ca928c6802a101/include/qemu/osdep.h#L240-242 is not valid in clang++ 15.0.7.
+
+Switching `extern` with `G_NORETURN` seems to fix the issue.
+Steps to reproduce:
+1. Build qemu system for MIPSEL or use minimal reproducer:
+
+`example.cpp`:
+```
+#include "/path/to/qemu/include/glib-compat.h"
+
+extern G_NORETURN
+void // QEMU_ERROR("code path is reachable")
+    qemu_build_not_reached_always(void);
+```
+
+```
+$ clang++ --version
+clang version 15.0.7
+Target: x86_64-pc-linux-gnu
+Thread model: posix
+InstalledDir: /usr/bin
+$ clang++ -m64 -mcx16 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu++11 -O0 -g example.cpp
+example.cpp:3:8: error: an attribute list cannot appear here
+extern G_NORETURN
+       ^~~~~~~~~~
+/usr/include/glib-2.0/glib/gmacros.h:1075:21: note: expanded from macro 'G_NORETURN'
+# define G_NORETURN [[noreturn]]
+                    ^~~~~~~~~~~~
+1 error generated.
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1543 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1543
new file mode 100644
index 00000000..9a25b604
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1543
@@ -0,0 +1 @@
+Heap-use-after-free in e1000e_receive_internal
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1544 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1544
new file mode 100644
index 00000000..080553a1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1544
@@ -0,0 +1 @@
+Abort in net_tx_pkt_do_sw_fragmentation
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1545 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1545
new file mode 100644
index 00000000..6d506bf5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1545
@@ -0,0 +1,9 @@
+SSL is out of date on website
+Description of problem:
+The Linux KVM website is running an out of date SSL certificate.
+Steps to reproduce:
+1. visit the website. https://www.linux-kvm.org/page/Main_Page
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1546 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1546
new file mode 100644
index 00000000..bd13b2d4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1546
@@ -0,0 +1 @@
+Git build fail in fp tests
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1548 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1548
new file mode 100644
index 00000000..276ef31d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1548
@@ -0,0 +1,38 @@
+8.0.0rc0 Regression: vnc fails with Segmentation fault
+Description of problem:
+On connecting with `gvncviewer localhost:05` the qemu process fails with
+```
+Segmentation fault
+```
+`gvncviewer localhost:05` prints
+```
+Connected to server
+Error: Server closed the connection
+Disconnected from server
+```
+Steps to reproduce:
+1. Enter `qemu-system-x86_64 -m 1536 -display vnc=:05 -k de -cdrom openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso` in first terminal
+2. Enter `gvncviewer localhost:05` in second terminal
+Additional information:
+Final output of `git bisect`:
+```
+385ac97f8fad0e6980c5dfea71132d5ecfb16608 is the first bad commit
+commit 385ac97f8fad0e6980c5dfea71132d5ecfb16608
+Author: Marc-André Lureau <marcandre.lureau@redhat.com>
+Date:   Tue Jan 17 15:24:40 2023 +0400
+
+    ui: keep current cursor with QemuConsole
+    
+    Keeping the current cursor around is useful, not only for VNC, but for
+    other displays. Let's move it down, see the following patches for other
+    usages.
+    
+    Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
+    Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
+
+ include/ui/console.h | 1 +
+ ui/console.c         | 8 ++++++++
+ ui/vnc.c             | 7 ++-----
+ ui/vnc.h             | 1 -
+ 4 files changed, 11 insertions(+), 6 deletions(-)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1549 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1549
new file mode 100644
index 00000000..53dc0ad7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1549
@@ -0,0 +1,95 @@
+8.0.0rc0 Regression: spicy windows doesn't open
+Description of problem:
+Soon after start the qemu process outputs 
+```
+qemu-system-x86_64.exe: fd=900 is not a socket, AIO implementation is missing
+qemu-system-x86_64.exe: fd=800 is not a socket, AIO implementation is missing
+```
+On connecting with `spicy -h localhost -p 5905 --spice-debug` spicy stops progress after writing this line
+```
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.406: ../spice-gtk-0.42/src/spice-channel.c:1415 main-1:0: channel type 1 id 0 num common caps 1 num caps 1
+```
+Steps to reproduce:
+1. Start qemu with `qemu-system-x86_64 -m 1536 -vga qxl -spice port=5905,addr=127.0.0.1,disable-ticketing=on -cdrom openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso` in first MSYS2 MinGW64 terminal
+2. Start spice with `spicy -h localhost -p 5905 --spice-debug` in second MSYS2 MinGW64 terminal
+Additional information:
+Final output of `git bisect`
+```
+abe34282b088499f4e86fff9bb6d6dafd57ae1d0 is the first bad commit
+commit abe34282b088499f4e86fff9bb6d6dafd57ae1d0
+Author: Marc-André Lureau <marcandre.lureau@redhat.com>
+Date:   Tue Feb 21 16:47:59 2023 +0400
+
+    win32: avoid mixing SOCKET and file descriptor space
+
+    Until now, a win32 SOCKET handle is often cast to an int file
+    descriptor, as this is what other OS use for sockets. When necessary,
+    QEMU eventually queries whether it's a socket with the help of
+    fd_is_socket(). However, there is no guarantee of conflict between the
+    fd and SOCKET space. Such conflict would have surprising consequences,
+    we shouldn't mix them.
+
+    Also, it is often forgotten that SOCKET must be closed with
+    closesocket(), and not close().
+
+    Instead, let's make the win32 socket wrapper functions return and take a
+    file descriptor, and let util/ wrappers do the fd/SOCKET conversion as
+    necessary. A bit of adaptation is necessary in io/ as well.
+
+    Unfortunately, we can't drop closesocket() usage, despite
+    _open_osfhandle() documentation claiming transfer of ownership, testing
+    shows bad behaviour if you forget to call closesocket().
+
+    Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
+    Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
+    Message-Id: <20230221124802.4103554-15-marcandre.lureau@redhat.com>
+
+ include/sysemu/os-win32.h |   4 +-
+ io/channel-watch.c        |   6 +-
+ util/aio-win32.c          |   9 +-
+ util/oslib-win32.c        | 219 +++++++++++++++++++++++++++++++++++++++-------
+ 4 files changed, 197 insertions(+), 41 deletions(-)
+```
+Complete spicy output
+```
+$ spicy -h localhost -p 5905 --spice-debug
+(spicy.exe:5584): GSpice-DEBUG: 18:43:52.890: ../spice-gtk-0.42/src/spice-session.c:288 New session (compiled from package spice-gtk 0.42)
+(spicy.exe:5584): GSpice-DEBUG: 18:43:53.872: ../spice-gtk-0.42/src/spice-session.c:292 Supported channels: main, display, inputs, cursor, playback, record, smartcard, usbredir, webdav
+(spicy.exe:5584): GSpice-WARNING **: 18:43:53.877: SpiceSession:gl-scanout is only available on Unix
+(spicy.exe:5584): GSpice-WARNING **: 18:43:53.881: UsbDk driver is not installed
+(spicy.exe:5584): GSpice-DEBUG: 18:43:53.908: ../spice-gtk-0.42/src/usb-device-manager.c:393 auto-connect filter set to 0x03,-1,-1,-1,0|-1,-1,-1,-1,1
+(spicy.exe:5584): GSpice-DEBUG: 18:43:53.913: ../spice-gtk-0.42/src/usb-backend.c:440 spice_usb_backend_new >>
+(spicy.exe:5584): GSpice-DEBUG: 18:43:53.918: ../spice-gtk-0.42/src/usb-backend.c:462 spice_usb_backend_new <<
+(spicy.exe:5584): GSpice-DEBUG: 18:43:53.995: ../spice-gtk-0.42/src/usb-backend.c:207 adding 04F2:B43C at 1:1
+(spicy.exe:5584): GSpice-DEBUG: 18:43:53.998: ../spice-gtk-0.42/src/usb-backend.c:207 adding 8086:8C26 at 3:0
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.000: ../spice-gtk-0.42/src/usb-backend.c:207 adding 8086:8C2D at 1:0
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.003: ../spice-gtk-0.42/src/usb-backend.c:207 adding 0BDA:B728 at 1:4
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.006: ../spice-gtk-0.42/src/usb-backend.c:158 created dev 00000148d2a9e280, usblib dev 00000148d27a2590
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.010: ../spice-gtk-0.42/src/usb-backend.c:207 adding 8086:8C31 at 2:0
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.014: ../spice-gtk-0.42/src/usb-backend.c:207 adding 05E3:0608 at 3:5
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.017: ../spice-gtk-0.42/src/usb-backend.c:207 adding 8087:8008 at 1:5
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.020: ../spice-gtk-0.42/src/usb-backend.c:207 adding 0BDA:0129 at 1:3
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.023: ../spice-gtk-0.42/src/usb-backend.c:158 created dev 00000148d2a9e140, usblib dev 00000148d27a2b30
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.027: ../spice-gtk-0.42/src/usb-backend.c:207 adding 8087:8000 at 3:4
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.030: ../spice-gtk-0.42/src/usb-backend.c:207 adding 045E:00DB at 3:1
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.033: ../spice-gtk-0.42/src/usb-backend.c:207 adding 17EF:6019 at 3:2
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.035: ../spice-gtk-0.42/src/usb-backend.c:158 created dev 00000148d2a9e190, usblib dev 00000148d27a5460
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.074: ../spice-gtk-0.42/tools/spicy.c:1881 connection_new (1)
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.074: ../spice-gtk-0.42/src/usb-backend.c:469 handle_libusb_events >>
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.081: ../spice-gtk-0.42/src/spice-session.c:1835 no migration in progress
+Spice-INFO: 18:43:54.086: ../spice-gtk-0.42/src/channel-main.c:342:spice_main_set_property: SpiceMainChannel::color-depth has been deprecated. Property is ignored
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.090: ../spice-gtk-0.42/src/spice-channel.c:142 main-1:0: spice_channel_constructed
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.093: ../spice-gtk-0.42/src/spice-session.c:2330 main-1:0: new main channel, switching
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.097: ../spice-gtk-0.42/tools/spicy.c:1758 new channel (#0)
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.099: ../spice-gtk-0.42/tools/spicy.c:1761 new main channel
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.102: ../spice-gtk-0.42/src/usb-device-manager.c:800 device added 0bda:b728 (00000148d2a9e280)
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.105: ../spice-gtk-0.42/src/usb-device-manager.c:800 device added 0bda:0129 (00000148d2a9e140)
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.108: ../spice-gtk-0.42/src/usb-device-manager.c:800 device added 17ef:6019 (00000148d2a9e190)
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.113: ../spice-gtk-0.42/src/spice-channel.c:2763 main-1:0: Open coroutine starting 00000148d2a403f0
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.116: ../spice-gtk-0.42/src/spice-channel.c:2587 main-1:0: Started background coroutine 00000148d2a402b0
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.120: ../spice-gtk-0.42/src/spice-session.c:2267 main-1:0: Using plain text, port 5905
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.124: ../spice-gtk-0.42/src/spice-session.c:2198 open host localhost:5905
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.136: ../spice-gtk-0.42/src/spice-session.c:2120 main-1:0: connecting 000000010f1ffc90...
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.402: ../spice-gtk-0.42/src/spice-session.c:2104 main-1:0: connect ready
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.406: ../spice-gtk-0.42/src/spice-channel.c:1415 main-1:0: channel type 1 id 0 num common caps 1 num caps 1
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1550 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1550
new file mode 100644
index 00000000..86acfdda
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1550
@@ -0,0 +1,16 @@
+Crazy mouse movement when passing `-M pc,vmport=off -accel kvm -vga virtio` at the same time
+Description of problem:
+The mouse cursor is unusable in an x86 guest (disappears, jumps around like crazy) in a graphical environment when `-M pc,vmport=off -accel kvm -vga virtio` is given at the same time.
+Steps to reproduce:
+1. Download https://download.manjaro.org/xfce/22.0.5/manjaro-xfce-22.0.5-230316-linux61.iso
+2. Start above command
+3. Wait until the graphical desktop appears
+4. Click inside the window and move the mouse
+
+-> Mouse cursor disappears or jumps around like crazy
+Additional information:
+If vmport=off is **not** passed, at some point during startup (before graphical login manager appears) the guest switches to use vmmouse from PS/2 mouse. There it also requests usage of absolute input coordinates (VMMOUSE_REQUEST_ABSOLUTE). This code path works normal. Therefore the culprit might be in the guest.
+
+Another way to reproduce the issue is to use -accel whpx under Windows host (no need to pass vmport=off there). It can be observed that the same guest doesn't attempt to switch to vmmouse there, just like passing vmport=off under Linux.
+
+The problem does not exist on Linux host when -accel tcg is used in which case the guest doesn't attempt to switch to vmmouse.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1553 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1553
new file mode 100644
index 00000000..282da2ba
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1553
@@ -0,0 +1,12 @@
+Build error: implicit declaration of function 'qemu_close_to_socket'
+Description of problem:
+When build the latest master code with MSYS2 on Windows 10, GCC reports:
+../ui/spice-core.c: In function 'watch_remove':
+../ui/spice-core.c:152:5: error: implicit declaration of function 'qemu_close_to_socket' [-Werror=implicit-function-declaration]
+  152 |     qemu_close_to_socket(watch->fd);
+      |     ^~~~~~~~~~~~~~~~~~~~
+../ui/spice-core.c:152:5: error: nested extern declaration of 'qemu_close_to_socket' [-Werror=nested-externs]
+Steps to reproduce:
+1. ./configure --enable-sdl --enable-gtk --target-list=arm-softmmu,aarch64-softmmu
+2. cd build
+3. make
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1554 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1554
new file mode 100644
index 00000000..20b20ee7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1554
@@ -0,0 +1,6 @@
+I want get a qemu-img tool,which can run in Any linux operating system, what can i do?
+Description of problem:
+As we known,qemu-img depends on many dynamic libraries,it can't run in other os if libraries is not support.whether qemu can use static compilation to solve this problem？
+
+
+i refer to this [issue 1190](https://gitlab.com/qemu-project/qemu/-/issues/1190),but when compile over,it not generate a static qemu-img. Or it has other functions to get a qemu-img which can run in Any linux operating system?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1557 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1557
new file mode 100644
index 00000000..94bfc80e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1557
@@ -0,0 +1,11 @@
+qemu-binfmt-conf.sh handles errors inconsistently
+Description of problem:
+We are installing qemu via multiarch/qemu-user-static docker image. https://github.com/multiarch/qemu-user-static
+
+What we have noticed is that because qemu-binfmt-conf.sh does not use `set -e`, its behavior with regards to failures is inconsistent. In short, registering the same thing into binfmt twice is an error (you get EEXIST). However, the exit code of qemu-binfmt-conf.sh itself seems to depend only on whether the last interpreter succeeded, leading to confusing and inconsistent results.
+Steps to reproduce:
+1. Register only qemu-arm-static interpreter with binfmt.
+2. Run qemu-binfmt-conf.sh. Observe that the exit code is zero, and logs show the duplicate interpreter was rejected.
+3. Remove all qemu interpreters.
+3. Register only qemu-loongarch64-static interpreter (currently last in qemu_target_list) with binfmt.
+3. Run qemu-binfmt-conf.sh. Observe that the exit code is non-zero, and logs show the duplicate interpreter was rejected.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1558 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1558
new file mode 100644
index 00000000..7529f6b4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1558
@@ -0,0 +1,21 @@
+Bug checklist for AEHD
+Description of problem:
+There was a discussion on qemu-devel about addition of a new hypervisor, which is essentially a rewrite of linux/kvm, but for windows
+- 202303002 Haito Shan [PATCH 0/6] Adding the Android Emulator hypervisor driver accelerator  
+  https://lore.kernel.org/qemu-devel/CAGD3tSzW1QoAsn+uGjoAkBegLt1iZ=9YWDFcvqbcHMr0S_5kVw@mail.gmail.com/
+
+If the new hypervisor AEHD does not support these, then each of the below may automatically qualify as a feature catchup bug
+1) Nested Virtualization
+2) virtio-GPU/virgl/OpenGL/venus
+3) Vulkan passthrough
+4) Xen emulation on KVM ( a feature also currently under development)   
+  20230302 [phase1-qemu-8.0](https://lore.kernel.org/qemu-devel/20230302123029.153265-1-pbonzini@redhat.com/) [PULL 00/62] i386, misc changes for QEMU 8.0 soft freeze  
+  20230307 [phase2-qemu-8.0](https://lore.kernel.org/qemu-devel/20230307171750.2293175-1-dwmw2@infradead.org/) [PATCH v2 00/27] Enable PV backends with Xen/KVM emulation  
+5) Migration 
+6) others??
+
+perhaps also document if known for certain that there is no intention to catchup to a particular feature.
+Steps to reproduce:
+NA
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/156 b/gitlab/issues_text/target_missing/host_missing/accel_missing/156
new file mode 100644
index 00000000..73002a35
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/156
@@ -0,0 +1 @@
+-nodefaults has unclear documentation
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1560 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1560
new file mode 100644
index 00000000..442ed870
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1560
@@ -0,0 +1 @@
+SLIRP hostfwd_add ignores bind address and uses `INADDR_ANY`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1561 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1561
new file mode 100644
index 00000000..560f77b7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1561
@@ -0,0 +1,27 @@
+Compile QEMU 6.2.0 fail for file not found
+Description of problem:
+Compile QEMU failed with error message:
+```
+In file included from ../subprojects/libvhost-user/libvhost-user.c:45:
+../subprojects/libvhost-user/libvhost-user.h:23:10: Fatal error：standard-headers/linux/virtio_ring.h：no such file or directory
+   23 | #include "standard-headers/linux/virtio_ring.h"
+      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+Steps to reproduce:
+1. Download qemu-6.2.0 tarball at https://download.qemu.org/qemu-6.2.0.tar.xz
+2. unzip the tarball to dir ```qemu-6.2.0```
+2. cd ```qemu-6.2.0```, and then ```./configure && make -j2```
+Additional information:
+In ```qemu-6.2.0/subprojects/libvhost-user/libvhost-user.c:45```, the included files are:
+
+```
+#include <stdint.h>
+#include <stdbool.h>
+#include <stddef.h>
+#include <poll.h>
+#include <linux/vhost.h>
+#include <pthread.h>
+#include "standard-headers/linux/virtio_ring.h"    
+```
+
+```standard-headers``` are in ```qemu-6.2.0/include/standard-headers/```, but above #include assume it's in the same dir of ```libvhost-user.c```.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1562 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1562
new file mode 100644
index 00000000..050ae55b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1562
@@ -0,0 +1,129 @@
+qemu live migration with compression ( zstd or zlib ) in same server  always(100% reproduce) failed (recevied ram page flag 0x0)
+Description of problem:
+
+Steps to reproduce:
+1. live migration with compress mode in same server
+2. src:  qemu-system-x86_64  -cpu Cascadelake-Server-v4 -smp 10 -enable-kvm -m 50G -nographic -serial telnet:localhost:4321,server,nowait -nic tap,ifname=tap0,script=no,downscript=no CentOS-Stream-GenericCloud-9-20230123.0.x86_64_test_0.qcow2
+
+```
+   QEMU 7.2.91 monitor - type 'help' for more information
+(qemu) migrate_set_capability compress on
+(qemu) migrate_set_parameter multifd-compression zstd
+(qemu) info migrate_capabilities
+xbzrle: off
+rdma-pin-all: off
+auto-converge: off
+zero-blocks: off
+compress: on
+events: off
+postcopy-ram: off
+x-colo: off
+release-ram: off
+block: off
+return-path: off
+pause-before-switchover: off
+multifd: off
+dirty-bitmaps: off
+postcopy-blocktime: off
+late-block-activate: off
+x-ignore-shared: off
+validate-uuid: off
+background-snapshot: off
+zero-copy-send: off
+postcopy-preempt: off
+(qemu)  info migrate_parameters
+announce-initial: 50 ms
+announce-max: 550 ms
+announce-rounds: 5
+announce-step: 100 ms
+compress-level: 1
+compress-threads: 8
+compress-wait-thread: on
+decompress-threads: 2
+throttle-trigger-threshold: 50
+cpu-throttle-initial: 20
+cpu-throttle-increment: 10
+cpu-throttle-tailslow: off
+max-cpu-throttle: 99
+tls-creds: ''
+tls-hostname: ''
+max-bandwidth: 134217728 bytes/second
+downtime-limit: 300 ms
+x-checkpoint-delay: 20000 ms
+block-incremental: off
+multifd-channels: 2
+multifd-compression: zstd
+xbzrle-cache-size: 67108864 bytes
+max-postcopy-bandwidth: 0
+tls-authz: ''
+(qemu) migrate -d tcp:localhost:4444
+(qemu) qemu-system-x86_64: failed to save SaveStateEntry with id(name): 2(ram): -5
+qemu-system-x86_64: Unable to write to socket: Connection reset by peer
+```
+
+3.dest(in same server): qemu-system-x86_64  -cpu Cascadelake-Server-v4 -smp 10 -enable-kvm -m 50G -nographic -serial telnet:localhost:4322,server,nowait -nic tap,ifname=tap1,script=no,downscript=no --incoming tcp:0:4444  CentOS-Stream-GenericCloud-9-20230123.0.x86_64_test_0.qcow2
+
+```
+ QEMU 7.2.91 monitor - type 'help' for more information
+(qemu) migrate_set_capability compress on
+(qemu) migrate_set_parameter multifd-compression zstd
+(qemu) info mi
+mice                  migrate               migrate_capabilities
+migrate_parameters
+(qemu) info migrate_capabilities
+xbzrle: off
+rdma-pin-all: off
+auto-converge: off
+zero-blocks: off
+compress: on
+events: off
+postcopy-ram: off
+x-colo: off
+release-ram: off
+block: off
+return-path: off
+pause-before-switchover: off
+multifd: off
+dirty-bitmaps: off
+postcopy-blocktime: off
+late-block-activate: off
+x-ignore-shared: off
+validate-uuid: off
+background-snapshot: off
+zero-copy-send: off
+postcopy-preempt: off
+(qemu) info migr
+migrate               migrate_capabilities  migrate_parameters
+(qemu) info migrate_parameters
+announce-initial: 50 ms
+announce-max: 550 ms
+announce-rounds: 5
+announce-step: 100 ms
+compress-level: 1
+compress-threads: 8
+compress-wait-thread: on
+decompress-threads: 2
+throttle-trigger-threshold: 50
+cpu-throttle-initial: 20
+cpu-throttle-increment: 10
+cpu-throttle-tailslow: off
+max-cpu-throttle: 99
+tls-creds: ''
+tls-hostname: ''
+max-bandwidth: 134217728 bytes/second
+downtime-limit: 300 ms
+x-checkpoint-delay: 20000 ms
+block-incremental: off
+multifd-channels: 2
+multifd-compression: zstd
+xbzrle-cache-size: 67108864 bytes
+max-postcopy-bandwidth: 0
+tls-authz: ''
+(qemu) info migrate_capabilitiesqemu-system-x86_64: Unknown combination of migration flags: 0x0
+qemu-system-x86_64: decompress data failed
+qemu-system-x86_64: error while loading state section id 2(ram)
+qemu-system-x86_64: load of migration failed: Operation not permitted
+```
+Additional information:
+$ zstd -V
+*** zstd command line interface 64-bits v1.5.1, by Yann Collet ***
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1563 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1563
new file mode 100644
index 00000000..5b4eeb21
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1563
@@ -0,0 +1,3 @@
+lsi53c895a: DMA reentrancy issue leads to stack overflow (CVE-2023-0330)
+Description of problem:
+See https://bugzilla.redhat.com/show_bug.cgi?id=2160151.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1566 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1566
new file mode 100644
index 00000000..0cc9e207
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1566
@@ -0,0 +1,9 @@
+qemo-8-0-0-rc2 error: redeclaration of 'enum fsconfig_command'
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1567 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1567
new file mode 100644
index 00000000..4d6ca6fc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1567
@@ -0,0 +1,34 @@
+On windows, storage daemon does not support daemonize
+Description of problem:
+Presently, in order to run qemu-storage-daemon on windows, one has to login and run it in a terminal window that is kept open.
+
+#
+Steps to reproduce:
+just run the command
+Additional information:
+https://gitlab.com/qemu-project/qemu/-/blob/master/storage-daemon/qemu-storage-daemon.c#L299
+```
+        case OPTION_DAEMONIZE:
+            if (os_set_daemonize(true) < 0) {
+                /*
+                 * --daemonize is parsed before monitor_init_globals(), so
+                 * error_report() does not work yet
+                 */
+                fprintf(stderr, "--daemonize not supported in this build\n");
+                exit(EXIT_FAILURE);
+            }
+```
+https://gitlab.com/qemu-project/qemu/-/blob/master/include/sysemu/os-win32.h#L114
+```
+static inline int os_set_daemonize(bool d)
+{
+    if (d) {
+        return -ENOTSUP;
+    }
+    return 0;
+}
+```
+
+- Recently Marc has added windows socket support   
+  20230313 marcandre.lureau [PULL 00/25] Win socket patches  
+  https://lore.kernel.org/qemu-devel/20230313114335.424093-1-marcandre.lureau@redhat.com/
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1569 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1569
new file mode 100644
index 00000000..75e42de2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1569
@@ -0,0 +1,27 @@
+NVMe FS operations hang after suspending and resuming both guest and host
+Description of problem:
+Hello and thank you for your work on QEMU!
+
+Using the NVMe driver with my Seagate FireCuda 530 2TB M.2 works fine until I encounter this problem, which is reliably reproducible for me.
+
+When I suspend the guest and then suspend (s2idle) my host all is well until I resume the guest (manually with `virsh dompmwakeup $VMNAME`, after the host has resumed). Although the guest resumes and is interactive, it seems that anything involving filesystem operations hang forever and do not return.
+
+Suspending and resuming the Linux guest seems to work perfectly if I don't suspend/resume the host.
+
+Ultimately what I'm wanting to do is share the drive between VMs with qemu-storage-daemon. I can reproduce the problem in that scenario in much the same way. Using PCI passthrough with the same VM and device works fine and doesn't exhibit this problem.
+
+Hopefully that's clear enough - let me know if there's anything else I can provide.
+Steps to reproduce:
+1. Create a VM with a dedicated NVMe disk.
+2. Boot an ISO and install to the disk.
+3. Verify that suspend and resume works when not suspending the host.
+4. Suspend the guest.
+5. Suspend the host.
+6. Wake the host.
+7. Wake the guest.
+8. Try just about anything that isn't likely already cached somewhere: `du -s /etc`.
+Additional information:
+I've attached the libvirt domain XML[1] and libvirtd debug logs for QEMU[2] ("1:qemu") that covers suspending the guest & host, resuming host & guest and doing something to cause a hang. I tried to leave enough time afterwards for any timeout to occur.
+
+1. [nvme-voidlinux.xml](/uploads/1dea47af096ce58175f7aa526eca455e/nvme-voidlinux.xml)
+2. [nvme-qemu-debug.log](/uploads/42d3bed456a795069023a61d38fa5ccd/nvme-qemu-debug.log)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/157 b/gitlab/issues_text/target_missing/host_missing/accel_missing/157
new file mode 100644
index 00000000..a5f47bd3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/157
@@ -0,0 +1 @@
+Xbox One controller USB passthrough disconnections and stops
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1572 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1572
new file mode 100644
index 00000000..30e8840f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1572
@@ -0,0 +1 @@
+Assertion !rss_info->enabled failed in e1000e_write_lgcy_rx_descr
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1573 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1573
new file mode 100644
index 00000000..f8eb439d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1573
@@ -0,0 +1 @@
+TCP Previous segment not captured
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1574 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1574
new file mode 100644
index 00000000..b143fae0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1574
@@ -0,0 +1,89 @@
+The guest paused after living migration on destination host, vm-entry error code 0x80000021
+Description of problem:
+The guest start on source host, then living migration to destination host, the guest status is pausing.   
+source host CPU: Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz     
+destination host CPU: Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz   
+If the guest migration from E5-2650 to Silver 4114, the guest runs normally without pausing.
+Steps to reproduce:
+1. start guest, on source host, host CPU: Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz.
+2. living migration guest to destination host, host CPU: Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz.
+3. migration finished, the guest pausing.
+Additional information:
+/label ~"kind::Bug"
+qemu log:
+```
+KVM: entry failed, hardware error 0x80000021
+
+If you're running a guest on an Intel machine without unrestricted mode
+support, the failure can be most likely due to the guest entering an invalid
+state for Intel VT. For example, the guest maybe running in big real mode
+which is not supported on less recent Intel processors.
+
+EAX=94d14da0 EBX=95341e20 ECX=00000000 EDX=00000000
+ESI=00000000 EDI=00000046 EBP=95203eb0 ESP=95203eb0
+EIP=94d14f76 EFL=00000286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0000 00000000 0000ffff 00009300
+CS =f000 ffff0000 0000ffff 00009b00
+SS =0000 00000000 0000ffff 00009300
+DS =0000 00000000 0000ffff 00009300
+FS =0000 00000000 0000ffff 00009300
+GS =0000 00000000 0000ffff 00009300
+LDT=0000 00000000 0000ffff 00008200
+TR =0000 00000000 0000ffff 00008b00
+GDT=     00000000 0000ffff
+IDT=     00000000 0000ffff
+CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000000
+Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+```
+host log:
+```
+kernel: [228693.951391] *** Guest State ***
+kernel: [228693.951411] CR0: actual=0x0000000000000030, shadow=0x0000000060000010, gh_mask=fffffffffffffff7
+kernel: [228693.951422] CR4: actual=0x0000000000002040, shadow=0x0000000000000000, gh_mask=fffffffffffff871
+kernel: [228693.951430] CR3 = 0x0000000000000000
+kernel: [228693.951437] PDPTR0 = 0x0000000000000000  PDPTR1 = 0x0000000000000000
+kernel: [228693.951445] PDPTR2 = 0x0000000000000000  PDPTR3 = 0x0000000000000000
+kernel: [228693.951452] RSP = 0xffffffff95203eb0  RIP = 0xffffffff94d14f76
+kernel: [228693.951459] RFLAGS=0x00000286         DR7 = 0x0000000000000400
+kernel: [228693.951467] Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000
+kernel: [228693.951476] CS:   sel=0xf000, attr=0x0009b, limit=0x0000ffff, base=0x00000000ffff0000
+kernel: [228693.951485] DS:   sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951494] SS:   sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951502] ES:   sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951510] FS:   sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951519] GS:   sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951527] GDTR:                           limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951537] LDTR: sel=0x0000, attr=0x00082, limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951545] IDTR:                           limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951553] TR:   sel=0x0000, attr=0x0008b, limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951562] EFER =     0x0000000000000000  PAT = 0x0007040600070406
+kernel: [228693.951569] DebugCtl = 0x0000000000000000  DebugExceptions = 0x0000000000000000
+kernel: [228693.951578] Interruptibility = 00000000  ActivityState = 00000000
+kernel: [228693.951586] InterruptStatus = 00b1
+kernel: [228693.951591] *** Host State ***
+kernel: [228693.951597] RIP = 0xffffffffc4b064ff  RSP = 0xffffaf14ccf87d10
+kernel: [228693.951606] CS=0010 SS=0018 DS=0000 ES=0000 FS=0000 GS=0000 TR=0040
+kernel: [228693.951614] FSBase=00007f0b2657a640 GSBase=ffff9c083f580000 TRBase=fffffe00001a0000
+kernel: [228693.951623] GDTBase=fffffe000019e000 IDTBase=fffffe0000000000
+kernel: [228693.951631] CR0=0000000080050033 CR3=000000029800c004 CR4=00000000003726e0
+kernel: [228693.951639] Sysenter RSP=fffffe00001a0000 CS:RIP=0010:ffffffff95801590
+kernel: [228693.951648] EFER = 0x0000000000000d01  PAT = 0x0407050600070106
+kernel: [228693.951655] *** Control State ***
+kernel: [228693.951662] CPUBased=0xb5a06dfa SecondaryExec=0x00032ff2 TertiaryExec=0x0000000000000000
+kernel: [228693.951671] PinBased=0x000000ff EntryControls=0000d1ff ExitControls=002befff
+kernel: [228693.951679] ExceptionBitmap=00060042 PFECmask=00000000 PFECmatch=00000000
+kernel: [228693.951686] VMEntry: intr_info=00000000 errcode=00000000 ilen=00000000
+kernel: [228693.951695] VMExit: intr_info=00000000 errcode=00000000 ilen=00000000
+kernel: [228693.951702]         reason=80000021 qualification=0000000000000000
+kernel: [228693.951709] IDTVectoring: info=00000000 errcode=00000000
+kernel: [228693.951717] TSC Offset = 0xfffe2c437c9ab552
+kernel: [228693.951724] SVI|RVI = 00|b1 TPR Threshold = 0x00
+kernel: [228693.951734] virt-APIC addr = 0x00000002a3014000
+kernel: [228693.951736] PostedIntrVec = 0xf2
+kernel: [228693.951743] EPT pointer = 0x000000012dfe705e
+kernel: [228693.951749] PLE Gap=00000080 Window=00001000
+kernel: [228693.951755] Virtual processor ID = 0x0009
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1576 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1576
new file mode 100644
index 00000000..b3f95474
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1576
@@ -0,0 +1,28 @@
+Migration from v8.0.0-rc2 to v7.2.0 with pcie-root-port device fails
+Description of problem:
+Loading the VM state fails with:
+```
+qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10a read: 40 device: 0 cmask: ff wmask: 0 w1cmask:0
+qemu-system-x86_64: Failed to load PCIDevice:config
+qemu-system-x86_64: Failed to load pcie-root-port:parent_obj.parent_obj.parent_obj
+qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:1c.0/pcie-root-port'
+qemu-system-x86_64: Error -22 while loading VM state
+```
+Steps to reproduce:
+Used the following script with the first argument being a build directory of v8.0.0-rc2 and the second a build directory of v7.2.0
+```
+#!/bin/bash
+rm /tmp/disk.qcow2
+args="
+  -device pcie-root-port,multifunction=on,bus=pcie.0,addr=1c.0,port=1,chassis=1
+  -machine type=pc-q35-7.2"
+$1/qemu-img create -f qcow2 /tmp/disk.qcow2 1G
+$1/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args <<EOF
+{"execute": "qmp_capabilities"}
+{"execute": "snapshot-save", "arguments": { "job-id": "save0", "tag": "snap", "vmstate": "node0", "devices": ["node0"] } }
+{"execute": "quit"}
+EOF
+$2/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args -loadvm snap
+```
+Additional information:
+Bisecting shows that 010746ae1d ("hw/pci/aer: Implement PCI_ERR_UNCOR_MASK register") is the first bad commit.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1577 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1577
new file mode 100644
index 00000000..f2460908
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1577
@@ -0,0 +1,84 @@
+device_del return is already in the process of unplug frequently
+Description of problem:
+recently we update qemu 6.1.1 to qemu 7.1.0, and run into an issue with the following error:
+
+command '{ "execute": "device_del", "arguments": { "id": "virtio-diskX" } }' for VM "id" failed ({ "return": {"class": "GenericError", "desc": "Device virtio-diskX is already in the process of unplug"} }).
+
+The issue is reproducible. With a few seconds delay before hot-unplug, hot-unplug just works fine.
+
+After a few digging, we found that the commit 9323f892b39 may incur the issue.
+------------------ 
+    failover: fix unplug pending detection
+   
+    Failover needs to detect the end of the PCI unplug to start migration
+    after the VFIO card has been unplugged.
+   
+    To do that, a flag is set in pcie_cap_slot_unplug_request_cb() and reset in
+    pcie_unplug_device().
+   
+    But since
+        17858a169508 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35")
+    we have switched to ACPI unplug and these functions are not called anymore
+    and the flag not set. So failover migration is not able to detect if card
+    is really unplugged and acts as it's done as soon as it's started. So it
+    doesn't wait the end of the unplug to start the migration. We don't see any
+    problem when we test that because ACPI unplug is faster than PCIe native
+    hotplug and when the migration really starts the unplug operation is
+    already done.
+   
+    See c000a9bd06ea ("pci: mark device having guest unplug request pending")
+        a99c4da9fc2a ("pci: mark devices partially unplugged")
+   
+    Signed-off-by: Laurent Vivier <lvivier@redhat.com>
+    Reviewed-by: Ani Sinha <ani@anisinha.ca>
+    Message-Id: <20211118133225.324937-4-lvivier@redhat.com>
+    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
+    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+------------------  
+The purpose is for detecting the end of the PCI device hot-unplug. However, we feel the error confusing. How is it possible that a disk "is already in the process of unplug" during the first hot-unplug attempt? So far as I know, the issue was also encountered by libvirt, but they simply ignored it:
+
+    https://bugzilla.redhat.com/show_bug.cgi?id=1878659
+   
+Hence, a question is: should we have the line below in  acpi_pcihp_device_unplug_request_cb()?
+
+   pdev->qdev.pending_deleted_event = true;
+   
+It would be great if you as the author could give us a few hints.
+
+Thank you very much for your reply!
+
+Sincerely,
+
+Yu Zhang @ Compute Platform IONOS
+
+
+The issue is reproducible in our own stack, which is not quite easy to describe in a few command lines. We simplified it a bit by a script instead. Although it's not able to reproduce, it could be somewhat helpful to understand the issue.
+ 
+```
+#!/bin/bash
+
+HOME=~
+QEMU=$HOME/qemu/bin/qemu-system-x86_64
+DISK1=$HOME/img/disk1.qcow2
+DISK4=$HOME/img/disk4.qcow2
+DISK5=$HOME/img/disk5.qcow2
+
+$QEMU \
+  -cpu host -enable-kvm -m 2048 -smp 2 \
+  -object iothread,id=iothread1 \
+  -drive file=$DISK1,if=none,id=drive-virtio-disk1,format=qcow2,snapshot=off,discard=on,cache=none \
+  -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk1,iothread=iothread1,num-queues=1,discard=on,id=virtio-disk1 \
+  -object iothread,id=iothread4 \
+  -drive file=$DISK4,if=none,id=drive-virtio-disk4,format=qcow2,snapshot=off,discard=on,cache=none \
+  -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk4,iothread=iothread4,num-queues=1,discard=on,id=virtio-disk4 \
+  -object iothread,id=iothread5 \
+  -drive file=$DISK5,if=none,id=drive-virtio-disk5,format=qcow2,snapshot=off,discard=on,cache=none \
+  -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk5,iothread=iothread5,num-queues=1,discard=on,id=virtio-disk5 \
+  -qmp unix:./qmp-sock,server,nowait &
+
+sleep 5
+
+echo '{"execute":"qmp_capabilities"}{"execute": "device_del","arguments": { "id": "virtio-disk5"}}{"execute": "query-block"}' | nc -U -w 1 ./qmp-sock
+echo '{"execute":"qmp_capabilities"}{"execute": "device_del","arguments": { "id": "virtio-disk5"}}{"execute": "query-block"}' | nc -U -w 1 ./qmp-sock```
+Additional information:
+Possible workaround: https://lore.kernel.org/qemu-devel/20230403131833-mutt-send-email-mst@kernel.org/T/#t
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1578 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1578
new file mode 100644
index 00000000..cd5a9640
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1578
@@ -0,0 +1,3 @@
+Send all the SVQ control commands in parallel instead of serialized
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1579 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1579
new file mode 100644
index 00000000..56adc47b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1579
@@ -0,0 +1,4 @@
+Cache vdpa initialization & startup slow ioctls
+Additional information:
+* vring groups are cached in this patch, still not upstream [this example patch](https://lists.nongnu.org/archive/html/qemu-devel/2023-03/msg05961.html).
+* hw/virtio/vhost-vdpa.c and net/vhost-vdpa.c are both files that worth exploring.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/158 b/gitlab/issues_text/target_missing/host_missing/accel_missing/158
new file mode 100644
index 00000000..a245b6bc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/158
@@ -0,0 +1 @@
+qemu system emulator crashed when using xhci usb controller
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1580 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1580
new file mode 100644
index 00000000..19a7741f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1580
@@ -0,0 +1,44 @@
+QEMU crashes when running inside Hyper-V VM on AMD EPYC
+Description of problem:
+Starting the VM very rarely succeeds and often it crashes with:
+```
+# qemu-system-x86_64 -cpu EPYC -machine accel=kvm -smp 1 -m 512 -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=OVMF_VARS.fd -drive file=debian-11-nocloud-amd64-20230124-1270.qcow2,format=qcow2 -snapshot -monitor none
+qemu: module ui-ui-gtk not found, do you want to install qemu-system-gui package?
+qemu: module ui-ui-sdl not found, do you want to install qemu-system-gui package?
+VNC server running on ::1:5900
+KVM internal error. Suberror: 1
+extra data[0]: 0x0000000000000001
+extra data[1]: 0x96d0cff2bed0cf0f
+extra data[2]: 0x0bfd29af72b35c7c
+extra data[3]: 0x0000000000000400
+extra data[4]: 0x0000000100000004
+extra data[5]: 0x00000000581c356c
+extra data[6]: 0x0000000000000000
+extra data[7]: 0x0000000000000000
+emulation failure
+EAX=fffd26a4 EBX=00000000 ECX=00000000 EDX=b731cdad
+ESI=00000101 EDI=00005042 EBP=fffcc000 ESP=581c3564
+EIP=fffff8a8 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0008 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
+CS =0010 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
+SS =0008 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
+DS =0008 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
+FS =0008 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
+GS =0008 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
+LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
+TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
+GDT=     fffffee0 00000027
+IDT=     00000000 00000000
+CR0=40000033 CR2=00000000 CR3=00800000 CR4=00000660
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000100
+Code=00 0f 20 e0 0f ba e8 05 0f 22 e0 31 db e9 13 02 00 00 85 c0 <75> 38 b9 80 00 00 c0 0f 32 0f ba e8 08 0f 30 31 db b9 01 00 00 00 0f a3 0d 04 b0 80 00 74
+```
+Steps to reproduce:
+1. Create a [Standard_D8ads_v5 VM](https://learn.microsoft.com/en-us/azure/virtual-machines/dasv5-dadsv5-series) (AMD EPYC 7763 64-Core Processor) in Azure with Debian 11
+2. Install `qemu-system-x86` (1:7.2+dfsg-5~bpo11+1) from `bullseye-backports`
+3. Install `ovmf` (2022.11-6) from `bookworm` (testing)
+4. Run the commands under "QEMU command line"
+Additional information:
+VNC displays "Guest has not initialized the display (yet)". The setup works perfectly on a [Standard_D8ds_v5 VM](https://learn.microsoft.com/en-us/azure/virtual-machines/ddv5-ddsv5-series) (Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80GHz).
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1582 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1582
new file mode 100644
index 00000000..7bc657c1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1582
@@ -0,0 +1 @@
+Floating-point-exception in rtl8139_cplus_transmit_one
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1583 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1583
new file mode 100644
index 00000000..ab661fa2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1583
@@ -0,0 +1,19 @@
+SGX Device mapping is not listed into QEMU KVM
+Description of problem:
+I want to run SGX into QEMU VM, the vm is up and running but SGX device mappings are not listed there. I also looked in dmesg | grep sgx and it returned "There are zero epc section"
+
+I have upgraded the libvirt to 8.6.0 because of below issue
+https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1982896
+
+I tried with libvirt-8.0.0 but it did not help
+
+I have attached the xml, please let me know why sgx mappings are not showing inside VM
+Steps to reproduce:
+1. Create a Ubuntu 20.04 VM with SGX mapping
+Additional information:
+Please let me know if any other logs are required
+
+
+
+
+[ubuntu20.04.xml](/uploads/2609abc31db08e04cc3e3dbf923cd8d7/ubuntu20.04.xml)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1584 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1584
new file mode 100644
index 00000000..f8eb439d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1584
@@ -0,0 +1 @@
+TCP Previous segment not captured
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1585 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1585
new file mode 100644
index 00000000..933a2087
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1585
@@ -0,0 +1,27 @@
+Incorrect VGA text mode rendering
+Description of problem:
+All of my physical machines use black as `DarkGray` and have the text starting from `White+DarkGray` blink (watch the video below). The ISO I'm using is a minimal kernel I've written to check VGA text mode (provided by the BIOS at `0xb8000` with a 80x25 resolution) handling on multiple emulators and machines.
+Changing the emulated CPU and display driver doesn't change this behaviour.
+
+Hyper-V: color test shows correct colors, all text starting from `White+DarkGray` is blinking
+
+![Hyper-V](/uploads/0d6e9a2398d0f5aeca94e6fbbc31e055/image.png)
+
+AMD Athlon 64 X2 6000+ + NVIDIA Quadro 400 on actual hardware: same as Hyper-V
+I've tested this with multiple physical GPUs and they all have the same behaviour and color palette.
+
+![AMD Athlon 64 X2 6000+ + NVIDIA Quadro 400](/uploads/883484cea78f8d598634ebab3645341c/image.png)
+
+QEMU: dark gray is the wrong color and the text doesn't blink
+Changing the emulated device doesn't change this behaviour.
+
+![QEMU](/uploads/cf1e6a1e7e8bcfc48b60bd92d9024de5/image.png)
+
+I think QEMU should emulate the hardware as close as possible and therefore atleast have the blinking text.
+Consider this a low priority issue.
+Steps to reproduce:
+1. Download ISO from the link above
+2. Run the QEMU command above
+3. See the text not blink
+Additional information:
+![Demo of various machines](/uploads/9de70ecd2185bdb57b3ee324fe18dcd9/2023-04-08_04-56-05.mp4)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1586 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1586
new file mode 100644
index 00000000..b82fb239
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1586
@@ -0,0 +1,107 @@
+qemu-8.0.0-rc3 mock build test stage failures
+Description of problem:
+https://bugzilla.redhat.com/show_bug.cgi?id=2185288  
+Following files have been attached to that report  
+Attached :  
+- The rpmuild SPEC file so far (qemu.spec.20230408.v3.txt)
+- testlog.20230408.v3.txt
+- build.log.20230408.v3.txt
+- hw_info.log.20230408.v3.txt
+- installed_pkgs.log.20230408.v3.txt
+- root.log.20230408.v3.txt
+- state.log.20230408.v3.txt
+
+A number of test failure involving allwinner-i2c and pci_expander_bridge 
+
+```
+Summary of Failures:
+
+ 39/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/test-hmp                         ERROR          32.55s   killed by signal 6 SIGABRT
+ 41/817 qemu:qtest+qtest-arm / qtest-arm/test-hmp                                 ERROR          34.48s   killed by signal 6 SIGABRT
+  1/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/qom-test                         ERROR          210.93s   killed by signal 6 SIGABRT
+  3/817 qemu:qtest+qtest-arm / qtest-arm/qom-test                                 ERROR          212.50s   killed by signal 6 SIGABRT
+ 45/817 qemu:qtest+qtest-i386 / qtest-i386/bios-tables-test                       ERROR          272.50s   killed by signal 6 SIGABRT
+ 68/817 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test                   ERROR          286.06s   killed by signal 6 SIGABRT
+230/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/device-introspect-test           ERROR           8.92s   killed by signal 6 SIGABRT
+270/817 qemu:qtest+qtest-arm / qtest-arm/device-introspect-test                   ERROR           5.95s   killed by signal 6 SIGABRT
+337/817 qemu:qtest+qtest-i386 / qtest-i386/cxl-test                               ERROR           0.90s   killed by signal 6 SIGABRT
+630/817 qemu:qtest+qtest-x86_64 / qtest-x86_64/cxl-test                           ERROR           0.84s   killed by signal 6 SIGABRT
+
+Ok:                 737 
+Expected Fail:      0   
+Fail:               10  
+Unexpected Pass:    0   
+Skipped:            70  
+Timeout:            0   
+
+```
+
+The below includes a last line of log snippet for each failure
+```
+
+ 39/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/test-hmp                         ERROR          32.55s   killed by signal 6 SIGABRT
+ /builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x7fec734903a0 is not an instance of type allwinner.i2c
+Broken pipe
+../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
+
+
+ 41/817 qemu:qtest+qtest-arm / qtest-arm/test-hmp                                 ERROR          34.48s   killed by signal 6 SIGABRT
+/builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x55e683992440 is not an instance of type allwinner.i2c
+Broken pipe
+../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
+
+
+  1/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/qom-test                         ERROR          210.93s   killed by signal 6 SIGABRT
+/builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x7fbddaf123a0 is not an instance of type allwinner.i2c
+Broken pipe
+../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
+
+
+  3/817 qemu:qtest+qtest-arm / qtest-arm/qom-test                                 ERROR          212.50s   killed by signal 6 SIGABRT
+/builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x55c346ae4440 is not an instance of type allwinner.i2c
+Broken pipe
+../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
+
+45/817 qemu:qtest+qtest-i386 / qtest-i386/bios-tables-test                       ERROR          272.50s   killed by signal 6 SIGABRT
+../hw/pci-bridge/pci_expander_bridge.c:54:PXB_DEV: Object 0x5636d9f16fa0 is not an instance of type pxb
+Broken pipe
+../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
+
+
+68/817 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test                   ERROR          286.06s   killed by signal 6 SIGABRT
+../hw/pci-bridge/pci_expander_bridge.c:54:PXB_DEV: Object 0x55e0736d8e20 is not an instance of type pxb
+Broken pipe
+../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
+
+230/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/device-introspect-test           ERROR           8.92s   killed by signal 6 SIGABRT
+/builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x55ab62324420 is not an instance of type allwinner.i2c
+Broken pipe
+../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
+
+
+270/817 qemu:qtest+qtest-arm / qtest-arm/device-introspect-test                   ERROR           5.95s   killed by signal 6 SIGABRT
+----------------------------------- stderr -----------------------------------
+/builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x564fbf62ee90 is not an instance of type allwinner.i2c
+Broken pipe
+../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
+
+
+
+337/817 qemu:qtest+qtest-i386 / qtest-i386/cxl-test                               ERROR           0.90s   killed by signal 6 SIGABRT
+../hw/pci-bridge/pci_expander_bridge.c:54:PXB_DEV: Object 0x55c66482d5f0 is not an instance of type pxb
+Broken pipe
+../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
+
+630/817 qemu:qtest+qtest-x86_64 / qtest-x86_64/cxl-test                           ERROR           0.84s   killed by signal 6 SIGABRT
+../hw/pci-bridge/pci_expander_bridge.c:54:PXB_DEV: Object 0x5634e6278170 is not an instance of type pxb
+Broken pipe
+../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
+```
+Steps to reproduce:
+1. Populate rpmbuild folders with ```rpm -i qemu-7.2.0-7.fc39.srpm``` from https://koji.fedoraproject.org/koji/packageinfo?packageID=3685 
+2. Download to ```~/rpmbuild/SOURCES/qemu-8.0.0.tar.xz``` from ```https://download.qemu.org/qemu-8.0.0-rc3.tar.xz```
+3. craft ```~/SPECS/qemu.spec``` for qemu-8.0.0-rc3 (or download attachment of bugzilla bug)
+4. recreate new qemu-8.0.0 srpm ```rpmbuild -bs SPECS/qemu.spec```
+5. run ```mock -r /etc/mock/fedora-38-x86_64.cfg --rebuild ~/rpmbuild/SRPMS/qemu-8.0.0-0.fc38.src.rpm```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1588 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1588
new file mode 100644
index 00000000..7a93f413
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1588
@@ -0,0 +1,169 @@
+virsh backup-begin crashes guest - qcow2_get_specific_info: Assertion `false' failed.
+Description of problem:
+I run a daily backup job of around 350 guests, scattered on different host machines. 
+
+Each day around 1-2 guests crashes on virsh backup-begin with the following error in /var/log/libvirt/qemu/$GUEST.log:
+
+```qemu-system-x86_64: ../../block/qcow2.c:5175: qcow2_get_specific_info: Assertion `false' failed.``` (https://github.com/qemu/qemu/blob/0c8022876f2183f93e23a7314862140c94ee62e7/block/qcow2.c)
+
+Different guests every day, no patterns what I can see.
+
+I'm using a top and a base image with incremental backups, qcow2 compat 1.1, output of qemu-img info of the base and top image;
+
+```
+qemu-img info base.qcow2
+image: base.qcow2
+file format: qcow2
+virtual size: 5 GiB (5368709120 bytes)
+disk size: 1.9 GiB
+cluster_size: 65536
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: false
+    refcount bits: 16
+    corrupt: false
+    extended l2: false
+
+qemu-img info -U top.qcow2
+image: top.qcow2
+file format: qcow2
+virtual size: 60 GiB (64424509440 bytes)
+disk size: 1.36 GiB
+cluster_size: 65536
+backing file: base.qcow2
+backing file format: qcow2
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: false
+    bitmaps:
+        [0]:
+            flags:
+                [0]: in-use
+                [1]: auto
+            name: 1680670811
+            granularity: 65536
+    refcount bits: 16
+    corrupt: false
+    extended l2: false 
+```
+
+I know I'm not be using the latest qemu and that this is difficult to reproduce. This bug happens in production and upgrading qemu would be a huge task, given that I would have to upgrade the entire production. Nevertheless I of course would be willing to do it if deemed necessary but at this point I'm just looking for directions on how to pin point this bug.
+
+A "guest-1" grepped version of libvirt debug logs during the seconds this happened:
+
+```
+2023-04-08 20:37:20.453+0000: 431153: debug : virDomainLookupByName:413 : conn=0x7fbff000ca30, name=guest-1
+2023-04-08 20:37:20.453+0000: 431153: debug : virDomainDispose:348 : release domain 0x7fc068021c60 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f
+2023-04-08 20:37:20.454+0000: 431155: debug : virDomainGetState:2493 : dom=0x7fc068024330, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), state=0x7fc08c052cf0, reason=0x7fc08c052cf4, flags=0x0
+2023-04-08 20:37:20.454+0000: 431155: debug : virDomainDispose:348 : release domain 0x7fc068024330 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f
+2023-04-08 20:37:20.483+0000: 431152: debug : virDomainLookupByName:413 : conn=0x7fc070014e90, name=guest-1
+2023-04-08 20:37:20.483+0000: 431152: debug : virDomainDispose:348 : release domain 0x7fc0500075f0 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f
+2023-04-08 20:37:20.483+0000: 431148: debug : virDomainListAllCheckpoints:292 : dom=0x7fc0ac002380, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), checkpoints=0x7fc0b79018a8, flags=0x0
+2023-04-08 20:37:20.483+0000: 431148: debug : virDomainDispose:348 : release domain 0x7fc0ac002380 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f
+2023-04-08 20:37:20.484+0000: 431151: debug : virDomainDispose:348 : release domain 0x7fc0b0006950 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f
+2023-04-08 20:37:20.516+0000: 431150: debug : virDomainLookupByName:413 : conn=0x7fc0a80027a0, name=guest-1
+2023-04-08 20:37:20.516+0000: 431150: debug : virDomainDispose:348 : release domain 0x7fc08c007c60 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f
+2023-04-08 20:37:20.516+0000: 431152: debug : virDomainGetState:2493 : dom=0x7fc068021e90, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), state=0x7fc0a47c64d0, reason=0x7fc0a47c64d4, flags=0x0
+2023-04-08 20:37:20.516+0000: 431152: debug : virDomainDispose:348 : release domain 0x7fc068021e90 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f
+2023-04-08 20:37:20.544+0000: 431156: debug : virDomainLookupByName:413 : conn=0x7fc0a80025a0, name=guest-1
+2023-04-08 20:37:20.544+0000: 431156: debug : virDomainDispose:348 : release domain 0x7fc068029d00 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f
+2023-04-08 20:37:20.544+0000: 431149: debug : virDomainSuspend:623 : dom=0x7fc050007500, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f)
+2023-04-08 20:37:20.544+0000: 431149: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=suspend agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=none)
+2023-04-08 20:37:20.544+0000: 431149: debug : qemuDomainObjBeginJobInternal:883 : Started job: suspend (async=none vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.544+0000: 431149: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.580+0000: 1882669: debug : qemuProcessHandleStop:660 : Transitioned guest guest-1 to paused state, reason user, event detail 0
+2023-04-08 20:37:20.580+0000: 1882669: debug : virLockManagerLogParams:90 :   key=name type=string value=guest-1
+2023-04-08 20:37:20.580+0000: 1882669: debug : virDomainLockManagerAddImage:90 : Add disk /home/vm/domains/guest-1/disk.qcow2
+2023-04-08 20:37:20.580+0000: 1882669: debug : virLockManagerAddResource:325 : lock=0x7fbf8801fdc0 type=0 name=/home/vm/domains/guest-1/disk.qcow2 nparams=0 params=(nil) flags=0x0
+2023-04-08 20:37:20.581+0000: 431149: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.581+0000: 431149: debug : virLockManagerLogParams:90 :   key=name type=string value=guest-1
+2023-04-08 20:37:20.581+0000: 431149: debug : virDomainLockManagerAddImage:90 : Add disk /home/vm/domains/guest-1/disk.qcow2
+2023-04-08 20:37:20.581+0000: 431149: debug : virLockManagerAddResource:325 : lock=0x7fc0a8968e60 type=0 name=/home/vm/domains/guest-1/disk.qcow2 nparams=0 params=(nil) flags=0x0
+2023-04-08 20:37:20.582+0000: 431149: debug : qemuDomainObjEndJob:1135 : Stopping job: suspend (async=none vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.582+0000: 431149: debug : virDomainDispose:348 : release domain 0x7fc050007500 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f
+2023-04-08 20:37:20.608+0000: 431148: debug : virDomainLookupByName:413 : conn=0x7fbff000cc30, name=guest-1
+2023-04-08 20:37:20.608+0000: 431148: debug : virDomainDispose:348 : release domain 0x7fc07001e330 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f
+2023-04-08 20:37:20.608+0000: 431151: debug : virDomainGetState:2493 : dom=0x7fc050007550, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), state=0x7fc0a003d640, reason=0x7fc0a003d644, flags=0x0
+2023-04-08 20:37:20.608+0000: 431151: debug : virDomainDispose:348 : release domain 0x7fc050007550 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f
+2023-04-08 20:37:20.634+0000: 431150: debug : virDomainLookupByName:413 : conn=0x7fc0a8002ea0, name=guest-1
+2023-04-08 20:37:20.634+0000: 431150: debug : virDomainDispose:348 : release domain 0x7fbfc00072e0 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f
+2023-04-08 20:37:20.634+0000: 431152: debug : virDomainBackupBegin:13040 : dom=0x7fc0500075f0, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), backupXML=<domainbackup><incremental>1680930625</incremental></domainbackup>, checkpointXML=<domaincheckpoint><name>1680986240</name></domaincheckpoint>, flags=0x0
+2023-04-08 20:37:20.667+0000: 431152: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=none agentJob=none asyncJob=backup (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=none)
+2023-04-08 20:37:20.667+0000: 431152: debug : qemuDomainObjBeginJobInternal:892 : Started async job: backup (vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.668+0000: 431152: debug : virStringMatch:662 : match '/home/vm/domains/guest-1/qemu.agent' for '^/var/lib/libvirt/qemu/channel/target/([^/]+\.)|(domain-[^/]+/)org\.qemu\.guest_agent\.0$'
+2023-04-08 20:37:20.669+0000: 431152: debug : virStringMatch:662 : match '/home/vm/domains/guest-1/qemu.agent' for '^/var/lib/libvirt/qemu/channel/target/([^/]+\.)|(domain-[^/]+/)org\.qemu\.guest_agent\.0$'
+2023-04-08 20:37:20.670+0000: 431152: debug : virStringMatch:662 : match '/home/vm/domains/guest-1/qemu.agent' for '^/var/lib/libvirt/qemu/channel/target/([^/]+\.)|(domain-[^/]+/)org\.qemu\.guest_agent\.0$'
+2023-04-08 20:37:20.670+0000: 431152: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=async nested agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=backup)
+2023-04-08 20:37:20.670+0000: 431152: debug : qemuDomainObjBeginJobInternal:883 : Started job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.670+0000: 431152: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.671+0000: 1882669: debug : qemuMonitorJSONIOProcessLine:222 : Line [{"return": [{"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 32212254720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 7361290240, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-format", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "dirty-bitmaps": [{"name": "1680930625", "recording": true, "persistent": true, "busy": false, "granularity": 65536, "count": 458293248}], "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}, {"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 7882014720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "format": "file", "actual-size": 7361290240, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-storage", "backing_file_depth": 0, "drv": "file", "iops": 0, "bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}], "id": "libvirt-39597736"}]
+2023-04-08 20:37:20.671+0000: 1882669: debug : virJSONValueFromString:1691 : string={"return": [{"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 32212254720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 7361290240, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-format", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "dirty-bitmaps": [{"name": "1680930625", "recording": true, "persistent": true, "busy": false, "granularity": 65536, "count": 458293248}], "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}, {"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 7882014720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "format": "file", "actual-size": 7361290240, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-storage", "backing_file_depth": 0, "drv": "file", "iops": 0, "bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}], "id": "libvirt-39597736"}
+2023-04-08 20:37:20.672+0000: 1882669: info : qemuMonitorJSONIOProcessLine:241 : QEMU_MONITOR_RECV_REPLY: mon=0x7fc0480048b0 reply={"return": [{"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 32212254720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 7361290240, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-format", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "dirty-bitmaps": [{"name": "1680930625", "recording": true, "persistent": true, "busy": false, "granularity": 65536, "count": 458293248}], "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}, {"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 7882014720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "format": "file", "actual-size": 7361290240, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-storage", "backing_file_depth": 0, "drv": "file", "iops": 0, "bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}], "id": "libvirt-39597736"}
+2023-04-08 20:37:20.672+0000: 431152: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.672+0000: 431152: debug : qemuDomainObjEndJob:1135 : Stopping job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.672+0000: 431152: debug : virStorageFileBackendFileInit:57 : initializing FS storage file 0x7fc0704b3740 (file:/home/vm/domains/guest-1/disk.qcow2.1680986240)[64055:108]
+2023-04-08 20:37:20.672+0000: 431152: debug : qemuDomainStorageSourceAccessModify:7767 : src='/home/vm/domains/guest-1/disk.qcow2.1680986240' readonly=0 force_ro=0 force_rw=1 revoke=0 chain=0
+2023-04-08 20:37:20.672+0000: 431152: debug : virLockManagerLogParams:90 :   key=name type=string value=guest-1
+2023-04-08 20:37:20.672+0000: 431152: debug : virDomainLockManagerAddImage:90 : Add disk /home/vm/domains/guest-1/disk.qcow2.1680986240
+2023-04-08 20:37:20.672+0000: 431152: debug : virLockManagerAddResource:325 : lock=0x7fc0a460ca40 type=0 name=/home/vm/domains/guest-1/disk.qcow2.1680986240 nparams=0 params=(nil) flags=0x0
+2023-04-08 20:37:20.683+0000: 431152: debug : virCommandRunAsync:2630 : About to run LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -r -u libvirt-29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f -F /home/vm/domains/guest-1/disk.qcow2.1680986240
+2023-04-08 20:37:20.796+0000: 431151: debug : virDomainLookupByName:413 : conn=0x7fc0a80020a0, name=guest-1
+2023-04-08 20:37:20.893+0000: 431152: debug : qemuSetupImagePathCgroup:74 : Allow path /home/vm/domains/guest-1/disk.qcow2.1680986240, perms: rw
+2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=async nested agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=backup)
+2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjBeginJobInternal:883 : Started job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjEndJob:1135 : Stopping job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=async nested agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=backup)
+2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjBeginJobInternal:883 : Started job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.894+0000: 431151: debug : virDomainDispose:348 : release domain 0x7fc014007240 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f
+2023-04-08 20:37:20.894+0000: 431152: info : qemuMonitorSend:914 : QEMU_MONITOR_SEND_MSG: mon=0x7fc0480048b0 msg={"execute":"blockdev-add","arguments":{"driver":"file","filename":"/home/vm/domains/guest-1/disk.qcow2.1680986240","node-name":"libvirt-78-storage","auto-read-only":true,"discard":"unmap"},"id":"libvirt-39597737"}
+2023-04-08 20:37:20.894+0000: 1882669: info : qemuMonitorIOWrite:402 : QEMU_MONITOR_IO_WRITE: mon=0x7fc0480048b0 buf={"execute":"blockdev-add","arguments":{"driver":"file","filename":"/home/vm/domains/guest-1/disk.qcow2.1680986240","node-name":"libvirt-78-storage","auto-read-only":true,"discard":"unmap"},"id":"libvirt-39597737"}
+2023-04-08 20:37:20.895+0000: 1385058: debug : virDomainGetInfo:2444 : dom=0x7fc0ac001b80, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), info=0x7fc009ffa880
+2023-04-08 20:37:20.895+0000: 1385058: debug : virDomainDispose:348 : release domain 0x7fc0ac001b80 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f
+2023-04-08 20:37:20.895+0000: 431149: debug : virDomainGetBlockInfo:6284 : dom=0x7fc068024100, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), info=0x7fc0b7100890, flags=0x0
+2023-04-08 20:37:20.895+0000: 431149: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=query agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=async nested agentJob=none async=backup)
+2023-04-08 20:37:20.895+0000: 431149: debug : qemuDomainObjBeginJobInternal:867 : Waiting for job (vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.895+0000: 431152: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.895+0000: 431152: debug : qemuDomainObjEndJob:1135 : Stopping job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.896+0000: 431152: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=async nested agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=backup)
+2023-04-08 20:37:20.896+0000: 431152: debug : qemuDomainObjBeginJobInternal:883 : Started job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.896+0000: 431152: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.896+0000: 431149: debug : qemuDomainObjBeginJobInternal:867 : Waiting for job (vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.896+0000: 431152: info : qemuMonitorSend:914 : QEMU_MONITOR_SEND_MSG: mon=0x7fc0480048b0 msg={"execute":"blockdev-create","arguments":{"job-id":"create-libvirt-78-format","options":{"driver":"qcow2","file":"libvirt-78-storage","size":32212254720,"cluster-size":65536,"backing-file":"/home/vm/domains/guest-1/disk.qcow2","backing-fmt":"qcow2"}},"id":"libvirt-39597738"}
+2023-04-08 20:37:20.896+0000: 1882669: info : qemuMonitorIOWrite:402 : QEMU_MONITOR_IO_WRITE: mon=0x7fc0480048b0 buf={"execute":"blockdev-create","arguments":{"job-id":"create-libvirt-78-format","options":{"driver":"qcow2","file":"libvirt-78-storage","size":32212254720,"cluster-size":65536,"backing-file":"/home/vm/domains/guest-1/disk.qcow2","backing-fmt":"qcow2"}},"id":"libvirt-39597738"}
+2023-04-08 20:37:20.898+0000: 1882669: debug : qemuProcessHandleJobStatusChange:956 : job 'create-libvirt-78-format'(domain: 0x7fc0a4033a10,guest-1) state changed to 'created'(1)
+2023-04-08 20:37:20.898+0000: 1882669: debug : qemuProcessHandleJobStatusChange:956 : job 'create-libvirt-78-format'(domain: 0x7fc0a4033a10,guest-1) state changed to 'running'(2)
+2023-04-08 20:37:20.898+0000: 431152: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.898+0000: 431152: debug : qemuDomainObjEndJob:1135 : Stopping job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.899+0000: 431149: debug : qemuDomainObjBeginJobInternal:883 : Started job: query (async=backup vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:20.899+0000: 431149: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:21.432+0000: 1882669: debug : qemuProcessHandleAgentEOF:147 : Received EOF from agent on 0x7fc0a4033a10 'guest-1'
+2023-04-08 20:37:21.432+0000: 1882669: debug : qemuMonitorIO:576 : Error on monitor Unable to read from monitor: Connection reset by peer mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1
+2023-04-08 20:37:21.432+0000: 1882669: debug : qemuMonitorIO:609 : Triggering error callback mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1
+2023-04-08 20:37:21.432+0000: 1882669: debug : qemuProcessHandleMonitorError:355 : Received error on 0x7fc0a4033a10 'guest-1'
+2023-04-08 20:37:21.432+0000: 431149: debug : qemuMonitorSend:927 : Send command resulted in error Unable to read from monitor: Connection reset by peer mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1
+2023-04-08 20:37:21.433+0000: 431149: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:21.433+0000: 1882669: debug : qemuMonitorIO:576 : Error on monitor Unable to read from monitor: Connection reset by peer mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1
+2023-04-08 20:37:21.433+0000: 431149: debug : qemuDomainObjEndJob:1135 : Stopping job: query (async=backup vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:21.433+0000: 1882669: debug : qemuMonitorIO:598 : Triggering EOF callback mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1
+2023-04-08 20:37:21.433+0000: 1882669: debug : qemuProcessHandleMonitorEOF:310 : Received EOF on 0x7fc0a4033a10 'guest-1'
+2023-04-08 20:37:21.433+0000: 431149: debug : virDomainDispose:348 : release domain 0x7fc068024100 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f
+2023-04-08 20:37:21.433+0000: 620333: debug : qemuProcessKill:7931 : vm=0x7fc0a4033a10 name=guest-1 pid=1882665 flags=0x1
+2023-04-08 20:37:21.633+0000: 620333: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=destroy agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=backup)
+2023-04-08 20:37:21.633+0000: 620333: debug : qemuDomainObjBeginJobInternal:883 : Started job: destroy (async=backup vm=0x7fc0a4033a10 name=guest-1)
+2023-04-08 20:37:21.634+0000: 620333: debug : processMonitorEOFEvent:4025 : Monitor connection to 'guest-1' closed without SHUTDOWN event; assuming the domain crashed
+2023-04-08 20:37:21.634+0000: 620333: debug : qemuProcessStop:8014 : Shutting down vm=0x7fc0a4033a10 name=guest-1 id=814 pid=1882665, reason=crashed, asyncJob=none, flags=0x0
+2023-04-08 20:37:21.634+0000: 620333: debug : qemuDomainLogAppendMessage:6740 : Append log message (vm='guest-1' message='2023-04-08 20:37:21.634+0000: shutting down, reason=crashed
+2023-04-08 20:37:22.617+0000: 620333: debug : qemuProcessKill:7931 : vm=0x7fc0a4033a10 name=guest-1 pid=1882665 flags=0x5
+2023-04-08 20:37:22.617+0000: 620333: debug : qemuDomainCleanupRun:7321 : driver=0x7fc07015c730, vm=guest-1
+2023-04-08 20:37:22.617+0000: 620333: debug : qemuProcessAutoDestroyRemove:8416 : vm=guest-1
+2023-04-08 20:37:22.617+0000: 620333: debug : virCloseCallbacksUnset:145 : vm=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f, cb=0x7fc09e3f9ba0
+```
+
+If you need any further information just let me know. As per request, ping @pipo.sk
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1589 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1589
new file mode 100644
index 00000000..d39ad2bb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1589
@@ -0,0 +1,10 @@
+Crash when using qemu 8.0.0 version tcg mode
+Description of problem:
+Can I no longer use qemu in tcg mode?
+When operating in tcg mode in all versions of 8.0.0, a crash occurs on the booting screen and the window closes (the window stops responding before closing).
+Steps to reproduce:
+1. Run qemu with -accel tcg option
+2. enter the boot screen
+3. The screen freezes and the window closes after a few seconds (at which point it becomes unresponsive)
+Additional information:
+I have not checked whether the same symptom occurs in Linux, and it occurs in all versions of 8.0.0 for Windows.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/159 b/gitlab/issues_text/target_missing/host_missing/accel_missing/159
new file mode 100644
index 00000000..da9bd8a6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/159
@@ -0,0 +1 @@
+qemu-nbd -l and -s options don't work together
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1590 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1590
new file mode 100644
index 00000000..7f2d881b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1590
@@ -0,0 +1,121 @@
+Regression: ARMv8M secure mode debugging non-functional since ~v7.2.0
+Description of problem:
+Prior to qemu commit 4a35855682cebb89f9630b07aa9fd37c4e8c733b, both semihosting printf calls and debugging via gdb work as expected. 
+
+Builds of qemu containing commit 4a35855682cebb89f9630b07aa9fd37c4e8c733b do not produce any semihosting output and are not debuggable via gdb.
+Steps to reproduce:
+1. Run ``qemu-system-arm -machine mps2-an505 -nographic -semihosting -kernel build/mps2_an505_cm33_blink_demo.elf`` with qemu v7.1.0, note the "blinking" print to the console once a second.
+2. Run ``qemu-system-arm -machine mps2-an505 -nographic -semihosting -kernel build/mps2_an505_cm33_blink_demo.elf`` with qemu v7.2.0, note that no messages are printed to the console.
+3. Run ``qemu-system-arm -machine mps2-an505 -nographic -semihosting -kernel build/mps2_an505_cm33_blink_demo.elf -S -s`` and attach gdb with the following gdbinit file.
+Additional information:
+Log of successful gdb session with the attached patch on top of qemu master branch:
+```
+% arm-none-eabi-gdb build/mps2_an505_cm33_blink_demo.elf
+GNU gdb (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 13.1.90.20230307-git
+Copyright (C) 2023 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+Type "show copying" and "show warranty" for details.
+This GDB was configured as "--host=x86_64-apple-darwin19.6.0 --target=arm-none-eabi".
+Type "show configuration" for configuration details.
+For bug reporting instructions, please see:
+<https://bugs.linaro.org/>.
+Find the GDB manual and other documentation resources online at:
+    <http://www.gnu.org/software/gdb/documentation/>.
+
+For help, type "help".
+Type "apropos word" to search for commands related to "word"...
+Reading symbols from build/mps2_an505_cm33_blink_demo.elf...
+The target architecture is set to "armv8-m.main".
+Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:172
+172     {
+Section .privileged_functions, range 0x10000000 -- 0x10008000: matched.
+Section .text, range 0x10008000 -- 0x10019c18: matched.
+Section .rodata, range 0x10019c18 -- 0x1001b270: matched.
+Section .ARM.exidx, range 0x1001b270 -- 0x1001b278: matched.
+Section .copy.table, range 0x1001b278 -- 0x1001b284: matched.
+Section .data, range 0x1001b28c -- 0x1001bb90: matched.
+Section .ram_vectors, range 0x1001bb90 -- 0x1001bdd0: matched.
+Section .zero.table, range 0x1001b284 -- 0x1001b28c: matched.
+Breakpoint 1 at 0x10009900: file /FreeRTOS/Demo/ARM_MPS/fault_handlers.c, line 494.
+(gdb) s
+174         asm volatile
+(gdb) s
+189         init_data_sections();
+(gdb) s
+init_data_sections () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:99
+99          for( pCopyTable = &__copy_table_start__; pCopyTable <= &__copy_table_end__; pCopyTable++ )
+(gdb) s
+101             for( dataIndex = 0; dataIndex < pCopyTable->uxLen; dataIndex++ )
+(gdb) info locals
+pCopyTable = 0x1001b278
+dataIndex = 0
+(gdb) print /x *0xE000ED08
+$1 = 0x10000000
+```
+
+Log of an unsuccessful gdb session with qemu v7.2.0
+```
+pbartell@147dda7342a9 ARM_MPS % arm-none-eabi-gdb build/mps2_an505_cm33_blink_demo.elf
+GNU gdb (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 13.1.90.20230307-git
+Copyright (C) 2023 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+Type "show copying" and "show warranty" for details.
+This GDB was configured as "--host=x86_64-apple-darwin19.6.0 --target=arm-none-eabi".
+Type "show configuration" for configuration details.
+For bug reporting instructions, please see:
+<https://bugs.linaro.org/>.
+Find the GDB manual and other documentation resources online at:
+    <http://www.gnu.org/software/gdb/documentation/>.
+
+For help, type "help".
+Type "apropos word" to search for commands related to "word"...
+Reading symbols from build/mps2_an505_cm33_blink_demo.elf...
+The target architecture is set to "armv8-m.main".
+Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:172
+172     {
+Section .privileged_functions, range 0x10000000 -- 0x10008000: MIS-MATCHED!
+Section .text, range 0x10008000 -- 0x10019c18: MIS-MATCHED!
+Section .rodata, range 0x10019c18 -- 0x1001b270: MIS-MATCHED!
+Section .ARM.exidx, range 0x1001b270 -- 0x1001b278: MIS-MATCHED!
+Section .copy.table, range 0x1001b278 -- 0x1001b284: MIS-MATCHED!
+Section .data, range 0x1001b28c -- 0x1001bb90: MIS-MATCHED!
+Section .ram_vectors, range 0x1001bb90 -- 0x1001bdd0: MIS-MATCHED!
+Section .zero.table, range 0x1001b284 -- 0x1001b28c: MIS-MATCHED!
+warning: One or more sections of the target image does not match
+the loaded file
+
+Breakpoint 1 at 0x10009900: file /FreeRTOS/FreeRTOS/Demo/ARM_MPS/fault_handlers.c, line 494.
+(gdb) s
+Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:174
+174         asm volatile
+(gdb) s
+Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:189
+189         init_data_sections();
+(gdb) s
+init_data_sections () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:95
+95      {
+(gdb) s
+init_data_sections () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:99
+99          for( pCopyTable = &__copy_table_start__; pCopyTable <= &__copy_table_end__; pCopyTable++ )
+(gdb) info locals
+pCopyTable = <error reading variable pCopyTable (Cannot access memory at address 0x381fffdc)>
+dataIndex = <error reading variable dataIndex (Cannot access memory at address 0x381fffd8)>
+(gdb) print /x *0xE000ED08
+$1 = 0x0
+(gdb) quit
+```
+
+.gdbinit file:
+```
+set architecture armv8-m.main
+target extended-remote :1234
+compare-sections
+break HardFault_Handler
+```
+
+[mps2_an505_cm33_blink_demo.elf](/uploads/c86e086b00651a8d5392857b9e4a2c4d/mps2_an505_cm33_blink_demo.elf)
+[target-arm-Fix-debugging-of-ARMv8M-Secure-code.patch](/uploads/5735d5f7d7b15dbbeb0c2d214a46c1a8/target-arm-Fix-debugging-of-ARMv8M-Secure-code.patch)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1593 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1593
new file mode 100644
index 00000000..dd64fce4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1593
@@ -0,0 +1,7 @@
+SLIRP hostfwd ignores bind address and uses `INADDR_ANY`
+Description of problem:
+When using `-netdev hostfwd=`..., qemu SLIRP uses `INADDR_ANY` instead of any bind address provided by the user. As a result, even if the user specifies to listen only on localhost (e.g. `-netdev user,hostfwd=tcp:127.0.0.1:22-:22`), qemu will listen on `*.*`. This is a potential security issue (as it may unexpectedly expose the guest to internet or local network traffic).
+Additional information:
+The bug is here: https://gitlab.com/qemu-project/qemu/-/blob/master/net/slirp.c#L777
+
+Rather than hardcoding `INADDR_ANY`, qemu should respect the user-defined bind address.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1594 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1594
new file mode 100644
index 00000000..24018dc2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1594
@@ -0,0 +1,21 @@
+Wrong cpu information is still received when using whpx acceleration.
+Description of problem:
+I received wrong information the other day and registered an issue, but now the latest version has not been fixed and is delivering the same wrong information.
+If not fixed, Windows Home version (Windows 11 Home version) cannot run more than 5 cores with whpx acceleration.
+(If you boot after setting more than 5 cores, an incorrect CPU parameter BSOD occurs during booting, and Windows 11 home version seems to allow up to 4 physical CPUs..)
+* Even if you explicitly give -smp cores=n,threads=1,sockets=1 and boot, it is ignored and recognized as a PC with n 1-core CPUs.
+Steps to reproduce:
+1. Run qemu with -accel whpx option
+2. Check CPU information after booting is complete
+3. Check the same CPU information after booting from a physical PC and other virtualization software (VMware, Virtual Box, etc.)
+4. It has been confirmed that the number of physical CPUs and the number of cores per CPU are different from other virtualization software or physical PCs. (For example, when setting 4 cores, it is recognized as 1CPU 4Core in other virtualization software, but as 4CPU 1Core in qemu operated with whpx acceleration)
+Additional information:
+* The CPU was set to 4 cores, and the image was taken as a screenshot of the information recognized as the 4th processor by Linux.
+> Linux CPU information booted from qemu (with whpx acceleration)
+execution statement : qemu-system-x86_64 -M q35 -smp cores=4,threads=1,sockets=1 -m 4g -display sdl -drive file=test.vdi,id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -accel whpx (or 'qemu-system-x86_64 -M q35 -smp 4 -m 4g -display sdl -drive file=test.vdi,id=disk,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -accel whpx')
+
+![qemu](/uploads/5704aa53278d6719a5a5d3f980b2577f/qemu.jpg)
+
+> Linux CPU information booted from other virtualization software (Virtual Box)
+
+![virtualbox](/uploads/71f9d86a41060a018d1242e0a7d3ee9f/virtualbox.jpg)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1595 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1595
new file mode 100644
index 00000000..24b2547b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1595
@@ -0,0 +1,29 @@
+CPU boot sometimes fails on big.LITTLE CPUs with varying cache sizes
+Description of problem:
+The RK3588 SoC has three core clusters; one with A55 cores, and the other two have A76 cores. The big cores have more L2 cache than the little cores, so the value of `CCSIDR` depends on the core that it is read from.
+
+In `write_list_to_kvmstate`, QEMU attempts to use `KVM_SET_ONE_REG` with an ID for `KVM_REG_ARM_DEMUX_ID_CCSIDR`, trying to set `CCSIDR` to a previously read value.
+
+Normally, that works fine, but if the host kernel has moved QEMU from one core cluster to the other, then the value will be different and `demux_c15_set` will return `EINVAL`, causing the entire `arm_set_cpu_on` to fail, and the guest kernel to print an error.
+
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kvm/sys_regs.c?h=v6.2#n2827
+
+I tried changing the condition for the `ok = false` line in `write_list_to_kvmstate` to `ret && r.id >> 8 != 0x60200000001100`. This causes all CPUs to initialize correctly in the guest, but obviously that's a hack.
+
+I assume that `CCSIDR` not being uniform across all CPUs means that the guest's copy of `CCSIDR` may be wrong, and so cache maintenance operations may not act on the entire cache. I do not know whether that could actually cause problems. Will QEMU need to find the maximum cache size across all CPUs and present that to guests?
+Steps to reproduce:
+On a SoC where big and little cores have different cache sizes (e.g. RK3588):
+
+```text
+$ qemu-system-aarch64 -M virt -accel kvm -cpu host -smp 4 -nographic -kernel arch/arm64/boot/Image -append quiet
+[    0.001399][    T1] psci: failed to boot CPU1 (-22)
+[    0.001407][    T1] CPU1: failed to boot: -22
+[    0.001685][    T1] psci: failed to boot CPU2 (-22)
+[    0.001691][    T1] CPU2: failed to boot: -22
+[    0.001809][    T1] psci: failed to boot CPU3 (-22)
+[    0.001814][    T1] CPU3: failed to boot: -22
+```
+
+The error is not always printed, because it depends on which core cluster the processes are scheduled on.
+
+Using `taskset -c 0-3` or `taskset -c 4-7` to force QEMU to stick to the little or big cores respectively makes the bug not reproduce.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1596 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1596
new file mode 100644
index 00000000..31c2c366
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1596
@@ -0,0 +1,20 @@
+VNC console with 4K resolutions is cut off on the right side and mouse coordinates are offset (or horizontal res greater than 2600-3000 pixels)
+Description of problem:
+For some reason when connecting to the VNC console of a QEMU VM, when you use a resolution that has its horizontal size of about 3000 pixels or more, it gets cut off by about 1/4 of the screen from the right, and the mouse position is offset by that value towards the left. See image for explanation:
+
+![QEMU_2023-04-12_12-18](/uploads/42311339ffb1048e5d4b5e45ce25e529/QEMU_2023-04-12_12-18.png)
+Steps to reproduce:
+1. Create a Fedora 37 VM
+2. Use `virtio-vga-gl` and `egl-headless`
+3. Set the resolution to 4K (3840x2160) or anything with the horizontal resolution greater than 3000 pixels
+4. Use Windows to connect to the VNC console. Issue happens with TightVNC Viewer and RealVNC Viewer
+Additional information:
+I also tried `-device virtio-vga-gl,edid=off,xres=3840,yres=2160`. Same result, but `edid=off` helps to make 2560x1600 appear, making it bearable.
+
+This also happens with Wayland and Xorg.
+
+Please note that while it's possible to use Gnome's Screen Sharing (RDP/VNC) options, as well as NoMachine or other options, this is an undesirable behavior in QEMU's VNC server/console that should be fixed (and can, the VNC protocol perfectly supports 4K without issues)
+
+Not to mention that, at least in my use case, the VNC console is faster than the alternatives, even SPICE (connecting from Windows is barely unusable at 4K res - it's a bliss from Linux. Both cases from a remote machine in the same LAN, but that is unrelated to this bug).
+
+I would happily try different use cases to try to help nail down this bug :smile:
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1597 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1597
new file mode 100644
index 00000000..9259c3b4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1597
@@ -0,0 +1,56 @@
+Intel Arc A-Series GPUs VFIO passthrough no video out
+Description of problem:
+Once the VM is booted, the screen goes blank.
+Steps to reproduce:
+1. Passthough any Intel Arc A (Alchemist) series video card.
+2. Boot VM.
+3. Screen goes blank.
+Additional information:
+I have startup and shutdown scripts that detach and reattach the card and these scripts work fine if I test them alone. It's only when I start the VM that issue presents itself.
+
+
+
+kernel command line:
+
+```
+amd_iommu=on iommu=pt rd.driver.pre=vfio-pci pci=realloc iommu=1 i915.force_probe=*
+
+```
+
+startup script:
+
+```
+#!/bin/bash
+# Helpful to read output when debugging
+set -x
+
+# Load the config file with our environmental variables
+source "/etc/libvirt/hooks/kvm.conf"
+source "/etc/libvirt/hooks/vmPreBootSetup"
+
+cpuPerf
+
+# Stop your display manager. If you're on kde it'll be sddm.service. Gnome users should use 'killall gdm-x-session' instead
+systemctl stop gdm.service
+
+# Unbind VTconsoles
+echo 0 > /sys/class/vtconsole/vtcon0/bind
+echo 0 > /sys/class/vtconsole/vtcon1/bind
+
+# Avoid a race condition by waiting a couple of seconds. This can be calibrated to be shorter or longer if required for your system
+sleep 2
+
+modprobe -r drm_buddy intel_gtt video drm_display_helper cec ttm i915
+
+# Unbind the GPU from display driver
+virsh nodedev-detach $VIRSH_GPU_VIDEO
+virsh nodedev-detach $VIRSH_GPU_AUDIO
+
+# Load VFIO kernel module
+modprobe vfio
+modprobe vfio_pci
+modprobe vfio_iommu_type1
+
+sleep 5s ; systemctl restart connman.service
+
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1598 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1598
new file mode 100644
index 00000000..f1f5e46f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1598
@@ -0,0 +1,58 @@
+vfio-pci - Intel Arc DG2 - host errors
+Description of problem:
+The host continues to respond (slowly) after the VM is shutdown. Speeds back up to normal after about an hour. However, a reboot is required to get the host to operate normally.
+
+When shutting down the VM, the host starts to display the following messages in dmesg:
+
+[Thu Apr 13 01:30:47 2023] vfio-pci 0000:18:00.0: not ready 1023ms after FLR; waiting
+[Thu Apr 13 01:30:49 2023] vfio-pci 0000:18:00.0: not ready 2047ms after FLR; waiting
+[Thu Apr 13 01:30:52 2023] vfio-pci 0000:18:00.0: not ready 4095ms after FLR; waiting
+[Thu Apr 13 01:30:57 2023] vfio-pci 0000:18:00.0: not ready 8191ms after FLR; waiting
+[Thu Apr 13 01:31:06 2023] vfio-pci 0000:18:00.0: not ready 16383ms after FLR; waiting
+[Thu Apr 13 01:31:25 2023] vfio-pci 0000:18:00.0: not ready 32767ms after FLR; waiting
+[Thu Apr 13 01:31:59 2023] vfio-pci 0000:18:00.0: not ready 65535ms after FLR; giving up
+[Thu Apr 13 01:32:11 2023] vfio-pci 0000:18:00.0: not ready 1023ms after bus reset; waiting
+[Thu Apr 13 01:32:13 2023] vfio-pci 0000:18:00.0: not ready 2047ms after bus reset; waiting
+[Thu Apr 13 01:32:16 2023] vfio-pci 0000:18:00.0: not ready 4095ms after bus reset; waiting
+[Thu Apr 13 01:32:21 2023] vfio-pci 0000:18:00.0: not ready 8191ms after bus reset; waiting
+[Thu Apr 13 01:32:31 2023] vfio-pci 0000:18:00.0: not ready 16383ms after bus reset; waiting
+[Thu Apr 13 01:32:48 2023] vfio-pci 0000:18:00.0: not ready 32767ms after bus reset; waiting
+[Thu Apr 13 01:33:22 2023] vfio-pci 0000:18:00.0: not ready 65535ms after bus reset; giving up
+Steps to reproduce:
+1. Shutdown VM.
+Additional information:
+I have startup and shutdown scripts that detach and reattach the card and these scripts work fine if I test them alone. It's only when I shutdown the VM that issue presents itself.
+
+revert.sh
+
+```
+#!/bin/bash
+set -x
+
+systemctl reboot # to workaround host lockup on shutdown
+
+# Load the config file with our environmental variables
+source "/etc/libvirt/hooks/kvm.conf"
+source "/etc/libvirt/hooks/vmPreBootSetup"
+
+cpuSchedutil
+
+# Unload VFIO-PCI Kernel Driver
+modprobe -r vfio_pci
+modprobe -r vfio_iommu_type1
+modprobe -r vfio
+
+# Re-Bind GPU to our display drivers
+virsh nodedev-reattach $VIRSH_GPU_VIDEO
+virsh nodedev-reattach $VIRSH_GPU_AUDIO
+
+#modprobe drm_buddy intel_gtt video drm_display_helper cec ttm i915
+
+# Restart Display Manager
+systemctl restart sddm.service
+```
+
+
+
+Full dmesg log: 
+[vfio_13_april_2023.txt](/uploads/5d5b642595c53cabb3c3608c07d59eb3/vfio_13_april_2023.txt)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1599 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1599
new file mode 100644
index 00000000..27e39587
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1599
@@ -0,0 +1,9 @@
+7.2.1 - Windows installer
+Description of problem:
+Please release windows installer for new stable version 7.2.1 in
+
+https://www.qemu.org/download/
+Steps to reproduce:
+
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/160 b/gitlab/issues_text/target_missing/host_missing/accel_missing/160
new file mode 100644
index 00000000..aff60e31
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/160
@@ -0,0 +1 @@
+Record/replay example does not work
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1601 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1601
new file mode 100644
index 00000000..b5bea7c4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1601
@@ -0,0 +1,80 @@
+QEMU Guest Agent (qga) high CPU usage (1 core at 100%). May happen with guest-network-get-interfaces. Strace says: EAGAIN (Resource temporarily unavailable)
+Description of problem:
+I have a VM that has the QEMU guest agent installed. I use the QGA to get information periodically about the network interfaces. Meaning, I execute the `guest-network-get-interfaces` in a period around 1-2 seconds each.
+
+After a while (maybe a day or so) the QGA seems to lock up with the CPU at 100% in 1 core. It does not reply to more commands, and restarting the service sometimes doesn't work, so a hard reboot it is.
+
+`dmesg` doesn't show anything useful/relevant. When attempting to edit the `qemu-guest-agent.service` and append `/usr/bin/strace` to it, I can get this in a loop:
+
+```
+strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable)
+strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable)
+strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable)
+strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable)
+strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable)
+strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable)
+strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable)
+strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable)
+```
+
+I don't have more knowledge to debug this further. I can help to provide more info if some guidance is provided.
+
+**Don't know if it helps/affects**, but the guest VM is running Docker with around 10 containers or so, so when QGA works, I get around 18 network interfaces, counting loopback, docker `veth`s and `br` interfaces.
+Steps to reproduce:
+1. Create a VM with Fedora 37
+2. Install the QEMU Guest Agent
+3. Call `guest-network-get-interfaces` in a loop every 1-2 seconds (after it finishes) through QGA using the unix socket using the provided python script, called as: `python qga.py --socket /run/test-vm-108.qga '{ "execute": "guest-network-get-interfaces" }'`
+4. Eventually, the guest agent will lock up at 100% CPU usage on 1 core
+Additional information:
+Python script used to call QGA:
+```
+import argparse
+import socket
+import sys
+
+def main():
+    buf_size = 1024
+    timeout_secs = .5
+
+    parser = argparse.ArgumentParser()
+    parser.add_argument('--socket', required=True, help='Path to Unix socket')
+    parser.add_argument('request', help='Request to send')
+    args = parser.parse_args()
+
+    unix_socket_path = args.socket
+    request = args.request
+
+    try:
+        with socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) as sock:
+            sock.settimeout(timeout_secs)
+            sock.connect(unix_socket_path)
+
+            request_bytes = request.encode('utf-8')
+            sock.sendall(request_bytes)
+
+            response_bytes = b''
+            received_bytes = sock.recv(buf_size)
+            response_bytes += received_bytes
+
+            sock.setblocking(False)
+            while True:
+                try:
+                    received_bytes = sock.recv(buf_size)
+                    if not received_bytes:
+                        break
+                    response_bytes += received_bytes
+                except (BlockingIOError, TimeoutError):
+                    break
+                except (FileNotFoundError, ConnectionRefusedError):
+                    sock.close()
+                    sys.exit()
+
+            response = response_bytes.decode('utf-8').strip()
+            print(response)
+
+    except (TimeoutError, FileNotFoundError, BlockingIOError, ConnectionRefusedError):
+        sys.exit()
+
+if __name__ == "__main__":
+    main()
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1602 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1602
new file mode 100644
index 00000000..fe21b63d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1602
@@ -0,0 +1,7 @@
+github.com/qemu/qemu has been out of sync with GitLab since Mar 23, 2023
+Description of problem:
+https://github.com/qemu/qemu has been out of sync with https://gitlab.com/qemu-project/qemu since Mar 23, 2023.
+Steps to reproduce:
+See https://github.com/qemu/qemu
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1604 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1604
new file mode 100644
index 00000000..6bb1146f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1604
@@ -0,0 +1,63 @@
+Get wrong rom when loading 2 different firmware to 2 cpu.
+Description of problem:
+HI, I'm trying to model a machine with 2 cortex-m7 cpu. The 2 CPUs have their own address spaces.
+and when loading rom to init sp and pc, the CPU1 would load the rom of CPU0, because it seems not check 
+address space here.
+```c
+void *rom_ptr_for_as(AddressSpace *as, hwaddr addr, size_t size)
+{
+    /*
+     * Find any ROM data for the given guest address range.  If there
+     * is a ROM blob then return a pointer to the host memory
+     * corresponding to 'addr'; otherwise return NULL.
+     *
+     * We look not only for ROM blobs that were loaded directly to
+     * addr, but also for ROM blobs that were loaded to aliases of
+     * that memory at other addresses within the AddressSpace.
+     *
+     * Note that we do not check @as against the 'as' member in the
+     * 'struct Rom' returned by rom_ptr(). The Rom::as is the
+     * AddressSpace which the rom blob should be written to, whereas
+     * our @as argument is the AddressSpace which we are (effectively)
+     * reading from, and the same underlying RAM will often be visible
+     * in multiple AddressSpaces. (A common example is a ROM blob
+     * written to the 'system' address space but then read back via a
+     * CPU's cpu->as pointer.) This does mean we might potentially
+     * return a false-positive match if a ROM blob was loaded into an
+     * AS which is entirely separate and distinct from the one we're
+     * querying, but this issue exists also for rom_ptr() and hasn't
+     * caused any problems in practice.
+     */
+    FlatView *fv;
+    void *rom;
+    hwaddr len_unused;
+    FindRomCBData cbdata = {};
+
+    /* Easy case: there's data at the actual address */
+    rom = rom_ptr(addr, size);
+    if (rom) {
+        return rom;
+    }
+```
+Steps to reproduce:
+1. create a machine with 2 cortex-m7 cores and their own rom/ram. 
+2. Set different ram size for them. for example, cpu0 ram size:0x40000, cpu1 ram size:0x20000
+3. build firmware of 2 cpu. make sure the init SP(local at 0x0) is set to the top the ram.
+4. use command:
+```
+./qemu-system-arm -M mymachine -smp 2 \
+-device loader,file=./cpu0.elf,addr=0x0,cpu-num=0 \
+-device loader,file=./cpu1.elf,addr=0x0,cpu-num=1  \
+-serial stdio -serial tcp::5678,server=on,wait=off 
+```
+to start this machine.
+
+5. the cpu1 will panic when it try to use stack:
+`qemu-system-arm: ../target/arm/cpu.h:2396: arm_is_secure_below_el3: Assertion failed.` 
+
+
+Sorry that I'm not sure whether this is an issue or I did something wrong. So post it here.
+For local fix this problem, I add a func `rom_ptr_wit_as(addr,size,as)` to find a rom with addresspace check. 
+Is it proper?
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1605 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1605
new file mode 100644
index 00000000..3fd77be0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1605
@@ -0,0 +1,38 @@
+On windows, 2nd kind vhdx-dyn bug, crash on Unexpected error in bdrv_check_qiov_request() in io.c
+Description of problem:
+On windows, 2nd kind vhdx-dyn bug, crash on Unexpected error in bdrv_check_qiov_request() in io.c
+- qemu windows crashes during data copy   
+  ```D:\tmpq\qemu\8.0.0-rc4\qemu\qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -smp "sockets=1,cores=8,threads=1" -bios D:\vstorage\win_m01_edk2-x8_64.fd -boot c -drive "index=0,if=virtio,media=disk,format=raw,file=D:\vstorage\m01_bootnoefi.raw.img" -drive "index=1,if=virtio,media=disk,format=raw,file=F:\m01_lnx.raw.img.vtoy" -drive "index=2,if=virtio,media=disk,format=vhdx,file=F:\gkpics01.vhdx"  -drive "index=3,if=virtio,media=disk,format=vhdx,file=D:\test\sgdata.vhdx" -display sdl -vga virtio -rtc base=utc -netdev user,id=vmnic1,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15,hostfwd=tcp::9551-:22 -device virtio-net,netdev=vmnic1 -chardev qemu-vdagent,id=ch1,name=vdagent,clipboard=on -device virtio-serial -device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0 -qmp "tcp:127.0.0.1:5955,server,nowait"```   
+  ``` ```   
+  ```Windows Hypervisor Platform accelerator is operational```  
+  ```Unexpected error in bdrv_check_qiov_request() at ../../../block/io.c:815:```  
+  ```D:\tmpq\qemu\8.0.0-rc4\qemu\qemu-system-x86_64.exe: offset is negative: -28983296```  
+
+.
+- The **LINE NUMBER** : https://gitlab.com/qemu-project/qemu/-/blob/master/block/io.c#L815
+- qemu setup is ```qemu-w64-setup-20230414.exe ```
+Steps to reproduce:
+1. have fresh vhdx ready create a vhdx in ```diskmgmt``` (also attached to [comment](https://gitlab.com/qemu-project/qemu/-/issues/727#note_1346341805))
+2. have vhdx with synthetic generated data ready (see process to generate sgdata in [comment](https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694) )
+3. start qemu, login, open terminal
+4. Inside VM, start a terminal window, sudo root, 
+5. open```gdisk /dev/vdc``` create a ntfs partition
+6. format as ntfs: ```mkfs.ntfs -Q -L fs_gkpics01 /dev/vdc1``` 
+7. mount the partition ```mount -t ntfs3 /dev/vdc1 /mnt/a -o uid=1000,gid=1000,defaults,umask=0002```
+8. mount the partition ```mount -t ntfs3 /dev/vdd2 /mnt/b -o uid=1000,gid=1000,defaults,umask=0002```
+9. In a user login, do rsync data-copy step  
+   ```( fl="photos001" ; src="/mnt/b/sgdata" ; dst="/mnt/a" ; sdate=`date` ; echo "$sdate" ; cd "$src" ; rsync -avH "$fl" "$dst"  ; echo "$sdate" ; date ; sudo -u gana DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0.0 -- notify-send "$src/$fl" "rsync $src/$fl" )```
+
+
+The bug is easily reproducible.   
+The moment of the crash may seems spurious, but is almost certainly bound to happen.   
+When it happens, it can be seen to be the same error message.  
+Sometimes the crash happens in ```gdisk``` step, sometimes during ```mkfs.ntfs``` sometimes partway through the ```rsync```-copy, not very long into it.
+Additional information:
+- This has been happening for some time. I haven't used/tested vhdx much in windows much since 7.0.0 on account of other corruption bugs/lack of dependability. 
+- This does not happen in Linux, as tested in #727 
+- The fix of #727 is unrelated to this. It doesn't have the same feel/reproduction intuitive-signature. 
+  - Happens before (on doing the same test)  
+    - on 8.0.0-rc1 (line number of io.c there is L811)
+    - on 7.2.0 (line no of io.c there is [L971](https://gitlab.com/qemu-project/qemu/-/blob/ace5a161ea1c09d8eaa8b2a717528457dc924e83/block/io.c#L971))
+- It may be caused by other changes going into block code since 7.0 .
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1607 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1607
new file mode 100644
index 00000000..61914865
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1607
@@ -0,0 +1 @@
+QEMU calls glXMakeCurrent which is current in another thread when running VM with SDL
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/161 b/gitlab/issues_text/target_missing/host_missing/accel_missing/161
new file mode 100644
index 00000000..995c9858
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/161
@@ -0,0 +1 @@
+virtio-scsi gives improper discard sysfs entries
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1610 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1610
new file mode 100644
index 00000000..4a49de47
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1610
@@ -0,0 +1 @@
+support of directX in windows guest
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1611 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1611
new file mode 100644
index 00000000..eb470781
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1611
@@ -0,0 +1 @@
+How to test rutabaga_gfx/gfxstream patches
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1613 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1613
new file mode 100644
index 00000000..7607c736
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1613
@@ -0,0 +1,37 @@
+Enhanced SuperSpeed Isochronous Endpoints with high-bandwidth pipes not working (Webcams and Microphones)
+Description of problem:
+I have encountered an issue with QEMU when forwarding HD webcams and microphones in SuperSpeed mode.
+
+When passing the USB webcam "Logitech BRIO Ultra HD Webcam" to the guest using USB HighSpeed mode, all pixel formats and video modes work as expected. However, when using SuperSpeed mode, only the MJPEG format operates at low resolutions. I have attached a [USB_Webcam_Testing_Truth_Table.pdf](/uploads/309d493989da1164198af0b315012fb1/USB_Webcam_Testing_Truth_Table.pdf) that displays the functioning modes.
+
+This issue arises with both qemu-xhci and nec-usb-xhci xHCI implementations, as well as with usb-host and usb-redir.
+
+Upon tracing and comparing the USB packets from the host and guest systems, I discovered an issue with the isochronous endpoint configurations supporting "high bandwidth" pipes (e.g., SS Companion Descriptor with bMaxBurst > 0). I created three pcap files to illustrate the problem:
+1. [host-libusb.pcapng](/uploads/18a66948dc6dc10ff68b7f55d70fa209/host-libusb.pcapng) 
+2. [qemu-guest.pcapng](/uploads/b616507f2f7c1c042a9d085dc3af579f/qemu-guest.pcapng)
+3. [host-native.pcapng](/uploads/279aa7f264a75a77203fa7bf6c5afc83/host-native.pcapng)
+
+To generate each capture, I executed the following command:
+```console
+timeout --preserve-status 3s ffplay -f v4l2 -i "/dev/video0" -input_format mjpeg -framerate 30 -video_size 1920x1060
+```
+
+The "SET INTERFACE" packet reveals that the USB video driver selects bAlternateSetting=7, which has the following parameters:
+```
+wMaxPacketSize: 1024
+bMaxBurst: 2
+bmAttributes: 0x01
+    .... ..01 = Mult: 1
+```
+According to Section 4.14.2.1.3 of the xHCI specification, the size of an isoch transfer should be `Packet Size * (Max Burst Size + 1) * (Mult + 1) = 6144`.
+
+However, the host-libusb.pcapng capture shows that each transfer is only 1024 bytes in size.
+
+For higher bitrate formats, it is observed that the system generates erroneous transfers in which the data offset in the isodescriptor exceeds the packet size.
+
+Currently, I am unsure of the cause of this issue. If you need any additional information, logs, or specific USB packet captures, I would be more than happy to provide them.
+
+Thanks
+Additional information:
+[lsusb-cam-SuperSpeed.txt](/uploads/712ac9e67d0b53ce46573bee3df883d0/lsusb-cam-SuperSpeed.txt)
+[lsusb-cam-HighSpeed.txt](/uploads/70f855e471714fb1b48a7ed7912c0be4/lsusb-cam-HighSpeed.txt)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1614 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1614
new file mode 100644
index 00000000..cfa652cd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1614
@@ -0,0 +1 @@
+Add option to chardev pty for setting a named link to the allocated pty
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1615 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1615
new file mode 100644
index 00000000..c5aa8a42
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1615
@@ -0,0 +1,11 @@
+8.0.0: Crash when attempting to commit snapshot
+Description of problem:
+When trying to commit a snapshot to the backing store, qemu exits with the error:
+
+`qemu: qemu_mutex_unlock_impl: Operation not permitted`
+Steps to reproduce:
+1. Run qemu command above
+2. Open the monitor virtual console (Ctrl-Alt-2)
+3. Execute command: `commit os`
+Additional information:
+Attached are the [backtrace](/uploads/ba8f519e6b00eb054ba416054c782122/8.0.0-1-bt) and the [configure output](/uploads/17124b45e12b252bd01cf41e7a3d2ea4/8.0.0-1-conf.gz). This is a regression from 7.2.1
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1618 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1618
new file mode 100644
index 00000000..0ebb50b2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1618
@@ -0,0 +1,13 @@
+intel-hda:  SD_STS different behavior for byte write vs. word write
+Description of problem:
+The Intel HDA SD_STS register is accessible two different ways in QEMU:  either it's the top 8 bits of a 32-bit access
+or it's directly accessible as a byte.
+On reads, the register behavior for SD_STS is identical whether accessed as a 32-bit read or an 8-bit read.
+On writes, the behavior is different; when written to as an 8-bit write, the BCIS, FIFOE, and DESE bits implement the documented HDA behavior of RW1C (writing a 1 to a bit clears it).  When written to as the top 8 bits of a 32-bit write, writing a 1 to a bit sets the bit -- so an attempt to clear a status bit instead unconditionally sets the status bit.
+Steps to reproduce:
+1.  Write 32 bits at SD_CTL address with bit 27 set (FIFOE).  This should clear FIFOE, but does not.
+2.  Read back SD_STS (SD_CTL address + 3) as a byte.  The FIFOE bit will be set.
+3.  Write 8 bits at SD_STS address with bit 3 set (FIFOE).  This should clear FIFOE, and it does.
+4.  Read back SD_STS as a byte.  The FIFOE bit will be cleared.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1619 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1619
new file mode 100644
index 00000000..cfa31873
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1619
@@ -0,0 +1 @@
+Emulate x86_64 on ARM machine
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/162 b/gitlab/issues_text/target_missing/host_missing/accel_missing/162
new file mode 100644
index 00000000..807c83b1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/162
@@ -0,0 +1 @@
+util/path.c/follow_path() does not handle "/" well
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1621 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1621
new file mode 100644
index 00000000..dbf4c746
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1621
@@ -0,0 +1,106 @@
+QCOW2 image grows over 110% of its virtual size
+Description of problem:
+Follow-up of https://github.com/oVirt/vdsm/issues/371
+
+As oVirt divides a iSCSI LUN into a LVM device and each VM disk is a Logical Volume, the qcow2 images are inside a LV.
+This works fine, and oVirt allows the LV to grow to 110% of its virtual size.
+
+Now we have like 1 time each month the issue that a VM tries to grow over its 110% limit, which should never happen.
+Steps to reproduce:
+1. When it happend in production, I copied the LV via dd to some file.
+2. I copied the file to a new LV on a test machine, and created a VM for it
+3. Start the VM
+4. Issue reoccurs directly
+Additional information:
+So I started some gdb'ing on the pid, and this it what seems to happen:
+```
+#16 0x0000563c60921f25 in qcow2_add_task (bs=bs@entry=0x563c62bb8090, pool=pool@entry=0x0, func=func@entry=0x563c60924860 <qcow2_co_pwritev_task_entry>, subcluster_type=subcluster_type@entry=QCOW2_SUBCLUSTER_UNALLOCATED_PLAIN, host_offset=17718824960, offset=offset@entry=15192346624, bytes=1310720, qiov=0x7f84c4003a70, qiov_offset=0, l2meta=0x7f84c401c600)
+    at ../block/qcow2.c:2249
+        local_task = {task = {pool = 0x0, func = 0x563c60924860 <qcow2_co_pwritev_task_entry>, ret = 0}, bs = 0x563c62bb8090, subcluster_type = QCOW2_SUBCLUSTER_UNALLOCATED_PLAIN, host_offset = 17718824960, offset = 15192346624, bytes = 1310720, qiov = 0x7f84c4003a70, qiov_offset = 0, l2meta = 0x7f84c401c600}
+        task = 0x7f82bafffb00
+#17 0x0000563c609225b7 in qcow2_co_pwritev_part (bs=0x563c62bb8090, offset=15192346624, bytes=1310720, qiov=0x7f84c4003a70, qiov_offset=0, flags=<optimized out>) at ../block/qcow2.c:2645
+        s = 0x563c62bbf990
+        offset_in_cluster = <optimized out>
+        ret = <optimized out>
+        cur_bytes = 1310720
+        host_offset = 17718824960
+        l2meta = 0x7f84c401c600
+        aio = 0x0
+#18 0x0000563c6090395b in bdrv_driver_pwritev (bs=bs@entry=0x563c62bb8090, offset=offset@entry=15192346624, bytes=bytes@entry=1310720, qiov=qiov@entry=0x7f84c4003a70, qiov_offset=qiov_offset@entry=0, flags=flags@entry=0) at ../block/io.c:1248
+        drv = 0x563c6125fb20 <bdrv_qcow2>
+        sector_num = <optimized out>
+        nb_sectors = <optimized out>
+        local_qiov = {iov = 0x563c6125fb20 <bdrv_qcow2>, niov = 8192, {{nalloc = 4096, local_iov = {iov_base = 0x563c62bb8090, iov_len = 0}}, {__pad = "\000\020\000\000\000\000\000\000\220\200\273b", size = 0}}}
+        ret = <optimized out>
+        __PRETTY_FUNCTION__ = "bdrv_driver_pwritev"
+#19 0x0000563c60905872 in bdrv_aligned_pwritev (child=0x563c647f3c10, req=0x7f82bafffe30, offset=15192346624, bytes=1310720, align=<optimized out>, qiov=0x7f84c4003a70, qiov_offset=0, flags=0) at ../block/io.c:2122
+        bs = 0x563c62bb8090
+        drv = 0x563c6125fb20 <bdrv_qcow2>
+        ret = <optimized out>
+        bytes_remaining = 1310720
+        max_transfer = <optimized out>
+        __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev"
+#20 0x0000563c6090622b in bdrv_co_pwritev_part (child=0x563c647f3c10, offset=<optimized out>, offset@entry=15192346624, bytes=<optimized out>, bytes@entry=1310720, qiov=<optimized out>, qiov@entry=0x7f84c4003a70, qiov_offset=<optimized out>, qiov_offset@entry=0, flags=flags@entry=0) at ../block/io.c:2310
+        bs = <optimized out>
+        req = {bs = 0x563c62bb8090, offset = 15192346624, bytes = 1310720, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 15192346624, overlap_bytes = 1310720, list = {le_next = 0x7f829c6c8e30, le_prev = 0x7f82a3fffe60}, co = 0x7f84c4004210, wait_queue = {entries = {sqh_first = 0x0, sqh_last = 0x7f82bafffe78}}, waiting_for = 0x0}
+        align = <optimized out>
+        pad = {buf = 0x0, buf_len = 0, tail_buf = 0x0, head = 0, tail = 0, merge_reads = false, local_qiov = {iov = 0x0, niov = 0, {{nalloc = 0, local_iov = {iov_base = 0x0, iov_len = 0}}, {__pad = '\000' <repeats 11 times>, size = 0}}}}
+        ret = <optimized out>
+        padded = false
+        __PRETTY_FUNCTION__ = "bdrv_co_pwritev_part"
+#21 0x0000563c608f71e0 in blk_co_do_pwritev_part (blk=0x563c648183c0, offset=15192346624, bytes=1310720, qiov=0x7f84c4003a70, qiov_offset=qiov_offset@entry=0, flags=0) at ../block/block-backend.c:1289
+        ret = <optimized out>
+        bs = 0x563c62bb8090
+```
+
+There is a write from the VM with size 1310720 on offset 15192346624.
+A host offset is calculated for this, but this offset is 17718824960 !!
+The image/LV is only 17716740096, and 17716740096 < 17718824960 -> ENOSPC error is triggered.
+
+The code for calculating the host offset seems to be untouched for the last years.
+But it seems like for some reason it takes some offset way beyond the virtual size boundaries.
+
+The qemu-img output:
+```
+# qemu-img info /dev/mapper/test-xxxxx 
+image: /dev/mapper/test-xxxxx
+file format: qcow2
+virtual size: 15 GiB (16106127360 bytes)
+disk size: 0 B
+cluster_size: 65536
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: false
+    bitmaps:
+        [0]:
+            flags:
+                [0]: in-use
+                [1]: auto
+            name: 428fae80-3892-4083-9107-51fb76a7f06b
+            granularity: 65536
+        [1]:
+            flags:
+                [0]: in-use
+                [1]: auto
+            name: 51ccd1fc-08a4-485d-8c04-0eb750665e05
+            granularity: 65536
+        [2]:
+            flags:
+                [0]: in-use
+                [1]: auto
+            name: 19796bed-56a5-44c1-a7f2-dae633e65c87
+            granularity: 65536
+        [3]:
+            flags:
+                [0]: in-use
+                [1]: auto
+            name: 13056186-e65e-448e-a3c3-019ab25d3a27
+            granularity: 65536
+    refcount bits: 16
+    corrupt: false
+    extended l2: false
+```
+
+Also attaching the map where you can see there are plenty of zero blocks, but still it tries to allocate a new block for some reason.
+[map.txt](/uploads/0890cf718f77c0ad2e562165eb350d13/map.txt)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1622 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1622
new file mode 100644
index 00000000..53684218
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1622
@@ -0,0 +1 @@
+PNG screendump has R/B channels swapped
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1625 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1625
new file mode 100644
index 00000000..d2168f59
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1625
@@ -0,0 +1,13 @@
+[7.2.0] Qemu process hang with `defunct` when using `-blockdev` json property which file doesn't exists
+Description of problem:
+When using `throttle` and `throttle-group` to apply block device QOS,  
+there is something wrong with check file exists validation.  
+In upper commands, if the file which located `/mnt/b3b8dfb5-0a7c-4285-81d8-2bf8d33a3297/32c55f5a-96d1-4af4-a149-c95fd6652e3e/b016af76-f6b1-4614-b29a-78917924e55e` doesn't exist, it just hang with `defunct` process.  
+![defunct](/uploads/607c81f0c5a490a50cd0882139fded4b/defunct.png)
+Steps to reproduce:
+1. Start Guest with upper command.
+2. Hanged with defunct process
+3.
+Additional information:
+![1682511478](/uploads/4c6ec5d32e71bf5c116ed146a27dc8a6/1682511478.png)  
+- With GDB stack, i can find `no such file` error, but process don't exit
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1626 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1626
new file mode 100644
index 00000000..9e9e0f56
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1626
@@ -0,0 +1,5 @@
+QEMU insists on using /var/tmp instead of /tmp
+Description of problem:
+On a host, our sysadmins have decided for whatever reason that `/var/tmp` is not a thing that normal users can write to (and perhaps that's dumb, but it is what it is and would be a challenging non-technical problem to solve). Whenever QEMU detects the temporary directory is /tmp, it changes it to `/var/tmp` without a mechanism to change it (see https://gitlab.com/qemu-project/qemu/-/commit/69fbfff95e849156985cf95e2010ffc8762e34e6).
+
+I'm sure in the general case this is fine, but can you add an environment variable or a ./configure option to make this location configurable? I really would like to write to `/tmp`.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1629 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1629
new file mode 100644
index 00000000..e8ce977c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1629
@@ -0,0 +1 @@
+qem-img Heap Buffer Overflow
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/163 b/gitlab/issues_text/target_missing/host_missing/accel_missing/163
new file mode 100644
index 00000000..330d041c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/163
@@ -0,0 +1 @@
+SPICE session's connection_id's are not unique
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1630 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1630
new file mode 100644
index 00000000..cfec1b95
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1630
@@ -0,0 +1,200 @@
+[8.0.0] qemu breaks mac os vm (passed through sata controller)
+Description of problem:
+I have a mac os montery vm which is not able to boot after upgrading from qemu 7.2.1 to qemu 8.0.0.\
+Mac os bootloader (opencore) logs do not show anything useful, nothing useful also in libvirt logs.\
+Apple screen hangs at "still waiting for root device" with the prohibition symbol.\
+This should point that mac os is not able to find the disk to boot from.\
+The bootloader sees the disk with its partitions.\
+I'm passing through a sata controller with the boot disk attached, together with a usb controller, builtin audio and a gpu.\
+Changing machine type (q35) to older versions change nothing.\
+Downgrading to 7.2.1 and no issue.
+
+Maybe related to some acpi changes?
+Additional information:
+This is the libvirt xml I'm using:
+```
+<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
+  <name>Montereytest</name>
+  <memory unit='KiB'>33554432</memory>
+  <currentMemory unit='KiB'>33554432</currentMemory>
+  <memoryBacking>
+    <nosharepages/>
+  </memoryBacking>
+  <vcpu placement='static'>8</vcpu>
+  <iothreads>2</iothreads>
+  <iothreadids>
+    <iothread id='1'/>
+    <iothread id='2'/>
+  </iothreadids>
+  <cputune>
+    <vcpupin vcpu='0' cpuset='1'/>
+    <vcpupin vcpu='1' cpuset='2'/>
+    <vcpupin vcpu='2' cpuset='3'/>
+    <vcpupin vcpu='3' cpuset='4'/>
+    <vcpupin vcpu='4' cpuset='5'/>
+    <vcpupin vcpu='5' cpuset='6'/>
+    <vcpupin vcpu='6' cpuset='7'/>
+    <vcpupin vcpu='7' cpuset='9'/>
+  </cputune>
+  <os>
+    <type arch='x86_64' machine='pc-q35-7.2'>hvm</type>
+    <loader readonly='yes' type='pflash'>/opt/macos/OVMF_CODE_TEST.fd</loader>
+    <nvram>/opt/macos/OVMF_VARS_TEST.fd</nvram>
+    <boot dev='hd'/>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+  </features>
+  <cpu mode='host-passthrough' check='none' migratable='on'>
+    <topology sockets='1' dies='1' cores='4' threads='2'/>
+  </cpu>
+  <clock offset='utc'>
+    <timer name='rtc' tickpolicy='catchup'/>
+    <timer name='pit' tickpolicy='delay'/>
+    <timer name='hpet' present='no'/>
+  </clock>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>restart</on_crash>
+  <devices>
+    <emulator>/usr/bin/qemu-system-x86_64</emulator>
+    <controller type='pci' index='0' model='pcie-root'/>
+    <controller type='pci' index='1' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='1' port='0x8'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/>
+    </controller>
+    <controller type='pci' index='2' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='2' port='0x9'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
+    </controller>
+    <controller type='pci' index='3' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='3' port='0xc'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
+    </controller>
+    <controller type='pci' index='4' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='4' port='0x13'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/>
+    </controller>
+    <controller type='virtio-serial' index='0'>
+      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-ehci1'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-uhci1'>
+      <master startport='0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/>
+    </controller>
+    <controller type='sata' index='0'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
+    </controller>
+    <interface type='bridge'>
+      <mac address='c8:2a:14:55:1a:b2'/>
+      <source bridge='br0'/>
+      <model type='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
+    </interface>
+    <interface type='bridge'>
+      <mac address='c8:2a:14:32:2c:ff'/>
+      <source bridge='br1'/>
+      <model type='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+    </interface>
+    <serial type='pty'>
+      <target type='isa-serial' port='0'>
+        <model name='isa-serial'/>
+      </target>
+    </serial>
+    <console type='pty'>
+      <target type='serial' port='0'/>
+    </console>
+    <channel type='unix'>
+      <target type='virtio' name='org.qemu.guest_agent.0'/>
+      <address type='virtio-serial' controller='0' bus='0' port='1'/>
+    </channel>
+    <input type='keyboard' bus='ps2'/>
+    <input type='mouse' bus='ps2'/>
+    <audio id='1' type='none'/>
+    <hostdev mode='subsystem' type='pci' managed='yes'>
+      <driver name='vfio'/>
+      <source>
+        <address domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
+      </source>
+      <rom file='/opt/gpu-bios/6900xt.rom'/>
+      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0' multifunction='on'/>
+    </hostdev>
+    <hostdev mode='subsystem' type='pci' managed='yes'>
+      <driver name='vfio'/>
+      <source>
+        <address domain='0x0000' bus='0x06' slot='0x00' function='0x1'/>
+      </source>
+      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x1'/>
+    </hostdev>
+    <hostdev mode='subsystem' type='pci' managed='yes'>
+      <driver name='vfio'/>
+      <source>
+        <address domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
+      </source>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+    </hostdev>
+    <hostdev mode='subsystem' type='pci' managed='yes'>
+      <driver name='vfio'/>
+      <source>
+        <address domain='0x0000' bus='0x0c' slot='0x00' function='0x0'/>
+      </source>
+      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
+    </hostdev>
+    <hostdev mode='subsystem' type='pci' managed='yes'>
+      <driver name='vfio'/>
+      <source>
+        <address domain='0x0000' bus='0x84' slot='0x00' function='0x0'/>
+      </source>
+      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
+    </hostdev>
+    <hostdev mode='subsystem' type='usb' managed='no'>
+      <source>
+        <vendor id='0x046d'/>
+        <product id='0x0892'/>
+      </source>
+      <address type='usb' bus='0' port='2'/>
+    </hostdev>
+    <hostdev mode='subsystem' type='usb' managed='no'>
+      <source>
+        <vendor id='0x148f'/>
+        <product id='0x3070'/>
+      </source>
+      <address type='usb' bus='0' port='1'/>
+    </hostdev>
+    <watchdog model='itco' action='reset'/>
+    <memballoon model='none'/>
+  </devices>
+  <qemu:commandline>
+    <qemu:arg value='-smbios'/>
+    <qemu:arg value='type=2'/>
+    <qemu:arg value='-global'/>
+    <qemu:arg value='ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off'/>
+    <qemu:arg value='-global'/>
+    <qemu:arg value='pcie-root-port.x-speed=8'/>
+    <qemu:arg value='-global'/>
+    <qemu:arg value='pcie-root-port.x-width=16'/>
+    <qemu:arg value='-cpu'/>
+    <qemu:arg value='host,+hypervisor,migratable=no,-erms,kvm=on,+invtsc,+topoext,+avx,+aes,+xsave,+xsaveopt,+ssse3,+sse4_2,+popcnt,+arat,+pclmuldq,+pdpe1gb,+rdtscp,+vme,+umip,check'/>
+  </qemu:commandline>
+</domain>
+```
+
+06:00.0/1 --> gpu\
+00:1b.0 --> audio\
+0c:00.0 --> sata controller\
+84:00.0 --> usb controller\
+0x046d 0x0892 --> usb webcam\
+0x148f 0x3070 --> usb wifi
+
+
+
+[]
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1632 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1632
new file mode 100644
index 00000000..dd6114e7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1632
@@ -0,0 +1,490 @@
+Porting support for GVM/AEHD to qemu 8.0
+Description of problem:
+I'm trying to find reason why changes work fine with qemu 7.1 but it doesn't work with qemu 7.2 and 8.0. Could you recommend me point where I should investigate this bug/error when using GVM acceleration. I know it is not part of official QEMU and somebody is also working on that [topic ](https://gitlab.com/qemu-project/qemu/-/issues/1558). 
+
+
+```
+GVM is operational
+**
+ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+**
+ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+**
+ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+
+**
+ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+**
+ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+**
+ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+
+**
+ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+
+**
+ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+**
+ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+
+**
+ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+
+**
+ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+
+**
+ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+
+Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)
+```
+Steps to reproduce:
+1. Checkout my fork with this branch [qemu-8.0-gvm](https://gitlab.com/MateuszKrawczuk/qemu/-/tree/qemu-8.0-gvm)
+2. Build on windows using mingw64
+3. Try launch with using GVM acceleration
+Additional information:
+```
+./configure --enable-sdl --enable-gtk --enable-whpx --target-list=x86_64-softmmu
+Using './build' as the directory for build output
+ln: nie udało się utworzyć dowiązania symbolicznego 'x86_64-softmmu/qemu-system-x86_64.exe': No such file or directory
+The Meson build system
+Version: 0.61.5
+Source dir: C:/Users/AMD-RYZEN-PC/qemu
+Build dir: C:/Users/AMD-RYZEN-PC/qemu/build
+Build type: native build
+Project name: qemu
+Project version: 8.0.0
+C compiler for the host machine: cc -m64 -mcx16 (gcc 12.2.0 "cc (Rev10, Built by MSYS2 project) 12.2.0")
+C linker for the host machine: cc -m64 -mcx16 ld.bfd 2.40
+Host machine cpu family: x86_64
+Host machine cpu: x86_64
+Program scripts/symlink-install-tree.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/symlink-install-tree.py)
+Program sh found: YES (C:\Users\AMD-RYZEN-PC\scoop\apps\msys2\2023-03-18\usr\bin/sh.EXE)
+C++ compiler for the host machine: c++ -m64 -mcx16 (gcc 12.2.0 "c++ (Rev10, Built by MSYS2 project) 12.2.0")
+C++ linker for the host machine: c++ -m64 -mcx16 ld.bfd 2.40
+Program python3 found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe)
+Program bzip2 found: YES (C:\Users\AMD-RYZEN-PC\scoop\apps\msys2\2023-03-18\mingw64\bin/bzip2.EXE)
+Program iasl found: NO
+Compiler for C supports link arguments -Wl,-z,relro: NO
+Compiler for C supports link arguments -Wl,-z,now: NO
+Compiler for C supports link arguments -Wl,--no-seh: YES
+Compiler for C supports link arguments -Wl,--nxcompat: YES
+Compiler for C supports link arguments -Wl,--dynamicbase: YES
+Compiler for C supports link arguments -Wl,--high-entropy-va: YES
+Compiler for C++ supports link arguments -Wl,--warn-common: YES
+Program cgcc found: NO
+Library m found: YES
+Run-time dependency threads found: YES
+Library util found: NO
+Program midl found: NO
+Program widl found: YES
+Library pathcch found: YES
+Library ws2_32 found: YES
+Library winmm found: YES
+Windows resource compiler: GNU windres (GNU Binutils) 2.40
+Has header "WinHvPlatform.h" : YES
+Has header "WinHvEmulation.h" : YES
+Run-time dependency appleframeworks found: NO (tried framework)
+Found pkg-config: C:\Users\AMD-RYZEN-PC\scoop\apps\msys2\2023-03-18\mingw64\bin/pkg-config.EXE (1.8.0)
+Run-time dependency gio-2.0 found: YES 2.76.1
+Program C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/gdbus-codegen found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/gdbus-codegen.exe)
+Run-time dependency gio-unix-2.0 found: NO (tried pkgconfig)
+Run-time dependency pixman-1 found: YES 0.42.2
+Run-time dependency zlib found: YES 1.2.13
+Has header "libaio.h" : NO
+Run-time dependency liburing found: NO (tried pkgconfig)
+Run-time dependency libnfs found: NO (tried pkgconfig)
+Has header "attr/xattr.h" : NO
+Run-time dependency appleframeworks found: NO (tried framework)
+Run-time dependency appleframeworks found: NO (tried framework)
+Run-time dependency libseccomp found: NO (tried pkgconfig)
+Has header "cap-ng.h" : NO
+Run-time dependency xkbcommon found: NO (tried pkgconfig)
+Run-time dependency slirp found: YES 4.7.0
+Has header "libvdeplug.h" : NO
+Run-time dependency jack found: NO (tried pkgconfig)
+Run-time dependency sndio found: NO (tried pkgconfig)
+Run-time dependency spice-protocol found: NO (tried pkgconfig)
+Run-time dependency spice-server found: NO (tried pkgconfig)
+Library rt found: NO
+Run-time dependency libiscsi found: NO (tried pkgconfig)
+Run-time dependency libzstd found: YES 1.5.5
+Run-time dependency virglrenderer found: YES 0.9.1
+Run-time dependency blkio found: NO (tried pkgconfig)
+Run-time dependency libcurl found: NO (tried pkgconfig)
+Run-time dependency ncurses found: NO (tried pkgconfig)
+Run-time dependency ncursesw found: YES 6.4.20230211
+Has header "brlapi.h" : NO
+Run-time dependency sdl2 found: YES 2.26.5
+Run-time dependency sdl2_image found: YES 2.6.3
+Library rados found: NO
+Has header "rbd/librbd.h" : NO
+Run-time dependency glusterfs-api found: NO (tried pkgconfig)
+Run-time dependency libssh found: NO (tried pkgconfig)
+Has header "bzlib.h" : YES
+Library bz2 found: YES
+Has header "lzfse.h" : NO
+Has header "sys/soundcard.h" : NO
+Has header "dsound.h" : YES
+Run-time dependency epoxy found: YES 1.5.10
+Has header "epoxy/egl.h" with dependency epoxy: YES
+Run-time dependency gbm found: NO (tried pkgconfig)
+Run-time dependency gnutls found: NO (tried pkgconfig)
+Run-time dependency gnutls found: NO (tried pkgconfig)
+libgcrypt-config found: NO need ['>=1.8']
+Run-time dependency libgcrypt found: NO (tried config-tool)
+Run-time dependency nettle found: NO (tried pkgconfig)
+Run-time dependency gmp found: YES 6.2.1
+Run-time dependency gtk+-3.0 found: YES 3.24.38
+Run-time dependency gtk+-x11-3.0 found: NO (tried pkgconfig)
+Run-time dependency vte-2.91 found: NO (tried pkgconfig)
+Run-time dependency libpng found: YES 1.6.39
+Run-time dependency libjpeg found: YES 2.1.5.1
+Has header "sasl/sasl.h" : NO
+Has header "security/pam_appl.h" : NO
+Has header "snappy-c.h" : NO
+Has header "lzo/lzo1x.h" : YES
+Library lzo2 found: YES
+Has header "numa.h" : NO
+Library ibumad found: NO
+Has header "rdma/rdma_cma.h" : NO
+Library ibverbs found: NO
+Run-time dependency xencontrol found: NO (tried pkgconfig)
+Library xenstore found: NO
+Library xenctrl found: NO
+Library xendevicemodel found: NO
+Library xenforeignmemory found: NO
+Library xengnttab found: NO
+Library xenevtchn found: NO
+Library xentoolcore found: NO
+Run-time dependency libcacard found: NO (tried pkgconfig)
+Run-time dependency u2f-emu found: NO (tried pkgconfig)
+Run-time dependency canokey-qemu found: NO (tried pkgconfig)
+Run-time dependency libusbredirparser-0.5 found: NO (tried pkgconfig)
+Run-time dependency libusb-1.0 found: YES 1.0.26
+Run-time dependency libpmem found: NO (tried pkgconfig)
+Run-time dependency libdaxctl found: NO (tried pkgconfig)
+Run-time dependency libkeyutils found: NO (tried pkgconfig)
+Checking for function "gettid" : NO
+Run-time dependency libselinux found: NO (tried pkgconfig)
+Run-time dependency fuse3 found: NO (tried pkgconfig)
+Run-time dependency libbpf found: NO (tried pkgconfig)
+Run-time dependency libdw found: NO (tried pkgconfig)
+Checking for function "pthread_fchdir_np" : NO
+Has header "sys/epoll.h" : NO
+Has header "linux/magic.h" : NO
+Has header "valgrind/valgrind.h" : NO
+Has header "linux/btrfs.h" : NO
+Has header "libdrm/drm.h" : NO
+Has header "pty.h" : NO
+Has header "sys/disk.h" : NO
+Has header "sys/ioccom.h" : NO
+Has header "sys/kcov.h" : NO
+Has header "afunix.h" : YES
+Checking for function "close_range" : NO
+Checking for function "accept4" : NO
+Checking for function "clock_adjtime" : NO
+Checking for function "dup3" : NO
+Checking for function "fallocate" : NO
+Checking for function "posix_fallocate" : NO
+Checking for function "posix_memalign" : NO
+Checking for function "_aligned_malloc" : YES
+Checking for function "valloc" : NO
+Checking for function "memalign" : NO
+Checking for function "ppoll" : NO
+Checking for function "preadv" : NO
+Checking for function "pthread_fchdir_np" : NO (cached)
+Checking for function "sendfile" : NO
+Checking for function "setns" : NO
+Checking for function "syncfs" : NO
+Checking for function "sync_file_range" : NO
+Checking for function "timerfd_create" : NO
+Checking for function "copy_file_range" : NO
+Checking for function "getifaddrs" : NO
+Checking for function "openpty" with dependency -lutil: NO
+Checking for function "strchrnul" : NO
+Checking for function "system" : YES
+Header <sys/epoll.h> has symbol "epoll_create1" : NO
+Header <linux/falloc.h> has symbol "FALLOC_FL_PUNCH_HOLE" : NO
+Header <linux/falloc.h> has symbol "FALLOC_FL_ZERO_RANGE" : NO
+Has header "linux/fiemap.h" : NO
+Checking for function "getrandom" : NO
+Header <sys/inotify.h> has symbol "inotify_init" : NO
+Header <sys/inotify.h> has symbol "inotify_init1" : NO
+Header <sys/prctl.h> has symbol "PR_SET_TIMERSLACK" : NO
+Header <linux/rtnetlink.h> has symbol "IFLA_PROTO_DOWN" : NO
+Header <sys/sysmacros.h> has symbol "makedev" : NO
+Header <getopt.h> has symbol "optreset" : NO
+Header <netinet/in.h> has symbol "IPPROTO_MPTCP" : NO
+Checking whether type "struct sigevent" has member "sigev_notify_thread_id" : NO
+Checking whether type "struct stat" has member "st_atim" : NO
+Checking for type "struct iovec" : NO
+Checking for type "struct utmpx" : NO
+Checking for type "struct mmsghdr" : NO
+Header <linux/vm_sockets.h> has symbol "AF_VSOCK" : NO
+Has header "vscoordint.h" : NO
+Checking if "_lock_file and _unlock_file" : links: YES
+Checking if "mingw setjmp and longjmp" : links: NO
+Program scripts/minikconf.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/minikconf.py)
+Configuring x86_64-softmmu-config-target.h using configuration
+Configuring x86_64-softmmu-config-devices.mak with command
+Reading depfile: C:/Users/AMD-RYZEN-PC/qemu/build/meson-private/x86_64-softmmu-config-devices.mak.d
+Configuring x86_64-softmmu-config-devices.h using configuration
+Program scripts/make-config-poison.sh found: YES (sh C:/Users/AMD-RYZEN-PC/qemu/scripts/make-config-poison.sh)
+Run-time dependency capstone found: NO (tried pkgconfig)
+Library fdt found: NO
+Configuring config-host.h using configuration
+Program scripts/hxtool found: YES (sh C:/Users/AMD-RYZEN-PC/qemu/scripts/hxtool)
+Program scripts/shaderinclude.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/shaderinclude.py)
+Program scripts/qapi-gen.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/qapi-gen.py)
+Program scripts/qemu-version.sh found: YES (sh C:/Users/AMD-RYZEN-PC/qemu/scripts/qemu-version.sh)
+Program scripts/decodetree.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/decodetree.py)
+Program ../scripts/modules/module_block.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/block/../scripts/modules/module_block.py)
+Program ../scripts/block-coroutine-wrapper.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/block/../scripts/block-coroutine-wrapper.py)
+Program scripts/modinfo-collect.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/modinfo-collect.py)
+Program scripts/modinfo-generate.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/modinfo-generate.py)
+Program nm found: YES
+Program scripts/undefsym.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/undefsym.py)
+Program scripts/feature_to_c.sh found: YES (sh C:/Users/AMD-RYZEN-PC/qemu/scripts/feature_to_c.sh)
+Compiler for C supports link arguments -fstack-protector-all: YES
+Compiler for C supports link arguments -fstack-protector-strong: YES
+Compiler for C supports link arguments -Wl,--add-stdcall-alias: YES
+Compiler for C supports link arguments -Wl,--enable-stdcall-fixup: YES
+Library ole32 found: YES
+Library oleaut32 found: YES
+Library shlwapi found: YES
+Library uuid found: YES
+Library intl found: YES
+Program windmc found: YES
+Program windres found: YES
+Program wixl found: NO
+Configuring 50-edk2-i386-secure.json using configuration
+Configuring 50-edk2-x86_64-secure.json using configuration
+Configuring 60-edk2-aarch64.json using configuration
+Configuring 60-edk2-arm.json using configuration
+Configuring 60-edk2-i386.json using configuration
+Configuring 60-edk2-x86_64.json using configuration
+Program qemu-keymap found: NO
+Program sphinx-build found: NO
+Program diff found: YES (C:\Users\AMD-RYZEN-PC\scoop\apps\msys2\2023-03-18\usr\bin/diff.EXE)
+Program dbus-daemon found: NO
+Found CMake: C:\Users\AMD-RYZEN-PC\scoop\shims/cmake.EXE (3.26.3)
+WARNING: CMake Toolchain: Failed to determine CMake compilers state
+Run-time dependency gvnc-1.0 found: NO (tried pkgconfig and cmake)
+Run-time dependency sysprof-capture-4 found: NO (tried pkgconfig and cmake)
+Program initrd-stress.sh found: YES (sh C:/Users/AMD-RYZEN-PC/qemu/tests/migration/initrd-stress.sh)
+Program xgettext found: YES (C:\Users\AMD-RYZEN-PC\scoop\apps\msys2\2023-03-18\mingw64\bin/xgettext.EXE)
+Program scripts/nsis.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/nsis.py)
+Build targets in project: 516
+
+qemu 8.0.0
+
+  Directories
+    Install prefix               : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu
+    BIOS directory               : share/
+    firmware path                : share/qemu-firmware
+    binary directory             : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu/.
+    library directory            : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu/lib
+    module directory             : lib/
+    libexec directory            : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu/libexec
+    include directory            : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu/include
+    config directory             : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu/etc
+    local state directory        : queried at runtime
+    Doc directory                : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu/share/doc
+    Build directory              : C:/Users/AMD-RYZEN-PC/qemu/build
+    Source path                  : C:/Users/AMD-RYZEN-PC/qemu
+    GIT submodules               : ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc
+
+  Host binaries
+    git                          : git
+    make                         : make
+    python                       : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe (version: 3.10)
+    sphinx-build                 : NO
+    gdb                          : /mingw64/bin/gdb-multiarch
+    iasl                         : NO
+    genisoimage                  :
+    wixl                         : NO
+    smbd                         : NO
+
+  Configurable features
+    Documentation                : NO
+    system-mode emulation        : YES
+    user-mode emulation          : NO
+    block layer                  : YES
+    Install blobs                : YES
+    module support               : NO
+    fuzzing support              : NO
+    Audio drivers                : dsound sdl
+    Trace backends               : log
+    D-Bus display                : NO
+    QOM debugging                : NO
+    vhost-kernel support         : NO
+    vhost-net support            : NO
+    vhost-user support           : NO
+    vhost-user-crypto support    : NO
+    vhost-user-blk server support: NO
+    vhost-vdpa support           : NO
+    build guest agent            : YES
+
+  Compilation
+    host CPU                     : x86_64
+    host endianness              : little
+    C compiler                   : cc -m64 -mcx16
+    Host C compiler              : cc -m64 -mcx16
+    C++ compiler                 : c++ -m64 -mcx16
+    CFLAGS                       : -g -O2
+    CXXFLAGS                     : -g -O2
+    QEMU_CFLAGS                  : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-pie -no-pie -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -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 -Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong
+    QEMU_CXXFLAGS                : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-pie -no-pie -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -Wundef -Wwrite-strings -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong
+    QEMU_LDFLAGS                 : -fstack-protector-strong -Wl,--no-seh -Wl,--nxcompat -Wl,--dynamicbase -Wl,--high-entropy-va -Wl,--warn-common
+    profiler                     : NO
+    link-time optimization (LTO) : NO
+    PIE                          : NO
+    static build                 : NO
+    malloc trim support          : NO
+    membarrier                   : NO
+    debug stack usage            : NO
+    mutex debugging              : NO
+    memory allocator             : system
+    avx2 optimization            : YES
+    avx512bw optimization        : YES
+    avx512f optimization         : NO
+    gprof                        : NO
+    gcov                         : NO
+    thread sanitizer             : NO
+    CFI support                  : NO
+    strip binaries               : NO
+    sparse                       : NO
+    mingw32 support              : YES
+
+  Cross compilers
+    x86_64                       : cc
+
+  Targets and accelerators
+    KVM support                  : NO
+    GVM support                  : YES
+    HAX support                  : YES
+    HVF support                  : NO
+    WHPX support                 : YES
+    NVMM support                 : NO
+    Xen support                  : NO
+    Xen emulation                : NO
+    TCG support                  : YES
+    TCG backend                  : native (x86_64)
+    TCG plugins                  : NO
+    TCG debug enabled            : NO
+    target list                  : x86_64-softmmu
+    default devices              : YES
+    out of process emulation     : NO
+    vfio-user server             : NO
+
+  Block layer support
+    coroutine backend            : win32
+    coroutine pool               : YES
+    Block whitelist (rw)         :
+    Block whitelist (ro)         :
+    Use block whitelist in tools : NO
+    VirtFS support               : NO
+    Live block migration         : YES
+    replication support          : YES
+    bochs support                : YES
+    cloop support                : YES
+    dmg support                  : YES
+    qcow v1 support              : YES
+    vdi support                  : YES
+    vvfat support                : YES
+    qed support                  : YES
+    parallels support            : YES
+    FUSE exports                 : NO
+    VDUSE block exports          : NO
+
+  Crypto
+    TLS priority                 : NORMAL
+    GNUTLS support               : NO
+    libgcrypt                    : NO
+    nettle                       : NO
+    AF_ALG support               : NO
+    rng-none                     : NO
+    Linux keyring                : NO
+
+  Dependencies
+    SDL support                  : YES
+    SDL image support            : YES 2.6.3
+    GTK support                  : YES
+    pixman                       : YES 0.42.2
+    VTE support                  : NO
+    slirp support                : YES 4.7.0
+    libtasn1                     : NO
+    PAM                          : NO
+    iconv support                : YES
+    curses support               : YES
+    virgl support                : YES 0.9.1
+    blkio support                : NO
+    curl support                 : NO
+    Multipath support            : NO
+    PNG support                  : YES 1.6.39
+    VNC support                  : YES
+    VNC SASL support             : NO
+    VNC JPEG support             : YES 2.1.5.1
+    DirectSound support          : YES
+    JACK support                 : NO
+    brlapi support               : NO
+    vde support                  : NO
+    netmap support               : NO
+    l2tpv3 support               : NO
+    Linux AIO support            : NO
+    Linux io_uring support       : NO
+    ATTR/XATTR support           : NO
+    RDMA support                 : NO
+    PVRDMA support               : NO
+    fdt support                  : internal
+    libcap-ng support            : NO
+    bpf support                  : NO
+    spice protocol support       : NO
+    rbd support                  : NO
+    smartcard support            : NO
+    U2F support                  : NO
+    libusb                       : YES 1.0.26
+    usb net redir                : NO
+    OpenGL support (epoxy)       : YES 1.5.10
+    GBM                          : NO
+    libiscsi support             : NO
+    libnfs support               : NO
+    QGA VSS support              : YES
+    seccomp support              : NO
+    GlusterFS support            : NO
+    TPM support                  : NO
+    libssh support               : NO
+    lzo support                  : YES
+    snappy support               : NO
+    bzip2 support                : YES
+    lzfse support                : NO
+    zstd support                 : YES 1.5.5
+    NUMA host support            : NO
+    capstone                     : NO
+    libpmem support              : NO
+    libdaxctl support            : NO
+    libudev                      : NO
+    FUSE lseek                   : NO
+    selinux                      : NO
+    libdw                        : NO
+
+  User defined options
+    Native files                 : config-meson.cross
+    bindir                       :
+    prefix                       : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu
+    werror                       : true
+    b_pie                        : false
+    gtk                          : enabled
+    qemu_suffix                  :
+    sdl                          : enabled
+    vfio_user_server             : disabled
+    whpx                         : enabled
+
+Found ninja-1.11.1 at C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/usr/bin/ninja.exe
+Running postconf script 'C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/symlink-install-tree.py'
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1638 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1638
new file mode 100644
index 00000000..50c0fdb1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1638
@@ -0,0 +1,19 @@
+BUG: Segmentation fault when -object memory-backend-file use readonly=on, prealloc=on together
+Description of problem:
+Segmentation Fault while booting VM.
+Steps to reproduce:
+1. set qemu boot params to `-object memory-backend-file,id=mem1,readonly=on,prealloc=on,mem-path=<any-img-file>,size=4G`
+2.
+3.
+Additional information:
+It might not be a bug, probably a feature.
+The reason of this segfault is:
+readonly would mmap the backend file using PROT_READ, make it readonly,
+but the prealloc=on would touch_pages the memory mmaped by the file.
+SO the segfault happens.
+
+But there is no docs about this segfault condition (the readonly and prealloc cannot be used together.)
+
+And maybe there is a way to solve this problem, I think.
+Use mmap the memory backend file to PROT_READ|PROT_WRITE at the beginnning, after touch_pages, then mprotect the memory.
+change the prot to readonly if required.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1641 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1641
new file mode 100644
index 00000000..44f0af77
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1641
@@ -0,0 +1,24 @@
+[abrt] qemu-system-x86-core: do_patch_instruction(): qemu-system-x86_64 killed by SIGABRT
+Description of problem:
+Copied from downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2195952
+
+Description of problem:
+Virtualizing a Windows XP system which tried to reboot.
+
+Version-Release number of selected component:
+qemu-system-x86-core-2:7.2.1-1.fc38
+
+Additional info:
+reason:         qemu-system-x86_64 killed by SIGABRT
+backtrace_rating: 4
+crash_function: do_patch_instruction
+comment:        Virtualizing a Windows XP system which tried to reboot.
+
+Truncated backtrace:
+Thread no. 1 (6 frames)
+ #4 do_patch_instruction at ../hw/i386/kvmvapic.c:439
+ #5 process_queued_cpu_work at ../cpus-common.c:347
+ #6 qemu_wait_io_event at ../softmmu/cpus.c:435
+ #7 kvm_vcpu_thread_fn at ../accel/kvm/kvm-accel-ops.c:56
+ #8 qemu_thread_start at ../util/qemu-thread-posix.c:505
+ #10 clone3 at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1643 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1643
new file mode 100644
index 00000000..0ab593a1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1643
@@ -0,0 +1 @@
+Connect to MACVTAP by name
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1644 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1644
new file mode 100644
index 00000000..d1c3c69d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1644
@@ -0,0 +1,14 @@
+qemu 8.0.0 console-gl.c:105: surface_gl_update_texture: Assertion `gls' failed.
+Description of problem:
+run ubuntu20.04 in virtualBox, and run qemu in this ubuntu.
+1. qemu report error at qemu start.
+2. qemu-system-x86_64 can't run myOS with 'virtio-gpu-pci -display sdl,gl=on',
+3. qemu report error: qemu-system-x86_64: ../ui/console-gl.c:105: surface_gl_update_texture: Assertion `gls' failed. Aborted
+Steps to reproduce:
+1. run ubuntu20.04 in virtualBox
+2. qemu config enabled sdl, virglrenderer, opengl, gtk
+3. ./qemu-system-x86_64  -machine q35 -cpu Nehalem -m 1024 -smp 8 -kernel myOS -device virtio-gpu-pci -display sdl,gl=on
+4. qemu report error: qemu-system-x86_64: ../ui/console-gl.c:105: surface_gl_update_texture: Assertion `gls' failed. Aborted
+Additional information:
+qemu-system-x86_64: ../ui/console-gl.c:105: surface_gl_update_texture: Assertion `gls' failed.
+Aborted
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1645 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1645
new file mode 100644
index 00000000..7b5892a7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1645
@@ -0,0 +1,8 @@
+qemu error `hotplug memory" error="QMP command failed: a used vhost backend has no free memory slots left"`
+Description of problem:
+When I create a Qemu VM with 8 Gpus and hot-plugging memory, this will return the error QMP command failed: a used vhost backend has no free memory slots left. I read some source file https://gitlab.com/qemu-project/qemu/-/blob/master/hw/virtio/vhost-user.c#L2077, and debug show u->user->memory_slots is 32, but this https://gitlab.com/qemu-project/qemu/-/blob/master/hw/virtio/vhost.c#L62 used_memslots is bigger than u->user->memory_slots. `u->user->memory_slots` is defined 32 by https://gitlab.com/qemu-project/qemu/-/blob/master/subprojects/libvhost-user/libvhost-user.h#L37, but I also see VHOST_USER_MAX_RAM_SLOTS defined 512 under x86 architecture. Can I improve `u->user->memory_slots` by any way?
+Steps to reproduce:
+1.crate kata containers with 8 Gpus
+2.kata containers return error
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1646 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1646
new file mode 100644
index 00000000..1e7ed29b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1646
@@ -0,0 +1,61 @@
+fstrim dont work after live migrate
+Description of problem:
+We have use lvm thin pool and after live migration non-shared storage fstrim cannot free data usage Data% without reboot, after reboot fstim work fine
+
+```
+  LV      VG Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
+  p639937 vm Vwi-aotz--  30.00g pool        99.35
+
+virsh qemu-agent-command p639937 '{"execute":"guest-fstrim"}'
+{"return":{"paths":[{"minimum":0,"path":"/","trimmed":0}]}}
+
+virsh shutdown p639937
+Domain 'p639937' is being shutdown
+
+virsh start p639937
+Domain 'p639937' started
+
+virsh qemu-agent-command p639937 '{"execute":"guest-fstrim"}'
+{"return":{"paths":[{"minimum":0,"path":"/","trimmed":29178654720}]}}
+
+lvs|grep p639937
+  p639937 vm Vwi-aotz--  30.00g pool        9.58
+```
+
+On source host before migration:
+```
+  LV      VG Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
+  p639937 vm Vwi-a-tz-- 30.00g pool        9.48
+```
+
+migration script 
+```
+SSH_OPTS='-o StrictHostKeyChecking=no -o PasswordAuthentication=no '
+MIGR_OPTS="--live --copy-storage-all --verbose --persistent --undefinesource"
+ssh $SSH_OPTS $HOST -t "[ -b /dev/vm/$ACCT ] || /usr/sbin/lvcreate -V${SIZE}G -T vm/pool -n$ACCT" || f_print_err "Error: creation lvm"
+virsh migrate $MIGR_OPTS $ACCT qemu+ssh://$SERV/system  tcp://local.$SERV/ || f_print_err "Error on step: virsh migrate"
+echo "Waiting for trim start..."
+sleep 10
+ssh $SSH_OPTS $HOST -t "/usr/bin/virsh qemu-agent-command $ACCT --timeout 60 '{\"execute\":\"guest-fstrim\"}' >/dev/null 2>&1"
+```
+
+Disc config:
+```
+    <disk type='block' device='disk'>
+      <driver name='qemu' type='raw' cache='none' io='threads' discard='unmap'/>
+      <source dev='/dev/vm/p639937'/>
+      <backingStore/>
+      <target dev='sda' bus='scsi'/>
+      <iotune>
+        <write_bytes_sec>104857600</write_bytes_sec>
+        <write_bytes_sec_max>524288000</write_bytes_sec_max>
+        <write_bytes_sec_max_length>120</write_bytes_sec_max_length>
+      </iotune>
+      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+    </disk>
+```
+
+Sometimes trimming working after migration, bit this is very rare.
+We have try rescanning disc, drop caches on vm after migration, but didnt help.
+
+Inside vm's ext4 fs and almalinux 8/ubuntu 20+/debian 10-11
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1650 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1650
new file mode 100644
index 00000000..63984c3b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1650
@@ -0,0 +1,14 @@
+Consider doing runtime detection of MAP_FIXED_NOREPLACE
+Description of problem:
+```
+qemu-i386-static: Unable to reserve 0xfffff000 bytes of virtual address space at 0x1000 (Operation not supported) for use as guest address space (check your virtual memory ulimit setting, min_mmap_addr or reserve less using -R option)
+```
+strace says
+```
+ mmap(0x1000, 4294963200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE|MAP_FIXED_NOREPLACE, -1, 0) = -1 EOPNOTSUPP (Operation not supported)
+```
+Steps to reproduce:
+1. `apt install qemu-i386-static 32subsystem`
+2. `strace qemu-i386-static /opt/32/bin/as`
+Additional information:
+Repeating the strace call in a minimal C program gives the same errno as expected -- the kernel is only 4.4. The problem here is that qemu only does `MAP_FIXED_NOREPLACE` feature detection at build-time via a `#ifndef` and even that behavior is poorly documented. Maybe do something at runtime?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1652 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1652
new file mode 100644
index 00000000..0c410f75
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1652
@@ -0,0 +1,32 @@
+make check failed about qemu@master on debian10_aarch64
+Description of problem:
+make check failed about qemu@master on debian10_aarch64
+Steps to reproduce:
+1../configure
+2.make -j16
+3.make -j16 check
+Additional information:
+error:
+>>> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_IMG=./qemu-img G_TEST_DBUS_DAEMON=/home/stage/root/spack-stage-qemu-master-d6wsqaf6ydt7c6frhxqd3nyqhh72vz7v/spack-src/tests/dbus-vmstate-daemon.sh MALLOC_PERTURB_=105 QTEST_QEMU_BINARY=./qemu-system-aarch64 /home/stage/root/spack-stage-qemu-master-d6wsqaf6ydt7c6frhxqd3nyqhh72vz7v/spack-src/build/tests/qtest/migration-test --tap -k
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+stderr:
+Broken pipe
+../tests/qtest/libqtest.c:184: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0)
+
+
+TAP parsing error: Too few tests run (expected 18, got 0)
+(test program exited with status code -6)
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+
+190/627 qemu:qtest+qtest-aarch64 / qtest-aarch64/arm-cpu-features                          ERROR           0.34s   killed by signal 6 SIGABRT
+>>> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_IMG=./qemu-img G_TEST_DBUS_DAEMON=/home/stage/root/spack-stage-qemu-master-d6wsqaf6ydt7c6frhxqd3nyqhh72vz7v/spack-src/tests/dbus-vmstate-daemon.sh MALLOC_PERTURB_=115 QTEST_QEMU_BINARY=./qemu-system-aarch64 /home/stage/root/spack-stage-qemu-master-d6wsqaf6ydt7c6frhxqd3nyqhh72vz7v/spack-src/build/tests/qtest/arm-cpu-features --tap -k
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+stderr:
+qemu-system-aarch64: Failed to retrieve host CPU features
+Broken pipe
+../tests/qtest/libqtest.c:184: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0)
+
+
+TAP parsing error: Too few tests run (expected 5, got 1)
+(test program exited with status code -6)
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1653 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1653
new file mode 100644
index 00000000..cd836920
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1653
@@ -0,0 +1,20 @@
+qemu uses uefi to install the redhad6.0 VM, use the vnc connect it  which is  stuck
+Description of problem:
+I want to use uefi(udk2-->ovmf.fd) to install redhad6.0, but after I enter uefi and start up, I cannot use vnc to connect to it,The screen is black or often stuck, nor can I use the console of other pages, or it is a special slow to be able to use it. It's sure that the virtual machine is not crash. Anad the same operation is normal for redhad6.1 systems.
+Steps to reproduce:
+1.compile udk2 generate ovmf.fd
+compile config: 
+
+make -C BaseTools/Source/C
+
+./OvmfPkg/build.sh -D DEBUG_ON_SERIAL_PORT=true   
+
+
+2.run qemu with "-bios /bin/OVMF.fd"
+
+
+3.use vnc to connet it
+
+![image](/uploads/449ea89c218fe5d7e317db351271672a/image.png)
+
+The screen is stuck can't handle it.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1654 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1654
new file mode 100644
index 00000000..642abe67
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1654
@@ -0,0 +1,81 @@
+Memory out of bounds access vulnerability when guest accesses Block Limits information of SCSI devices
+Description of problem:
+When a guest uses a Linux kernel version 5.19 or higher and uses an scsi device, there will be a memory access violation, which can be clearly seen when ASAN is turned on.
+
+**reason：**
+Linux kernel 5.19 merge commit：
+
+https://github.com/torvalds/linux/commit/c92a6b5d63359dd6d2ce6ea88ecd8e31dd769f6b
+
+The Linux kernel will first issue a header request to obtain the VPD length before obtaining the VPD information. The BUF for obtaining the VPD length is less than 8 bytes. However, QEMU regards the header for obtaining the VPD length as obtaining all VPD information, and a memory access violation occurs when writing information to BUF.
+
+The specific memory out of bounds information is as follows:
+==12430==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+
+==12430==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 
+0x7fffebc1d000; bottom 0x7f61115ee000; size: 0x009eda62f000 (682268749824)
+
+False positive error reports may follow
+
+==12430==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200024d858 at pc 0x55767513791c bp 0x7f6111fcddc0 sp 0x7f6111fcddb0
+
+WRITE of size 4 at 0x60200024d858 thread T0
+
+    #0 0x55767513791b in stl_he_p /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:357
+
+    #1 0x55767513791b in stl_be_p /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:464
+
+    #2 0x55767513791b in scsi_handle_inquiry_reply hw/scsi/scsi-generic.c:173
+
+    #3 0x55767513791b in scsi_read_complete hw/scsi/scsi-generic.c:318
+
+    #4 0x55767545d7c6 in blk_aio_complete block/block-backend.c:1425
+
+    #5 0x557675544d79 in coroutine_trampoline util/coroutine-ucontext.c:115
+
+    #6 0x7f611b9f14df  (/lib/x86_64-linux-gnu/libc.so.6+0x5b4df)
+
+0x60200024d858 is located 4 bytes to the right of 4-byte region [0x60200024d850,0x60200024d854)
+
+allocated by thread T0 here:
+
+    #0 0x557674a987f2 in malloc (/sf/bin/qemu-system-x86_64+0x7827f2)
+
+    #1 0x7f6120141d41 in g_malloc (/usr/lib/libglib256-2.0.so.0+0x61d41)
+
+    #2 0x557675137bb4 in scsi_send_command hw/scsi/scsi-generic.c:459
+
+    #3 0x55767513e902 in scsi_req_enqueue hw/scsi/scsi-bus.c:836
+
+    #4 0x557674c5f26e in virtio_scsi_handle_cmd_req_submit /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi.c:589
+
+    #5 0x557674c5f26e in virtio_scsi_handle_cmd_vq /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi.c:634
+
+    #6 0x557674c61089 in virtio_scsi_data_plane_handle_cmd /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi-dataplane.c:60
+
+    #7 0x557674c9a520 in virtio_queue_notify_aio_vq /root/hci/qemu/qemu-5.0.0/hw/virtio/virtio.c:2338
+
+    #8 0x55767552c7c4 in aio_dispatch_handler util/aio-posix.c:328
+
+SUMMARY: AddressSanitizer: heap-buffer-overflow /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:357 stl_he_p
+Steps to reproduce:
+1. QEMU Enable ASAN
+2. Use a guest with a Linux kernel version greater than 5.19 and mount an scsi physical device
+3. Upon startup, memory out of bounds access can be detected
+Additional information:
+At present, I have made some simple modifications, but I am not sure if this is the best solution and can serve as a reference.
+
+Make a judgment on buflen, ignore the header information issued by the Linux kernel, and write the VPD information when issuing the actual instruction to obtain VPD information.
+
+hw/scsi/scsi-generic.c:scsi_handle_inquiry_reply
+
+```
+if (r->buflen >= 12) {
+    stl_be_p(&r->buf[8], max_transfer);
+}
+if (r->buflen >= 16){
+    /* Also take care of the opt xfer len. */
+    stl_be_p(&r->buf[12],
+        MIN_NON_ZERO(max_transfer, ldl_be_p(&r->buf[12])));
+}
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1655 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1655
new file mode 100644
index 00000000..afd30367
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1655
@@ -0,0 +1 @@
+qemu-7.2.2 build failed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1656 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1656
new file mode 100644
index 00000000..fcb0d249
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1656
@@ -0,0 +1,7 @@
+https://wiki.qemu.org/: TLS certificate has expired (`May 14 21:15:57 2023 GMT`)
+Description of problem:
+The ceritficate for https://wiki.qemu.org/ has expired on May 14 21:15:57 2023 GMT.
+Steps to reproduce:
+1. Browse https://wiki.qemu.org/
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/166 b/gitlab/issues_text/target_missing/host_missing/accel_missing/166
new file mode 100644
index 00000000..7827b94d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/166
@@ -0,0 +1 @@
+qemu-bridge-helper failure but qemu not exit
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1662 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1662
new file mode 100644
index 00000000..d2430b3f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1662
@@ -0,0 +1,35 @@
+qemu-system-loongarch64  start Loongnix system coredump
+Description of problem:
+
+Steps to reproduce:
+1. build qemu: 
+   ./configure --prefix=/usr  --disable-werror --disable-gtk  --target-list="loongarch64-softmmu"\
+        --enable-debug 
+         make -j32
+2. get bios and qcow2:
+   wget https://mirrors.wsyu.edu.cn/loongarch/archlinux/images/QEMU_EFI_7.2.fd
+   wget http://pkg.loongnix.cn/loongnix/isos/Loongnix-20.4/Loongnix-20.4.cartoon.gui.loongarch64.en.qcow2
+3. start Loongnix
+   ./build/qemu-system-loongarch64 \
+    -m 8G \
+    -cpu la464 \
+    -machine virt \
+    -smp 16 \
+    -bios ./QEMU_EFI_7.2.fd \
+    -serial stdio  \
+    -device virtio-gpu-pci \
+    -net nic -net user \
+    -device nec-usb-xhci,id=xhci,addr=0x1b \
+    -device usb-tablet,id=tablet,bus=xhci.0,port=1 \
+    -device usb-kbd,id=keyboard,bus=xhci.0,port=2 \
+    -device virtio-blk-pci,drive=test -drive if=none,id=test,file=./Loongnix-20.4.cartoon.gui.loongarch64.en.qcow2
+
+4. VNC connect
+5. use the system
+   login  loongson/Loongson20 
+6. qemu coredump 
+
+   qemu-system-loongarch64: /root/work/qemu/include/tcg/tcg.h:675: temp_idx: Assertion `n >= 0 && n < tcg_ctx->nb_temps' failed.
+./start-loongnix.sh: line 13: 40242 Aborted                 (core dumped) ./build/qemu-system-loongarch64 -m 8G -cpu la464 -machine virt -smp 16 -bios ./QEMU_EFI_7.2.fd -serial stdio -device virtio-gpu-pci -net nic -net user -device nec-usb-xhci,id=xhci,addr=0x1b -device usb-tablet,id=tablet,bus=xhci.0,port=1 -device usb-kbd,id=keyboard,bus=xhci.0,port=2 -device virtio-blk-pci,drive=test -drive if=none,id=test,file=./Loongnix-20.4.cartoon.gui.loongarch64.en.qcow2
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1663 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1663
new file mode 100644
index 00000000..9ef0f650
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1663
@@ -0,0 +1,34 @@
+make check-venv fails with errors about incompatible avocado
+Description of problem:
+```
+$ rm -rf build/
+$ ./configure --target-list=x86_64-softmmu,i386-softmmu
+$ make -j 16
+$ ./scripts/device-crash-test -q --tcg-only ./qemu-system-i386
+Module 'qemu' not found.
+  Try 'make check-venv' from your build directory,
+  and then one way to run this script is like so:
+  > $builddir/pyvenv/bin/python3 "/home/berrange/src/virt/qemu/scripts/device-crash-test"
+$ make check-venv
+make[1]: Entering directory '/home/berrange/src/virt/qemu/build'
+  GIT     ui/keycodemapdb tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc
+  VENVPIP install -e /home/berrange/src/virt/qemu/python/
+  VENVPIP install -r /home/berrange/src/virt/qemu/tests/requirements.txt
+ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
+avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 101.0 which is incompatible.
+avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 101.0 which is incompatible.
+make[1]: Leaving directory '/home/berrange/src/virt/qemu/build'
+```
+
+Despite this, it seems to have at least partially populated the venv, since I can now run device-crash-test.
+
+My host does have some avocado related python bits present:
+
+```
+python-avocado-common-98.0-1.module_f38+15908+ffe8d4e2.noarch
+python3-avocado-98.0-1.module_f38+15908+ffe8d4e2.noarch
+python3-avocado-plugins-output-html-98.0-1.module_f38+15908+ffe8d4e2.noarch
+python3-avocado-plugins-varianter-yaml-to-mux-98.0-1.module_f38+15908+ffe8d4e2.noarch
+```
+
+I would expect the venv to not use these host packages however, since they're outdated compare to what QEMU askes for in tests/requirements.txt
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1664 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1664
new file mode 100644
index 00000000..59c12a3a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1664
@@ -0,0 +1 @@
+mingw64 cross compile: libslirp from subproject fails to link, undefined reference to WinMain
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1665 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1665
new file mode 100644
index 00000000..1ad56086
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1665
@@ -0,0 +1 @@
+When using the"yum install qemu-kvm" command in in rhel 9 , it is not possible to proceed past the "Windows Installer Select Disk" page by iso install
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1666 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1666
new file mode 100644
index 00000000..00ddeafc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1666
@@ -0,0 +1 @@
+About the develop environment
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1669 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1669
new file mode 100644
index 00000000..e018bf31
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1669
@@ -0,0 +1,11 @@
+In the ARM environment, using pci-ohci with specific OS (CentOS-8-aarch64-1905-dvd1.iso) to start a virtual machine, will cause the memory leak
+Description of problem:
+
+Steps to reproduce:
+1.Using the pci-ohci as the USB controller to start the VM;
+
+2.install the OS using the CentOS-8-aarch64-1905-dvd1.iso ;
+
+3.The QEMU process is taking up more and more memory, which looks like Memory leak
+Additional information:
+![bugreport](/uploads/63af75a469be21e7ce734a22a3dcf33c/bugreport.PNG)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/167 b/gitlab/issues_text/target_missing/host_missing/accel_missing/167
new file mode 100644
index 00000000..85045ca7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/167
@@ -0,0 +1 @@
+qemu 4.0 doesnt support glsl 3.0 but yes older versions, that have no sense IMO
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1670 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1670
new file mode 100644
index 00000000..fea5bf20
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1670
@@ -0,0 +1,9 @@
+Cannot statically build x86_64-softmmu with Darwin(Intel)
+Description of problem:
+I am using `Podman` and currently,`Podman` uses qemu on macOS. The `Podman` team has adopted a scheme to dynamically compile `qemu` (https://github.com/containers/podman-machine-qemu). However, I am currently trying to use static compilation for both amd64 and arm64 targets.
+
+I have searched many articles online, most of which are about static compilation on Linux. Very few articles mention static compilation on macOS, and some mention that `softmmu` does not support static compilation. However, I have not found any concrete evidence to support this claim.
+
+I also want to ask another question: Does `qemu` support static compilation on macOS?
+Additional information:
+[meson-log.txt](/uploads/6e32691488533a06c64dc34ee4514135/meson-log.txt)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1672 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1672
new file mode 100644
index 00000000..f5d9b1d2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1672
@@ -0,0 +1,8 @@
+failed to migrate using multifd with multifd-channels larger than 2
+Description of problem:
+try to using multifd live migration on QEMU v8.0.0 using multifd channels larger than 2, but failed.
+Steps to reproduce:
+1. start source / dest qemu vm
+2. migrate_set_capability multifd on && migrate_set_parameter multifd-channels 8
+
+then live migration will failed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1673 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1673
new file mode 100644
index 00000000..96fe071b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1673
@@ -0,0 +1,49 @@
+compilation of 8.0.0 FAILED: target/hexagon/idef-generated-emitter.indented.c on ubuntu 18.04
+Description of problem:
+Cannot compile on ubuntu 18.04.
+Steps to reproduce:
+1. get 8.0.0 tarball or git clone/submodule... on a ubuntu 18.04 system (with a few more recent tools in ~/opt, such as python 3.9)
+2. ./configure --prefix=$HOME/opt && make
+3. It finishes with this strange error: FAILED: target/hexagon/idef-generated-emitter.indented.c
+```
+...
+[850/10154] Compiling C object target/hexagon/idef-parser.p/meson-generated_idef-parser.yy.c.o
+[851/10154] Compiling C object target/hexagon/idef-parser.p/meson-generated_idef-parser.tab.c.o
+[852/10154] Compiling C object target/hexagon/idef-parser.p/_home_pbourguignon_opt_src_qemu-8.0.0_target_hexagon_idef-parser_parser-helpers.c.o
+[853/10154] Linking target target/hexagon/idef-parser
+[854/10154] Generating target/hexagon/idef-generated-tcg with a custom command
+[855/10154] Generating target/hexagon/indent with a custom command
+FAILED: target/hexagon/idef-generated-emitter.indented.c
+/home/pbourguignon/bin/indent -linux target/hexagon/idef-generated-emitter.c -o target/hexagon/idef-generated-emitter.indented.c
+Indenting region...
+Indenting region... done
+Directory `/home/pbourguignon/opt/src/qemu-8.0.0/build/-linux target/hexagon/idef-generated-emitter.c -o target/hexagon/' does not exist; create? (y or n) Error reading from stdin
+ninja: build stopped: subcommand failed.
+Makefile:165: recipe for target 'run-ninja' failed
+make[1]: *** [run-ninja] Error 1
+make[1]: Leaving directory '/home/pbourguignon/opt/src/qemu-8.0.0/build'
+GNUmakefile:10: recipe for target 'all' failed
+make: *** [all] Error 2
+```
+Additional information:
+https://dpaste.org/Hr9Zq
+```
+~/opt/src/qemu-git
+16:15[pbourguignon@frprld7818008 :0.0 qemu-git ]$ ls ~/opt/bin
+./	      ecl-config*     pydoc3@		 run-avr*      run-microblaze*
+../	      emacs@	      pydoc3.9*		 run-bfin*     run-mips*
+2to3@	      emacs-27.2*     python@		 run-bpf*      run-mn10300*
+2to3-3.9*     emacsclient*    python3@		 run-cr16*     run-moxie*
+bundle*       erb*	      python3-config@	 run-cris*     run-msp430*
+bundler*      etags*	      python3.9*	 run-d10v*     run-or1k*
+ccl*	      gcore*	      python3.9-config*  run-erc32*    run-ppc*
+ccmake*       gdb*	      racc*		 run-frv*      run-pru*
+cmake*	      gdb-add-index*  rake*		 run-ft32*     run-riscv*
+cpack*	      gdbserver*      rbs*		 run-h8300*    run-rl78*
+ctags*	      gem*	      rdbg*		 run-iq2000*   run-rx*
+ctest*	      idle3@	      rdoc*		 run-lm32*     run-sh*
+curl*	      idle3.9*	      ri*		 run-m32c*     run-v850*
+curl-config*  irb*	      ruby*		 run-m32r*     sbcl*
+ebrowse*      pip3*	      run-aarch64*	 run-m68hc11*  sis*
+ecl*	      pip3.9*	      run-arm*		 run-mcore*    typeprof*
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1674 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1674
new file mode 100644
index 00000000..31b27860
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1674
@@ -0,0 +1,23 @@
+Arrow key not functional in QEMU monitor when using nographic on Windows 11 host
+Description of problem:
+The arrow keys do not work on the Windows QEMU when using -nographic option. On the Linux QEMU they work.
+Steps to reproduce:
+1. Download the qemu source code from https://download.qemu.org/qemu-8.0.0.tar.xz. THe sha256sum of the file is bb60f0341531181d6cc3969dd19a013d0427a87f918193970d9adb91131e56d0.
+2. Prepare the build system on MSYS2 according to the instructions on https://wiki.qemu.org/Hosts/W32#Native_builds_with_MSYS2.
+3. Uncompress the source code using `tar -xf qemu-8.0.0.tar.xz`.
+4. Change the working directory to qemu-8.0.0/. The build configuration command is `./configure --target-list=arm-softmmu --extra-cflags="-g -ggdb"`
+5. Run the command `./qemu-system-arm -s -S -M virt -nographic`.
+6. Press Ctrl-C A to switch to QEMU monitor.
+7. Input "help" command to the monitor.
+8. Press Arrow-Up key.
+9. The previous "help" command does not appear in the monitor prompt.
+Additional information:
+1. The pre-built binary downloaded from https://qemu.weilnetz.de/w64/qemu-w64-setup-20230424.exe has the same behaviour.
+2. The QEMU from MSYS2, `pacman -S mingw-w64-x86_64-qemu`, has the same behaviour.
+3. If the "-nographic" option is removed, the arrow-up key works in the GTK console.
+4. Neither of arrow-up, arrow-down, arrow-right, arrow-left key work.
+5. If the valid kernel and rootfs are added in the command line by "-kernel" and "-initrd" options, neither key work after booting to the Linux successfully.
+6. If the code `dwMode |= ENABLE_LINE_INPUT;` in the function `qemu_chr_open_stdio()` is changed to `dwMode |= ENABLE_LINE_INPUT|ENABLE_VIRTUAL_TERMINAL_INPUT;`, build again. All arrow keys work.
+7. The VT sequence support was added in `EmulatorPkg/Win/Host/WinThunk.c` by this commit https://gitlab.com/qemu-project/edk2/-/commit/5601e90d5cdbc4cea748e00e34ae07ce39bd700f.
+8. The above commit is to add VT sequence support at compile-time. Microsoft provides some code to enable it at run-time on https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences#example-of-enabling-virtual-terminal-processing.
+9. The function readline_handle_byte() is not called when the VT sequence is not enabled.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1675 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1675
new file mode 100644
index 00000000..947ba037
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1675
@@ -0,0 +1 @@
+virtual machines still randomly crashing on kernel 6.1.30
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1676 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1676
new file mode 100644
index 00000000..6ce8bf94
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1676
@@ -0,0 +1,7 @@
+Signed release tarball for 8.0.2 is missing
+Description of problem:
+Hi! I package QEMU for Arch Linux. I usually rely on the signed tarballs (which are also linked to from the website).
+For [8.0.2](https://gitlab.com/qemu-project/qemu/-/tags/v8.0.2) there does not seem to be a signed tarball though.
+Steps to reproduce:
+1. Try to update to 8.0.2 using a signed tarball
+2. Find no signed tarball in https://download.qemu.org/
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1677 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1677
new file mode 100644
index 00000000..5cca58e5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1677
@@ -0,0 +1,13 @@
+qemu-system-x86_64 cannot run on Windows when -smp is specified with a value higher than `1`. An important argument for any expectation of VM performance
+Description of problem:
+qemu-system-x86_64 seems to crash on Windows the moment you try to use -smp to define more vcpus, even the basic usage of `-smp 4` will cause qemu to segfault after the guest's boot option is selected.
+Steps to reproduce:
+1. `qemu-system-x86_64 -smp 4 -cdrom rhel-9.2-x86_64-dvd.iso -drive if=pflash,format=raw,unit=0,readonly=on,file=edk2-x64/OVMF_CODE.fd -m 6G -nodefaults -serial mon:stdio`
+2. Select the boot option to begin your installation
+3. qemu hangs for 10 or so seconds then throws a Segmentation Fault.
+Additional information:
+1. This does not happen if -smp arguments are omitted, but running VMs with a single vcpu thread is slow and painful.
+2. This still happens even without OVMF (Traditional bios booting)
+3. This still happens even without -defaults and without a serial device
+
+Only output from qemu at death is `Segmentation fault`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1679 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1679
new file mode 100644
index 00000000..3638ffb4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1679
@@ -0,0 +1,15 @@
+Running Qemu on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work.Enter the issue title
+Description of problem:
+Running QemuV8.0 on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work.
+Steps to reproduce:
+1.qemu-img.exe create hdd.img 10G
+
+2.qemu-system-x86_64.exe -m 8096 hdd.img -cdrom ubuntu22.04-desktop-amd64.iso  -machine pc
+Additional information:
+both Use qemu v8.0 and qemu v8.1 to test, but failed also
+
+
+
+Thanks,
+
+Jianbin
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1680 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1680
new file mode 100644
index 00000000..5f4c39e9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1680
@@ -0,0 +1,102 @@
+qemu-system-x86_64: ../softmmu/memory.c:1111: memory_region_transaction_commit: Assertion `qemu_mutex_iothread_locked()' failed.
+Description of problem:
+While testing master build, I have the following crash on shutdown of the VM:
+qemu-system-x86_64: ../softmmu/memory.c:1111: memory_region_transaction_commit: Assertion `qemu_mutex_iothread_locked()' failed.
+Steps to reproduce:
+1. Run VM
+2. Once booted, do poweroff inside the Linux VM
+3. When poweroff completes, qemu crashes.
+Additional information:
+```(gdb) bt full
+#0  0x00007ffff29edacf in raise () at /lib64/libc.so.6
+#1  0x00007ffff29c0ea5 in abort () at /lib64/libc.so.6
+#2  0x00007ffff29c0d79 in _nl_load_domain.cold.0 () at /lib64/libc.so.6
+#3  0x00007ffff29e6426 in  () at /lib64/libc.so.6
+#4  0x0000555555bed6d3 in memory_region_transaction_commit () at ../softmmu/memory.c:1111
+        as = <optimized out>
+        __PRETTY_FUNCTION__ = "memory_region_transaction_commit"
+#5  0x0000555555bef2bf in memory_region_add_eventfd (mr=mr@entry=0x555557c318a0, addr=<optimized out>, size=size@entry=0, match_data=<optimized out>, data=<optimized out>, e=<optimized out>) at ../softmmu/memory.c:2583
+        mrfd = {addr = {start = 0, size = 0}, match_data = false, data = 0, e = 0x555557c41aa4}
+        i = <optimized out>
+#6  0x0000555555a2c85c in virtio_pci_ioeventfd_assign (d=0x555557c30a00, notifier=0x555557c41aa4, n=0, assign=<optimized out>) at ../hw/virtio/virtio-pci.c:347
+        proxy = 0x555557c30a00
+        vdev = <optimized out>
+        vq = <optimized out>
+        legacy = true
+        modern = <optimized out>
+        fast_mmio = true
+        modern_pio = false
+        modern_mr = <optimized out>
+        modern_notify_mr = 0x555557c319c0
+        legacy_mr = 0x555557c31430
+        modern_addr = <optimized out>
+#7  0x0000555555a2be78 in virtio_bus_set_host_notifier (bus=0x555557c38d50, n=n@entry=0, assign=assign@entry=true) at ../hw/virtio/virtio-bus.c:296
+        vdev = <optimized out>
+        k = 0x555556a7b620
+        proxy = 0x555557c30a00
+        vq = 0x555557c41a30
+        notifier = 0x555557c41aa4
+        r = <optimized out>
+        __func__ = "virtio_bus_set_host_notifier"
+#8  0x0000555555ba1595 in virtio_scsi_set_host_notifier (s=s@entry=0x555557c38dd0, n=n@entry=0, vq=<optimized out>) at /root/qemu/include/hw/virtio/virtio-bus.h:35
+        qbus = <optimized out>
+        rc = <optimized out>
+#9  0x0000555555ba1860 in virtio_scsi_dataplane_start (vdev=<optimized out>) at ../hw/scsi/virtio-scsi-dataplane.c:130
+        i = <optimized out>
+        rc = <optimized out>
+        vq_init_count = 0
+        qbus = 0x555557c38d50
+        k = 0x555556a7b620
+        vs = 0x555557c38dd0
+        s = 0x555557c38dd0
+#10 0x0000555555a2bbd2 in virtio_bus_start_ioeventfd (bus=0x555557c38d50) at ../hw/virtio/virtio-bus.c:236
+        k = <optimized out>
+        proxy = 0x555557c30a00
+        vdev = 0x555557c38dd0
+        vdc = 0x555556a19cc0
+        r = <optimized out>
+        __func__ = "virtio_bus_start_ioeventfd"
+#11 0x0000555555bc0739 in virtio_device_start_ioeventfd (vdev=vdev@entry=0x555557c38dd0) at ../hw/virtio/virtio.c:3741
+        qbus = <optimized out>
+        vbus = <optimized out>
+#12 0x0000555555b9fc80 in virtio_scsi_defer_to_dataplane (s=0x555557c38dd0) at ../hw/scsi/virtio-scsi.c:614
+        s = 0x555557c38dd0
+#13 0x0000555555b9fc80 in virtio_scsi_defer_to_dataplane (s=0x555557c38dd0) at ../hw/scsi/virtio-scsi.c:608
+        s = 0x555557c38dd0
+#14 0x0000555555b9fc80 in virtio_scsi_handle_event (vdev=<optimized out>, vq=<optimized out>) at ../hw/scsi/virtio-scsi.c:1011
+        s = 0x555557c38dd0
+#15 0x0000555555bba2af in virtio_queue_notify_vq (vq=0x555557c41ac8) at ../hw/virtio/virtio.c:2248
+        vdev = 0x555557c38dd0
+#16 0x0000555555de7b08 in aio_dispatch_handler (ctx=ctx@entry=0x555556c2c130, node=0x555557ffbff0) at ../util/aio-posix.c:356
+        progress = false
+        poll_ready = true
+        revents = <optimized out>
+#17 0x0000555555de861c in aio_dispatch_ready_handlers (ready_list=0x7fffde952fe8, ctx=0x555556c2c130) at ../util/aio-posix.c:401
+        progress = false
+        node = <optimized out>
+        ready_list = {lh_first = 0x0}
+        progress = true
+        use_notify_me = <optimized out>
+        timeout = <optimized out>
+        start = <optimized out>
+        __PRETTY_FUNCTION__ = "aio_poll"
+#18 0x0000555555de861c in aio_poll (ctx=0x555556c2c130, blocking=blocking@entry=true) at ../util/aio-posix.c:723
+        ready_list = {lh_first = 0x0}
+        progress = true
+        use_notify_me = <optimized out>
+        timeout = <optimized out>
+        start = <optimized out>
+        __PRETTY_FUNCTION__ = "aio_poll"
+#19 0x0000555555ca9ae6 in iothread_run (opaque=opaque@entry=0x555556943200) at ../iothread.c:63
+        iothread = 0x555556943200
+#20 0x0000555555deaf6a in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:541
+        __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {93825016192880, 1094026140696841148, 140737488341294, 140737488341295, 140737488341440, 140736927707584, 6520036150746942396, 1094028099712322492}, __mask_was_saved = 0}}, __pad = {0x7fffde953110, 0x0, 0x0, 0x0}}
+        __cancel_routine = 0x555555deafc0 <qemu_thread_atexit_notify>
+        __not_first_call = <optimized out>
+        qemu_thread_args = <optimized out>
+        start_routine = 0x555555ca9aa0 <iothread_run>
+        arg = 0x555556943200
+        r = <optimized out>
+#21 0x00007ffff2d6c1ca in start_thread () at /lib64/libpthread.so.0
+#22 0x00007ffff29d8e73 in clone () at /lib64/libc.so.6
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1681 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1681
new file mode 100644
index 00000000..84d2f77d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1681
@@ -0,0 +1,49 @@
+watchdog: BUG: soft lockup - CPU#N stuck for XXs!
+Description of problem:
+Repeatedly seeing Qemu VMs locking up with guest Linux kernel reporting:
+"watchdog: BUG: soft lockup - CPU#<N> stuck for <XX>s!"
+e.g.: "watchdog: BUG: soft lockup - CPU#5 stuck for 26s! [swapper/5:0]"
+
+When the guest VM is in this condition, the host Linux OS reports that the Qemu process is typically running steadily at ~250% CPU.
+Steps to reproduce:
+1. Windows 10 on an x64 PC (right on the metal).
+2. VMWare Workstation running Fedora Workstation 38 x64 guest, in turn acting as host with nested virtualization.
+3. Qemu 7.2.1 running on Fedora host with Fedora Server 38 x64 guest.
+4. Invoke Qemu using F38 QCow2 image: `$ qemu-system-x86_64 -machine pc -cpu max -smp 8 -accel kvm -accel hvf -accel tcg -m 3G -nographic -hda Client.qcow2 -nic socket,model=virtio-net-pci,mcast=239.1.2.3:4567,mac=4a:e0:72:85:c0:fb -nic user,model=virtio-net-pci,mac=4a:e0:d8:cd:a5:e6,hostfwd=tcp:127.0.0.1:2288-:22`
+5. Not necessarily right away, but pretty consistently if left running overnight, guest Linux kernel repeatedly reports CPU(s) stuck, guest VM is unresponsive
+6. Host Linux `top` reports Qemu process using ~250% CPU.
+Additional information:
+Console log attached, small sample here:
+
+```
+[  181.101152] watchdog: BUG: soft lockup - CPU#5 stuck for 26s! [swapper/5:0]
+[  181.145578] Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nfg
+[  181.145578] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 6.2.9-300.fc38.x86_64 #1
+[  181.145578] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014
+[  181.145578] RIP: 0010:netif_receive_skb_list_internal+0x58/0x300
+[  181.145578] Code: 4c 89 74 24 08 49 89 ec 4c 89 74 24 10 4c 8b 6d 00 48 39 ef 75 14 eb 7c 49 8b 8
+[  181.145578] RSP: 0018:ff5a086d401b8da8 EFLAGS: 00000202
+[  181.145578] RAX: 0000000000000000 RBX: ff2d02b1b404c910 RCX: 0000000000000100
+[  181.145578] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ff2d02b1b404c910
+[  181.145578] RBP: ff2d02b18998a600 R08: 0000000000000001 R09: ff2d02b188bd5d00
+[  181.145578] R10: 000000000000000c R11: ffa7ad3980175000 R12: ff2d02b18998a600
+[  181.145578] R13: ff2d02b1b404c910 R14: ff5a086d401b8db0 R15: ff2d02b1882d19c0
+[  181.145578] FS:  0000000000000000(0000) GS:ff2d02b23cb40000(0000) knlGS:0000000000000000
+[  181.145578] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[  181.145578] CR2: 00007f232000f0d8 CR3: 0000000027010000 CR4: 0000000000751ee0
+[  181.145578] PKRU: 55555554
+[  181.145578] Call Trace:
+[  181.145578]  <IRQ>
+[  181.145578]  napi_complete_done+0x6e/0x1a0
+[  181.145578]  virtnet_poll+0x420/0x550 [virtio_net]
+[  181.145578]  __napi_poll+0x2b/0x1b0
+[  181.145578]  net_rx_action+0x2a5/0x360
+[  181.145578]  ? vp_vring_interrupt+0x73/0x90
+[  181.145578]  __do_softirq+0xfd/0x31a
+[  181.145578]  __irq_exit_rcu+0xd7/0x140
+[  181.145578]  common_interrupt+0xb9/0xd0
+[  181.145578]  </IRQ>
+[  181.145578]  <TASK>
+[  181.145578]  asm_common_interrupt+0x22/0x40
+[  181.145578] RIP: 0010:native_safe_halt+0xb/0x10
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1682 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1682
new file mode 100644
index 00000000..9139826d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1682
@@ -0,0 +1,3 @@
+QEMU-USER macOS support
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1683 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1683
new file mode 100644
index 00000000..566b1418
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1683
@@ -0,0 +1 @@
+How to run qemu inside ubuntu:latest docker container?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1685 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1685
new file mode 100644
index 00000000..8c58a67e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1685
@@ -0,0 +1,59 @@
+QEMU segfaults when I restart Windows 11 VM with virtio-vga-gl
+Description of problem:
+When I restart the Windows 11 VM with the virtio GPU DoD driver installed, QEMU crashes with a SIGSEGV. This also happens if I try to uninstall this driver in the Device Manager. I attached the backtrace.
+Steps to reproduce:
+1. Install Windows 11 into the VM;
+2. Install virtio GPU DoD driver;
+3. Click Start -> Power -> Restart.
+Additional information:
+virtio-win version: 0.1.229
+
+Backtrace:
+```
+Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
+[Switching to Thread 0x7ffff64a3e80 (LWP 118206)]
+_mesa_TexParameteri () at ../mesa-23.1.1/src/mesa/main/texparam.c:1248
+1248       texObj = _mesa_get_texobj_by_target_and_texunit(ctx, target,                                                                                                 
+(gdb) bt
+#0  _mesa_TexParameteri() () at ../mesa-23.1.1/src/mesa/main/texparam.c:1248
+#1  0x00007ffece03cba2 in _mesa_unmarshal_TexParameteri () at src/mapi/glapi/gen/marshal_generated0.c:5332
+#2  0x00007ffecdf1bb30 in glthread_unmarshal_batch() () at ../mesa-23.1.1/src/mesa/main/glthread.c:122
+#3  0x00007ffecdf269c2 in _mesa_glthread_finish () at ../mesa-23.1.1/src/mesa/main/glthread.c:382
+#4  _mesa_glthread_finish() () at ../mesa-23.1.1/src/mesa/main/glthread.c:347
+#5  0x00007ffecdebd20f in dri_make_current () at ../mesa-23.1.1/src/gallium/frontends/dri/dri_context.c:303
+#6  dri_make_current () at ../mesa-23.1.1/src/gallium/frontends/dri/dri_context.c:287
+#7  driBindContext() () at ../mesa-23.1.1/src/gallium/frontends/dri/dri_util.c:701
+#8  0x00007ffee6e8693f in dri3_bind_context () at ../mesa-23.1.1/src/glx/dri3_glx.c:181
+#9  0x00007ffee6e78075 in MakeContextCurrent () at ../mesa-23.1.1/src/glx/glxcurrent.c:149
+#10 0x00007ffee7c84e73 in InternalMakeCurrentVendor
+    (dpy=dpy@entry=0x5555570fe3b0, draw=draw@entry=90177544, read=read@entry=90177544, ctxInfo=ctxInfo@entry=0x5555579418b0, callerOpcode=callerOpcode@entry=5 '\005', threadState=threadState@entry=0x55555702fbe0, vendor=0x55555707f520) at ../libglvnd-v1.6.0/src/GLX/libglx.c:871
+#11 0x00007ffee7c8bce1 in CommonMakeCurrent (dpy=0x5555570fe3b0, draw=90177544, read=90177544, context=0x55555780f760, callerOpcode=<optimized out>)
+    at ../libglvnd-v1.6.0/src/GLX/libglx.c:1053
+#12 0x00007ffff51f90b1 in X11_GL_MakeCurrent (_this=0x5555570c1aa0, window=<optimized out>, context=0x55555780f760)
+    at /usr/src/debug/sdl2/SDL2-2.26.5/src/video/x11/SDL_x11opengl.c:865
+#13 0x00007ffff51d0a3f in SDL_GL_MakeCurrent_REAL (window=0x5555570048b0, ctx=0x55555780f760) at /usr/src/debug/sdl2/SDL2-2.26.5/src/video/SDL_video.c:4120
+#14 0x00007ffff6492b86 in sdl2_gl_switch () at ../qemu-8.0.2/ui/sdl2-gl.c:83
+#15 0x000055555598efe2 in displaychangelistener_gfx_switch () at ../qemu-8.0.2/ui/console.c:1158
+#16 0x00005555559997aa in dpy_gfx_replace_surface () at ../qemu-8.0.2/ui/console.c:1815
+#17 0x0000555555d03398 in vga_draw_graphic () at ../qemu-8.0.2/hw/display/vga.c:1589
+#18 vga_update_display () at ../qemu-8.0.2/hw/display/vga.c:1789
+#19 vga_update_display () at ../qemu-8.0.2/hw/display/vga.c:1762
+#20 0x0000555555998acb in graphic_hw_update () at ../qemu-8.0.2/ui/console.c:234
+#21 0x00007ffff6493952 in sdl2_gl_refresh () at ../qemu-8.0.2/ui/sdl2-gl.c:113
+#22 0x000055555599d79a in dpy_refresh () at ../qemu-8.0.2/ui/console.c:1852
+#23 gui_update () at ../qemu-8.0.2/ui/console.c:169
+#24 0x0000555555fd9690 in timerlist_run_timers () at ../qemu-8.0.2/util/qemu-timer.c:576
+#25 0x0000555555fd97b4 in timerlist_run_timers () at ../qemu-8.0.2/util/qemu-timer.c:509
+#26 qemu_clock_run_timers () at ../qemu-8.0.2/util/qemu-timer.c:590
+#27 qemu_clock_run_all_timers () at ../qemu-8.0.2/util/qemu-timer.c:672
+#28 0x0000555555fd9a53 in main_loop_wait () at ../qemu-8.0.2/util/main-loop.c:603
+#29 0x0000555555e1ab17 in qemu_main_loop () at ../qemu-8.0.2/softmmu/runstate.c:731
+--Type <RET> for more, q to quit, c to continue without paging--c
+#30 qemu_default_main () at ../qemu-8.0.2/softmmu/main.c:37
+#31 0x00007ffff6c15850 in __libc_start_call_main (main=main@entry=0x55555598baa0 <main>, argc=argc@entry=33, argv=argv@entry=0x7fffffffd338)
+    at ../sysdeps/nptl/libc_start_call_main.h:58
+#32 0x00007ffff6c1590a in __libc_start_main_impl
+    (main=0x55555598baa0 <main>, argc=33, argv=0x7fffffffd338, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd328)
+    at ../csu/libc-start.c:360
+#33 0x000055555598e6f5 in _start ()
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1686 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1686
new file mode 100644
index 00000000..d747734a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1686
@@ -0,0 +1,43 @@
+VPS does not boots with CPU Model QEMU64 or KVM64
+Description of problem:
+
+Steps to reproduce:
+1. Boot the VPS using AlmaLinux 9 ISO / image and it boots to kernel panic
+Additional information:
+VNC shows this message :
+
+[ 1.749935] do_exit.cold+0x14/0x9f
+
+[1.7502581 do_group_exit+0x33/0xa0
+
+1.7506001 _x64_sys_exit_group+0x14/0x20
+
+1.7510081 do_syscall 64+0x5c/0x90
+
+[1.751361] ? syscall_exit_to_user_mode+0x12/0x30
+
+[1.7517911 ? do_syscall_64+0x69/0x90
+
+[1.752131] ? do_user_addr_fault+0x1d8/0x698
+
+[1.7525091 ? exc_page_fault+0x62/0x150 1.752896] entry_SYSCALL_64_after_hwframe+ +0x63/0xcd
+
+[1.753612] RIP: 0033:0x7fb0e95b62d1
+
+[ 1.7539561 Code: c3 of 1f 84 00 00 00 00 00 f3 Of le fa be e7 00 00 00 ba 3c 00 00 00 eb Od 89 de Of 05 48 3d 00 fe ff ff 77 1c f4 89 fe of 05 <48> 3d 00 fe ff ff 76 e7 f7 d8 89 05 ff fe 00 00 eb dd of 1f 44 00
+
+[ 1.755047] RSP: 002b:00007ffe484df 288 EFLAGS: 00000246 ORIG_RAX: 00000000000
+
+000e7
+
+[ 1.755590] RAX: fffff ffffda RBX: 00007fb0e95b0f30 RCX: 00007fb0e95b62d1 1.756100] RDX: 000000000000003c RSI: 00000000000000e7 RDI: 000000000000007f
+
+[1.756565] RBP: 00007ffe484df410 R08: 00007ffe484dedf9 R09: 0000000000000000
+
+[ 1.757034] R10: 00000000ffffffff R11: 0000000000000246 R12: 00007fb0e958f000
+
+[ 1.7574981 R13: 0000002300000007 R14: 0000000000000007 R15: 00007ffe484df420
+
+[ 1.7579921 Kernel Offset: 0x3aa00000 from Oxffffffff81000000 (relocation ran ge: 0xffffffff80000000-0xffffffffbfffffff)
+
+[ 1.7589051---[ end Kernel panic code=0x00007f00 --- not syncing: Attempted to kill init! exit
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1687 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1687
new file mode 100644
index 00000000..1c685f4f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1687
@@ -0,0 +1,53 @@
+Memory leak for x86 guest on macOS ARM host
+Description of problem:
+QEMU is used by docker to run `x86` binaries on Apple silicon. Then using `mmap` followed by `munmap` results in a memory leak manifested by continuously growing RSS memory usage when running `mmap` and `munmap` in a loop, e.g., when running the following binary:
+
+```
+#include <stdio.h>
+#include <unistd.h>
+#include <sys/mman.h>
+
+const int page = 4096;
+
+int work(int N) {
+  int *ptr = mmap(NULL, N * sizeof(int), PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
+
+  if (ptr == MAP_FAILED) {
+    printf("Mapping Failed\n");
+    return 1;
+  }
+
+  for(int i = 0; i < N; i++) {
+    ptr[i] = i * 10;
+  }
+
+  int err = munmap(ptr, N * sizeof(int));
+  if (err != 0) {
+    printf("UnMapping Failed\n");
+    return 1;
+  }
+
+  return 0;
+}
+
+int main() {
+  int N = page * 1024;
+
+  while (1) {
+    int res = work(N);
+    if (res) {
+      return res;
+    }
+    printf(".\n");
+  }
+
+  return 0;
+}
+```
+Steps to reproduce:
+```
+$ LEAK=$(docker run --platform linux/amd64 -d -it martin2718/mmap-leak ./a.out)
+$ docker exec -it $LEAK top        # you should observe that RES for a.out keeps growing
+$ docker exec -it $LEAK pmap -x 1  # you should see a single memory mapping whose RSS memory usage keeps growing
+$ docker kill $LEAK                # abort the experiment
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1689 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1689
new file mode 100644
index 00000000..ec6c997a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1689
@@ -0,0 +1,11 @@
+memory backend file unnecessarily requires write permission while it is only mapped privately
+Description of problem:
+One day I wanted to boot the machine with physical memory initialized with a file, in a copy-on-write style. That is why I tried out `-mem-path` and `-object memory-backend-file`. Actually `-mem-path` already works if not considering that qemu dislikes the backing file being readonly and requires it to be writeable even when only private mappings are used here.
+
+I sadly found out that when using memory-backend-file, and when `share=off`, if `readonly=on`, then file is `open`ed with `O_RDONLY` and mmap prot is `PROT_READ`; if `readonly=off`, then the file is `open`ed with `O_RDWR` and mmap prot is `PROT_READ|PROT_WRITE`. I want `O_RDONLY` and `PROT_READ|PROT_WRITE` but I cannot find it anywhere.
+
+In my opinion, expected behavior should be that if `share=off`, the file can already be opened with `O_RDONLY` no matter what prot the mmap is. That is how linux `MAP_PRIVATE` works - basically copy on write. When I only need copy on write for the content of file, why do I require write permission for it?
+
+Now I cannot find a setup that opens the file with `fd=open(*, O_RDONLY)` and mmap it with `mmap(*, *, PROT_READ|PROT_WRITE, MAP_PRIVATE|*, fd, *)`.
+
+Tell me if I misunderstood linux (for example certain file behave differently if one open with O_RDONLY and this behavior is necessary) or qemu or other posix systems where copy-on-write does not work like this.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/169 b/gitlab/issues_text/target_missing/host_missing/accel_missing/169
new file mode 100644
index 00000000..1274cfd3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/169
@@ -0,0 +1 @@
+[RFC] dma buf: support sprite plane
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1690 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1690
new file mode 100644
index 00000000..366893e1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1690
@@ -0,0 +1,3 @@
+arguments to specify mapping offsets or map like a elf loader for memory backend file
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1691 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1691
new file mode 100644
index 00000000..e7662acb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1691
@@ -0,0 +1,10 @@
+QEMU's NVMe emulator behaving not standard compliant
+Description of problem:
+QEMU's NVMe emulator behaves slightly non-conformant to the standard.
+For one, in the CAP.CSS register, bits 0, 6 and 7 are set. Bit 7 indicates that the NVMe Controller does not support any I/O Command Set, while bit 6 is set when the NVMe Controller supports one or more I/O Command Sets (see Figure 36 of the NVM Express® Base Specification, Revision 2.0c). This is obviously contradictory and only bit 6 (and 0) should be set. These bits are configured in hw/nvme/ctrl.c:8250.
+The NVMe emulator also checks whether the values of CC.IOSQES and CC.IOCQES are within the allowed range when the controller is enabled by setting CC.EN to 1. However this check should not be performed yet, as the allowed range can only be discovered after the controller is enabled, by submitting the Identify Command. This command reports the valid range in the Identify Controller Data Structure, however it requires the controller to be enabled which in turn would, at least in the current version, require valid values in CC.IOSQES and CC.IOCQES. The NVMe emulator also uses the values configured in CC.IOSQES and IO.IOCQES for the Admin Queues which, from what I understand, should not be the case. Only the I/O Queues should use these values. These checks are done in hw/nvme/ctrl.c:7199f. In the same function the values are already used to initialize the controllers cqe_size and sqe_size which should also happen at a later time.
+Steps to reproduce:
+1. Start any virtual machine with a NVMe Controller attached.
+2. Read the value of CAP.CSS (located in BAR0 of the PCIe NVMe Controller). This value will be contradictory.
+3. Follow the initialization procedure as described in section 3.5.1 of the NVM Express® Base Specification, Revision 2.0c. Do not set the values of CC.IOSQES and CC.IOCQES.
+4. The NVMe Controller will fail to enable when setting CC.EN to 1 by setting CC.CFS to 1 and reporting the respective trace event (pci_nvme_err_startfail_cqent_too_small and variations).
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1692 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1692
new file mode 100644
index 00000000..6482bace
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1692
@@ -0,0 +1,102 @@
+Got "Assertion `bus->irq_count[i] == 0` failed" when running fuzzing
+Description of problem:
+When running the fuzzer on ac97, it always stops with "Assertion `bus->irq_count[i] == 0` failed".
+Steps to reproduce:
+Run `./qemu-fuzz-x86_64 --fuzz-target=generic-fuzz-ac97`
+Additional information:
+The logs triggered by the crash report are:
+```
+==2330108==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+[I 0.000000] OPENED
+INFO: libFuzzer ignores flags that start with '--'
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 1879893091
+INFO: Loaded 1 modules   (358762 inline 8-bit counters): 358762 [0x55bec313a1a0, 0x55bec3191b0a), 
+INFO: Loaded 1 PC tables (358762 PCs): 358762 [0x55bec3191b10,0x55bec370b1b0), 
+./qemu-fuzz-x86_64: Running 1 inputs 1 time(s) each.
+Running: ./crash-55e7a160b7c66d5b41718e22c7620a29e9f568f1
+Starting x86_64 with Arguments: -display none -machine accel=qtest, -m 512M -machine q35 -nodefaults -device ac97,audiodev=snd0 -audiodev none,id=snd0 -nodefaults -qtest /dev/null
+Matching objects by name ac97*
+This process will try to fuzz the following MemoryRegions:
+  * bus master[0] (size 0xffffffffffffffff)
+  * ac97-nabm[0] (size 0x100)
+  * bus master container[0] (size 0xffffffffffffffff)
+  * ac97-nam[0] (size 0x400)
+[R +0.033680] outl 0xcf8 0x80000800
+[S +0.033714] [R +0.033729] inw 0xcfc
+[S +0.033750] [R +0.033766] outl 0xcf8 0x80000810
+[S +0.033781] [R +0.033792] outl 0xcfc 0xffffffff
+[S +0.033816] [R +0.033827] outl 0xcf8 0x80000810
+[S +0.033841] [R +0.033852] inl 0xcfc
+[S +0.033866] [R +0.033879] outl 0xcf8 0x80000810
+[S +0.033894] [R +0.033904] outl 0xcfc 0xc001
+[S +0.033920] [R +0.033935] outl 0xcf8 0x80000814
+[S +0.033952] [R +0.033967] outl 0xcfc 0xffffffff
+[S +0.033984] [R +0.033994] outl 0xcf8 0x80000814
+[S +0.034008] [R +0.034017] inl 0xcfc
+[S +0.034031] [R +0.034043] outl 0xcf8 0x80000814
+[S +0.034057] [R +0.034067] outl 0xcfc 0xc401
+[S +0.034085] [R +0.034096] outl 0xcf8 0x80000804
+[S +0.034110] [R +0.034120] inw 0xcfc
+[S +0.034133] [R +0.034145] outl 0xcf8 0x80000804
+[S +0.034159] [R +0.034170] outw 0xcfc 0x7 
+[S +0.035259] [R +0.035272] outl 0xcf8 0x80000804
+[S +0.035285] [R +0.035291] inw 0xcfc
+[S +0.035300] [I +0.035389] CLOSED
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outl 0xcf8 0x80000805
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outl 0xcfc 0x5050505
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outw 0xc40b 0x6f0d
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x0 0x8 0x2a256c5a2c008425
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] clock_step
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outl 0xcf8 0x80000805
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outl 0xcfc 0x8468920
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] clock_step
+qemu-fuzz-x86_64: ../../../../hw/pci/pci.c:435: void pcibus_reset(BusState *): Assertion `bus->irq_count[i] == 0' failed.
+==2330108== ERROR: libFuzzer: deadly signal
+    #0 0x55bebf2624de in __sanitizer_print_stack_trace ../../llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_stack.cpp:87:3
+    #1 0x55bebf1a4b31 in fuzzer::PrintStackTrace() ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x55bebf17f406 in fuzzer::Fuzzer::CrashCallback() (.part.0) ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:18
+    #3 0x55bebf17f4cd in fuzzer::Fuzzer::CrashCallback() ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:205:1
+    #4 0x55bebf17f4cd in fuzzer::Fuzzer::StaticCrashSignalCallback() ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:204:19
+    #5 0x7fae9f8a441f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466)
+    #6 0x7fae9f69800a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+    #7 0x7fae9f69800a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+    #8 0x7fae9f677858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
+    #9 0x7fae9f677728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3
+    #10 0x7fae9f688fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3
+    #11 0x55bebfab33a7 in pcibus_reset ../hw/pci/pci.c:435:9
+    #12 0x55bec0c75ae3 in resettable_phase_hold ../hw/core/resettable.c
+    #13 0x55bec0c6e543 in device_reset_child_foreach ../hw/core/qdev.c:276:9
+    #14 0x55bec0c757c5 in resettable_phase_hold ../hw/core/resettable.c:173:5
+    #15 0x55bec0c5c421 in bus_reset_child_foreach ../hw/core/bus.c:97:13
+    #16 0x55bec0c757c5 in resettable_phase_hold ../hw/core/resettable.c:173:5
+    #17 0x55bec0c73729 in resettable_assert_reset ../hw/core/resettable.c:60:5
+    #18 0x55bec0c7336a in resettable_reset ../hw/core/resettable.c:45:5
+    #19 0x55bec0c7309a in qemu_devices_reset ../hw/core/reset.c:84:9
+    #20 0x55bec02d95bb in pc_machine_reset ../hw/i386/pc.c:1901:5
+    #21 0x55bebff4ede6 in qemu_system_reset ../softmmu/runstate.c:451:9
+    #22 0x55bec0c49684 in fuzz_reset ../tests/qtest/fuzz/fuzz.c:56:5
+    #23 0x55bec0c55641 in generic_fuzz ../tests/qtest/fuzz/generic_fuzz.c:676:5
+    #24 0x55bec0c4a0f7 in LLVMFuzzerTestOneInput ../tests/qtest/fuzz/fuzz.c:158:5
+    #25 0x55bebf17fc88 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) .. /../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:612:15
+    #26 0x55bebf1630a4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:21
+    #27 0x55bebf16fa8a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:19
+    #28 0x55bebf15a856 in main ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #29 0x7fae9f679082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #30 0x55bebf15a8dd in _start (../qemu-fuzz-x86_64+0x1e938dd)
+
+NOTE: libFuzzer has rudimentary signal handlers.
+      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
+SUMMARY: libFuzzer: deadly signal
+
+```
+
+After some manual checks, I find out that the instruction `outl 0xcf8 0x80000805` and `outl 0xcfc 0x8468920` will set irq_count[5] to -1 while the pcibus_reset() doesn't set it back to 0 so it will fail the assertion.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1694 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1694
new file mode 100644
index 00000000..4df798f9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1694
@@ -0,0 +1 @@
+cpu-x86-uarch-abi.py  is missing "xsave" cpuid for x86-64-v3 && x86-64-v4
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1695 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1695
new file mode 100644
index 00000000..7d670929
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1695
@@ -0,0 +1,11 @@
+Latest Windows MSI does not include libssp-0.dll
+Description of problem:
+The latest Qemu MSI installer for Windows (https://qemu.weilnetz.de/w64/2023/qemu-w64-setup-20230530.exe) does not include libssp-0.dll, which is why the executables fail to run.
+
+This Mingw library should be included when building the MSI if stack protection is enabled.
+Steps to reproduce:
+1. Install the latest qemu MSI
+2. Try to invoke any qemu command
+3. Use Dependency Walker to easily find missing dependencies (https://www.dependencywalker.com/)
+Additional information:
+![image](/uploads/7a8b46fc9f97e5481fd37493dd66da95/image.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1696 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1696
new file mode 100644
index 00000000..e380fb97
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1696
@@ -0,0 +1,39 @@
+Linux kernel hangs rarely when booting on the latest qemu
+Description of problem:
+(Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2213346)
+
+In Fedora we have noticed that the latest Linux kernel (rarely) hangs when booting
+on the latest qemu.  It hangs after printing:
+
+```
+[    0.070120] x86/cpu: User Mode Instruction Prevention (UMIP) activated
+[    0.070120] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127
+[    0.070120] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0
+[    0.070120] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
+[    0.070120] Spectre V2 : Mitigation: Retpolines
+[    0.070120] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
+[    0.070120] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT
+[    0.070120] Spectre V2 : Enabling Speculation Barrier for firmware calls
+[    0.070120] RETBleed: Mitigation: untrained return thunk
+[    0.070120] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
+[    0.070120] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
+[    0.070120] Freeing SMP alternatives memory: 48K
+```
+
+The next line which would be printed (if it didn't hang) is:
+
+```
+[    0.070794] smpboot: CPU0: AMD Ryzen 9 3900X 12-Core Processor (family: 0x17, model: 0x71, stepping: 0x0)
+```
+
+We've seen this hang on both AMD and Intel.  It probably happens one in every 300 boots.
+Steps to reproduce:
+By far the easiest way to reproduce this is to just run guestfish in a loop:
+
+```
+$ while guestfish -a /dev/null -v run >& /tmp/log; do echo -n . ; done 
+```
+Additional information:
+The full qemu command is rather long but you can find it in this log file:
+
+https://bugzilla-attachments.redhat.com/attachment.cgi?id=1969620
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/170 b/gitlab/issues_text/target_missing/host_missing/accel_missing/170
new file mode 100644
index 00000000..a572bcf7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/170
@@ -0,0 +1 @@
+Request to add something like "Auth failed from IP" log report for built-in VNC server
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1701 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1701
new file mode 100644
index 00000000..5c2f52ce
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1701
@@ -0,0 +1,5 @@
+-boot menu=on that vm is hangs
+Description of problem:
+virtual machine hangs, stop at press ESC for boot menu.
+Additional information:
+![qem-bootmenu](/uploads/423605d05b869c606bcd167e3934298d/qem-bootmenu.jpg)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1702 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1702
new file mode 100644
index 00000000..ae00f736
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1702
@@ -0,0 +1,8 @@
+Enable whpx acceleration, unable to start Linux system
+Description of problem:
+The accel=whpx parameter stops responding in the boot menu.
+
+The accel=whpx,kernel-irqchip=off parameter stops responding during startup
+Additional information:
+![qemu-bug1](/uploads/9567c717850daac6cd4872d201b46300/qemu-bug1.jpg)![qemu-bug3](/uploads/c8b49702337fc7db103b91b5cff7f36d/qemu-bug3.jpg)
+![qemu-bug2](/uploads/21338ae572e88cc3a6ebf4772f27f0b5/qemu-bug2.jpg)![qemu-bug5](/uploads/e7fdeb60684879b4a00124c35546e43e/qemu-bug5.jpg)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1703 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1703
new file mode 100644
index 00000000..41ac48ab
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1703
@@ -0,0 +1,45 @@
+Undefined behaviour when running guest with -enable-kvm and attached debugger
+Description of problem:
+When attaching a debugger to a Qemu instance with `-enable-kvm` my linux kernel panics on (f.e.) module load.
+I am not sure if this is a Qemu bug, however the issue is not occurring if I a) do not attach the debugger (even though Qemu is listening for one) or b) I do not pass `-enable-kvm` (and attach a debugger).
+The issue seems to relate to the `lx-symbols` command provided by the Linux kernel gdb script suite.
+Every time a module is loaded this script will reload the symbols for said module which may take some time, so maybe there is some race involved?
+The issue does not reproduce if you do not run `lx-symbols` prior to continuing (it will however run automatically after first module load as it adds a breakpoint to kernel/module/main.c:do_init_module, so the kernel will crash after the second module load)
+Steps to reproduce:
+1. Start kernel with some img
+2. Attach gdb debugger
+3. Run the `lx-symbols` command provided by the Linux kernel gdb scripts in gdb, run `continue` in gdb
+3. Load a kernel module
+Additional information:
+This is the kernel stack trace:
+```
+[   22.930691] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
+[   22.931174] CPU: 2 PID: 241 Comm: modprobe Tainted: G            E      6.1.31+ #2
+[   22.931675] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc37 04/01/2014
+[   22.931675] RIP: 0010:do_init_module+0x1/0x210
+[   22.931675] Code: 74 0c 48 8b 78 08 48 89 de e8 8b df ff ff 65 ff 0d 84 94 ef 7e 0f 85 e5 fe ff ff 0f 1f 44 00 008
+[   22.931675] RSP: 0018:ffffc90000593e40 EFLAGS: 00010246
+[   22.931675] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000006e202
+[   22.931675] RDX: 000000000006e002 RSI: 5b4504de76578f76 RDI: ffffffffc024e180
+[   22.931675] RBP: ffffc90000593e50 R08: ffffea0000174a88 R09: ffffea0000174ac0
+[   22.931675] R10: ffff888006a9c270 R11: 0000000000000100 R12: 0000562f9087b4a0
+[   22.931675] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
+[   22.931675] FS:  00007f0dbc5a4040(0000) GS:ffff88801f500000(0000) knlGS:0000000000000000
+[   22.931675] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[   22.931675] CR2: 00007ffdc94bc3f8 CR3: 0000000006f8e000 CR4: 00000000003506e0
+[   22.931675] Call Trace:
+[   22.931675]  <TASK>
+[   22.931675]  ? die+0x32/0x80
+[   22.931675]  ? do_trap+0xd6/0x100
+[   22.931675]  ? do_init_module+0x1/0x210
+[   22.931675]  ? do_error_trap+0x6a/0x90
+[   22.931675]  ? do_init_module+0x1/0x210
+[   22.931675]  ? exc_invalid_op+0x4c/0x60
+[   22.931675]  ? do_init_module+0x1/0x210
+[   22.931675]  ? asm_exc_invalid_op+0x16/0x20
+[   22.931675]  ? do_init_module+0x1/0x210
+[   22.931675]  __do_sys_finit_module+0x9e/0xf0
+[   22.931675]  do_syscall_64+0x63/0x90
+[   22.931675]  ? exit_to_user_mode_prepare+0x1a/0x120
+[   22.931675]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1705 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1705
new file mode 100644
index 00000000..74c4dd28
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1705
@@ -0,0 +1,66 @@
+Illegal instruction when I want to numactl --cpubind=0 --membind=1 to CXL Memory
+Description of problem:
+I ran QEMU for simulating CXL DRAM and when I tried to run `numactl --cpubind=0 --membind=1  ls` , I got `Illegal instruction`
+The numa node 1 was the CXL DRAM simulated by QEMU.
+
+> root@8003:~# numactl -H
+> available: 2 nodes (0-1)
+> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
+> node 0 size: 32090 MB
+> node 0 free: 31325 MB
+> node 1 cpus:
+> node 1 size: 32768 MB
+> node 1 free: 32768 MB
+> node distances:
+> node 0 1
+> 0: 10 20
+> 1: 20 10
+
+When I ran on numa node 1, no failed
+
+> root@8003:~# numactl --membind=0 ls
+> ndctl
+
+When I ran on numa node 1(CXL DRAM),it failed.
+
+> root@8003:~# numactl --membind=1 ls
+> [ 913.975032] traps: ls[667] trap invalid opcode ip:7fdec255d180 sp:7ffd3c507288 error:0 in ld-linux-x86-64.so.2[7fdec2546000+2a000]
+> **Illegal instruction**
+Steps to reproduce:
+1. start the guest
+2. cxl list  (we could see the simulated CXL DRAM)
+> root@8003:~# cxl list
+> [
+>   {
+>     "memdev":"mem0",
+>     "ram_size":34359738368,
+>     "serial":0,
+>     "host":"0000:0d:00.0"
+>   }
+> ]
+3. cxl create-region -t ram -d decoder0.0 -m mem0
+4. daxctl reconfigure-device dax0.0 --mode=system-ram
+5. numactl -H
+> root@8003:~# numactl -H
+> available: 2 nodes (0-1)
+> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
+> node 0 size: 32090 MB
+> node 0 fr
+> ee: 31254 MB
+> node 1 cpus:
+> node 1 size: 32768 MB
+> node 1 free: 32768 MB
+> node distances:
+> node   0   1 
+>   0:  10  20 
+>   1:  20  10 
+6. numactl --membind=1 ls
+> root@8003:~# numactl --membind=1 ls
+> [38441.892140] **traps: ls[861] trap invalid opcode ip:7f15db6ac180 sp:7ffc648755c8 **error:0 in ld-linux-x86-64.so.2[7f15db695000+2a000]
+> **Illegal instruction**
+Additional information:
+When I run dmesg, I found an error.
+> root@8003:~# dmesg|grep error
+> [    2.321130] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
+
+Since my CPU is a Xeon III, not a Xeon IV with CXL support, **I'm wondering if it's because the CPU doesn't support CXL instructions, or if the Xeon III can emulate it, just because my settings don't make sense**. If this is my settings problem, could you help me to deal this? Or it just caused by my Xeon III,I will update it to  Xeon IV.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1706 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1706
new file mode 100644
index 00000000..9e31bc22
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1706
@@ -0,0 +1,9 @@
+Allow TCG plugins to read registers
+Additional information:
+- `include/qemu/plugin.h`
+- `include/qemu/qemu-plugin.h`
+
+PANDA implemented this already but it is not a very clean solution:
+- https://github.com/panda-re/qemu/commit/b97c5a56edd0ba3b5f6ab16bf531ac1f7abaac04 (mentioned in QPP patch series: https://lore.kernel.org/qemu-devel/20221213213757.4123265-1-fasano@mit.edu/)
+
+I personally think the flag for the TB translation and execution callbacks makes more sense
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1707 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1707
new file mode 100644
index 00000000..ee317fd7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1707
@@ -0,0 +1,23 @@
+linux-user  qemu-x86_64  can't exec a binary  on aarch64 or Loongarch.
+Description of problem:
+on master branch,  we build an simply hello.c with x86_cross gcc.
+then. run './build/qemu-x86_64 hello', no output.
+Steps to reproduce:
+1. build  an hello.c with x86_64 cross.  use --static.
+2. build qemu-x86_64 on aarch64 or LoongArch host.
+3. run './build/qemu-x86_64 hello'
+Additional information:
+[strace.txt](/uploads/5362e0e9b04ad9a582470faf4a9fcedb/strace.txt)
+ 
+
+
+ [hello](/uploads/12d9277fa4e853286414f575010a37ac/hello)
+
+ 
+The following commit causes this problem．
+
+commit 86f04735ac2088d5c069c3d1712212ec7428c562
+Author: Helge Deller <deller@gmx.de>
+Date:   Sun Dec 25 09:23:19 2022 +0100
+
+    linux-user: Fix brk() to release pages
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1709 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1709
new file mode 100644
index 00000000..ca59fba3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1709
@@ -0,0 +1,36 @@
+Qemu commit 7efd65423a cannot be built: Couldn't find file "symbols/ar" in include paths
+Description of problem:
+Hello.
+
+I try to build qemu based on commit 7efd65423a but it breaks in step 9035/10108, complaining about a missing "symbols/ar".
+
+The last time I get a full build was with commit fdd0df5340.
+
+Configure options: `--prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror`
+
+Here is the error log I got:
+
+```
+Running postconf script '/home/fred/qemu-git/src/qemu/build-full/pyvenv/bin/python3 /home/fred/qemu-git/src/qemu/scripts/symlink-install-tree.py'
+[9035/10108] Generating pc-bios/keymaps/ar with a custom command
+FAILED: pc-bios/keymaps/ar 
+/home/fred/qemu-git/src/qemu/build-full/qemu-keymap -f pc-bios/keymaps/ar -l ar
+xkbcommon: ERROR: Couldn't find file "symbols/ar" in include paths
+xkbcommon: ERROR: 1 include paths searched:
+xkbcommon: ERROR: 	/usr/share/X11/xkb
+xkbcommon: ERROR: 3 include paths could not be added:
+xkbcommon: ERROR: 	/home/fred/.config/xkb
+xkbcommon: ERROR: 	/home/fred/.xkb
+xkbcommon: ERROR: 	/etc/xkb
+xkbcommon: ERROR: Abandoning symbols file "(unnamed)"
+xkbcommon: ERROR: Failed to compile xkb_symbols
+xkbcommon: ERROR: Failed to compile keymap
+[9040/10108] Generating pc-bios/edk2-x...d (wrapped by meson to capture output)
+ninja: build stopped: subcommand failed.
+```
+
+I'll try to do a bisect as soon as possible to see which commit break all.
+Steps to reproduce:
+1. Just grab commit 7efd65423a
+2. Apply these configure options: `--prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror`
+3. launch make and wait
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/171 b/gitlab/issues_text/target_missing/host_missing/accel_missing/171
new file mode 100644
index 00000000..fc5a41b6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/171
@@ -0,0 +1 @@
+[RFE] option to suppress gemu_log() output
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1710 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1710
new file mode 100644
index 00000000..ee2e7e25
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1710
@@ -0,0 +1,51 @@
+contrib/plugins/Makefile is not crossplatform
+Description of problem:
+Currently `contrib/plugins/Makefile` makes multiple assumptions about paths used, compiler flags available, and library extension
+Steps to reproduce:
+1. Compile QEMU from sources on macOS or Windows
+2. Enter `contrib/plugins`
+3. Type `make` and become sad.
+Additional information:
+As the rest of QEMU switched to Meson, maybe it's a good idea to do the same for plugins as well?
+
+This is what I come with myself:
+
+`meson.build`:
+```meson
+project('qemu-plugins', 'c', meson_version: '>=0.50.0')
+
+qemu_src = get_option('qemu_path')
+if qemu_src == ''
+  qemu_src = '../..'
+endif
+
+qemu_include = qemu_src + '/include/qemu'
+incdir = include_directories(qemu_include)
+
+plugins = [
+  'execlog',
+  'hotblocks',
+  'hotpages',
+  'howvec',
+  'lockstep',
+  'hwprofile',
+  'cache',
+  'drcov',
+]
+
+th = dependency('threads', required: true)
+glib = dependency('glib-2.0', required: true)
+
+foreach p: plugins
+  library(p, p + '.c',
+    include_directories: incdir,
+    dependencies: [th, glib],
+    override_options: ['b_lundef=false']
+  )
+endforeach
+```
+
+`meson_options.txt`:
+```
+option('qemu_path', type : 'string', value : '', description : 'Full path to the QEMU sources to build the plugin for')
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1711 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1711
new file mode 100644
index 00000000..351ca81e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1711
@@ -0,0 +1 @@
+unable to set PWD with guest-exec without starting a shell
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1712 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1712
new file mode 100644
index 00000000..afbb5c88
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1712
@@ -0,0 +1,9 @@
+Arabic keyboard layout wrong.
+Description of problem:
+After a while the compilation process starts, xkb gives an error about symbols/ar not found. According to my research, linux distros using "ara" for arabic layout. But qemu pc-bios/keymaps/ folder contains "ar" for arabic layout.
+Steps to reproduce:
+1.Configure
+2.Build
+3.Wait until error appears.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1713 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1713
new file mode 100644
index 00000000..22591e4f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1713
@@ -0,0 +1,40 @@
+hw/input/hid.c - Add Support for More Than Five Mouse Buttons in QEMU for evdev?
+Additional information:
+Sure enough, there appear to only be five buttons defined.
+
+https://gitlab.com/qemu-project/qemu/-/blob/master/hw/input/hid.c#L113
+
+```c
+[INPUT_BUTTON_LEFT]   = 0x01,
+[INPUT_BUTTON_RIGHT]  = 0x02,
+[INPUT_BUTTON_MIDDLE] = 0x04,
+[INPUT_BUTTON_SIDE] = 0x08,
+[INPUT_BUTTON_EXTRA] = 0x10,
+```
+
+
+At this point, the existing naming schema cannot be continued... might I suggest:
+
+```c
+[INPUT_BUTTON_SIX] = 0x??,
+[INPUT_BUTTON_SEVEN] = 0x??,
+[INPUT_BUTTON_EIGHT] = 0x??,
+[INPUT_BUTTON_NINE] = 0x??,
+[INPUT_BUTTON_TEN] = 0x??,
+[INPUT_BUTTON_ELEVEN] = 0x??,
+[INPUT_BUTTON_TWELVE] = 0x??,
+```
+Although, I'm not sure if 12 buttons is future-proofed enough.
+
+I should also note that I found this post which states that there's no more space left in PS2 emulation, so I don't know if that would cause a conflict.
+"ps/2 emulation looks like there are no unused bits for more buttons.  Possibly we have to extend the usb mouse emulation for that."
+https://listman.redhat.com/archives/vfio-users/2016-January/001596.html
+
+Unfortunately, I have never written a patch. I'm not even sure how I would apply a patch in Unraid, other than overwriting the bin file. So if this is ever fixed, I would simply hope that one day a new version of QEMU would get up-streamed into a new version of Unraid.
+
+So, here I am humbly asking for support. I don't know if it's as simple as just adding new definitions... and I have no idea what hex value to assign them.
+
+*edit* I also failed to get a temporary workaround to work by remapping the mouse buttons in the host VM using xmodmap using this command:
+
+`xmodmap -e "pointer = 1 12 3 4 5 6 7 8 9 10 11 2" &`
+I tried saving `pointer = 1 12 3 4 5 6 7 8 9 10 11 2` in the host VM's root folder in .Xmodmap, but it did not propogate to guest VMs. The buttons were still their original mapping and running the xmod command had no effect.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1715 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1715
new file mode 100644
index 00000000..80aa09ee
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1715
@@ -0,0 +1 @@
+qemu-img convert about target_is_new
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1716 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1716
new file mode 100644
index 00000000..d67de981
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1716
@@ -0,0 +1,9 @@
+Cannot  raise low memory using max-ram-below-4g on current i440fx
+Description of problem:
+We have a use case where we have a virtual machine with at least 8 Gb of RAM and at least 3.5Gb of it in the low memory. However, I could not achieve it this far with QEMU, only on the deprecated i440fx 1.7 architecture. The size of lowmem is never greater than 3 Gb, except if I assign memory to the vm between 3 Gb and 3.5 Gb. If I go even a slightly above 3.5 Gb then it falls back to 3 Gb.
+
+I did some research and I found the source file hw/i386/pc_piix.c. There is a piece of code which is responsible for setting the low memory at the beginning of function pc_init1(). It seems that the problem lies in the property `gigabyt_align` of all i440fx architectures newer than 1.7. The comment which explains this piece of code does not mention at all that raising lowmem does not work on newer pc architectures. According to the comments setting the size of lowmem based of the `max-ram-below-4g` option should happen before the gigabyte alignment, not after it. Anyway, it does not make sense because with default being 3 Gb gigabyte alignment always means 3 Gb so raising is not possible at all. The last example of the comment clearly states that raising should be possible using the newest `pc` architecture: `qemu -M pc,max-ram-below-4g=4G -m 3968M  -> 3968M low (=4G-128M)`. However, according to the code below the comment this is not the way it works because gigabyte alignment happens after.
+
+To solve the problem there are two possibilities: if this is a bug then the solution is obvious, the gigabyte aligment should happen before applying the `max-ram-below-4g` option. If this is not a bug but the expected way of working then there could be an option to override the `gigabyte_align` attribute from command line.
+
+What do you think?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1717 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1717
new file mode 100644
index 00000000..13ab8c04
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1717
@@ -0,0 +1,29 @@
+GPU passthrough (NV h100)case vfio Error
+Description of problem:
+GPU passthrough (NV h100) will case a error 
+
+
+qemu-system-x86_64: vfio_err_notifier_handler(0000:17:00.0) Unrecoverable error detected. Please collect any data possible and then kill the guest
+
+
+this error happen in centos, redhat linux,ubuntu with some kernel i have try( 5.19.0,6.0,6.2)
+The same server insert L4,L40 GPU, will not happen. Only happen on H100 GPU
+The same server install esxios. everything is normal. GPU work fine
+
+With vfio error. there is some idrac log error on my dell server
+
+```
+A bus fatal error was detected on a component at slot 2.	Tue Jun 20 2023 05:51:51
+A fatal error was detected on a component at bus 23 device 0 function 0.	Tue Jun 20 2023 05:51:51
+A fatal error was detected on a component at bus 22 device 2 function 0.	Tue Jun 20 2023 05:51:51
+```
+
+Otherwise, I have try to passthrough gpu on dell amd and intel server both. 
+With AMD CPU , gpu not working in vm. but will not case vfio error
+With INTEL CPU, will case vfio error.
+Steps to reproduce:
+1. Set GPU passthrought
+2. Start VM
+3. Do something in vm
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1718 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1718
new file mode 100644
index 00000000..c5f7688c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1718
@@ -0,0 +1,47 @@
+Strange throttle-group test results
+Description of problem:
+I have a question about throttle-group test results.
+
+I did a test to limit IO by applying THROTTLE-GROUP and the expected result is not what I expected
+
+The setup environment looks like this throttle-group to x-iops-total=500, x-bps-total=524288000 and throttling vdb, benchmarked with fio command
+
+```
+# mount -t xfs /dev/vdb1 /mnt/disk
+
+# fio --direct=1 --bs=1M --iodepth=128 --rw=read --size=1G --numjobs=1 --runtime=600 --time_based --name=/mnt/disk/fio-file --ioengine=libaio --output=/mnt/disk/read-1M
+```
+
+When I test with a --bs value of 1M, I get 500Mib throughput.
+![iops_500-1M](/uploads/f63ecbfdb13adc87bd4524f5298a224c/iops_500-1M.png)
+
+
+When I test with a --bs value of 2m, I don't get 500Mibs but 332Mibs throughput.
+```
+fio --direct=1 --bs=2M --iodepth=128 --rw=read --size=1G --numjobs=1 --runtime=600 --time_based --name=/mnt/disk/fio-file --ioengine=libaio --output=/mnt/disk/read-2M
+```
+![iops_500-2M](/uploads/0a384fd9f026943e5e40af1c4b5d6dcd/iops_500-2M.png)
+
+
+If I set the qemu x-iops-total value to 1500 and the fio --bs value to 2M test again, I get 500Mib throughput.
+
+![iops_1500-2M](/uploads/f31eb8213d034d612e915e355b52a324/iops_1500-2M.png)
+
+
+To summarize, here is the Test result.
+
+| fio bs | qemu x-iops-total | qemu x-bps-total | Result iops |Result throughput
+| ------ | ------ |------ |------ |------ |
+| 2M     | 1500   | 524288000 | 250 |  500 |
+| **2M** |**500** | **524288000** | **166** |  **332** |
+| 1M     | 1500   | 524288000 | 500 |  500 |
+| 1M     |  500.  | 524288000 | 500 |  500 |
+
+
+When the --bs value is 2M and the x-iops-total value is 500, the throughput should be 500, but it is not, so I don't know what the problem is.
+
+If there is anything I missed, please let me know.
+Steps to reproduce:
+1. Apply throttle-group to vdb and start the VM
+2. mount vdb1
+3. test fio
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1719 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1719
new file mode 100644
index 00000000..c51e32c9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1719
@@ -0,0 +1,7 @@
+Allow TCG plugins to read memory
+Additional information:
+* `include/qemu/plugin.h`
+* `include/qemu/qemu-plugin.h`
+* `plugin/api.c`
+
+PANDA implemented this already (not sure if this solution is acceptable for the mainline QEMU): https://github.com/qemu/qemu/commit/72c661a7f141ab41fbce5e95eb3593b69f40e246
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1720 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1720
new file mode 100644
index 00000000..66a50c3c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1720
@@ -0,0 +1,40 @@
+Problems in mapping memory regions in multiple machines using GPEX pci-host
+Description of problem:
+Multiple machines use the GPEX pci-host model. This model forsees 3 MMIO regions:
+1. ECAM space
+2. MMIO space
+3. IO space
+
+In the different machines, aliases to the 3 memory regions are created which are then mapped onto the sysbus. 
+
+For the ARM virt machine for example following calls are happening:
+
+    ecam_alias = g_new0(MemoryRegion, 1);
+    ecam_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 0);
+    memory_region_init_alias(ecam_alias, OBJECT(dev), "pcie-ecam", ecam_reg, 0, size_ecam);
+    memory_region_add_subregion(get_system_memory(), base_ecam, ecam_alias);
+
+    mmio_alias = g_new0(MemoryRegion, 1);
+    mmio_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 1);
+    memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio", mmio_reg, base_mmio, size_mmio);
+    memory_region_add_subregion(get_system_memory(), base_mmio, mmio_alias);
+
+We now add a generic PCIe root port (gen_pcie_root_port.c) on the PCIBus exposed by the GPEX device:
+
+    pci_create_simple(PCI_HOST_BRIDGE(dev)->bus, -1, "pcie-root-port");
+
+This device contains an MSI-x table which is accessible via BAR 0.
+
+However, if we try to access this space we always get 0xFFFFFFFF as a return value on reads because the memory regions are not correctly mapped IMO. 
+
+If we again look at the mapping of the MMIO space:
+
+    memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio", mmio_reg, base_mmio, size_mmio);
+    memory_region_add_subregion(get_system_memory(), base_mmio, mmio_alias);
+
+The alias is created to the MMIO region in the GPEX device, at offset base_mmio. Afterwards the memory region alias is mapped onto the sysbus at offset base_mmio. To me it seems that the offset is incorrect in creating the alias and should be 0 instead:
+
+    memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio", mmio_reg, 0, size_mmio);
+    memory_region_add_subregion(get_system_memory(), base_mmio, mmio_alias);
+
+With this change the above scenario (accessing the MSI-x table of the generic PCIe root port) is working. I'm not sure if this is the correct fix for this problem and how to cope with e.g. high MMIO regions (as are also present in the virt machine).
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1721 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1721
new file mode 100644
index 00000000..db3237ed
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1721
@@ -0,0 +1,62 @@
+Problem in combination with RabbitMQ and erlang
+Description of problem:
+I have a problem with rabbitMQ /erlang / Qemu on my local system.
+
+I use docker with:
+
+version: "3.6"
+```
+services:
+  rabbitmq:
+    image: rabbitmq:3-management
+```
+
+Docker Desktop 4.20.1 (110738) 
+Docker version 24.0.2, build cb74dfc
+
+Apple Macbook Pro with M1 Chip Ventura 13.4.
+
+I deleted all containers and images related to rabbitMQ. Then when I do a: docker compose up -d
+
+I always get this error and rabbitMQ stopps:
+
+```
+rabbitmq-server-rabbitmq-1  | 2023-06-22 08:12:18.984151+00:00 [notice] <0.44.0> Application mnesia exited with reason: stopped
+rabbitmq-server-rabbitmq-1  | 2023-06-22 08:12:20.658039+00:00 [info] <0.230.0> Waiting for Mnesia tables for 30000 ms, 9 retries left
+rabbitmq-server-rabbitmq-1  | 2023-06-22 08:12:20.659274+00:00 [info] <0.230.0> Successfully synced tables from a peer
+rabbitmq-server-rabbitmq-1  | 2023-06-22 08:12:20.662647+00:00 [notice] <0.283.0> Feature flags: attempt to enable `stream_sac_coordinator_unblock_group`...
+rabbitmq-server-rabbitmq-1  | 2023-06-22 08:12:20.793670+00:00 [notice] <0.283.0> Feature flags: `stream_sac_coordinator_unblock_group` enabled
+rabbitmq-server-rabbitmq-1  | qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+rabbitmq-server-rabbitmq-1  | Segmentation fault
+```
+
+In the past it worked, like 5 months ago.
+
+Reproduction steps docker compose up -d
+
+Expected behavior that the container runs and does not exit
+
+Additional context docker compose logs
+
+```
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:06.946635+00:00 [notice] <0.44.0> Application syslog exited with reason: stopped
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:06.966134+00:00 [notice] <0.230.0> Logging: switching to configured handler(s); following messages may not be visible in this log output
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:06.973002+00:00 [notice] <0.230.0> Logging: configured log handlers are now ACTIVE
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.539052+00:00 [info] <0.230.0> ra: starting system quorum_queues
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.539748+00:00 [info] <0.230.0> starting Ra system: quorum_queues in directory: /var/lib/rabbitmq/mnesia/rabbit@4fb71bcd203a/quorum/rabbit@4fb71bcd203a
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.715984+00:00 [info] <0.261.0> ra system 'quorum_queues' running pre init for 0 registered servers
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.749375+00:00 [info] <0.262.0> ra: meta data store initialised for system quorum_queues. 0 record(s) recovered
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.786151+00:00 [notice] <0.267.0> WAL: ra_log_wal init, open tbls: ra_log_open_mem_tables, closed tbls: ra_log_closed_mem_tables
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.857344+00:00 [info] <0.230.0> ra: starting system coordination
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.857635+00:00 [info] <0.230.0> starting Ra system: coordination in directory: /var/lib/rabbitmq/mnesia/rabbit@4fb71bcd203a/coordination/rabbit@4fb71bcd203a
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.868808+00:00 [info] <0.274.0> ra system 'coordination' running pre init for 0 registered servers
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.874965+00:00 [info] <0.275.0> ra: meta data store initialised for system coordination. 0 record(s) recovered
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.875747+00:00 [notice] <0.280.0> WAL: ra_coordination_log_wal init, open tbls: ra_coordination_log_open_mem_tables, closed tbls: ra_coordination_log_closed_mem_tables
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0>
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> Starting RabbitMQ 3.12.0 on Erlang 25.3.2.2 [jit]
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> Copyright (c) 2007-2023 VMware, Inc. or its affiliates.
+rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> Licensed under the MPL 2.0. Website: https://rabbitmq.com
+rabbitmq-server-rabbitmq-1 |
+rabbitmq-server-rabbitmq-1 |
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1725 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1725
new file mode 100644
index 00000000..77dd71e0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1725
@@ -0,0 +1,21 @@
+qemu-system-x86_64 reports wrong thread to GDB on SIGINT
+Description of problem:
+Upon interruption of a thread by GDB, QEMU in some circumstances will send a stop reply with the ID of a thread that had not been resumed.
+
+This happens for the following reasons:
+1. GDB uses `vCont` exclusively to resume and step through threads.
+2. When a thread is interrupted by GDB, QEMU runs `vm_stop(RUN_STATE_PAUSED)`, which triggers `gdb_vm_state_change`, which, in turn, uses whatever CPU is pointed to by `gdbserver_state.c_cpu` at that time to construct the stop reply.
+3. The `vCont` handler in QEMU doesn't set `gdbserver_state.c_cpu` before resuming any CPUs.
+
+Important to note is that stepping is not affected by this issue because the `EXCP_DEBUG` handler sets `gdbserver_state.c_cpu` to the CPU the exception happened in before `gdb_vm_state_change` runs. Which also means single stepping before continuing is an effective way to work around this bug.
+Steps to reproduce:
+1. Run QEMU with at least two threads and the GDB stub enabled.
+2. Run `gdb --nx --ex 'target remote :1234' --ex 'set scheduler-locking on'`
+3. Switch to Thread 1.2 in GDB with `thr 2`
+4. Resume Thread 1.2 in GDB with `c`
+5. Press Ctrl+C to interrupt the VM
+6. Notice that the event is reported as having happened in Thread 1.1, which has not been resumed.
+Additional information:
+Note that, while this bug happens no matter the state of `scheduler-locking`, it only becomes a problem when it is enabled. This is because, when it is disabled, GDB will always resume all threads on `continue`, so it doesn't matter what thread ID QEMU says the interrupt happened in, as it is guaranteed to have been resumed anyway. That, however, is not the case when `scheduler-locking` is enabled.
+
+Regardless, I don't think it makes sense for QEMU to be reporting events happening in threads that weren't resumed through either `s/S/c/C` or `vCont`, which is what it's doing here.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1727 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1727
new file mode 100644
index 00000000..5163b726
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1727
@@ -0,0 +1,81 @@
+virtio-gpu-gl-pci console tries to make GL context before widget is realized leading to crash
+Description of problem:
+When `-vga none` is added to the command line, there is no crash.
+
+When it is not, two `GtkGLArea` widgets are created: one for VGA and one for `virtio-gpu-gl-pci`. Only the first one is realized, but the virgl code tries to create a GL context for the second. In `gd_gl_area_create_context`, `gtk_widget_get_window(vc->gfx.drawing_area)` evaluates to NULL a crash follows:
+
+```
+qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed
+qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed
+qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed
+qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed
+qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed
+qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed
+qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed
+qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed
+qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed
+qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed
+qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed
+qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed
+qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed
+qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed
+qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed
+qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed
+qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed
+qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed
+qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed
+qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed
+qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed
+qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed
+qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed
+gl_version 0 - compat profile
+WARNING: running without ARB/KHR robustness in place may crash
+qemu-system-x86_64: ../libepoxy/src/dispatch_common.c:872: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.
+```
+Steps to reproduce:
+1. Get OVMF. On Arch Linux, you can install the `edk2-ovmf` package. On other distros, find a similar package and modify the path in the command accordingly.
+2. Run the command above.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1728 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1728
new file mode 100644
index 00000000..b79688f1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1728
@@ -0,0 +1,18 @@
+blockdev parameter does not accept dots in pool name in json config
+Description of problem:
+I'm trying to provision a VM using qemu 6.2.0 and pass the remote disk parameters like libvirt. When I start the VM, I get an error saying 
+
+
+```
+qemu-system-x86_64: -blockdev {driver:rbd,pool:cloud.disk.hiops,image:csi-vol-8577fffd-0f48-3344-b333-02000038163a,server:[{host:1.2.3.4,port:6789},{host:1.2.3.5,port:6789},{host:1.2.3.6,port:6789}],user:compute-staging,auth-client-required:[cephx,none],key-secret:ceph-secret,node-name:pv-MD7PBV3SRD21L08115JUJ94HMG,cache:{direct:false,no-flush:false},auto-read-only:true,discard:unmap}: JSON parse error, stray '.'
+```
+
+
+I changed the ip address and some fields.
+
+
+My question is should we avoid dots in pool name? I tried to look at the source code of json parser but in its doc, it did not mention a sequence of characters for escaping dots.
+Steps to reproduce:
+1. Provision a VM with the provided config
+Additional information:
+bl
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1729 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1729
new file mode 100644
index 00000000..996ecd14
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1729
@@ -0,0 +1,47 @@
+mremap fails with EFAULT if address range overlaps with stack guard
+Description of problem:
+When running 32-bit user-static on 64-bit host, `mremap` behave differently from the kernel. This difference let programs that call `pthread_getattr_np` on musl-libc to run into a loop on repeated calling `mremap`.
+
+https://git.musl-libc.org/cgit/musl/plain/src/thread/pthread_getattr_np.c
+
+``` c
+		while (mremap(p-l-PAGE_SIZE, PAGE_SIZE, 2*PAGE_SIZE, 0)==MAP_FAILED && errno==ENOMEM)
+			l += PAGE_SIZE;
+```
+Steps to reproduce:
+Compile the following program against musl-libc arm 32-bit, and run it in qemu-user-static on x86_64 host.
+
+``` c
+#define _GNU_SOURCE
+#include <pthread.h>
+
+int main(int argc, char *argv[]) {
+	pthread_attr_t attr;
+	return pthread_getattr_np(pthread_self(), &attr);
+}
+```
+
+For example, on x86_64 fedora 38 with podman and qemu-user-static installed, we can reproduce this with alpine container:
+
+```
+$ podman run --rm -it --arch arm/v7 docker.io/library/alpine:latest
+
+/ # apk add alpine-sdk
+
+......
+
+/ # cat test.c
+#define _GNU_SOURCE
+#include <pthread.h>
+
+int main(int argc, char *argv[]) {
+	pthread_attr_t attr;
+	return pthread_getattr_np(pthread_self(), &attr);
+}
+
+/ # gcc test.c
+
+/ # ./a.out
+```
+Additional information:
+Original thread on musl mail list where this was initially reported: https://www.openwall.com/lists/musl/2017/06/15/9
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/173 b/gitlab/issues_text/target_missing/host_missing/accel_missing/173
new file mode 100644
index 00000000..cfc51763
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/173
@@ -0,0 +1 @@
+unable to read symlinks when mounting 9p filesystem with security_model=mapped
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1730 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1730
new file mode 100644
index 00000000..48091360
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1730
@@ -0,0 +1,16 @@
+Virtual console in GTK input uses wrong color for dark gray
+Description of problem:
+The virtual console in the GTK window uses black to draw dark gray text. This becomes unintelligible if drawing on black background.
+Steps to reproduce:
+1. Boot any distro to shell prompt with `-serial vc`.
+2. Switch to serial console in QEMU GTK window (Ctrl+Alt+3).
+4. Run `echo -e "\e[1;30mDark Greay\e[m"`.
+5. Output is black on black.
+
+or
+
+1. `qemu-system-x86_64 -bios /usr/share/edk2/x64/OVMF.fd`
+2. Enter EFI internal shell
+3. `cls 0 8`
+4. Run `help cls` and observe correct colors in VGA window.
+5. Switch to serial console and observe black on black colors.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1731 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1731
new file mode 100644
index 00000000..aaceefea
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1731
@@ -0,0 +1,12 @@
+i440fx ide cdrom pathological slow on early win10 install  screen
+Description of problem:
+if you choose i440fx virtual hardware (default in proxmox) for windows 10 instead of q35 , from power on to the windows boot logo is 10 times slower.  you need to wait more then 1m45s on my hardware until the blinking cursor in the upper left goes away and the blue windows bootlogo appears. that leads to false assumption, that your setup hangs. 
+
+what's causing this slownewss?
+
+is implementation really that bad?
+
+i did compare read performance of ide, sata and scsi cdrom in linux vm and cannot observe such a big difference.
+
+see
+https://forum.proxmox.com/threads/win10-installation-pathological-slowness-with-i440fx-ide-cdrom.129351/
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1732 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1732
new file mode 100644
index 00000000..210fa72c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1732
@@ -0,0 +1,3 @@
+Is there a way to disconnect the network of guest?
+Description of problem:
+When guest is running,I wan to disconnect the network(not detach the net),which should keep disconnect after migrate or restart if we not reconnect it againt.  Whether qemu has some ways to do it?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1734 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1734
new file mode 100644
index 00000000..44545592
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1734
@@ -0,0 +1,16 @@
+mmap-ing more than 1GB of files fails on v8.0 of QEMU, but works on older version
+Description of problem:
+Trying to run an application using QEMU user mode for an ARM binary.  My host system is Ubuntu 22.04 based.  The v6.2 from Ubuntu repos is able to mmap files that contain more than 1GB of address space, but version 8.0 that I compiled will not.
+
+I created a repo with a readme, and a simple application that you can use to demonstrate the problem:
+https://github.com/mwales/qemu_mmap_test
+
+Example application simply takes a list of files, mmaps the entire file into memory, and then computes a checksum of the file data.  Once the file(s) sizes exceed around 1GB, the mmap calls will fail because the memory from 0x00000000 - 0x40000000 has been exhausted.
+Steps to reproduce:
+1. Compile test application that mmaps entire files
+2. Create 5 256MB test files
+3. Run the program tell it to mmap all the files.  The first 3 files succeed, but the 4th when run gets a -1 returned from mmap.
+Additional information:
+Lots of details on my github writeup and a demo of the bug in question.
+
+It seems that this 1GB limit is an artifact of where QEMU loaded the original ELF binary at (0x40000000).  I've also been playing around with moving that address using the -B 0x80000000 option, but I've encountered other problems doing that.  As I diagnose that, I figured I would write up this report on what I've seen so far incase I'm doing something dumb / creating a bad build or something.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1738 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1738
new file mode 100644
index 00000000..3be4a4f4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1738
@@ -0,0 +1,149 @@
+qemu-system-x86_64 crash during kernel PCI init with large number of busses
+Description of problem:
+When booting a Linux kernel under qemu-system-x86_64 (tcg) using a large number of PCI busses (25+), qemu crashes with an invalid memory access during kernel PCI init phase. Failure rate is not 100%; some kernel boots do succeed, but the failure rate increases as the number of pci busses increases. Note that no initrd is needed; crash happens before kernel even gets to the point of trying to mount root.
+Steps to reproduce:
+Launch qemu using command line above along with 4.19.x kernel image (have not tested 5.x). It may take a few tries but within about 20 boot attempts, qemu will crash at least once.
+Additional information:
+Final kernel logs before crash:
+```
+...
+[    1.413615] ACPI: Added _OSI(Module Device)
+[    1.413947] ACPI: Added _OSI(Processor Device)
+[    1.414262] ACPI: Added _OSI(3.0 _SCP Extensions)
+[    1.414421] ACPI: Added _OSI(Processor Aggregator Device)
+[    1.414922] ACPI: Added _OSI(Linux-Dell-Video)
+[    1.415445] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
+[    1.444489] ACPI: 1 ACPI AML tables successfully acquired and loaded
+[    1.468218] ACPI: Interpreter enabled
+[    1.469897] ACPI: (supports S0 S3 S4 S5)
+[    1.470200] ACPI: Using IOAPIC for interrupt routing
+[    1.471811] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and repog
+[    1.474421] ACPI: Enabled 2 GPEs in block 00 to 3F
+[    1.536854] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
+[    1.537996] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
+[    1.540988] acpi PNP0A08:00: _OSC: platform does not support [LTR]
+[    1.542232] acpi PNP0A08:00: _OSC: OS now controls [PME AER PCIeCapability]
+[    1.546310] PCI host bridge to bus 0000:00
+[    1.546650] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
+[    1.547471] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
+[    1.548039] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
+[    1.548421] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window]
+[    1.549086] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window]
+[    1.549945] pci_bus 0000:00: root bus resource [mem 0x280000000-0xa7fffffff window]
+[    1.550994] pci_bus 0000:00: root bus resource [bus 00-ff]
+<...crash...>
+```
+
+QEMU backtrace:
+```
+$ gdb build/qemu-system-x86_64 core.3475232
+<...>
+Reading symbols from build/qemu-system-x86_64...
+[New LWP 3475243]
+[New LWP 3475244]
+[New LWP 3475241]
+[New LWP 3475238]
+[New LWP 3475245]
+[New LWP 3475239]
+[New LWP 3475246]
+[New LWP 3475240]
+[New LWP 3475232]
+[New LWP 3475242]
+[New LWP 3475236]
+[New LWP 3475247]
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+Core was generated by `build/qemu-system-x86_64 -m 8192 -smp cpus=10,threads=2 -nographic -machine q35'.
+Program terminated with signal SIGSEGV, Segmentation fault.
+#0  0x0000556065897e0e in memory_region_dispatch_write (mr=mr@entry=0x0, addr=addr@entry=768, data=data@entry=253, 
+    op=op@entry=MO_32, attrs=...) at ../softmmu/memory.c:1497
+1497	    if (mr->alias) {
+[Current thread is 1 (Thread 0x7fe2e951d640 (LWP 3475243))]
+(gdb) bt full
+#0  0x0000556065897e0e in memory_region_dispatch_write
+    (mr=mr@entry=0x0, addr=addr@entry=768, data=data@entry=253, op=op@entry=MO_32, attrs=...) at ../softmmu/memory.c:1497
+        size = <optimized out>
+#1  0x00005560659112c2 in io_writex
+    (env=env@entry=0x556066bbd5d0, full=0x7fe08401ec70, mmu_idx=mmu_idx@entry=2, val=val@entry=253, addr=addr@entry=18446744073699050240, retaddr=retaddr@entry=140611404753775, op=MO_32) at ../accel/tcg/cputlb.c:1430
+        _iothread_lock_auto = 0x1
+        cpu = 0x556066bbb1e0
+        mr_offset = 768
+        section = 0x7fe078d7d570
+        mr = 0x0
+        r = <optimized out>
+#2  0x0000556065915f14 in store_helper
+    (op=MO_32, retaddr=140611404753775, oi=<optimized out>, val=<optimized out>, addr=18446744073699050240, env=0x556066bbd5d0)
+    at ../accel/tcg/cputlb.c:2454
+        full = <optimized out>
+        need_swap = false
+        a_bits = <optimized out>
+        mmu_idx = 2
+        tlb_addr = <optimized out>
+        haddr = <optimized out>
+        size = 4
+        index = <optimized out>
+        entry = 0x7fe08401bc40
+#3  full_le_stl_mmu (env=0x556066bbd5d0, addr=18446744073699050240, val=253, oi=<optimized out>, retaddr=140611404753775)
+    at ../accel/tcg/cputlb.c:2542
+#4  0x00007fe2a4d4eb6f in code_gen_buffer ()
+#5  0x00005560659065bb in cpu_tb_exec
+    (cpu=cpu@entry=0x556066bbb1e0, itb=itb@entry=0x7fe2a4d4e9c0 <code_gen_buffer+13953427>, tb_exit=tb_exit@entry=0x7fe2e951c758)
+    at ../accel/tcg/cpu-exec.c:460
+        env = 0x556066bbd5d0
+        ret = <optimized out>
+        last_tb = <optimized out>
+        tb_ptr = 0x7fe2a4d4ea80 <code_gen_buffer+13953619>
+        __PRETTY_FUNCTION__ = "cpu_tb_exec"
+#6  0x0000556065906ab6 in cpu_loop_exec_tb
+    (tb_exit=0x7fe2e951c758, last_tb=<synthetic pointer>, pc=<optimized out>, tb=0x7fe2a4d4e9c0 <code_gen_buffer+13953427>, cpu=0x556066bbb1e0) at ../accel/tcg/cpu-exec.c:893
+        insns_left = <optimized out>
+        __PRETTY_FUNCTION__ = "cpu_loop_exec_tb"
+        tb = 0x7fe2a4d4e9c0 <code_gen_buffer+13953427>
+        flags = <optimized out>
+        cflags = 4280811520
+        cs_base = <optimized out>
+        pc = <optimized out>
+        last_tb = <optimized out>
+        tb_exit = 0
+--Type <RET> for more, q to quit, c to continue without paging--
+        ret = <optimized out>
+#7  cpu_exec_loop (cpu=cpu@entry=0x556066bbb1e0, sc=sc@entry=0x7fe2e951c7f0) at ../accel/tcg/cpu-exec.c:1013
+        tb = 0x7fe2a4d4e9c0 <code_gen_buffer+13953427>
+        flags = <optimized out>
+        cflags = 4280811520
+        cs_base = <optimized out>
+        pc = <optimized out>
+        last_tb = <optimized out>
+        tb_exit = 0
+        ret = <optimized out>
+#8  0x0000556065907311 in cpu_exec_setjmp (cpu=cpu@entry=0x556066bbb1e0, sc=sc@entry=0x7fe2e951c7f0) at ../accel/tcg/cpu-exec.c:1043
+        __func__ = "cpu_exec_setjmp"
+#9  0x00005560659079f0 in cpu_exec (cpu=cpu@entry=0x556066bbb1e0) at ../accel/tcg/cpu-exec.c:1069
+        ret = <optimized out>
+        sc = {diff_clk = 0, last_cpu_icount = 0, realtime_clock = 0}
+#10 0x000055606592a854 in tcg_cpus_exec (cpu=cpu@entry=0x556066bbb1e0) at ../accel/tcg/tcg-accel-ops.c:81
+        ret = <optimized out>
+        __PRETTY_FUNCTION__ = "tcg_cpus_exec"
+#11 0x000055606592a9a7 in mttcg_cpu_thread_fn (arg=arg@entry=0x556066bbb1e0) at ../accel/tcg/tcg-accel-ops-mttcg.c:95
+        r = <optimized out>
+
+                  force_rcu = {notifier = {notify = 0x55606592aac0 <mttcg_force_rcu>, node = {le_next = 0x0, le_prev = 0x7fe2e951d4a0}}, cpu = 0x556066bbb1e0}
+        cpu = 0x556066bbb1e0
+        __PRETTY_FUNCTION__ = "mttcg_cpu_thread_fn"
+        __func__ = "mttcg_cpu_thread_fn"
+#12 0x0000556065aa2e91 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:541
+
+                    __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {140612553791040, -3809744250012005023, 93872529245600, 25, 140612607756368, 140729970282144, -7051494707616903839, -3809738403745854111}, __mask_was_saved = 0}}, __pad = {0x7fe2e951c970, 0x0, 0x0, 0x0}}
+        __cancel_routine = 0x556065aa2ee0 <qemu_thread_atexit_notify>
+        __not_first_call = <optimized out>
+        start_routine = 0x55606592a8a0 <mttcg_cpu_thread_fn>
+        arg = 0x556066bbb1e0
+        r = <optimized out>
+#13 0x00007fe2ec894b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
+        ret = <optimized out>
+        pd = <optimized out>
+
+                      unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140729970281792, 7053160723592154465, 140612553791040, 25, 140612607756368, 140729970282144, -7051494707570766495, -7051505217351676575}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
+        not_first_call = <optimized out>
+#14 0x00007fe2ec926a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1739 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1739
new file mode 100644
index 00000000..ed3b24c2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1739
@@ -0,0 +1,36 @@
+Build process is broken in /audio/dbusaudio.c:36: pixman.h cannot be found
+Description of problem:
+Hello.
+
+I try to build qemu using commit aa1048e33c. But build process stop in /audio/dbusaudio.c with this error log:
+
+```
+[979/9916] Generating audio-dbus.modin...d (wrapped by meson to capture output)
+FAILED: audio-dbus.modinfo 
+/home/fred/qemu-git/src/qemu/build-full/pyvenv/bin/meson --internal exe --capture audio-dbus.modinfo -- /home/fred/qemu-git/src/qemu/build-full/pyvenv/bin/python3 /home/fred/qemu-git/src/qemu/scripts/modinfo-collect.py ../audio/dbusaudio.c
+--- stderr ---
+In file included from /home/fred/qemu-git/src/qemu/include/ui/console.h:4,
+                 from /home/fred/qemu-git/src/qemu/ui/dbus.h:31,
+                 from ../audio/dbusaudio.c:36:
+/home/fred/qemu-git/src/qemu/include/ui/qemu-pixman.h:12:10: fatal error: pixman.h: No such file or directory
+   12 | #include <pixman.h>
+      |          ^~~~~~~~~~
+compilation terminated.
+```
+
+Of course I have pixman.h which could be find in pixman package:
+
+```                                                              
+pacman -Ql pixman | grep pixman.h
+pixman /usr/include/pixman-1/pixman.h
+```
+
+Used configuration: ```--prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror```
+
+The last time I got a buildable qemu was with commit 79dbd910c9, 3 days ago.
+Steps to reproduce:
+1. Grab latest commit
+2. Use this configure line: ```--prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror```
+3. make and wait
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/174 b/gitlab/issues_text/target_missing/host_missing/accel_missing/174
new file mode 100644
index 00000000..90bf8ab2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/174
@@ -0,0 +1 @@
+European keyboard PC-105 deadkey
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1741 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1741
new file mode 100644
index 00000000..dcd55799
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1741
@@ -0,0 +1 @@
+95059f9c313a7fbd7f22e4cdc1977c0393addc7b breaks some 32bit architectures in linux-user on amd64
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1743 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1743
new file mode 100644
index 00000000..ccb400ae
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1743
@@ -0,0 +1,16 @@
+QEm+Android emulator crashes on x86 host (but not mac M1)
+Description of problem:
+Using QEmu+Android emulator crashes when using tflite on x86 hosts (but not M1 macs).
+Steps to reproduce:
+1. Install android toolchain, including emulator (sdkmanager, adb, avdmanager etc)
+2. Start android emulator on an x86 host
+3. Follow instructions to download and run tflite benchmarking tool [here](https://www.tensorflow.org/lite/performance/measurement)
+4. Crashes with the following error
+
+```
+06-27 17:38:28.093  8355  8355 F ndk_translation: vendor/unbundled_google/libs/ndk_translation/intrinsics/intrinsics_impl_x86_64.cc:86: CHECK failed: 524288 == 0
+```
+
+We have tried with many different models and the result is always the same. The same models run fine when the emulator runs on a mac M1 host.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1744 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1744
new file mode 100644
index 00000000..7d8556ae
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1744
@@ -0,0 +1 @@
+Divide-by-zero in virtio_gpu_simple_process_cmd
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1746 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1746
new file mode 100644
index 00000000..131ab500
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1746
@@ -0,0 +1,3 @@
+PIC32 support in QEMU
+Additional information:
+There is a fork of an older version of QEMU that includes running a PIC32 microcontoller in QEMU hosted [here](https://github.com/sergev/qemu), however, it is very outdated.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1747 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1747
new file mode 100644
index 00000000..ece0bda4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1747
@@ -0,0 +1,16 @@
+eMMC support is missing as a storage type
+Additional information:
+There seems several attempts at this, but the most recent appears much more complete:
+* https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg00347.html
+
+
+
+Historical;
+"[PATCH v3 06/21] sd: emmc: Update CMD8 to send EXT_CSD register"
+https://mail.gnu.org/archive/html/qemu-devel/2021-03/msg00118.html
+
+"[RFC PATCH 00/17] hw/sd: Rework models for eMMC support"
+https://lore.kernel.org/qemu-devel/8aa56da0-a54a-102a-fc85-2fa9f02c18d1@kaod.org/
+
+2011 eMMC original support
+https://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg02835.html
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1748 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1748
new file mode 100644
index 00000000..dd63e95a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1748
@@ -0,0 +1,56 @@
+qcow2: disk size exceeds virtual size
+Description of problem:
+Disk size of qcow2 image file exceeds its virtual size after repeatedly writing, and deleting data in qemu vm.
+Steps to reproduce:
+1. qemu-img create -f qcow2 tmp.qcow2 32M
+2. attach tmp.qcow2 as a device to qemu vm
+3. mount the device in qemu vm, and repeatedly writing, and deleting data
+Additional information:
+xml for attaching tmp.qcow2
+```xml
+   <disk device="disk" type="file">
+      <target bus="virtio" dev="vdb"/>
+      <source file="/path/to/tmp.qcow2"/>
+      <driver type="qcow2" name="qemu" cache="none" discard="unmap"/>
+   </disk>
+```
+in fact, set discard="unmap" or not seems has `little impact` on the final result.
+reproducible shell script.
+```sh
+#! /bin/sh
+
+for i in {1..1000}; do
+    for j in {1..27}; do
+        dd if=/dev/zero of=/mnt/test-$j bs=1M count=1 &
+    done
+    sync
+    sleep 10
+    rm -f /mnt/test-*   
+    fstrim /mnt
+done
+```
+MOUNT the device and run this script, problem happens about 30 minutes.
+
+final result looks like:
+```sh
+# qemu-img info tmp.qcow2 --force
+image: tmp.qcow2
+file format: qcow2
+virtual size: 32 MiB (33554432 bytes)
+disk size: 33 MiB
+cluster_size: 65536
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: false
+    refcount bits: 16
+    corrupt: false
+    extended l2: false
+Child node '/file':
+    filename: tmp.qcow2
+    protocol type: file
+    file length: 32.3 MiB (33882112 bytes)
+    disk size: 33 MiB
+    Format specific information:
+        extent size hint: 1048576
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/175 b/gitlab/issues_text/target_missing/host_missing/accel_missing/175
new file mode 100644
index 00000000..42b46dfd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/175
@@ -0,0 +1 @@
+qmp monitor deadlock (with spice events for ex)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1753 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1753
new file mode 100644
index 00000000..ea3f48ef
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1753
@@ -0,0 +1,3 @@
+Does the qemu have luks2 support?
+Description of problem:
+Does the qemu have luks2 support?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1754 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1754
new file mode 100644
index 00000000..80ffefb8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1754
@@ -0,0 +1,16 @@
+QEMU wrongly requires SD card sizes to be a power of two
+Description of problem:
+QEMU arbitrarily requires SD card sizes to be a power of 2. However, this behavior does not match the real world, and I am unable to pass a *physical* SD card into the guest operating system.
+```
+$ sudo qemu-system-aarch64 -M raspi2b -drive file=/dev/mmcblk0,if=sd,format=raw
+qemu-system-aarch64: Invalid SD card size: 29.7 GiB
+SD card size has to be a power of 2, e.g. 32 GiB.
+You can resize disk images with 'qemu-img resize <imagefile> <new-size>'
+(note that this will lose data if you make the image smaller than it currently is).
+```
+Steps to reproduce:
+1. Insert a physical SD card into your host system and make a note of its device name. It will be something like `/dev/mmcblk0`
+2. Attempt to start a guest OS with the SD card attached. See the command above.
+3. You will get an error saying that the card size is not a power of two.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1755 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1755
new file mode 100644
index 00000000..c23d64c0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1755
@@ -0,0 +1,20 @@
+qemu-arm fails to execute a cortex-M binary (page_set_flags: Assertion 'last <= GUEST_ADDR_MAX' failed.)
+Description of problem:
+I've noticed that qemu-arm (so linux-user mode) fails to execute a binary targeting cortex-M. This used to work until commit
+"Make the commpage executable".
+Steps to reproduce:
+1. Compile a simple hello.c for arm-eabi. If you don't have such a toolchain, you can download one from https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads    For instance https://developer.arm.com/-/media/Files/downloads/gnu/12.2.rel1/binrel/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi.tar.xz (for an x86_64 linux host)
+
+2.# compile for cortex-m3:
+
+3. arm-none-eabi-gcc hello.c -o hello.exe.m3 -mcpu=cortex-m3 -specs=rdimon.specs
+
+4.qemu-arm -cpu cortex-m3 hello.exe.m3
+.....user-exec.c:492: page_set_flags: Assertion 'last <= GUEST_ADDR_MAX' failed.
+
+5. # compile for cortex-a9:
+
+6. arm-none-eabi-gcc hello.c -o hello.exe.a9 -mcpu=cortex-a9 -specs=rdimon.specs
+
+7. qemu-arm -cpu cortex-a9 hello.exe.a9
+Hello
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1756 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1756
new file mode 100644
index 00000000..1c30a239
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1756
@@ -0,0 +1,43 @@
+qemu8-user on Linux: SIGSEGV because brk(NULL) does not exist
+Description of problem:
+On Linux, the return value of the system call brk(NULL) need not point to a page that exists.
+If so, then qemu8-user will generate SIGSEGV at the next call to brk() with a higher value,
+because qemu8 believes that it should maintain contiguous .bss with bytes of value 0.
+Thus qemu8-user so calls `memset(g2h_untagged(target_brk), 0, brk_page - target_brk);
+in do_brk() at ../linux-user/syscall.c:867, and this generates SIGSEGV at
+the non-existent page that covers brk(NULL).
+
+Instead, the safest thing to do is nothing at all.
+Linux deliberately returns a random value for brk(NULL), subject to the conditions
+that the value be at least as large as the maximum over all PT_LOAD of (.p_vaddr + .p_memsz),
+and "somewhat near" that maximum.  The purpose of randomness is to use variability
+to interfere with effectiveness of malware, and to expose application coding errors
+regarding brk() and sbrk().  If qemu-user wants to preserve contiguous .bss,
+then qemu-user should call memset() only if the first page of the range exists.
+(As explained in the next paragraph, "contiguous .bss" is a murky concept.)
+
+Linux itself is partly to blame, because it computes the maximum (.p_vaddr + .p_memsz)
+over all the PT_LOAD of the most recent execve().  The most recent execve() seen by
+Linux might have no relationship to the state of the address space at the time of
+_either_ call to brk().  The app can do arbitrary mmap, munmap, mprotect at any time.
+In particular, the run-time de-compressor of UPX does exactly that for a compressed
+main program.  The maximum computed by Linux is for the compressed program,
+which has a different layout than the de-compressed program.
+
+There is a Linux system call prctl(PR_SET_MM_BRK, new_value) which sets a value
+for "the brk", but that syscall tries to validate the new_value based on
+the most recent execve().  Once again, that has no relationship to the current
+layout of the address space produced by the UPX de-compressor.
+Steps to reproduce:
+1. build qemu8-x86_64 from
+```
+commit fcb237e64f9d026c03d635579c7b288d0008a6e5 (HEAD -> master, origin/master, origin/HEAD)
+Merge: 2ff49e96ac c00aac6f14
+Date:   Mon Jul 10 09:17:06 2023 +0100
+```
+2. run `build/qemu-x86_64 -strace upx-4.0.2-amd64_linux/upx --version` where the upx
+is from https://github.com/upx/upx/releases/download/v4.0.2/upx-4.0.2-amd64_linux.tar.xz
+3. output ends with
+```
+372621 close(3) = 0
+372621 munmap(0x0000004000803000,3055) = 0
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1757 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1757
new file mode 100644
index 00000000..138abda4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1757
@@ -0,0 +1 @@
+guest-agent: improve help for --allow-rpcs and --block-rpcs
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1758 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1758
new file mode 100644
index 00000000..13c8ad5f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1758
@@ -0,0 +1,12 @@
+libssh missing on macOS/m1
+Description of problem:
+I did a "git pull" in my source for qemu. Now when I do "make" I get:
+../block/ssh.c:27:10: fatal error: 'libssh/libssh.h' file not found
+
+Am I supposed to install libssh separately? I were able to compile qemu about a month ago or so.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1759 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1759
new file mode 100644
index 00000000..098bafaf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1759
@@ -0,0 +1,10 @@
+qemu-system-i386 error during install windows 95/98
+Description of problem:
+Installation of the Windows starts but when Windows 95 is supposed to copy files it failes like: ![qemu803_win95](/uploads/40e94adda4cdf5c57fa751d5db04ef7b/qemu803_win95.png)
+Installation of Windows 98 failes like: ![qemu803_win98](/uploads/110ece638cd71f8ec41dd029379af807/qemu803_win98.png)
+Steps to reproduce:
+1. get boot floppy & install cd for windows 95
+2. create hard drive C image
+3. try to install Windows 95
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/176 b/gitlab/issues_text/target_missing/host_missing/accel_missing/176
new file mode 100644
index 00000000..0449b901
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/176
@@ -0,0 +1 @@
+virtual machine cpu soft lockup when qemu attach disk
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1760 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1760
new file mode 100644
index 00000000..b6afa440
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1760
@@ -0,0 +1,53 @@
+qemu8-i386 gets wrong arguments for 32-bit old mmap syscall (_NR_mmap = 90)
+Description of problem:
+qemu8-i386 does not decode syscall arguments correctly for system call _NR_mmap = 90 on i386.
+```
+$ strace ./oldmmap
+execve("./oldmmap", ["./oldmmap"], 0x7fff46ba6d40 /* 61 vars */) = 0
+[ Process PID=405233 runs in 32 bit mode. ]
+mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fa7000
+exit(5)                                 = ?
++++ exited with 5 +++
+
+$ build/qemu-i386 -strace ./oldmmap
+405254 mmap(0x40800058,0,PROT_NONE,0,0,0) = 0x3fffb000
+405254 exit(5)
+```
+Steps to reproduce:
+1. gcc -m32 -o oldmmap -nostartfiles -nostdlib oldmmap.S  # build 32-bit executable
+2. strace ./oldmmap  # run under strace
+3. build/qemu-i386 -strace ./oldmmap  # run under "qemu-i386 -strace"
+4. Notice that qemu-i386 did not report the same arguments to the _NR_map syscall as /usr/bin/strace did.
+Additional information:
+```
+$ cat oldmmap.S
+MAP_FIXED=     0x10
+MAP_PRIVATE=   0x02
+MAP_ANONYMOUS= 0x20
+
+PROT_READ=      1
+PROT_WRITE=     2
+PROT_EXEC=      4
+
+_NR_exit = 1
+_NR_mmap = 90  // oldmmap: %ebx -> array of 6 arguments
+
+    .globl _start
+_start:
+    push $0  // offset
+    push $-1  // fd
+    push $MAP_PRIVATE|MAP_ANONYMOUS  // flags
+    push $PROT_READ|PROT_WRITE  // protection
+    push $2<<12  // length
+    push $0  // addr (kernel chooses)
+    mov %esp,%ebx
+    mov $_NR_mmap,%eax
+    int $0x80
+    nop
+
+    mov $5,%ebx
+    mov $_NR_exit,%eax
+    int $0x80
+    hlt
+$ 
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1764 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1764
new file mode 100644
index 00000000..d1c317eb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1764
@@ -0,0 +1 @@
+lsusb fails with qemu-system-x86_64 command (qemu-system-x86 package)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1766 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1766
new file mode 100644
index 00000000..0dec71af
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1766
@@ -0,0 +1,3 @@
+-strace should print target program counter when SIGSEGV
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1767 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1767
new file mode 100644
index 00000000..3792bf33
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1767
@@ -0,0 +1,3 @@
+Add iphone emulated device
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1768 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1768
new file mode 100644
index 00000000..0bd34a03
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1768
@@ -0,0 +1,32 @@
+Could not allocate more than ~2GB with qemu-user
+Description of problem:
+On qemu-user, failed to allocate more than about 2GB on 32bit platform supporting up to 4GB (arm, ppc, etc.)
+Steps to reproduce:
+1. Try to allocate more than 2GB [e.g. for(i=0;i<64;i++) if(malloc(64*1024*1024)==NULL) perror("Failed to allocate 64MB");]
+2. Only 1 64MB chunck is allocated in the upper 2GB memory space
+3. Failed to allocate after about 2GB.
+Additional information:
+The problem is in **pageflags_find** and **pageflags_next** functions (found in _accel/tcg/user-exec.c_) 3rd parameters, that should be **target_ulong** instead of incorrect _target_long_ (the parameter will be converted signed extended to uint64_t).
+The testing program is the following:
+```
+#include <stdio.h>
+#include <stdlib.h>
+
+int main(int argc,char *argv[]) {
+  unsigned int a;
+  unsigned int i;
+  char *al;
+  unsigned int sss=1U*1024*1024*64;
+  for(a=0;a<128;a++) {
+    al=malloc(sss);
+    if(al!=NULL) {
+      printf("ALLOC OK %u (%08lX)!\n",sss*(a+1),al);
+    }
+    else {
+      printf("Cannot alloc %d\n",(a+1)*sss);
+      perror("Cannot alloc");
+      exit(1);
+    }
+  }
+}
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/177 b/gitlab/issues_text/target_missing/host_missing/accel_missing/177
new file mode 100644
index 00000000..4745d730
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/177
@@ -0,0 +1 @@
+qemu-bridge-helper undocumented and broken
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1770 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1770
new file mode 100644
index 00000000..002e3910
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1770
@@ -0,0 +1,22 @@
+Wrong unpacked structure for epoll_event on qemu-or1k (openrisc)
+Description of problem:
+When using cmake automoc, the process will infinite loop waiting for epoll_events.
+Steps to reproduce:
+1. Try to compile cmake with qt5 support
+2. The build process will freeze when "Automatic MOC" is invoked
+Additional information:
+The problem is that or1k has a "packed" epoll_event structure, so it should be also packed in target_epoll_event structure.
+Following the (very trivial) patch:
+```
+--- qemu-20230327/linux-user/syscall_defs.h.orig	2023-03-27 15:41:42.000000000 +0200
++++ qemu-20230327/linux-user/syscall_defs.h	2023-06-30 17:29:39.034322213 +0200
+@@ -2714,7 +2709,7 @@ 
+ #define FUTEX_CMD_MASK          ~(FUTEX_PRIVATE_FLAG | FUTEX_CLOCK_REALTIME)
+ 
+ #ifdef CONFIG_EPOLL
+-#if defined(TARGET_X86_64)
++#if defined(TARGET_X86_64) || defined(TARGET_OPENRISC)
+ #define TARGET_EPOLL_PACKED QEMU_PACKED
+ #else
+ #define TARGET_EPOLL_PACKED
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1773 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1773
new file mode 100644
index 00000000..abdceee9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1773
@@ -0,0 +1,9 @@
+qemu does not use the mic of the webcam dedicated to the VM
+Description of problem:
+
+Steps to reproduce:
+1. plug two webcams to the desktop, one for the host and one for the VM
+2. launch QEMU VM
+3. QEMU VM take the desktop webcam mic instead of the webcam mic dedicated to the VM.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1775 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1775
new file mode 100644
index 00000000..926932e0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1775
@@ -0,0 +1,61 @@
+QEMU abort on Cortex-M breakpoint exception
+Description of problem:
+When a breakpoint exception is raised in a ARM Cortex-M board QEMU aborts.
+
+```
+$ qemu-system-arm --version
+QEMU emulator version 8.0.90 (v8.1.0-rc0-21-gd1181d2937)
+
+$ ./qemu-system-arm -M stm32vldiscovery -nographic -device loader,file=raw-bkpt.hex -d in_asm,exec,int 
+[...]
+Trace 0: 0x7fac6c000100 [00800400/0000000000000100/00000110/ff200000]
+----------------
+IN:
+0x00000110:  be01       bkpt     #1
+
+Linking TBs 0x7fac6c000100 index 0 -> 0x7fac6c0002c0
+Trace 0: 0x7fac6c0002c0 [00800400/0000000000000110/00000110/ff200000]
+qemu-system-arm: ../target/arm/helper.c:12224: arm_security_space_below_el3: Assertion `!arm_feature(env, ARM_FEATURE_M)' failed.
+```
+
+Expected behavior:
+```
+$ qemu-system-arm --version
+QEMU emulator version 7.1.0
+
+$ ./qemu-system-arm -M stm32vldiscovery -nographic -device loader,file=raw-bkpt.hex -d in_asm,exec,int 
+[...]
+Trace 0: 0x7f5408000100 [00800400/00000100/00000110/ff000000]
+----------------
+IN:
+0x00000110:  be01       bkpt     #1
+
+Linking TBs 0x7f5408000100 [00000100] index 0 -> 0x7f54080002c0 [00000110]
+Trace 0: 0x7f54080002c0 [00800400/00000110/00000110/ff000000]
+Taking exception 7 [Breakpoint] on CPU 0
+...BusFault with BFSR.STKERR
+...taking pending nonsecure exception 3
+...loading from element 3 of non-secure vector table at 0xc
+...loaded new PC 0x0
+----------------
+```
+Steps to reproduce:
+1. Run any Cortex-M firmware that raises a breakpoint exception. (minimal example attached)
+Additional information:
+- Minimal Reproducer:
+[raw-bkpt.hex](/uploads/b9289c6f3a4feef015c8a3dffb4fc467/raw-bkpt.hex)
+- This is **not** a duplicate of #1658 / #1740
+- Stacktrace:
+```
+#2  0x00007ffff5a68538 in abort () at /usr/lib/libc.so.6
+#3  0x00007ffff5a6845c in  () at /usr/lib/libc.so.6
+#4  0x00007ffff5a783d6 in  () at /usr/lib/libc.so.6
+#5  0x0000555555c55921 in arm_security_space_below_el3 (env=0x555556dc1b40) at ../target/arm/helper.c:12224
+#6  arm_security_space_below_el3 (env=env@entry=0x555556dc1b40) at ../target/arm/helper.c:12222
+#7  0x0000555555c48b08 in arm_is_secure_below_el3 (env=0x555556dc1b40) at ../target/arm/cpu.h:2465
+#8  arm_is_el2_enabled (env=0x555556dc1b40) at ../target/arm/cpu.h:2517
+#9  arm_debug_target_el (env=env@entry=0x555556dc1b40) at ../target/arm/debug_helper.c:24
+#10 0x0000555555c49cb5 in helper_exception_bkpt_insn (env=0x555556dc1b40, syndrome=0xe2000001) at ../target/arm/debug_helper.c:510
+#11 0x00007fffac0002d9 in code_gen_buffer ()
+[...]
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1777 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1777
new file mode 100644
index 00000000..59e9986a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1777
@@ -0,0 +1 @@
+Allow logging of IP addresses of connections made to QEMU socket backends for e.g. VNC or SPICE console
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1778 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1778
new file mode 100644
index 00000000..b007a368
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1778
@@ -0,0 +1 @@
+Spice audio play at wrong speed and frequency after qemu-7.2.0
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/178 b/gitlab/issues_text/target_missing/host_missing/accel_missing/178
new file mode 100644
index 00000000..143483b3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/178
@@ -0,0 +1 @@
+Meson setup fails with meson 0.58.0
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1781 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1781
new file mode 100644
index 00000000..b50fa1b4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1781
@@ -0,0 +1,54 @@
+8.1.0rc0: configure from tar file fetches subprojects via git
+Description of problem:
+Executing configure from tar file fetches subprojects via git. Fetched subprojects are https://gitlab.com/qemu-project/dtc and https://gitlab.com/qemu-project/keycodemapdb
+```
+$ ./configure --disable-download
+Using './build' as the directory for build output
+...
+Initialized empty Git repository in /home/helge/qemu-8.1.0-rc0/subprojects/dtc/.git/
+remote: Enumerating objects: 319, done.
+remote: Counting objects: 100% (319/319), done.
+remote: Compressing objects: 100% (251/251), done.
+remote: Total 319 (delta 54), reused 163 (delta 38), pack-reused 0
+Receiving objects: 100% (319/319), 250.56 KiB | 1.94 MiB/s, done.
+Resolving deltas: 100% (54/54), done.
+From https://gitlab.com/qemu-project/dtc
+ * branch            b6910bec11614980a21e46fbccc35934b671bd81 -> FETCH_HEAD
+HEAD is now at b6910be Bump version to v1.6.1
+...
+Initialized empty Git repository in /home/helge/qemu-8.1.0-rc0/subprojects/keycodemapdb/.git/
+remote: Enumerating objects: 26, done.
+remote: Counting objects: 100% (26/26), done.
+remote: Compressing objects: 100% (21/21), done.
+remote: Total 26 (delta 0), reused 23 (delta 0), pack-reused 0
+Unpacking objects: 100% (26/26), 30.65 KiB | 216.00 KiB/s, done.
+From https://gitlab.com/qemu-project/keycodemapdb
+ * branch            f5772a62ec52591ff6870b7e8ef32482371f22c6 -> FETCH_HEAD
+HEAD is now at f5772a6 Add Qemu qcode support for F13 to F24
+...
+```
+
+Using `--disable-download` is no option:
+```
+$ ./configure --disable-download
+Using './build' as the directory for build output
+
+ERROR: missing subprojects
+
+This is not a GIT checkout but subproject content appears to
+be missing. Do not use 'git archive' or GitHub download links
+to acquire QEMU source archives. Non-GIT builds are only
+supported with source archives linked from:
+
+  https://www.qemu.org/download/#source
+```
+
+If I understand the error message correctly, the subprojects should be part of the tar.
+Steps to reproduce:
+1. Open Clang64 console
+2. `pacman -Syu`
+3. `pacman -S binutils mingw-w64-clang-x86_64-toolchain mingw-w64-clang-x86_64-glib2 mingw-w64-clang-x86_64-ninja mingw-w64-clang-x86_64-pixman mingw-w64-clang-x86_64-python mingw-w64-clang-x86_64-python-sphinx mingw-w64-clang-x86_64-python-sphinx_rtd_theme`
+4. `wget https://download.qemu.org/qemu-8.1.0-rc0.tar.xz`
+5. `tar -xf qemu-8.1.0-rc0.tar.xz`
+6. `cd qemu-8.1.0-rc0`
+7. `./configure` or `./configure --disable-download`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1782 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1782
new file mode 100644
index 00000000..62b3b34d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1782
@@ -0,0 +1,58 @@
+8.1.0rc0: Build failure compiling with clang on windows
+Description of problem:
+Building in Clang64 environment finally fails with:
+```
+...
+[1416/2001] Compiling C object libcommon.fa.p/ui_dbus-listener.c.obj
+FAILED: libcommon.fa.p/ui_dbus-listener.c.obj
+"cc" "-m64" "-mcx16" "-Ilibcommon.fa.p" "-Isubprojects/dtc/libfdt" "-I../subprojects/dtc/libfdt" "-Iui" "-I../ui" "-IC:/msys64/clang64/include/pixman-1" "-IC:/msys64/clang64/include/glib-2.0" "-IC:/msys64/clang64/lib/glib-2.0/include" "-IC:/msys64/clang64/include/ncursesw" "-fcolor-diagnostics" "-Wall" "-Winvalid-pch" "-std=gnu11" "-O2" "-g" "-fstack-protector-strong" "-Wundef" "-Wwrite-strings" "-Wmissing-prototypes" "-Wstrict-prototypes" "-Wredundant-decls" "-Wold-style-definition" "-Wtype-limits" "-Wformat-security" "-Wformat-y2k" "-Winit-self" "-Wignored-qualifiers" "-Wempty-body" "-Wnested-externs" "-Wendif-labels" "-Wexpansion-to-defined" "-Wmissing-format-attribute" "-Wno-initializer-overrides" "-Wno-missing-include-dirs" "-Wno-shift-negative-value" "-Wno-string-plus-int" "-Wno-typedef-redefinition" "-Wno-tautological-type-limit-compare" "-Wno-psabi" "-Wno-gnu-variable-sized-type-not-at-end" "-Wthread-safety" "-iquote" "." "-iquote" "C:/msys64/home/helge/qemu-8.1.0-rc0" "-iquote" "C:/msys64/home/helge/qemu-8.1.0-rc0/include" "-iquote" "C:/msys64/home/helge/qemu-8.1.0-rc0/host/include/x86_64" "-iquote" "C:/msys64/home/helge/qemu-8.1.0-rc0/host/include/generic" "-iquote" "C:/msys64/home/helge/qemu-8.1.0-rc0/tcg/i386" "-D_GNU_SOURCE" "-D_FILE_OFFSET_BITS=64" "-D_LARGEFILE_SOURCE" "-fno-strict-aliasing" "-fno-common" "-fwrapv" "-fno-pie" "-DNCURSES_WIDECHAR" "-DNCURSES_WIDECHAR=1" -MD -MQ libcommon.fa.p/ui_dbus-listener.c.obj -MF "libcommon.fa.p/ui_dbus-listener.c.obj.d" -o libcommon.fa.p/ui_dbus-listener.c.obj "-c" ../ui/dbus-listener.c
+../ui/dbus-listener.c:355:10: error: call to undeclared function 'd3d_texture2d_release0'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
+    if (!d3d_texture2d_release0(tex, &err)) {
+         ^
+../ui/dbus-listener.c:360:10: error: call to undeclared function 'd3d_texture2d_share'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
+    if (!d3d_texture2d_share(tex, &share_handle, &err)) {
+         ^
+../ui/dbus-listener.c:392:10: error: call to undeclared function 'd3d_texture2d_acquire0'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
+    if (!d3d_texture2d_acquire0(tex, &err)) {
+         ^
+3 errors generated.
+ninja: build stopped: subcommand failed.
+make[1]: *** [Makefile:162: run-ninja] Error 1
+make[1]: Leaving directory '/home/helge/qemu-8.1.0-rc0/build'
+make: *** [GNUmakefile:11: all] Error 2
+
+...
+```
+Steps to reproduce:
+1. Open Clang64 console
+2. `pacman -Syu`
+3. `pacman -S binutils mingw-w64-clang-x86_64-toolchain mingw-w64-clang-x86_64-glib2 mingw-w64-clang-x86_64-ninja mingw-w64-clang-x86_64-pixman mingw-w64-clang-x86_64-python mingw-w64-clang-x86_64-python-sphinx mingw-w64-clang-x86_64-python-sphinx_rtd_theme`
+4. `wget https://download.qemu.org/qemu-8.1.0-rc0.tar.xz`
+5. `tar -xf qemu-8.1.0-rc0.tar.xz`
+6. `cd qemu-8.1.0-rc0`
+7. `./configure --target-list=x86_64-softmmu`
+8. `make`
+Additional information:
+The used cc is clang in Msys2/Clang64 environment:
+```
+$ md5sum /clang64/bin/cc.exe /clang64/bin/clang.exe
+bb70e04a10456b05b07f14d190ad9015 */clang64/bin/cc.exe
+bb70e04a10456b05b07f14d190ad9015 */clang64/bin/clang.exe
+```
+
+On manually repeating the command in build directory a different error is shown:
+```
+$ cd build
+$ "cc" "-m64" "-mcx16" "-Ilibcommon.fa.p" "-Isubprojects/dtc/libfdt" "-I../subprojects/dtc/libfdt" "-Iui" "-I../ui" "-IC:/msys64/clang64/include/pixman-1" "-IC:/msys64/clang64/include/glib-2.0" "-IC:/msys64/clang64/lib/glib-2.0/include" "-IC:/msys64/clang64/include/ncursesw" "-fcolor-diagnostics" "-Wall" "-Winvalid-pch" "-std=gnu11" "-O2" "-g" "-fstack-protector-strong" "-Wundef" "-Wwrite-strings" "-Wmissing-prototypes" "-Wstrict-prototypes" "-Wredundant-decls" "-Wold-style-definition" "-Wtype-limits" "-Wformat-security" "-Wformat-y2k" "-Winit-self" "-Wignored-qualifiers" "-Wempty-body" "-Wnested-externs" "-Wendif-labels" "-Wexpansion-to-defined" "-Wmissing-format-attribute" "-Wno-initializer-overrides" "-Wno-missing-include-dirs" "-Wno-shift-negative-value" "-Wno-string-plus-int" "-Wno-typedef-redefinition" "-Wno-tautological-type-limit-compare" "-Wno-psabi" "-Wno-gnu-variable-sized-type-not-at-end" "-Wthread-safety" "-iquote" "." "-iquote" "C:/msys64/home/helge/qemu-8.1.0-rc0" "-iquote" "C:/msys64/home/helge/qemu-8.1.0-rc0/include" "-iquote" "C:/msys64/home/helge/qemu-8.1.0-rc0/host/include/x86_64" "-iquote" "C:/msys64/home/helge/qemu-8.1.0-rc0/host/include/generic" "-iquote" "C:/msys64/home/helge/qemu-8.1.0-rc0/tcg/i386" "-D_GNU_SOURCE" "-D_FILE_OFFSET_BITS=64" "-D_LARGEFILE_SOURCE" "-fno-strict-aliasing" "-fno-common" "-fwrapv" "-fno-pie" "-DNCURSES_WIDECHAR" "-DNCURSES_WIDECHAR=1" -MD -MQ libcommon.fa.p/ui_dbus-listener.c.obj -MF "libcommon.fa.p/ui_dbus-listener.c.obj.d" -o libcommon.fa.p/ui_dbus-listener.c.obj "-c" ../ui/dbus-listener.c
+../ui/dbus-listener.c:236:9: error: expected expression
+        Error *err = NULL;
+        ^
+../ui/dbus-listener.c:240:56: error: use of undeclared identifier 'err'
+        if (!d3d_texture2d_release0(ddl->d3d_texture, &err)) {
+                                                       ^
+../ui/dbus-listener.c:241:30: error: use of undeclared identifier 'err'
+            error_report_err(err);
+                             ^
+3 errors generated.
+
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1783 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1783
new file mode 100644
index 00000000..685d9595
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1783
@@ -0,0 +1,3 @@
+Emulate Breakout Network Connections
+Additional information:
+This functionality is required to model/QA real-world implementations for datacenter fabrics in virtual environments. Break-out cabling is how port density is achieved in practice on modern optical fabrics.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1784 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1784
new file mode 100644
index 00000000..ffcbc6da
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1784
@@ -0,0 +1,13 @@
+Mac M1 Max / Debian guest / Luks password / Switching to graphical login manager (lightdm/Gdm) hangs in 75%
+Description of problem:
+In approximately 70% of cases I start QEMU with a Debian guest where the Debian guest was installed with full disk encryption, QEMU 'hangs' (does not respond') after I unlock the encrypted guest and the guest tries to start the graphical login manager (gdm or lightdm).
+
+I need to force quit QEMU, restart it multiple times until the start of the graphical login manager works.
+Steps to reproduce:
+1. Install Debian with (guided) full disk encryption and either the Gnome or the XFCE desktop environment
+2. To be able to unlock the hard disk after the installation finished, the Linux boot parameter 'console=tty1' needs to be added within grub to the Linux command line
+3. Try to restart/reboot QEMU  several times and QEMU will become unresponsive multiple times in this process.
+Additional information:
+I encounter this problem for several months now, with different versions of QEMU, macOS and Debian.
+
+There is one observation, which might help: I installed [DropBear](https://packages.debian.org/buster/dropbear-initramfs) to experiment with remote unlocking of Luks encrypted Linux boxes. It seems, that QEMU does not go into the unresponsive state, when I unlock the hard disk via SSH and not focus the QEMU window until after the graphical login manager started. (Only tried remote unlocking a few times so it is too early to confirm if this works 100% of the time.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1785 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1785
new file mode 100644
index 00000000..684ed07a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1785
@@ -0,0 +1,25 @@
+8.1.0rc0: Build failure when building static binaries, auto config incorrectly mark bzip2 as supported on my machine
+Description of problem:
+8.1.0rc0 fails to build when I build static binaries.
+
+```
+Jul 24 20:28:22 clang-13: warning: argument unused during compilation: '-pie' [-Wunused-command-line-argument]
+Jul 24 20:28:22 ld.lld: error: attempted static link of dynamic object /usr/bin/../lib/libbz2.so
+Jul 24 20:28:22 clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
+```
+
+It seems that `./configure` mistaken my dynamic library of bzip2 as able to compile under static compilation.
+Steps to reproduce:
+1. `./configure --target-list=x86_64-softmmu --static` with bzip2 only dynamicly installed and static library not installed
+2. see output
+
+You can see
+```
+    snappy support                               : NO
+    bzip2 support                                : YES
+    lzfse support                                : NO
+```
+
+which is wrong. Additionally, the compilation fails because the system only have bzip2 dynamicly but not staticly.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1786 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1786
new file mode 100644
index 00000000..a58ec574
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1786
@@ -0,0 +1,24 @@
+Impossible to create an uncompressed QCOW2 disk
+Description of problem:
+An QCOW2 image is created compressed unconditionally. There is no way to disable compression, albeit the QCOW format specification allows this.
+
+```
+$ qemu-img --version
+qemu-img version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.12)
+Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
+$ qemu-img create -f qcow2 test.qcow2 1G
+Formatting 'test.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16
+$
+```
+
+Same is applicable for 8-x qemu-img version (I built it for testing purposes)
+```
+$ ./build/qemu-img create -f qcow2 disk.qcow2 1G
+Formatting 'disk.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16
+$ ./build/qemu-img --version
+qemu-img version 8.0.90 (v8.1.0-rc0-21-gd1181d2937)
+Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers
+$ 
+```
+Steps to reproduce:
+Create a QCOW2 disk with `qemu-img` of never versions.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1787 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1787
new file mode 100644
index 00000000..d7a87a52
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1787
@@ -0,0 +1,13 @@
+Qemu asan test make vm crash when using qxl and spice
+Description of problem:
+When I tested QEMU with asan, the vm crash. The error message is as follows：
+![1](/uploads/a44f3790fe6c375aa8eac3a178da963d/1.jpg)
+Steps to reproduce:
+1.Start the vm with qxl and spice.
+2.Attach the vm with vnc and spice.
+3.Placed for more than three days.
+4.Operation on spice client and possible reproduce this bug.
+Additional information:
+https://github.com/qemu/qemu/blob/44f28df24767cf9dca1ddc9b23157737c4cbb645/ui/cursor.c#L112
+I think the reason for the problem is that the cursor pointer was not set to NULL when qemu call cursor_put. But I don't know what situation will trigger this error.
+This error is difficult to reproduce by natural.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1788 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1788
new file mode 100644
index 00000000..c04f1f04
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1788
@@ -0,0 +1,29 @@
+Floating point rounding fails on mps3-an547 amd cortex-m55 while using LLVM-embedded-toolchain-for-Arm and Picolibic.
+Description of problem:
+Rounding of long double gives unexpected result. Simple code as example:
+```
+#include <math.h>
+int main(void)
+{
+  long double value = -8.5L;
+  long rounded_value = lrintl(value);
+  if( -8 == rounded_value )
+  {
+    return 0;
+  }
+  return 1;
+}
+```
+Steps to reproduce:
+1. Checkout project: [LLVM-embedded-toolchain-for-ARM](https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm)
+2. Configure it with option -DLLVM_TOOLCHAIN_LIBRARY_VARIANTS=armv8.1m.main_hard_nofp_mve 
+3. Build project
+4. Run Picolbic tests with ninja picolibc_armv8.1m.main_hard_nofp_mve-test
+
+As a result long_double test fails with incorrect rounding.
+Last qemu version which successfully execute mentioned test is: qemu 7.0.0 downloaded via [qemu-7.0.0](https://download.qemu.org/qemu-7.0.0.tar.bz2). 
+Issue is present since qemu version 7.1.
+Additional information:
+As a result long_double test fails with incorrect rounding.
+Last qemu version which successfully execute mentioned test is: qemu 7.0.0 downloaded via [qemu-7.0.0](https://download.qemu.org/qemu-7.0.0.tar.bz2). 
+Issue is present since qemu version 7.1.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1789 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1789
new file mode 100644
index 00000000..841bbd3c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1789
@@ -0,0 +1,17 @@
+First connection to spice hangs after 1 min
+Description of problem:
+After starting a VM the first connection to spice logs this errors:
+
+```
+2023-07-25T16:00:47.497042Z qemu-system-x86_64: warning: Spice: main:0 (0x7f1a3fca5b90): invalid net test stage, ping id 0 test id 0 stage 4
+2023-07-25T16:00:47.497170Z qemu-system-x86_64: warning: Spice: main:0 (0x7f1a3fca5b90): invalid net test stage, ping id 0 test id 0 stage 0
+```
+
+And after 60 seconds the spice viewer is closed with this error:
+```
+2023-07-25T16:01:47.384207Z qemu-system-x86_64: warning: Spice: main:0 (0x7f1a3fca5b90): rcc 0x7f1a1968cb60 has been unresponsive for more than 30000 ms, disconnecting
+```
+Steps to reproduce:
+1. Start vm with spice
+2. Connect to spice
+3. Wait for at least 60 seconds and the viewer will close
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/179 b/gitlab/issues_text/target_missing/host_missing/accel_missing/179
new file mode 100644
index 00000000..e3c40e1a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/179
@@ -0,0 +1 @@
+qemu guest crashes on spice client USB redirected device removal
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1791 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1791
new file mode 100644
index 00000000..b01c936b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1791
@@ -0,0 +1,40 @@
+qemu 8.1.0 rc tarballs are broken, missing subproject content
+Description of problem:
+The released tarballs for 8.1.0 rc releases (both rc0 adn rc1) are missing the
+subproject content. Only the submodule content appears present
+Steps to reproduce:
+1. `wget http://download.qemu.org/qemu-8.1.0-rc1.tar.xz`
+2. `tar Jxvf qemu-8.1.0-rc1.tar.xz`
+3. `cd qemu-8.1.0-rc1`
+4. `./configure  --target-list=x86_64-softmmu --disable-download`
+
+```
+Using './build' as the directory for build output
+
+ERROR: missing subprojects
+
+This is not a GIT checkout but subproject content appears to
+be missing. Do not use 'git archive' or GitHub download links
+to acquire QEMU source archives. Non-GIT builds are only
+supported with source archives linked from:
+
+  https://www.qemu.org/download/#source
+
+Developers working with GIT can use scripts/archive-source.sh
+if they need to create valid source archives.
+
+```
+
+The missing subprojects are
+
+```
+ berkeley-softfloat-3
+ berkeley-testfloat-3
+ dtc
+ keycodemapdb
+ libvfio-user
+```
+
+If I use 'make-release . 8.1.0-rc1' to create a tarball from git, it has all the expected content.
+
+IOW, either the release tarballs are not being created using 'make-release', or there's something broken with 'make-release' in some scenarios
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1792 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1792
new file mode 100644
index 00000000..e0f78ec6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1792
@@ -0,0 +1,81 @@
+qemu-8.1-rc1 and rc0 fail build. 8.0 is fine
+Description of problem:
+Build error with 8.1.0-rc0 and 8.1.0-rc1.
+Build of 8.0.3 works correctly, using the same build configuration.
+Steps to reproduce:
+1. Run configure as below in logs
+2.`/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/.x86_64-linux-gnu/pyvenv/bin/python3 -m ensurepip --upgrade --default-pip`
+3.
+Additional information:
+```
+$ s/build qemu:host
+CLEAN      qemu
+    *      Removing /var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc0 ...
+    *      Removing /var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/qa_checks/qemu-* ...
+UNPACK      qemu
+BUILD      qemu (host)
+    TOOLCHAIN      configure
+Executing (host): /var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/configure --bindir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/bin --extra-cflags=-I/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/include --extra-ldflags=-L/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib --libexecdir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib --localstatedir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/var --prefix=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain --sbindir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/sbin --sysconfdir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/etc --enable-tools --enable-malloc=system --disable-attr --disable-auth-pam --disable-install-blobs --disable-capstone --disable-curl --disable-debug-info --disable-debug-mutex --disable-debug-tcg --disable-docs --disable-gcrypt --disable-gnutls --disable-system --disable-user --disable-vnc --disable-werror --disable-xkbcommon --disable-zstd 
+python determined to be '/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/bin/python3'
+python version: Python 3.11.4
+mkvenv: Creating non-isolated virtual environment at 'pyvenv'
+mkvenv subprocess failed:
+cmd: ['/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/.x86_64-linux-gnu/pyvenv/bin/python3', '-m', 'ensurepip', '--upgrade', '--default-pip']
+returncode: 1
+========== stdout ==========
+Looking in links: /tmp/tmpio395oka
+Processing /tmp/tmpio395oka/setuptools-65.5.0-py3-none-any.whl
+Processing /tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl
+Installing collected packages: setuptools, pip
+ERROR: Exception:
+Traceback (most recent call last):
+  File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/cli/base_command.py", line 169, in exc_logging_wrapper
+    status = run_func(*args)
+             ^^^^^^^^^^^^^^^
+  File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/cli/req_command.py", line 248, in wrapper
+    return func(self, options, args)
+           ^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/commands/install.py", line 449, in run
+    installed = install_given_reqs(
+                ^^^^^^^^^^^^^^^^^^^
+  File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/req/__init__.py", line 72, in install_given_reqs
+    requirement.install(
+  File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/req/req_install.py", line 800, in install
+    install_wheel(
+  File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/operations/install/wheel.py", line 731, in install_wheel
+    _install_wheel(
+  File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/operations/install/wheel.py", line 620, in _install_wheel
+    assert os.path.exists(pyc_path)
+AssertionError
+Traceback (most recent call last):
+  File "<frozen runpy>", line 198, in _run_module_as_main
+  File "<frozen runpy>", line 88, in _run_code
+  File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__main__.py", line 5, in <module>
+    sys.exit(ensurepip._main())
+             ^^^^^^^^^^^^^^^^^
+  File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__init__.py", line 286, in _main
+    return _bootstrap(
+           ^^^^^^^^^^^
+  File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__init__.py", line 202, in _bootstrap
+    return _run_pip([*args, *_PACKAGE_NAMES], additional_paths)
+           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__init__.py", line 103, in _run_pip
+    return subprocess.run(cmd, check=True).returncode
+           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/subprocess.py", line 571, in run
+    raise CalledProcessError(retcode, process.args,
+subprocess.CalledProcessError: Command '['/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/.x86_64-linux-gnu/pyvenv/bin/python3', '-W', 'ignore::DeprecationWarning', '-c', '\nimport runpy\nimport sys\nsys.path = [\'/tmp/tmpio395oka/setuptools-65.5.0-py3-none-any.whl\', \'/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl\'] + sys.path\nsys.argv[1:] = [\'install\', \'--no-cache-dir\', \'--no-index\', \'--find-links\', \'/tmp/tmpio395oka\', \'--upgrade\', \'setuptools\', \'pip\']\nrunpy.run_module("pip", run_name="__main__", alter_sys=True)\n']' returned non-zero exit status 2.
+
+============================
+
+*** Ouch! ***
+
+VENV creation subprocess failed. 
+
+
+
+ERROR: python venv creation failed
+
+FAILURE: s/build qemu:host during configure_host (default)
+
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1794 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1794
new file mode 100644
index 00000000..d1bcbf53
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1794
@@ -0,0 +1,27 @@
+Virtio-GPU doesn't fill Response data for cursor queue
+Description of problem:
+Implementation of virtio-gpu in Qemu is likely not fill Response header in cursor commands.
+
+Inside the virtio 1.2 specification, document said:
+```
+VIRTIO_GPU_CMD_UPDATE_CURSOR
+    Update cursor. Request data is struct virtio_gpu_update_cursor. Response type is VIRTIO_GPU_RESP_OK_NODATA.
+    Full cursor update. Cursor will be loaded from the specified resource_id and will be moved to pos. The driver must 
+    transfer the cursor into the resource beforehand (using control queue commands) and make sure the commands to fill 
+    the resource are actually processed (using fencing).
+
+VIRTIO_GPU_CMD_MOVE_CURSOR
+    Move cursor. Request data is struct virtio_gpu_update_cursor. Response type is VIRTIO_GPU_RESP_OK_NODATA.
+    Move cursor to the place specified in pos. The other fields are not used and will be ignored by the device.
+```
+The cursor commands do have a response like control commands.
+
+But in [hw/display/virtio-gpu.c#L1136](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu.c#L1136), QEMU doesn't care anything about response, just fetching command and execute.
+
+It this a Implementation compromise or I missing something in the specification?
+Steps to reproduce:
+1. Write any kernel that using virtio-gpu.
+2. Run on qemu.
+3. No response on cursor command.
+Additional information:
+Specification: [virtio-v1.2-cs01.html](https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.html#x1-3650007)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1796 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1796
new file mode 100644
index 00000000..2b515afb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1796
@@ -0,0 +1,16 @@
+qemu-img does not accept backing image file path, only file name
+Description of problem:
+In `qemu-img create ... -b <backing_image> ... <snapshot_image>`, <backing_image> cannot be a file path, but must be a file name. <backing_image> and <snapshot_image> are forced to be in the same directory for the command to work.
+Steps to reproduce:
+```
+$ mkdir test
+$ qemu-img create -f qcow2 test/a.img 1G
+...
+$ qemu-img create -f qcow2 -b test/a.img -F qcow2 test/a.img.snap
+qemu-img: test/a.img.snap: Could not open 'test/test/a.img': No such file or directory
+Could not open backing image.
+$ qemu-img create -f qcow2 -b a.img -F qcow2 test/a.img.snap
+...
+$ ls test
+a.img  a.img.snap
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1797 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1797
new file mode 100644
index 00000000..ddb1a72c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1797
@@ -0,0 +1,3 @@
+RAM-backed snapshotting
+Additional information:
+And thank you for QEMU! 🙂
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1798 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1798
new file mode 100644
index 00000000..595e846e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1798
@@ -0,0 +1 @@
+conversions of malloc/calloc/free to g_malloc/g_new/g_free etc
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1801 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1801
new file mode 100644
index 00000000..baeab1ac
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1801
@@ -0,0 +1,51 @@
+qemu-system-arm: Linux doesn't boot with UEFI (hangs after printing `EFI stub: Exiting boot services... `.)
+Description of problem:
+Ubuntu 23.04 (armhf) doesn't boot with UEFI.
+It hangs after printing `EFI stub: Exiting boot services... `.
+Steps to reproduce:
+```console
+$ qemu-system-arm -machine virt -m 2048 -nographic -bios /usr/local/share/qemu/edk2-arm-code.fd -hda ubuntu-23.04-server-cloudimg-armhf.img -snapshot
+UEFI firmware (version edk2-stable202302-for-qemu built at 17:13:00 on Mar 15 2023)                                                                  
+Error: Image at 000BFD84000 start failed: Not Found                                                                                                  
+Error: Image at 000BFCEE000 start failed: Unsupported                                                                                                
+Error: Image at 000BFC85000 start failed: Not Found                                                                                                  
+Tpm2SubmitCommand - Tcg2 - Not Found                                                                                                                 
+Tpm2GetCapabilityPcrs fail!                                                                                                                          
+Tpm2SubmitCommand - Tcg2 - Not Found                                                                                                                 
+BdsDxe: loading Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x0)                                                                           
+BdsDxe: starting Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x0)                                                                          
+EFI stub: Booting Linux Kernel...                                         
+EFI stub: Entering in SVC mode with MMU enabled                  
+EFI stub: Using DTB from configuration table                      
+EFI stub: Exiting boot services... 
+```
+Additional information:
+It still boots when vmlinuz and initrd are directly specified:
+```console
+$ qemu-system-arm -machine virt -m 2048 -nographic -bios /usr/local/share/qemu/edk2-arm-code.fd -hda ubuntu-23.04-server-cloudimg-armhf.img -snapshot -kernel ubuntu-23.04-server-cloudimg-armhf-vmlinuz-lpae -initrd ubuntu-23.04-server-cloudimg-armhf-initrd-generic-lpae -append "root=LABEL=cloudimg-rootfs ro"                                          
+UEFI firmware (version edk2-stable202302-for-qemu built at 17:13:00 on Mar 15 2023)                                                                  
+Error: Image at 000BFD84000 start failed: Not Found                                                                                                  
+Error: Image at 000BFCEE000 start failed: Unsupported                                                                                                
+Tpm2SubmitCommand - Tcg2 - Not Found                                                                                                                 
+Tpm2GetCapabilityPcrs fail!                                               
+Tpm2SubmitCommand - Tcg2 - Not Found                                      
+EFI stub: Booting Linux Kernel...                                                                                                                    
+EFI stub: Entering in SVC mode with MMU enabled                                                                                                      
+EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path                                                                                 
+EFI stub: Using DTB from configuration table                                                                                                         
+EFI stub: Exiting boot services...                                                                                                                   
+[    0.000000] Booting Linux on physical CPU 0x0                                                                                                     
+[    0.000000] Linux version 6.2.0-26-generic-lpae (buildd@bos02-arm64-018) (arm-linux-gnueabihf-gcc-12 (Ubuntu 12.2.0-17ubuntu1) 12.2.0, GNU ld (GNU
+ Binutils for Ubuntu) 2.40) #26-Ubuntu SMP Tue Jul 11 10:32:58 UTC 2023 (Ubuntu 6.2.0-26.26-generic-lpae 6.2.13)
+[    0.000000] CPU: ARMv7 Processor [414fc0f0] revision 0 (ARMv7), cr=30c5387d
+...
+Ubuntu 23.04 ubuntu ttyAMA0
+
+ubuntu login:
+```
+
+
+Files:
+- https://cloud-images.ubuntu.com/releases/23.04/release-20230729/ubuntu-23.04-server-cloudimg-armhf.img
+- https://cloud-images.ubuntu.com/releases/23.04/release-20230729/unpacked/ubuntu-23.04-server-cloudimg-armhf-vmlinuz-lpae
+- https://cloud-images.ubuntu.com/releases/23.04/release-20230729/unpacked/ubuntu-23.04-server-cloudimg-armhf-initrd-generic-lpae
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1804 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1804
new file mode 100644
index 00000000..2f222d35
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1804
@@ -0,0 +1,11 @@
+Virtual Machines Do Not Recognize Mouse 5 and 6
+Description of problem:
+Trying to click the mouse buttons 5 and 6 to go forwards and backwards in Firefox does not work. It seems that those buttons are not recognized by the virtual machine. Tested with both `libvirt` and `aqemu`. Though `libvirt` testing was done on a Fedora host a few months prior.
+
+Running Fedora 38 VM in virtualbox does not have this problem, the guest recognizes button 5 and 6, going forwards and backwards in Firefox.
+Steps to reproduce:
+1. Install aqemu or libvirt on Debian 12
+2. Create a Fedora 38 Guest machine
+3. Open Firefox and navigate to a few pages, then try to go backwards and forwards in history using the mouse buttons.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1805 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1805
new file mode 100644
index 00000000..f5849982
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1805
@@ -0,0 +1,66 @@
+build-user-hexagon  CI job is not actually testing hexagon
+Description of problem:
+Look at the output from the `build-user-hexagon` CI job and see what compiler meson reports it is using:
+
+  https://gitlab.com/qemu-project/qemu/-/jobs/4790457871
+
+```
+Project name: qemu
+Project version: 8.0.91
+C compiler for the host machine: cc -m64 -mcx16 (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 20210110")
+C linker for the host machine: cc -m64 -mcx16 ld.bfd 2.35.2
+Host machine cpu family: x86_64
+Host machine cpu: x86_64
+```
+
+What is 'cc' resolving to ?
+
+```
+$ podman run -it registry.gitlab.com/qemu-project/qemu/qemu/debian-hexagon-cross cc -v | grep Target
+Target: x86_64-linux-gnu
+```
+
+That is a x86_64 target native compiler, not a hexagon target cross compiler.
+
+The ``tests/docker/dockerfiles/debian-hexagon-cross.docker`` file installs the hexagon toolchain under ``/opt`` and adds the dir to ``$PATH`` with: 
+
+```
+ENV PATH $PATH:${TOOLCHAIN_INSTALL}/${TOOLCHAIN_BASENAME}/x86_64-linux-gnu/bin
+```
+
+This toolchain just installs a `clang` binary, not ``cc``
+
+So when ``configure`` runs it looks for ``cc`` first and finds the naitve x86_64 GCC install from the container, not the clang cross compiler
+
+It is also not possible to merely set ``CC=clang`` because meson will assume it is a native compiler and crash and burn when unable to run binaries
+
+```
+# CC=clang ./configure --target-list=x86_64-softmmu
+Using './build' as the directory for build output
+...snip...
+Sphinx not found/usable, disabling docs.
+Disabling PIE due to missing toolchain support
+The Meson build system
+Version: 1.2.0
+Source dir: /qemu
+Build dir: /qemu/build
+Build type: native build
+Project name: qemu
+Project version: 8.0.92
+
+../meson.build:1:0: ERROR: Executables created by c compiler clang -m64 -mcx16 are not runnable.
+```
+
+AFAICT, the root problem here is that the hexagon container is not setup in the same way as the other cross compiler containers.
+
+We need the toolchain binaries to be named after the target triplet - ie not ``clang`` but ``hexagon-unknown-linux-musl-clang``
+
+This used to be done but was thrown away when switching to a pre-built toolchain in b9052d36342c947b36447558ed0a0dd3fb3fb8f4
+
+Then the container also needs to set the configure args for the cross target
+
+```
+ENV QEMU_CONFIGURE_OPTS --cross-prefix=hexagon-unknown-linux-musl-
+```
+
+AFAICT, this was never done, so even before switching to the pre-built toolchain, I think the `build-user-hexagon` CI job was running a native built not hexagon build.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1809 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1809
new file mode 100644
index 00000000..662e939f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1809
@@ -0,0 +1,53 @@
+config machine "virt-6.2" with qemu-system-aarch64,it report "mem is not supported by this machine type"
+Description of problem:
+When i config the machine with virt-6.2 and config the numa for cpu,it report "mem is not supported by this machine type",but with virt-5.0 it work well,the newer version virt not support it? It is bug or require hardware support?Or compile configure is not correctlly?
+
+when i create vm,get the error report as follow:
+ 
+virsh create test.xml
+```
+qemu unexpectedly closed the monitor: qemu-system-aarch64: -chardev socket,id=charmonitor,fd=34,server,nowait: warning: short-form boolean option 'server' deprecated
+Please use server=on instead
+qemu-system-aarch64: -chardev socket,id=charmonitor,fd=34,server,nowait: warning: short-form boolean option 'nowait' deprecated
+Please use wait=off instead
+configure accelerator virt-6.2 start
+machine init start
+2023-08-04T02:17:13.984797Z qemu-system-aarch64: -numa node,nodeid=0,cpus=0-3,mem=8192: Parameter -numa node,mem is not supported by this machine type
+Use -numa node,memdev instead
+
+```
+
+
+I use qmp command "query-machines" get the result as follow:
+```
+{
+      "hotpluggable-cpus": true,
+      "name": "virt-6.2",
+     ** "numa-mem-supported": false,**
+      "default-cpu-type": "cortex-a15-arm-cpu",
+      "cpu-max": 512,
+      "deprecated": false,
+      "default-ram-id": "mach-virt.ram",
+      "alias": "virt"
+    },
+```
+
+I add the code "mc->numa_mem_supported = true;" in the api "virt_machine_6_1_options",it can supoort numa,but i don't know whether it is affected.
+
+```
+DEFINE_VIRT_MACHINE_AS_LATEST(6, 2)
+
+static void virt_machine_6_1_options(MachineClass *mc)
+{
+    VirtMachineClass *vmc = VIRT_MACHINE_CLASS(OBJECT_CLASS(mc));
+
+    virt_machine_6_2_options(mc);
+    compat_props_add(mc->compat_props, hw_compat_6_1, hw_compat_6_1_len);
+    mc->smp_props.prefer_sockets = true;
+    vmc->no_cpu_topology = true;
+    **mc->numa_mem_supported = true;**
+
+    /* qemu ITS was introduced with 6.2 */
+    vmc->no_tcg_its = true;
+}
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/181 b/gitlab/issues_text/target_missing/host_missing/accel_missing/181
new file mode 100644
index 00000000..a5b810e6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/181
@@ -0,0 +1 @@
+qemu crashes when doing iotest on  virtio-9p filesystem
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1810 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1810
new file mode 100644
index 00000000..217fc170
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1810
@@ -0,0 +1,191 @@
+heap-buffer-overflow in esp_do_dma()
+Description of problem:
+Got a heap-buffer-overflow error when fuzzing the device am53c974.
+Steps to reproduce:
+Minimized reproducer:
+
+```plaintext
+cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -device \
+am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \
+id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest /dev/null\
+ -qtest stdio
+outl 0xcf8 0x80001010
+outl 0xcfc 0xc000
+outl 0xcf8 0x80001004
+outw 0xcfc 0x05
+outl 0xc03d 0x03000000
+outl 0xc047 0x065a9d80
+outl 0xc00a 0xc10000
+write 0x65a9d 0x1 0x04
+write 0x65a9e 0x1 0x10
+outl 0xc03d 0x03000000
+outl 0xc00a 0xc10000
+outl 0xc00b 0x0800
+outl 0xc00b 0x00
+outl 0xc00b 0x0800
+outl 0xc00b 0x0800
+outl 0xc00b 0x0800
+outl 0xc00b 0x0400
+outl 0xc00b 0x0800
+outl 0xc00b 0x0800
+outw 0xc00b 0x1000
+outw 0xc00b 0x9000
+EOF
+```
+Additional information:
+The crash report triggered by the reproducer is:
+
+```plaintext
+[I 0.000000] OPENED
+[R +0.022834] outl 0xcf8 0x80001010
+[S +0.022864] OK
+OK
+[R +0.022874] outl 0xcfc 0xc000
+[S +0.022887] OK
+OK
+[R +0.022942] outl 0xcf8 0x80001004
+[S +0.022990] OK
+OK
+[R +0.023028] outw 0xcfc 0x05
+[S +0.023508] OK
+OK
+[R +0.023518] outl 0xc03d 0x03000000
+[S +0.023527] OK
+OK
+[R +0.023532] outl 0xc047 0x065a9d80
+[S +0.023537] OK
+OK
+[R +0.023544] outl 0xc00a 0xc10000
+[S +0.023573] OK
+OK
+[R +0.023581] write 0x65a9d 0x1 0x04
+[S +0.023891] OK
+OK
+[R +0.023900] write 0x65a9e 0x1 0x10
+[S +0.023906] OK
+OK                                                                                                                                                                                                                                                                                                                           [R +0.023910] outl 0xc03d 0x03000000
+[S +0.023917] OK
+OK
+[R +0.023921] outl 0xc00a 0xc10000
+[S +0.023983] OK
+OK
+[R +0.023581] write 0x65a9d 0x1 0x04
+[S +0.023891] OK
+OK
+[R +0.023900] write 0x65a9e 0x1 0x10
+[S +0.023906] OK
+OK                                                                                                                                                                                                                                                                                                                           [R +0.023910] outl 0xc03d 0x03000000
+[S +0.023917] OK
+OK
+[R +0.023921] outl 0xc00a 0xc10000
+[S +0.023983] OK
+OK
+[R +0.023991] outl 0xc00b 0x0800
+[S +0.023998] OK
+OK
+[R +0.024002] outl 0xc00b 0x00
+[S +0.024008] OK
+OK
+[R +0.024014] outl 0xc00b 0x0800
+[S +0.024028] OK
+OK
+[R +0.024034] outl 0xc00b 0x0800
+[S +0.024040] OK
+OK
+[R +0.024051] outl 0xc00b 0x0800
+[S +0.024058] OK
+OK
+[R +0.024065] outl 0xc00b 0x0400
+[S +0.024073] OK
+OK
+[R +0.024082] outl 0xc00b 0x0800
+[S +0.024089] OK
+OK
+[R +0.024104] outl 0xc00b 0x0800
+[S +0.024121] OK
+OK
+[R +0.024133] outw 0xc00b 0x1000
+[S +0.024150] OK
+OK
+[R +0.024159] outw 0xc00b 0x9000
+=================================================================
+==63330==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62500020c000 at pc 0x5601fffcf1d4 bp 0x7ffe1920dcf0 sp 0x7ffe1920d4b0
+WRITE of size 32736 at 0x62500020c000 thread T0
+    #0 0x5601fffcf1d3 in __asan_memcpy ../../llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3
+    #1 0x5602015f506b in flatview_read_continue ../softmmu/physmem.c:2726:13
+    #2 0x5602015f5ee3 in flatview_read ../softmmu/physmem.c:2762:12
+    #3 0x5602015f5bf7 in address_space_read_full ../softmmu/physmem.c:2775:18
+    #4 0x560200943ef0 in dma_memory_rw_relaxed ../include/sysemu/dma.h:87:12
+    #5 0x560200943ef0 in dma_memory_rw ../include/sysemu/dma.h:130:12
+    #6 0x560200943ef0 in pci_dma_rw ../hw/pci/pci_device.h:233:12
+    #7 0x560200943ef0 in esp_pci_dma_memory_rw ../hw/scsi/esp-pci.c:283:5
+    #8 0x56020092db7e in esp_do_dma ../hw/scsi/esp.c
+    #9 0x560200935774 in handle_ti ../hw/scsi/esp.c:912:9
+    #10 0x560200932db6 in esp_reg_write ../hw/scsi/esp.c:1083:13
+    #11 0x56020094574d in esp_pci_io_write ../hw/scsi/esp-pci.c:214:9
+    #12 0x5602015b5f23 in memory_region_write_accessor ../softmmu/memory.c:493:5
+    #13 0x5602015b56aa in access_with_adjusted_size ../softmmu/memory.c:569:18
+    #14 0x5602015b4a50 in memory_region_dispatch_write ../softmmu/memory.c
+    #15 0x5602015fefbf in flatview_write_continue ../softmmu/physmem.c:2653:23
+    #16 0x5602015f6463 in flatview_write ../softmmu/physmem.c:2695:12
+    #17 0x5602015f6177 in address_space_write ../softmmu/physmem.c:2791:18
+    #18 0x5602015a7e99 in cpu_outw ../softmmu/ioport.c:75:5
+    #19 0x560200d28daa in qtest_process_command ../softmmu/qtest.c:483:13
+    #20 0x560200d2795b in qtest_process_inbuf ../softmmu/qtest.c:788:9
+    #21 0x560201b581a6 in fd_chr_read ../chardev/char-fd.c:72:9
+    #22 0x7f8fce57e04d in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5204d) (BuildId: 5fdb313daf182a33a858ba2cc945211b11d34561)
+    #23 0x560201dc540f in glib_pollfds_poll ../util/main-loop.c:290:9
+    #24 0x560201dc540f in os_host_main_loop_wait ../util/main-loop.c:313:5
+    #25 0x560201dc540f in main_loop_wait ../util/main-loop.c:592:11
+    #26 0x560200d34f76 in qemu_main_loop ../softmmu/runstate.c:732:9
+    #27 0x56020173e835 in qemu_default_main ../softmmu/main.c:37:14
+    #28 0x7f8fcd3a5082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #29 0x5601fff2009d in _start ./qemu-system-x86_64+0x1e9109d)
+
+0x62500020c000 is located 0 bytes to the right of 4096-byte region [0x62500020b000,0x62500020c000)
+allocated by thread T0 here:
+    #0 0x5601fffd0a0c in posix_memalign ../../llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
+    #1 0x560201db83da in qemu_try_memalign ../util/memalign.c:53:11
+    #2 0x560201db8762 in qemu_memalign ../util/memalign.c:73:15
+    #3 0x5602008c779e in scsi_req_enqueue ../hw/scsi/scsi-bus.c:906:10
+    #4 0x56020093bd2f in do_command_phase ../hw/scsi/esp.c:296:15
+    #5 0x56020093bd2f in do_cmd ../hw/scsi/esp.c:344:5
+    #6 0x560200932911 in esp_reg_write ../hw/scsi/esp.c:1112:13
+    #7 0x56020094574d in esp_pci_io_write ../hw/scsi/esp-pci.c:214:9
+    #8 0x5602015b5f23 in memory_region_write_accessor ../softmmu/memory.c:493:5
+    #9 0x5602015b56aa in access_with_adjusted_size ../softmmu/memory.c:569:18
+
+SUMMARY: AddressSanitizer: heap-buffer-overflow ./llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 in __asan_memcpy
+Shadow bytes around the buggy address:
+  0x0c4a800397b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c4a800397c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c4a800397d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c4a800397e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c4a800397f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+=>0x0c4a80039800:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c4a80039810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c4a80039820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c4a80039830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c4a80039840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c4a80039850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+Shadow byte legend (one shadow byte represents 8 application bytes):
+  Addressable:           00
+  Partially addressable: 01 02 03 04 05 06 07
+  Heap left redzone:       fa
+  Freed heap region:       fd
+  Stack left redzone:      f1
+  Stack mid redzone:       f2
+  Stack right redzone:     f3
+  Stack after return:      f5
+  Stack use after scope:   f8
+  Global redzone:          f9
+  Global init order:       f6
+  Poisoned by user:        f7
+  Container overflow:      fc
+  Array cookie:            ac
+  Intra object redzone:    bb
+  ASan internal:           fe
+  Left alloca redzone:     ca
+  Right alloca redzone:    cb
+==63330==ABORTING
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1811 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1811
new file mode 100644
index 00000000..b382c1f5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1811
@@ -0,0 +1,36 @@
+ppc serial appears to have a maximum ratio of output to input, hides output and only writes it on subsequent input(?!)
+Description of problem:
+When pasting in large chunks of text, the echo is partial, but completes with subsequent writes (and is drained when the writes are small). Sorry this is really stupid, see video.
+
+(also, when booting, the console stops at
+```
+Building dt strings...
+Building dt structure...
+Device tree strings 0x00000000062c0000 -> 0x00000000062c0b90
+Device tree struct  0x00000000062d0000 -> 0x00000000062e0000
+Quiescing Open Firmware ...
+Booting Linux via __start() @ 0x0000000002000000 ...
+Linux ppc64le
+#1 SMP Debian 6.
+```
+and then continues with more messages from just after the dot:
+```
+Linux ppc64le
+#1 SMP Debian 6.[   15.683156] vio vio: uevent: failed to send synthetic uevent: -19
+vio: Failed to write 'add' to '/sys/devices/vio/uevent', ignoring: No such device
+/dev/vda2: clean, 17371/987360 files, 345018/3942144 blocks
+```
+)
+Steps to reproduce:
+1. `cat > /dev/null`
+2. paste in a couple solid lines
+3. observe that the echo completed mid-line
+4. paste in a couple more solid lines
+5. observe that the echo includes the end of the first few lines, and the start of the second set
+6. ^D
+7. observe that with every key input into the shell, you get a few bytes back, and those bytes are the tail-end of the second set of lines
+8. when the echo buffer is drained, it's drained
+Additional information:
+Demo video: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1041707;filename=2023-07-21+17-59-25.mp4;msg=5
+
+Downstream bug: https://bugs.debian.org/1041707
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1813 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1813
new file mode 100644
index 00000000..a143de34
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1813
@@ -0,0 +1,112 @@
+FPE division by zero in scsi_disk_reset() [CVE-2023-42467]
+Description of problem:
+Got an FPE division by zero error when fuzzing the device am53c974.
+Steps to reproduce:
+Minimized reproducer for the error:
+
+```plaintext
+cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -device \
+am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \
+id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest /dev/null\
+ -qtest stdio
+outl 0xcf8 0x80001010
+outl 0xcfc 0xc000
+outl 0xcf8 0x80001004
+outw 0xcfc 0x05
+outl 0xc047 0x065a9d01
+write 0x65a9d 0x1 0x15
+write 0x65a9e 0x1 0x10
+write 0x65aa0 0x1 0x08
+write 0x65aa1 0x1 0x0c
+write 0x65aa7 0x1 0x01
+outl 0xc03d 0x03000000
+outl 0xc00a 0xc10000
+outl 0xc03d 0x03000000
+outl 0xc00a 0xc10000
+outl 0xc00b 0x9000
+outl 0xc00b 0x0300
+EOF
+```
+Additional information:
+The crash report triggered by the reproducer is:
+
+```plaintext
+[I 0.000000] OPENED
+[R +0.024387] outl 0xcf8 0x80001010
+[S +0.024420] OK
+OK
+[R +0.024470] outl 0xcfc 0xc000
+[S +0.024490] OK
+OK
+[R +0.024513] outl 0xcf8 0x80001004
+[S +0.024521] OK
+OK
+[R +0.024527] outw 0xcfc 0x05
+[S +0.022723] OK
+OK
+[R +0.022734] outl 0xc047 0x065a9d01
+[S +0.022742] OK
+OK
+[R +0.022747] write 0x65a9d 0x1 0x15
+[S +0.022932] OK
+OK
+[R +0.022941] write 0x65a9e 0x1 0x10
+[S +0.022947] OK
+OK
+[R +0.022952] write 0x65aa0 0x1 0x08
+[S +0.022958] OK
+OK
+[R +0.022965] write 0x65aa1 0x1 0x0c
+[S +0.022973] OK
+OK
+[R +0.022983] write 0x65aa7 0x1 0x01
+[S +0.022991] OK
+OK
+[R +0.023004] outl 0xc03d 0x03000000
+[S +0.023014] OK
+OK
+[R +0.023021] outl 0xc00a 0xc10000
+[S +0.023048] OK
+OK
+[R +0.023056] outl 0xc03d 0x03000000
+[S +0.023065] OK
+OK
+[R +0.023072] outl 0xc00a 0xc10000
+[S +0.023128] OK
+OK
+[R +0.023141] outl 0xc00b 0x9000
+[S +0.023159] OK
+OK
+[R +0.023166] outl 0xc00b 0x0300
+../hw/scsi/scsi-disk.c:2351:16: runtime error: division by zero
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/scsi/scsi-disk.c:2351:16 in
+AddressSanitizer:DEADLYSIGNAL
+=================================================================
+==1208622==ERROR: AddressSanitizer: FPE on unknown address 0x558e9c0a9386 (pc 0x558e9c0a9386 bp 0x7ffcc04aaf50 sp 0x7ffcc04aaec0 T0)
+    #0 0x558e9c0a9386 in scsi_disk_reset ../hw/scsi/scsi-disk.c:2351:16
+    #1 0x558e9cf23f23 in resettable_phase_hold ../hw/core/resettable.c
+    #2 0x558e9cf0a861 in bus_reset_child_foreach ../hw/core/bus.c:97:13
+    #3 0x558e9cf23c05 in resettable_phase_hold ../hw/core/resettable.c:173:5
+    #4 0x558e9cf21b69 in resettable_assert_reset ../hw/core/resettable.c:60:5
+    #5 0x558e9cf217aa in resettable_reset ../hw/core/resettable.c:45:5
+    #6 0x558e9c0facd7 in esp_reg_write ../hw/scsi/esp.c:1075:13
+    #7 0x558e9c10d74d in esp_pci_io_write ../hw/scsi/esp-pci.c:214:9
+    #8 0x558e9cd7df23 in memory_region_write_accessor ../softmmu/memory.c:493:5
+    #9 0x558e9cd7d6aa in access_with_adjusted_size ../softmmu/memory.c:569:18
+    #10 0x558e9cd7ca50 in memory_region_dispatch_write ../softmmu/memory.c
+    #11 0x558e9cdc6fbf in flatview_write_continue ../softmmu/physmem.c:2653:23
+    #12 0x558e9cdbe463 in flatview_write ../softmmu/physmem.c:2695:12
+    #13 0x558e9cdbe177 in address_space_write ../softmmu/physmem.c:2791:18
+    #14 0x558e9cd70208 in cpu_outl ../softmmu/ioport.c:85:5
+    #15 0x558e9c4f0e76 in qtest_process_command ../softmmu/qtest.c:485:13
+    #16 0x558e9c4ef95b in qtest_process_inbuf ../softmmu/qtest.c:788:9
+    #17 0x558e9d3201a6 in fd_chr_read ../chardev/char-fd.c:72:9
+    #18 0x7f974a7c904d in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5204d) (BuildId: 5fdb313daf182a33a858ba2cc945211b11d34561)
+    #19 0x558e9d58d40f in glib_pollfds_poll ../util/main-loop.c:290:9
+    #20 0x558e9d58d40f in os_host_main_loop_wait ../util/main-loop.c:313:5
+    #21 0x558e9d58d40f in main_loop_wait ../util/main-loop.c:592:11
+    #22 0x558e9c4fcf76 in qemu_main_loop ../softmmu/runstate.c:732:9
+    #23 0x558e9cf06835 in qemu_default_main ../softmmu/main.c:37:14
+    #24 0x7f97495f0082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #25 0x558e9b6e809d in _start (./qemu-system-x86_64+0x1e9109d)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1814 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1814
new file mode 100644
index 00000000..a339b69c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1814
@@ -0,0 +1,16 @@
+`-M none` breaks on ARM64 platforms with max IPA size < 40
+Description of problem:
+QEMU fails to initialize the KVM type properly when `-M none` is used. On ARM64, the KVM type sets the IPA size. Without that setting, the kernel defaults to 40 bits. This fails on machines which cannot support that IPA size, such as Apple M1 machines.
+
+This presumably happens because `virt_machine_class_init()` in `hw/arm/virt.c` never gets called in that case, which means it doesn't initialize `mc->kvm_type` to the correct callback to do the IPA check.
+
+Since the max IPA size is a property of the host CPU and must be queried properly for things to work at all, this logic should be invoked unconditionally for all machines, even `none`.
+
+This is breaking libvirt on Apple M1/M2 systems, since it uses `-M none,accel=kvm` for its KVM test, and when it fails it considers KVM support unavailable. See: https://gitlab.com/libvirt/libvirt/-/issues/365
+Steps to reproduce:
+On any ARM64 machine:
+
+1. strace -e ioctl qemu-system-aarch64 -M none,accel=kvm 2>&1 | grep -C1 CREATE_VM
+2. strace -e ioctl qemu-system-aarch64 -M virt,accel=kvm 2>&1 | grep -C1 CREATE_VM
+
+Observe that the first command line does not issue a `KVM_CAP_ARM_VM_IPA_SIZE` and does not set the machine type argument to `KVM_CREATE_VM`, while the second one does. On machines with <40 bit max IPA, the first invocation would fail to initialize KVM.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1815 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1815
new file mode 100644
index 00000000..f98054c2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1815
@@ -0,0 +1,82 @@
+Null pointer access in nvme_directive_receive()
+Description of problem:
+Got an access within null pointer error when fuzzing nvme.
+Steps to reproduce:
+Minimized reproducer for the error:
+
+```plaintext
+cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -machine q35 \
+-nodefaults -drive file=null-co://,if=none,format=raw,id=disk0 -device \
+nvme,drive=disk0,serial=1 -qtest /dev/null -qtest stdio
+outl 0xcf8 0x80000810
+outl 0xcfc 0xe0000000
+outl 0xcf8 0x80000804
+outw 0xcfc 0x06
+write 0xe0000024 0x4 0x040002
+write 0xe0000014 0x4 0x61004600
+write 0xe0001000 0x1 0x04
+write 0x0 0x1 0x1a
+write 0x4 0x1 0x01
+write 0x2c 0x1 0x01
+EOF
+```
+Additional information:
+The crash report triggered by the reproducer is:
+
+```plaintext
+[I 0.000000] OPENED
+[R +0.025407] outl 0xcf8 0x80000810
+[S +0.025443] OK
+OK
+[R +0.025456] outl 0xcfc 0xe0000000
+[S +0.025470] OK
+OK
+[R +0.025476] outl 0xcf8 0x80000804
+[S +0.025483] OK
+OK
+[R +0.025489] outw 0xcfc 0x06
+[S +0.025934] OK
+OK
+[R +0.025946] write 0xe0000024 0x4 0x040002
+[S +0.025958] OK
+OK
+[R +0.025964] write 0xe0000014 0x4 0x61004600
+[S +0.025988] OK
+OK
+[R +0.026025] write 0xe0001000 0x1 0x04
+[S +0.026041] OK
+OK
+[R +0.026048] write 0x0 0x1 0x1a
+[S +0.026256] OK
+OK
+[R +0.026268] write 0x4 0x1 0x01
+[S +0.026279] OK
+OK
+[R +0.026292] write 0x2c 0x1 0x01
+[S +0.026303] OK
+OK
+../hw/nvme/ctrl.c:6890:29: runtime error: member access within null pointer of type 'NvmeEnduranceGroup' (aka 'struct NvmeEnduranceGroup')
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/nvme/ctrl.c:6890:29 in
+AddressSanitizer:DEADLYSIGNAL
+=================================================================
+==1085476==ERROR: AddressSanitizer: SEGV on unknown address 0x000000001fc8 (pc 0x56306b765ebf bp 0x7ffff17fd890 sp 0x7ffff17f6a00 T0)
+==1085476==The signal is caused by a READ memory access.
+    #0 0x56306b765ebf in nvme_directive_receive ../hw/nvme/ctrl.c:6890:33
+    #1 0x56306b765ebf in nvme_admin_cmd ../hw/nvme/ctrl.c:6958:16
+    #2 0x56306b765ebf in nvme_process_sq ../hw/nvme/ctrl.c:7015:13
+    #3 0x56306cda2c3b in aio_bh_call ../util/async.c:169:5
+    #4 0x56306cda3384 in aio_bh_poll ../util/async.c:216:13
+    #5 0x56306cd3f15b in aio_dispatch ../util/aio-posix.c:423:5
+    #6 0x56306cda72da in aio_ctx_dispatch ../util/async.c:358:5
+    #7 0x7fa321cc417c in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5217c) (BuildId: 5fdb313daf182a33a858ba2cc945211b11d34561)
+    #8 0x56306cda840f in glib_pollfds_poll ../util/main-loop.c:290:9
+    #9 0x56306cda840f in os_host_main_loop_wait ../util/main-loop.c:313:5
+    #10 0x56306cda840f in main_loop_wait ../util/main-loop.c:592:11
+    #11 0x56306bd17f76 in qemu_main_loop ../softmmu/runstate.c:732:9
+    #12 0x56306c721835 in qemu_default_main ../softmmu/main.c:37:14
+    #13 0x7fa320aeb082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #14 0x56306af0309d in _start (./qemu-system-x86_64+0x1e9109d)
+
+AddressSanitizer can not provide additional info.
+SUMMARY: AddressSanitizer: SEGV ../hw/nvme/ctrl.c:6890:33 in nvme_directive_receive
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1816 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1816
new file mode 100644
index 00000000..ed8f494f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1816
@@ -0,0 +1,74 @@
+Memory size limitation under podman on Apple silicon
+Description of problem:
+We are using latest MacOS (Ventura) on M2 Ultra with 128Gb RAM (Mac Studio) to run our product Linux aarch64 builds in podman containers. This is cheaper than buying ARM server hardware, and we are not able to use cloud services.
+
+The issue arises when we try to use the available RAM for the underlying QEMU machine. There seems to be a memory limit which looks like it is in QEMU not podman machine, since that is more of a wrapper in this process.
+
+The use case is to init a Fedora Linux VM by QEMU which provides a Linux kernel. That kernel is then used to run podman containers.
+
+When we set the memory limit to 64513Mb the podman machine (VM) start fails with "Error: HV_BAD_ARGUMENT". If we reduce the memory limit to "64512" it works as expected.
+
+This is an example of how to reproduce:
+
+`
+macstudio:~ build $ podman machine init --cpus="18" --memory="64513" podman-machine-default
+Extracting compressed file
+Image resized.
+Machine init complete
+To start your machine run:
+
+podman machine start
+
+macstudio:~ build $ podman machine start
+Starting machine "podman-machine-default"
+Waiting for VM ...
+Error: qemu exited unexpectedly with exit code -1, stderr: qemu-system-aarch64: Error: HV_BAD_ARGUMENT
+
+macstudio:~ build $ podman machine rm --force
+macstudio:~ build $ podman machine init --cpus="18" --memory="64512" podman-machine-default
+Extracting compressed file
+Image resized.
+Machine init complete
+To start your machine run:
+
+podman machine start
+
+macstudio:~ build $ podman machine start
+Starting machine "podman-machine-default"
+Waiting for VM ...
+Mounting volume... /Users:/Users
+Mounting volume... /private:/private
+Mounting volume... /var/folders:/var/folders
+
+This machine is currently configured in rootless mode. If your containers
+require root permissions (e.g. ports < 1024), or if you run into compatibility
+issues with non-podman clients, you can switch using the following command:
+
+podman machine set --rootful
+
+API forwarding listening on: /Users/build_ci/.local/share/containers/podman/machine/qemu/podman.sock
+
+The system helper service is not installed; the default Docker API socket
+address can't be used by podman. If you would like to install it run the
+following commands:
+
+sudo /opt/homebrew/Cellar/podman/4.6.0/bin/podman-mac-helper install
+podman machine stop; podman machine start
+
+You can still connect Docker API clients by setting DOCKER_HOST using the
+following command in your terminal session:
+
+export DOCKER_HOST='unix:///Users/build/.local/share/containers/podman/machine/qemu/podman.sock'
+
+Machine "podman-machine-default" started successfully
+macstudio:~ build $ podman machine ls
+NAME                     VM TYPE     CREATED             LAST UP            CPUS        MEMORY     DISK SIZE
+podman-machine-default*  qemu        About a minute ago  Currently running  18          63GiB      100GiB
+
+`
+Steps to reproduce:
+1. Initialise the VM with a RAM limit of 64513Mb, then start it.
+2.
+3.
+Additional information:
+Feel free to ask for more information. Unfortunately, these machines are our production platform, so further testing will not have a rapid turn around. We are open to taking a machine out of production for testing, it just needs scheduling.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1817 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1817
new file mode 100644
index 00000000..5aae4b24
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1817
@@ -0,0 +1 @@
+meson complains about use of install_subdir in docs/meson.build
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1818 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1818
new file mode 100644
index 00000000..0d16ae07
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1818
@@ -0,0 +1,20 @@
+whpx does not work with hyper-v enabled
+Description of problem:
+I am experiencing issues with the WHPX (Windows Hypervisor Platform Accelerator) hardware acceleration in QEMU on my Windows 10 22h2 system. When I run QEMU with the `-accel whpx` option, I encounter the following problems:
+
+2. I receive the error message "WHPX: No accelerator found, hr=00000000" followed by "failed to initialize whpx: No space left on device."
+Steps to reproduce:
+1. Enable the Hyper-V feature on Windows.
+2. Install the latest QEMU version
+3. Run the QEMU command with the `-accel whpx` option.
+Additional information:
+- my cpu : intel i7 6500U
+- ram : 8 gigabytes
+- gpu : intel hd 520
+- drive : C: -> 200 gigabytes, D: -> 1to (c: 109 used, d: 732 used)
+- emulated drive -> 50 gigabytes (500mb used)
+
+![image](/uploads/bbc4648b36f7a0430da39460d8f6c4de/image.png)
+![image](/uploads/cb0a59ddf0a1e7ed62253ea7abe21046/image.png)
+![image](/uploads/cd1c1116f6b3fa2c043d638f3983cc83/image.png)
+(in french sorry)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/182 b/gitlab/issues_text/target_missing/host_missing/accel_missing/182
new file mode 100644
index 00000000..dbac4e03
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/182
@@ -0,0 +1 @@
+qemu-xhci device should detect if libusb host supports streams
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1821 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1821
new file mode 100644
index 00000000..390c2a9b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1821
@@ -0,0 +1,53 @@
+snapshot-save very slow in 8.1-rc2
+Description of problem:
+Before commit 813cd61669 ("migration: Use migration_transferred_bytes() to calculate rate_limit") the above script will take about 1.5 seconds to execute, after the commit, 1 minute 30 seconds. More RAM makes it take longer still.
+Steps to reproduce:
+1. Execute the script given as the command line above.
+Additional information:
+Creating the issue here, so it doesn't get lost and is documented.
+
+The following series by @juan.quintela would've avoided the regression, but seems like it never landed: https://lists.nongnu.org/archive/html/qemu-devel/2023-05/msg07971.html
+
+Logs:
+
+Before commit 813cd61669 
+```
+root@pve8a1 /home/febner/repos/qemu/build # time ~/save-snap.sh
+Formatting '/tmp/test.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16
+{"QMP": {"version": {"qemu": {"micro": 50, "minor": 0, "major": 8}, "package": "v8.0.0-967-g3db9c05a90-dirty"}, "capabilities": ["oob"]}}
+VNC server running on ::1:5900
+{"return": {}}
+{"timestamp": {"seconds": 1691572701, "microseconds": 708660}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "save0"}}
+{"timestamp": {"seconds": 1691572701, "microseconds": 708731}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "save0"}}
+{"return": {}}
+{"timestamp": {"seconds": 1691572701, "microseconds": 709239}, "event": "STOP"}
+{"timestamp": {"seconds": 1691572702, "microseconds": 939059}, "event": "RESUME"}
+{"timestamp": {"seconds": 1691572702, "microseconds": 939565}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "save0"}}
+{"timestamp": {"seconds": 1691572702, "microseconds": 939605}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "save0"}}
+{"timestamp": {"seconds": 1691572702, "microseconds": 939638}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "save0"}}
+{"return": {}}
+{"timestamp": {"seconds": 1691572702, "microseconds": 939730}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-qmp-quit"}}
+{"timestamp": {"seconds": 1691572702, "microseconds": 941746}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "save0"}}
+~/save-snap.sh  1.18s user 0.09s system 85% cpu 1.476 total
+```
+
+After commit 813cd61669
+```
+root@pve8a1 /home/febner/repos/qemu/build # time ~/save-snap.sh
+Formatting '/tmp/test.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16
+{"QMP": {"version": {"qemu": {"micro": 92, "minor": 0, "major": 8}, "package": "v8.1.0-rc2-102-ga8fc5165aa"}, "capabilities": ["oob"]}}
+VNC server running on ::1:5900
+{"return": {}}
+{"timestamp": {"seconds": 1691572864, "microseconds": 944026}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "save0"}}
+{"timestamp": {"seconds": 1691572864, "microseconds": 944115}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "save0"}}
+{"return": {}}
+{"timestamp": {"seconds": 1691572864, "microseconds": 944631}, "event": "STOP"}
+{"timestamp": {"seconds": 1691572954, "microseconds": 697523}, "event": "RESUME"}
+{"timestamp": {"seconds": 1691572954, "microseconds": 697962}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "save0"}}
+{"timestamp": {"seconds": 1691572954, "microseconds": 697996}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "save0"}}
+{"timestamp": {"seconds": 1691572954, "microseconds": 698020}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "save0"}}
+{"return": {}}
+{"timestamp": {"seconds": 1691572954, "microseconds": 698089}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-qmp-quit"}}
+{"timestamp": {"seconds": 1691572954, "microseconds": 701263}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "save0"}}
+~/save-snap.sh  31.81s user 41.69s system 81% cpu 1:30.03 total
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1822 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1822
new file mode 100644
index 00000000..210039cf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1822
@@ -0,0 +1,7 @@
+Signed source tarball for 8.0.4 missing
+Description of problem:
+Hi! I package this project for Arch Linux. I would like to upgrade to 8.0.4, but unfortunately there is no signed source tarball for that version available yet.
+Steps to reproduce:
+1. Go to https://download.qemu.org/ and find no source tarball for 8.0.4
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1824 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1824
new file mode 100644
index 00000000..85e4c34c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1824
@@ -0,0 +1 @@
+[8.x] qemu-user does not build under CentOS 7 any longer
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1827 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1827
new file mode 100644
index 00000000..56b9af7e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1827
@@ -0,0 +1 @@
+Turn DPRINTF macro use into tracepoints
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1828 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1828
new file mode 100644
index 00000000..9e5995e8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1828
@@ -0,0 +1,21 @@
+[v8.0.4 regression] `qemu-system-x86_64: -accel hvf: Unknown Error`
+Description of problem:
+`-accel hvf` crashes with "Unknown Error".
+Regression in v8.0.4.
+
+The master branch doesn't seem affected.
+Steps to reproduce:
+v8.0.3:
+```console
+$ qemu-system-x86_64 -accel hvf
+(shows iPXE screen, as expected)
+```
+
+v8.0.4:
+```console
+$ qemu-system-x86_64 -accel hvf
+qemu-system-x86_64: -accel hvf: Unknown Error
+Abort trap: 6
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1829 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1829
new file mode 100644
index 00000000..eacdc2a3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1829
@@ -0,0 +1,88 @@
+DoS via assert failure by guest user
+Description of problem:
+As root in guest VM user can execute special script, which crashes the whole VM with error
+
+```plaintext
+hw/display/qxl.c:1594 inside of function void qxl_set_mode(PCIQXLDevice *, unsigned int, int): Assertion `qxl_add_memslot(d, 0, devmem, QXL_SYNC) == 0` failed
+```
+Steps to reproduce:
+1. This bug can be reproduced with:
+
+   ```bash
+   cat << EOF | ./build/qemu-system-x86_64 -vga qxl -m 2048 -nodefaults -qtest stdio
+   outl 0xcf8 0x8000101c
+   outl 0xcfc 0xc000
+   outl 0xcf8 0x80001001
+   outl 0xcfc 0x01000000
+   outl 0xc006 0x00
+   EOF
+   ```
+2. Also, we can execute this python3 script inside guest VM as root (to invoke VM use command: **_qemu-system-x86_64 -vga qxl -hda debian.img -m 2048 -nodefaults_**):
+
+   ```python
+   import os
+   f = os.open("/dev/port", os.O_RDWR|os.O_NDELAY)
+   l = os.lseek(f, 0xcf8, 0)
+   os.write(f, b'\x80\x00\x10\x1c')
+   l = os.lseek(f, 0xcfc, 0)
+   os.write(f, b'\xc0\x00')
+   l = os.lseek(f, 0xcf8, 0)
+   os.write(f, b'\x80\x00\x10\x01')
+   l = os.lseek(f, 0xcfc, 0)
+   os.write(f, b'\x01\x00\x00\x00')
+   l = os.lseek(f, 0xc006, 0)
+   os.write(f, b'\x00')
+   ```
+
+   This script causes VM to crash.
+
+   [PoC_qxl-vga_crash.mkv](/uploads/7ee262c20dca69aa9417812f6a93a532/PoC_qxl-vga_crash.mkv)
+Additional information:
+This issue was found by fuzzing. Here is an auto-generated C source code for a test case that will reproduce the bug.
+
+```plaintext
+/*
+ * Autogenerated Fuzzer Test Case
+ *
+ * Copyright (c) 2023 Artem Nasonov <anasonov@astralinux.ru>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+
+#include "libqtest.h"
+
+/*
+ * cat << EOF | qemu-system-x86_64 -vga qxl -hda \
+ * ~/Downloads/virtualdebian.img -m 2048 -nodefaults -qtest stdio
+ * outl 0xcf8 0x8000101c
+ * outl 0xcfc 0xc000
+ * outl 0xcf8 0x80001001
+ * outl 0xcfc 0x01000000
+ * outl 0xc006 0x00
+ * EOF
+*/
+static void test_qxl_set_mode(void)
+{
+QTestState *s = qtest_init("-vga qxl -m 2048 -nodefaults");
+qtest_outl(s, 0xcf8, 0x8000101c);
+qtest_outl(s, 0xcfc, 0xc000);
+qtest_outl(s, 0xcf8, 0x80001001);
+qtest_outl(s, 0xcfc, 0x01000000);
+qtest_outl(s, 0xc006, 0x00);
+qtest_quit(s);
+}int main(int argc, char **argv)
+{
+    const char *arch = qtest_get_arch();
+
+    g_test_init(&argc, &argv, NULL);
+
+   if (strcmp(arch, "x86_64") == 0) {
+        qtest_add_func("fuzz/test_qxl_set_mode",test_qxl_set_mode);
+   }
+
+   return g_test_run();
+}
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/183 b/gitlab/issues_text/target_missing/host_missing/accel_missing/183
new file mode 100644
index 00000000..6ffb0b23
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/183
@@ -0,0 +1 @@
+Cannot use usb-host on Mac OS
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1830 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1830
new file mode 100644
index 00000000..24472b67
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1830
@@ -0,0 +1,26 @@
+command hangs in CentOS 7 arm64 container with Ubuntu 22 amd64 host
+Description of problem:
+The command hangs in the container, taking over the CPU:
+
+```
+$ docker run -it centos:7
+[root@42e655bf3d60 /]# LD_DEBUG=all /lib64/ld-2.17.so --list /usr/bin/true &
+[1] 74
+[root@42e655bf3d60 /]#         74:      file=/usr/bin/true [0];  generating link map
+
+[root@42e655bf3d60 /]# ps -e -o pid,ppid,etime,time,state,args
+    PID    PPID     ELAPSED     TIME S COMMAND
+      1       0       34:59 00:00:00 S /usr/libexec/qemu-binfmt/aarch64-binfmt-P /bin/bash /bin/bash
+     74       1       03:16 00:03:13 R /usr/libexec/qemu-binfmt/aarch64-binfmt-P /lib64/ld-2.17.so /lib64/ld-2.17.so
+     80       1  4-19:34:01 00:00:00 R ps -e -o pid,ppid,etime,time,state,args
+[root@42e655bf3d60 /]#
+```
+Steps to reproduce:
+1. Start container
+2. Run `/lib64/ld-2.17.so --list /usr/bin/true`
+Additional information:
+1. The problem is not observed in an Ubuntu 20.04 host system performing the same scenario.
+2. My team build environment has amd64 native architecture hardware.  I ran a similar scenario on an AWS arm64 native machine (QEMU is not needed) and the command works fine in the container.
+3. My team builds several Linux images daily - about a dozen amd64 and eight arm64.  This is the only image that's causing us this problem.
+4. I built trace-cmd but when I tried to start a trace it told me `No events enabled with kvm`.
+5. I built qemu-8.1.0-rc3 and saw the same behavior but I don't think `/usr/libexec/qemu-binfmt/aarch64-binfmt-P` was replaced with a new version so I don't think the old version was used for my container.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1835 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1835
new file mode 100644
index 00000000..abdea2db
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1835
@@ -0,0 +1,18 @@
+IPv4 guest/outbound port forwarding not working
+Description of problem:
+Python http server running on the host can receive the first http request from guest and provides correct response, but the resent request gets stuck. Package couldn't be seen in `tcpdump` running on host.
+Steps to reproduce:
+1. Build libslirp, I am using HEAD @ master.
+1. Build your QEMU with user network enabled to use slirp (`./configure -target-list=x86_64-softmmu --enable-slirp`).
+1. Ran a Python server on host listening to port `6655` (`python3 -m http.server --bind :: 6655`).
+1. Boot your QEMU with aforementioned QEMU command line, I am forwarding a server address to host's local address `guestfwd=tcp:10.0.2.100:6657-tcp:127.0.0.1:6655`. For image, I am using a ordinary Fedora 38 workstation live cdrom.
+1. In your guest OS (emulated enviroment), open a terminal and run `curl http://10.0.2.100:6657`, this sends a http get to the 
+slirp outbound forwarding server. You should see the Python http server gets the request and provides correct response `::ffff:127.0.0.1 - - [17/Aug/2023 18:24:34] "GET / HTTP/1.1" 200 -`, nothing but just `ls` the directory.
+5. Repeat step 4, you will see the `curl` command gets stuck.
+Additional information:
+I've added a .pacp capturing line in QEMU command line and investigated it via Wireshark, noticed the slirp gets the http get, but after that being stuck in some place, I saw the guest sending keep alive request to slirp, so I think this could be something in the QEMU side.
+
+
+
+
+![Screenshot_2023-08-17_at_11.45.02_AM](/uploads/2f93c50bba1105860f2b85226703d65b/Screenshot_2023-08-17_at_11.45.02_AM.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1837 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1837
new file mode 100644
index 00000000..7a6a2ca6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1837
@@ -0,0 +1,35 @@
+Support IP_MULTICAST_IF socket option in linux-user
+Additional information:
+I've run into this limitation in qemu-aarch64-static version Debian 1:6.2+dfsg-2ubuntu6.12, but from the link above, it doesn't seem to be implemented on master yet.
+
+Here's some source code that demonstrates the failure:
+```
+#include <sys/socket.h>
+#include <arpa/inet.h>
+#include <netinet/ip.h>
+#include <unistd.h>
+#include <assert.h>
+#include <stdio.h>
+
+int main()
+{
+    int fd, ret;
+    struct in_addr addr = {htonl(INADDR_LOOPBACK)};
+
+    fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
+    assert(fd >= 0);
+    ret = setsockopt(fd, IPPROTO_IP, IP_MULTICAST_IF, &addr, sizeof(addr));
+    if (ret < 0)
+    {
+        perror("setsockopt failed");
+        return 1;
+    }
+    close(fd);
+    printf("Success!\n");
+    return 0;
+}
+```
+
+When run under qemu, it gives the error `setsockopt failed: Protocol not available`.
+
+It doesn't look like it should be too hard to support (certainly no worse than IP_ADD_MEMBERSHIP). Let me know if I can help with a patch.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1838 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1838
new file mode 100644
index 00000000..dbb24a80
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1838
@@ -0,0 +1 @@
+Win9x on qemu 8.0.3 - Impossible to launch a win32 app
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1839 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1839
new file mode 100644
index 00000000..7bdea7c6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1839
@@ -0,0 +1,41 @@
+command line option (fw_cfg) not being treated as opaque and generates error "short-form boolean option 'x' deprecated"
+Description of problem:
+I'm trying to run qemu with `fw_cfg` arguments. With a full example I am trying to provide an ignition configuration a flatcar VM using a 'string' parameter which is JSON (rather than a file parameter).
+
+Running qemu with command line options where the fields have arbitrary data that should be opaque to qemu are being interpreted and cause the command line argument parsing the fail. I have tried putting quotes and double quotes around various parts of the command without success.
+
+
+Sorry, but I haven't tested this with latest (v8.1.0.rc4 / v8.0.4)
+
+Examples:
+
+```# qemu-system-x86_64 -fw_cfg name=z,string=a,b
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: warning: short-form boolean option 'b' deprecated
+Please use b=on instead
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: Invalid parameter 'b'
+```
+
+Single quotes around the `string` value:
+```
+# qemu-system-x86_64 -fw_cfg name=z,string='a,b'
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: warning: short-form boolean option 'b' deprecated
+Please use b=on instead
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: Invalid parameter 'b'
+```
+
+Double quotes around the `string` value
+```
+# qemu-system-x86_64 -fw_cfg name=z,string="a,b"
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: warning: short-form boolean option 'b' deprecated
+Please use b=on instead
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: Invalid parameter 'b'
+
+```
+
+Double quotes around the whole `fw_cfg` option value:
+```
+# qemu-system-x86_64 -fw_cfg "name=z,string=a,b"
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: warning: short-form boolean option 'b' deprecated
+Please use b=on instead
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: Invalid parameter 'b'
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1840 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1840
new file mode 100644
index 00000000..0c0d4d77
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1840
@@ -0,0 +1 @@
+Amend RISCV machine default value
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1841 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1841
new file mode 100644
index 00000000..c18cb8e0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1841
@@ -0,0 +1,12 @@
+qemu version with 7.2.5 or earlier than 7.2.5 with nvme disk has  I/O QID 22 timeout, Aborting errors
+Description of problem:
+When I use the 7.2.5 version of qemu or versions earlier than 7.2.5 to compile and start the virtual machine, the machine has an nvme disk which is SAMSUNG MZQL23T8HCLS-00B7C and passed through by VFIO. When i use fio to perform pressure test on the nvme disk in vm, dmesg shows message like this nvme nvme0: I/O QID 22 timeout, Aborting, the picture below shows its details. Howerver, when i use 8.0.0 version of qemu to compile and start vm, and using fio to perform pressure test on the nvme disk in vm, it does not have the problem like that. I have using different kernel version, however, the probelem persists, so i think this is not a kernel issue, but a qemu problem.
+
+
+if the irqbalance is running in vm, the problem happens very often, however if the irqbalance is stopped, the problem disappear.
+
+![image](/uploads/180a13da3a29032e4f07f5eb83da959c/image.png)
+Steps to reproduce:
+1. using the 7.2.5 or versions earlier than 7.2.5 and start vm which has an nvme disk 
+2. the nvme disk is passed through by VFIO
+3. using FIO to perform pressure test on the nvme disk in vm
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1842 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1842
new file mode 100644
index 00000000..107b792c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1842
@@ -0,0 +1,15 @@
+keyutils meson regression in 8.1.0
+Description of problem:
+keyutils is no longer found by meson during the build.
+
+commit 0db0fbb5cf8955d4f7a4a82bde32cfd93bd042ea appears to be buggy:
+```
+$ grep KEYUTILS config-host.h
+#undef CONFIG_KEYUTILS
+```
+Steps to reproduce:
+1. Have keyutils installed
+2. Build QEMU 8.1.0
+3. Note that keyutils is no longer linked into the build
+
+Thanks
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1843 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1843
new file mode 100644
index 00000000..2848861b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1843
@@ -0,0 +1,15 @@
+Multitouch - GTK:  Tapping 3 points or more at too close in interval causes all points to be lost
+Description of problem:
+When using the new multitouch input device, if you use three or more fingers within two rapid interval, the all finger inputs get dropped.
+Steps to reproduce:
+ANDROID
+1. Download and install BlissOS
+2. Swipe with two fingers
+3. try multitouch debug app
+
+FEDORA
+1. Load fedora
+2. install wev
+3. try touch 3 or more points
+Additional information:
+Not sure what logs are relevant
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1844 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1844
new file mode 100644
index 00000000..7278dcc7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1844
@@ -0,0 +1,22 @@
+qemu process memory usage greater than windows guest memory usage
+Description of problem:
+The Windows Guest internal memory usage is low,but is very high on host of qemu progress. But the linux guest is no such case.Is there any way to trigger the host to reclaim virtual machine memory?
+Steps to reproduce:
+1.install a windows guest with 128GB of memory and start it.
+
+2.When the machine is stable, the VM internal memory usage is low,but is very high on host of qemu progress.
+
+3.on host,use "free -g" to query,the memory used is also very high
+
+4.when migrate or dormancy,it can recovery,but I want to know is there any way to trigger the host to reclaim virtual machine memory?
+ 
+
+host:
+
+![image](/uploads/a15d1e7fee58b86d267042b97f1e02cc/image.png)
+
+![image](/uploads/0d5ced57c8fb8311fc2c1a7912f473c0/image.png)
+
+guest:
+
+![image](/uploads/128578b50162cb4ea19ce9f12178e5d5/image.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1845 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1845
new file mode 100644
index 00000000..91216cc9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1845
@@ -0,0 +1,9 @@
+qemu-xhci not working on aarch64
+Description of problem:
+Once the VM is loaded I run lsusb from the cli and I get no devices listed.
+Steps to reproduce:
+1. Build qemu from source with libusb support
+2. Launch vm using the above configuration
+3. Run lsusb from the command line in the VM instance
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1848 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1848
new file mode 100644
index 00000000..1cd4dfcd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1848
@@ -0,0 +1,25 @@
+8.1.0 build failure ../accel/tcg/cputlb.c: In function ‘do_ld_mmio_beN’: error: call to ‘qemu_build_not_reached_always’ declared with attribute error: code path is reachable
+Description of problem:
+Error when building with -Og. Does not occur with -O2.
+
+```
+FAILED: libqemu-i386-softmmu.fa.p/accel_tcg_cputlb.c.o 
+x86_64-pc-linux-gnu-gcc -m64 -mcx16 -Ilibqemu-i386-softmmu.fa.p -I. -I.. -Itarget/i386 -I../target/i386 -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/opus -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -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 -Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -isystem /x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0/linux-headers -isystem linux-headers -iquote . -iquote /x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0 -iquote /x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0/include -iquote /x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0/host/include/x86_64 -iquote /x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0/host/include/generic -iquote /x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0/tcg/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -march=amdfam10 -Og -g -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="i386-softmmu-config-target.h"' '-DCONFIG_DEVICES="i386-softmmu-config-devices.h"' -MD -MQ libqemu-i386-softmmu.fa.p/accel_tcg_cputlb.c.o -MF libqemu-i386-softmmu.fa.p/accel_tcg_cputlb.c.o.d -o libqemu-i386-softmmu.fa.p/accel_tcg_cputlb.c.o -c ../accel/tcg/cputlb.c
+In file included from ../accel/tcg/cputlb.c:20:
+../accel/tcg/cputlb.c: In function ‘do_ld_mmio_beN’:
+/x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0/include/qemu/osdep.h:244:35: error: call to ‘qemu_build_not_reached_always’ declared with attribute error: code path is reachable
+  244 | #define qemu_build_not_reached()  qemu_build_not_reached_always()
+      |                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../accel/tcg/cputlb.c:2121:13: note: in expansion of macro ‘qemu_build_not_reached’
+ 2121 |             qemu_build_not_reached();
+      |             ^~~~~~~~~~~~~~~~~~~~~~
+../accel/tcg/cputlb.c: In function ‘do_st_mmio_leN’:
+/x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0/include/qemu/osdep.h:244:35: error: call to ‘qemu_build_not_reached_always’ declared with attribute error: code path is reachable
+  244 | #define qemu_build_not_reached()  qemu_build_not_reached_always()
+      |                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../accel/tcg/cputlb.c:2764:13: note: in expansion of macro ‘qemu_build_not_reached’
+ 2764 |             qemu_build_not_reached();
+      |             ^~~~~~~~~~~~~~~~~~~~~~
+```
+
+Downstream bug: https://bugs.gentoo.org/913083
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1849 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1849
new file mode 100644
index 00000000..f039b93d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1849
@@ -0,0 +1,71 @@
+Problems with building riscv Linux using qemu on wsl2
+Description of problem:
+execute:
+
+`qemu-system-riscv64 -M virt -m 256M -nographic -kernel /home/ysc/test/linux-6.1.46/arch/riscv/boot/Image -drive file=rootfs.img,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -append "root=/dev/vda rw console=ttyS0"`
+
+**appear:**
+
+OpenSBI
+
+/ \_\_ \\ / **_| \_ \_ | | | | | \_\_ \__\_ \_ \_\_ | (_**\_ | |_) || | | | | | '\_ \\ / \_ \\ '\_ \\ \__\_ | \_ \< | | | |\*\*| | |_) | \_\_/ | | |) | |) || | \_\_**/| .**/ \_\*\*|_| |_|**_/|\___\_/_**| | | |\_|
+
+Platform Name : riscv-virtio,qemu
+
+Platform Features : medeleg Platform HART Count : 1
+
+Platform IPI Device : aclint-mswi
+
+Platform Timer Device : aclint-mtimer @ 10000000Hz
+
+Platform Console Device : uart8250 Platform HSM Device : ---
+
+Platform Reboot Device : sifive_test Platform Shutdown Device : sifive_test
+
+Firmware Base : 0x80000000
+
+Firmware Size : 252 KB
+
+Runtime SBI Version : 0.3
+
+Domain0 Name : root
+
+Domain0 Boot HART : 0
+
+Domain0 HARTs : 0\*
+
+Domain0 Region00 : 0x0000000002000000-0x000000000200ffff (I)
+
+Domain0 Region01 : 0x0000000080000000-0x000000008003ffff ()
+
+Domain0 Region02 : 0x0000000000000000-0xffffffffffffffff (R,W,X)
+
+Domain0 Next Address : 0x0000000080200000 Domain0 Next Arg1 : 0x000000008f000000
+
+Domain0 Next Mode : S-mode Domain0 SysReset : yes
+
+Boot HART ID : 0
+
+Boot HART Domain : root
+
+Boot HART ISA : rv64imafdcsuh
+
+Boot HART Features : scounteren,mcounteren,time
+
+Boot HART PMP Count : 16
+
+Boot HART PMP Granularity : 4
+
+Boot HART PMP Address Bits: 54
+
+Boot HART MHPM Count : 0
+
+Boot HART MIDELEG : 0x0000000000001666
+
+Boot HART MEDELEG : 0x0000000000f0b509
+
+When I run qemu, it's stuck here
+Steps to reproduce:
+1. Build the kernel file using Linux-6.1.46
+2. Use busbox to build rootfs
+3. run qemu
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/185 b/gitlab/issues_text/target_missing/host_missing/accel_missing/185
new file mode 100644
index 00000000..f8a8ca37
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/185
@@ -0,0 +1 @@
+Coroutines: Audit use of "coroutine_fn" specifier
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1851 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1851
new file mode 100644
index 00000000..c0e55849
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1851
@@ -0,0 +1,435 @@
+hw/net/rocker: NULL pointer dereference in of_dpa_cmd_add_l2_flood
+Description of problem:
+rocker_tlv_parse_nested could return early because of no group ids in the group_tlvs. In such case tlvs is NULL; tlvs\[i + 1\] in the next for-loop will deref the NULL pointer.
+Steps to reproduce:
+Compile and run the following code within the guest:
+
+```
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <assert.h>
+#include <fcntl.h>
+#include <inttypes.h>
+#include <sys/mman.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+#include <sys/io.h>
+#include <stdint.h>
+#include <stdbool.h>
+#include <err.h>
+#include <errno.h>
+#include <pthread.h>
+
+/*
+ * Rocker DMA ring register offsets
+ */
+#define ROCKER_DMA_DESC_BASE            0x1000
+#define ROCKER_DMA_DESC_SIZE            32
+#define ROCKER_DMA_DESC_MASK            0x1F
+#define ROCKER_DMA_DESC_TOTAL_SIZE \
+    (ROCKER_DMA_DESC_SIZE * 64) /* 62 ports + event + cmd */
+#define ROCKER_DMA_DESC_ADDR_OFFSET     0x00     /* 8-byte */
+#define ROCKER_DMA_DESC_SIZE_OFFSET     0x08
+#define ROCKER_DMA_DESC_HEAD_OFFSET     0x0c
+#define ROCKER_DMA_DESC_TAIL_OFFSET     0x10
+#define ROCKER_DMA_DESC_CTRL_OFFSET     0x14
+#define ROCKER_DMA_DESC_CREDITS_OFFSET  0x18
+#define ROCKER_DMA_DESC_RSVD_OFFSET     0x1c
+
+/*
+ * Rocker dma ctrl register bits
+ */
+#define ROCKER_DMA_DESC_CTRL_RESET      (1 << 0)
+
+/*
+ * Rocker test registers
+ */
+#define ROCKER_TEST_REG                 0x0010
+#define ROCKER_TEST_REG64               0x0018  /* 8-byte */
+#define ROCKER_TEST_IRQ                 0x0020
+#define ROCKER_TEST_DMA_ADDR            0x0028  /* 8-byte */
+#define ROCKER_TEST_DMA_SIZE            0x0030
+#define ROCKER_TEST_DMA_CTRL            0x0034
+
+/*
+ * Rocker general purpose registers
+ */
+#define ROCKER_CONTROL                  0x0300
+#define ROCKER_PORT_PHYS_COUNT          0x0304
+#define ROCKER_PORT_PHYS_LINK_STATUS    0x0310 /* 8-byte */
+#define ROCKER_PORT_PHYS_ENABLE         0x0318 /* 8-byte */
+#define ROCKER_SWITCH_ID                0x0320 /* 8-byte */
+
+/*
+ * Rocker test register ctrl
+ */
+#define ROCKER_TEST_DMA_CTRL_CLEAR      (1 << 0)
+#define ROCKER_TEST_DMA_CTRL_FILL       (1 << 1)
+#define ROCKER_TEST_DMA_CTRL_INVERT     (1 << 2)
+
+#define __le16 uint16_t
+#define __le32 uint32_t
+#define __le64 uint64_t
+
+typedef struct rocker_desc {
+    __le64 buf_addr;
+    uint64_t cookie;
+    __le16 buf_size;
+    __le16 tlv_size;
+    __le16 rsvd[5];   /* pad to 32 bytes */
+    __le16 comp_err;
+} __attribute__((packed, aligned(8))) RockerDesc;
+
+
+/*
+ * Rocker TLV type fields
+ */
+
+typedef struct rocker_tlv {
+    __le32 type;
+    __le16 len;
+    __le16 rsvd;
+} __attribute__((packed, aligned(8))) RockerTlv;
+
+
+typedef struct cmd_group_msg {
+    RockerTlv tlv1;
+    __le64 t1_value;
+    RockerTlv tlv2;
+    __le64 t2_value;
+    RockerTlv tlv3;
+    __le64 t3_value;
+} __attribute__((packed, aligned(8))) CmdGroupMsg;
+
+
+typedef struct cmd_msg {
+    RockerTlv tlv1;
+    __le64 t1_value;
+    RockerTlv tlv2;
+    CmdGroupMsg group_msg;
+} __attribute__((packed, aligned(8))) CmdMsg;
+
+
+typedef struct rx_msg {
+    RockerTlv tlv1;
+    __le64 t1_value;
+    RockerTlv tlv2;
+    __le64 t2_value;
+    RockerTlv tlv3;
+    __le64 t3_value;
+    RockerTlv tlv4;
+    __le64 t4_value;
+    RockerTlv tlv5;
+    __le64 t5_value;
+} __attribute__((packed, aligned(8))) RxMsg;
+
+
+/* Rx msg */
+enum {
+    ROCKER_TLV_RX_UNSPEC,
+    ROCKER_TLV_RX_FLAGS,                /* u16, see RX_FLAGS_ */
+    ROCKER_TLV_RX_CSUM,                 /* u16 */
+    ROCKER_TLV_RX_FRAG_ADDR,            /* u64 */
+    ROCKER_TLV_RX_FRAG_MAX_LEN,         /* u16 */
+    ROCKER_TLV_RX_FRAG_LEN,             /* u16 */
+
+    __ROCKER_TLV_RX_MAX,
+    ROCKER_TLV_RX_MAX = __ROCKER_TLV_RX_MAX - 1,
+};
+
+/* Tx msg */
+enum {
+    ROCKER_TLV_TX_UNSPEC,
+    ROCKER_TLV_TX_OFFLOAD,              /* u8, see TX_OFFLOAD_ */
+    ROCKER_TLV_TX_L3_CSUM_OFF,          /* u16 */
+    ROCKER_TLV_TX_TSO_MSS,              /* u16 */
+    ROCKER_TLV_TX_TSO_HDR_LEN,          /* u16 */
+    ROCKER_TLV_TX_FRAGS,                /* array */
+
+    __ROCKER_TLV_TX_MAX,
+    ROCKER_TLV_TX_MAX = __ROCKER_TLV_TX_MAX - 1,
+};
+
+/* cmd msg */
+enum {
+    ROCKER_TLV_CMD_UNSPEC,
+    ROCKER_TLV_CMD_TYPE,                /* u16 */
+    ROCKER_TLV_CMD_INFO,                /* nest */
+
+    __ROCKER_TLV_CMD_MAX,
+    ROCKER_TLV_CMD_MAX = __ROCKER_TLV_CMD_MAX - 1,
+};
+
+enum {
+    ROCKER_TLV_CMD_TYPE_UNSPEC,
+    ROCKER_TLV_CMD_TYPE_GET_PORT_SETTINGS,
+    ROCKER_TLV_CMD_TYPE_SET_PORT_SETTINGS,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_FLOW_ADD,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_FLOW_MOD,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_FLOW_DEL,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_FLOW_GET_STATS,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_GROUP_ADD,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_GROUP_MOD,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_GROUP_DEL,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_GROUP_GET_STATS,
+
+    __ROCKER_TLV_CMD_TYPE_MAX,
+    ROCKER_TLV_CMD_TYPE_MAX = __ROCKER_TLV_CMD_TYPE_MAX - 1,
+};
+
+/*
+ * cmd info nested for OF-DPA msgs
+ */
+
+enum {
+    ROCKER_TLV_OF_DPA_UNSPEC,
+    ROCKER_TLV_OF_DPA_TABLE_ID,            /* u16 */
+    ROCKER_TLV_OF_DPA_PRIORITY,            /* u32 */
+    ROCKER_TLV_OF_DPA_HARDTIME,            /* u32 */
+    ROCKER_TLV_OF_DPA_IDLETIME,            /* u32 */
+    ROCKER_TLV_OF_DPA_COOKIE,              /* u64 */
+    ROCKER_TLV_OF_DPA_IN_PPORT,            /* u32 */
+    ROCKER_TLV_OF_DPA_IN_PPORT_MASK,       /* u32 */
+    ROCKER_TLV_OF_DPA_OUT_PPORT,           /* u32 */
+    ROCKER_TLV_OF_DPA_GOTO_TABLE_ID,       /* u16 */
+    ROCKER_TLV_OF_DPA_GROUP_ID,            /* u32 */
+    ROCKER_TLV_OF_DPA_GROUP_ID_LOWER,      /* u32 */
+    ROCKER_TLV_OF_DPA_GROUP_COUNT,         /* u16 */
+    ROCKER_TLV_OF_DPA_GROUP_IDS,           /* u32 array */
+    ROCKER_TLV_OF_DPA_VLAN_ID,             /* __be16 */
+    ROCKER_TLV_OF_DPA_VLAN_ID_MASK,        /* __be16 */
+    ROCKER_TLV_OF_DPA_VLAN_PCP,            /* __be16 */
+    ROCKER_TLV_OF_DPA_VLAN_PCP_MASK,       /* __be16 */
+    ROCKER_TLV_OF_DPA_VLAN_PCP_ACTION,     /* u8 */
+    ROCKER_TLV_OF_DPA_NEW_VLAN_ID,         /* __be16 */
+    ROCKER_TLV_OF_DPA_NEW_VLAN_PCP,        /* u8 */
+    ROCKER_TLV_OF_DPA_TUNNEL_ID,           /* u32 */
+    ROCKER_TLV_OF_DPA_TUNNEL_LPORT,        /* u32 */
+    ROCKER_TLV_OF_DPA_ETHERTYPE,           /* __be16 */
+    ROCKER_TLV_OF_DPA_DST_MAC,             /* binary */
+    ROCKER_TLV_OF_DPA_DST_MAC_MASK,        /* binary */
+    ROCKER_TLV_OF_DPA_SRC_MAC,             /* binary */
+    ROCKER_TLV_OF_DPA_SRC_MAC_MASK,        /* binary */
+    ROCKER_TLV_OF_DPA_IP_PROTO,            /* u8 */
+    ROCKER_TLV_OF_DPA_IP_PROTO_MASK,       /* u8 */
+    ROCKER_TLV_OF_DPA_IP_DSCP,             /* u8 */
+    ROCKER_TLV_OF_DPA_IP_DSCP_MASK,        /* u8 */
+    ROCKER_TLV_OF_DPA_IP_DSCP_ACTION,      /* u8 */
+    ROCKER_TLV_OF_DPA_NEW_IP_DSCP,         /* u8 */
+    ROCKER_TLV_OF_DPA_IP_ECN,              /* u8 */
+    ROCKER_TLV_OF_DPA_IP_ECN_MASK,         /* u8 */
+    ROCKER_TLV_OF_DPA_DST_IP,              /* __be32 */
+    ROCKER_TLV_OF_DPA_DST_IP_MASK,         /* __be32 */
+    ROCKER_TLV_OF_DPA_SRC_IP,              /* __be32 */
+    ROCKER_TLV_OF_DPA_SRC_IP_MASK,         /* __be32 */
+    ROCKER_TLV_OF_DPA_DST_IPV6,            /* binary */
+    ROCKER_TLV_OF_DPA_DST_IPV6_MASK,       /* binary */
+    ROCKER_TLV_OF_DPA_SRC_IPV6,            /* binary */
+    ROCKER_TLV_OF_DPA_SRC_IPV6_MASK,       /* binary */
+    ROCKER_TLV_OF_DPA_SRC_ARP_IP,          /* __be32 */
+    ROCKER_TLV_OF_DPA_SRC_ARP_IP_MASK,     /* __be32 */
+    ROCKER_TLV_OF_DPA_L4_DST_PORT,         /* __be16 */
+    ROCKER_TLV_OF_DPA_L4_DST_PORT_MASK,    /* __be16 */
+    ROCKER_TLV_OF_DPA_L4_SRC_PORT,         /* __be16 */
+    ROCKER_TLV_OF_DPA_L4_SRC_PORT_MASK,    /* __be16 */
+    ROCKER_TLV_OF_DPA_ICMP_TYPE,           /* u8 */
+    ROCKER_TLV_OF_DPA_ICMP_TYPE_MASK,      /* u8 */
+    ROCKER_TLV_OF_DPA_ICMP_CODE,           /* u8 */
+    ROCKER_TLV_OF_DPA_ICMP_CODE_MASK,      /* u8 */
+    ROCKER_TLV_OF_DPA_IPV6_LABEL,          /* __be32 */
+    ROCKER_TLV_OF_DPA_IPV6_LABEL_MASK,     /* __be32 */
+    ROCKER_TLV_OF_DPA_QUEUE_ID_ACTION,     /* u8 */
+    ROCKER_TLV_OF_DPA_NEW_QUEUE_ID,        /* u8 */
+    ROCKER_TLV_OF_DPA_CLEAR_ACTIONS,       /* u32 */
+    ROCKER_TLV_OF_DPA_POP_VLAN,            /* u8 */
+    ROCKER_TLV_OF_DPA_TTL_CHECK,           /* u8 */
+    ROCKER_TLV_OF_DPA_COPY_CPU_ACTION,     /* u8 */
+
+    __ROCKER_TLV_OF_DPA_MAX,
+    ROCKER_TLV_OF_DPA_MAX = __ROCKER_TLV_OF_DPA_MAX - 1,
+};
+
+#define PAGE_SHIFT  12
+#define PAGE_SIZE   (1 << PAGE_SHIFT)
+#define PFN_PRESENT (1ull << 63)
+#define PFN_PFN     ((1ull << 55) - 1)
+
+uint64_t get_physical_pfn(void* ptr)
+{
+    uint64_t pfn = -1;
+    FILE* fp = fopen("/proc/self/pagemap", "rb");
+    if (!fp)
+    {
+        return pfn;
+    }
+
+    if (!fseek(fp, (unsigned long)ptr / PAGE_SIZE * 8, SEEK_SET))
+    {
+        fread(&pfn, sizeof(pfn), 1, fp);
+        if (pfn & PFN_PRESENT)
+        {
+            pfn &= PFN_PFN;
+        }
+    }
+    fclose(fp);
+    return pfn;
+}
+
+uint64_t get_physical_addr(void* ptr)
+{
+    uint64_t pfn = get_physical_pfn(ptr);
+    return pfn * PAGE_SIZE + (uint64_t)ptr % PAGE_SIZE;
+}
+
+void* mmio_mem;
+
+void mmio_write(uint32_t addr, uint32_t value)
+{
+    *((uint32_t*)(mmio_mem + addr))= value;
+}
+
+void mmio_write64(uint32_t addr, uint64_t value)
+{
+    *((uint64_t*)(mmio_mem + addr))= value;
+}
+
+uint64_t mmio_read(uint32_t addr)
+{
+    return *((uint64_t*)(mmio_mem +addr));
+}
+
+uint64_t mmio_read64(uint64_t addr)
+{
+    return *((uint64_t*)(mmio_mem +addr));
+}
+
+uint64_t ring_desk_base_addr(int index)
+{
+    return ROCKER_DMA_DESC_BASE + index * 32;
+}
+
+int main()
+{
+    int mmio_fd= open("/sys/devices/pci0000:00/0000:00:04.0/resource0", O_RDWR | O_SYNC);
+    if (mmio_fd== -1) {
+        printf("mmio_fd open failed");
+    	return 1;
+    }
+
+    mmio_mem = mmap(0, 0x2000, PROT_READ | PROT_WRITE, MAP_SHARED, mmio_fd, 0);
+    if (mmio_mem == MAP_FAILED) {
+        printf("mmap mmio_mem failed");
+	return 1;
+    }
+
+    iopl(3);
+
+    RockerTlv cmd_group_tlv = {ROCKER_TLV_OF_DPA_GROUP_ID, sizeof(RockerTlv) + sizeof(__le64), 12345 };
+    RockerTlv cmd_count_tlv = {ROCKER_TLV_OF_DPA_GROUP_COUNT, sizeof(RockerTlv) + sizeof(__le64), 12345};
+    RockerTlv cmd_ids_tlv = {ROCKER_TLV_OF_DPA_GROUP_IDS, sizeof(RockerTlv) + sizeof(__le64), 12345 };
+
+    CmdGroupMsg group_msg = { cmd_group_tlv, 0x40000000, cmd_count_tlv, 65535, cmd_ids_tlv, 12345};
+
+    RockerTlv cmd_type_tlv = {ROCKER_TLV_CMD_TYPE, sizeof(RockerTlv) + sizeof(__le64), 12345 };
+    RockerTlv cmd_info_tlv = {ROCKER_TLV_CMD_INFO, sizeof(RockerTlv) + sizeof(CmdGroupMsg), 12345 };
+    CmdMsg cmd_msg = {cmd_type_tlv, ROCKER_TLV_CMD_TYPE_OF_DPA_GROUP_ADD, cmd_info_tlv, group_msg };
+    RockerDesc cmd_desc = {get_physical_addr(&cmd_msg), 0xdeadbeef, sizeof(CmdMsg), sizeof(CmdMsg), 0x1, 0x4242 };
+
+    mmio_write64(ROCKER_PORT_PHYS_ENABLE, 0xE);
+
+    // cmd ring
+    mmio_write(ring_desk_base_addr(0) + ROCKER_DMA_DESC_CTRL_OFFSET, ROCKER_DMA_DESC_CTRL_RESET);
+    // base_addr
+    mmio_write64(ring_desk_base_addr(0), get_physical_addr(&cmd_desc));
+    mmio_write(ring_desk_base_addr(0) + ROCKER_DMA_DESC_SIZE_OFFSET, 8);
+    mmio_write(ring_desk_base_addr(0) + ROCKER_DMA_DESC_HEAD_OFFSET, 4);
+
+    printf("End\n");
+    return 0;
+}
+```
+
+Stack trace:
+
+```plaintext
+===================================================================================================
+ldl_he_p(const void * ptr) (/home/arayz/arayz/qemu-git-e1000e/include/qemu/bswap.h:359)
+ldl_le_p(const void * ptr) (/home/arayz/arayz/qemu-git-e1000e/include/qemu/bswap.h:394)
+rocker_tlv_get_le32(const RockerTlv * tlv) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_tlv.h:114)
+of_dpa_cmd_add_l2_flood(OfDpa * of_dpa, OfDpaGroup * group, RockerTlv ** group_tlvs) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_of_dpa.c:2043)
+of_dpa_cmd_group_do(OfDpa * of_dpa, uint32_t group_id, OfDpaGroup * group, RockerTlv ** group_tlvs) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_of_dpa.c:2125)
+of_dpa_cmd_group_add(OfDpa * of_dpa, uint32_t group_id, RockerTlv ** group_tlvs) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_of_dpa.c:2145)
+of_dpa_group_cmd(OfDpa * of_dpa, struct desc_info * info, char * buf, uint16_t cmd, RockerTlv ** group_tlvs) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_of_dpa.c:2204)
+of_dpa_cmd(World * world, struct desc_info * info, char * buf, uint16_t cmd, RockerTlv * cmd_info_tlv) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_of_dpa.c:2234)
+world_do_cmd(World * world, DescInfo * info, char * buf, uint16_t cmd, RockerTlv * cmd_info_tlv) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_world.c:43)
+cmd_consume(Rocker * r, DescInfo * info) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker.c:450)
+ring_pump(DescRing * ring) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_desc.c:242)
+desc_ring_set_head(DescRing * ring, uint32_t new) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_desc.c:281)
+rocker_io_writel(void * opaque, hwaddr addr, uint32_t val) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker.c:805)
+rocker_mmio_write(void * opaque, hwaddr addr, uint64_t val, unsigned int size) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker.c:996)
+memory_region_write_accessor(MemoryRegion * mr, hwaddr addr, uint64_t * value, unsigned int size, int shift, uint64_t mask, MemTxAttrs attrs) (/home/arayz/arayz/qemu-git-e1000e/softmmu/memory.c:492)
+access_with_adjusted_size(hwaddr addr, uint64_t * value, unsigned int size, unsigned int access_size_min, unsigned int access_size_max, MemTxResult (*)(MemoryRegion *, hwaddr, uint64_t *, unsigned int, int, uint64_t, MemTxAttrs) access_fn, MemoryRegion * mr, MemTxAttrs attrs) (/home/arayz/arayz/qemu-git-e1000e/softmmu/memory.c:554)
+memory_region_dispatch_write(MemoryRegion * mr, hwaddr addr, uint64_t data, MemOp op, MemTxAttrs attrs) (/home/arayz/arayz/qemu-git-e1000e/softmmu/memory.c:1514)
+flatview_write_continue(FlatView * fv, hwaddr addr, MemTxAttrs attrs, const void * ptr, hwaddr len, hwaddr addr1, hwaddr l, MemoryRegion * mr) (/home/arayz/arayz/qemu-git-e1000e/softmmu/physmem.c:2783)
+flatview_write(FlatView * fv, hwaddr addr, MemTxAttrs attrs, const void * buf, hwaddr len) (/home/arayz/arayz/qemu-git-e1000e/softmmu/physmem.c:2823)
+address_space_write(AddressSpace * as, hwaddr addr, MemTxAttrs attrs, const void * buf, hwaddr len) (/home/arayz/arayz/qemu-git-e1000e/softmmu/physmem.c:2915)
+address_space_rw(AddressSpace * as, hwaddr addr, MemTxAttrs attrs, void * buf, hwaddr len, _Bool is_write) (/home/arayz/arayz/qemu-git-e1000e/softmmu/physmem.c:2925)
+kvm_cpu_exec(CPUState * cpu) (/home/arayz/arayz/qemu-git-e1000e/accel/kvm/kvm-all.c:2929)
+kvm_vcpu_thread_fn(void * arg) (/home/arayz/arayz/qemu-git-e1000e/accel/kvm/kvm-accel-ops.c:49)
+qemu_thread_start(void * args) (/home/arayz/arayz/qemu-git-e1000e/util/qemu-thread-posix.c:556)
+libpthread.so.0!start_thread(void * arg) (/build/glibc-sMfBJT/glibc-2.31/nptl/pthread_create.c:477)
+libc.so.6!clone() (/build/glibc-sMfBJT/glibc-2.31/sysdeps/unix/sysv/linux/x86_64/clone.S:95)
+===================================================================================================
+
+    disassemble and register context:
+===================================================================================================
+Dump of assembler code for function ldl_he_p:
+   0x000055d8a1a473e6 <+0>:	push   %rbp
+   0x000055d8a1a473e7 <+1>:	mov    %rsp,%rbp
+   0x000055d8a1a473ea <+4>:	sub    $0x20,%rsp
+   0x000055d8a1a473ee <+8>:	mov    %rdi,-0x18(%rbp)
+   0x000055d8a1a473f2 <+12>:	mov    %fs:0x28,%rax
+   0x000055d8a1a473fb <+21>:	mov    %rax,-0x8(%rbp)
+   0x000055d8a1a473ff <+25>:	xor    %eax,%eax
+   0x000055d8a1a47401 <+27>:	mov    -0x18(%rbp),%rax
+=> 0x000055d8a1a47405 <+31>:	mov    (%rax),%eax
+   0x000055d8a1a47407 <+33>:	mov    %eax,-0xc(%rbp)
+   0x000055d8a1a4740a <+36>:	mov    -0xc(%rbp),%eax
+   0x000055d8a1a4740d <+39>:	mov    -0x8(%rbp),%rdx
+   0x000055d8a1a47411 <+43>:	xor    %fs:0x28,%rdx
+   0x000055d8a1a4741a <+52>:	je     0x55d8a1a47421 <ldl_he_p+59>
+   0x000055d8a1a4741c <+54>:	callq  0x55d8a186d6d0 <__stack_chk_fail@plt>
+   0x000055d8a1a47421 <+59>:	leaveq 
+   0x000055d8a1a47422 <+60>:	retq   
+End of assembler dump.
+
+rax            0x8                 8
+rbx            0x7f7828088ac0      140154044451520
+rcx            0x0                 0
+rdx            0x7f7828088ac0      140154044451520
+rsi            0x8                 8
+rdi            0x8                 8
+rbp            0x7f7832cfd100      0x7f7832cfd100
+rsp            0x7f7832cfd0e0      0x7f7832cfd0e0
+r8             0x7f7828088ac0      140154044451520
+r9             0x7f7828000790      140154043893648
+r10            0x7f78280008d0      140154043893968
+r11            0x7f7828000080      140154043891840
+r12            0x7ffec007cb1e      140732120156958
+r13            0x7ffec007cb1f      140732120156959
+r14            0x7ffec007cbe0      140732120157152
+r15            0x7f7832cfdb00      140154225285888
+rip            0x55d8a1a47405      0x55d8a1a47405 <ldl_he_p+31>
+eflags         0x10246             [ PF ZF IF RF ]
+cs             0x33                51
+ss             0x2b                43
+ds             0x0                 0
+es             0x0                 0
+fs             0x0                 0
+gs             0x0                 0
+===================================================================================================
+```
+Additional information:
+This was wrongly assigned a high-severity CVE and is being discussed on qemu-devel ML: https://lists.nongnu.org/archive/html/qemu-devel/2023-08/msg04621.html
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1853 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1853
new file mode 100644
index 00000000..9cfcb73a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1853
@@ -0,0 +1 @@
+Errors when install QEMU from source code
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1855 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1855
new file mode 100644
index 00000000..f1435edb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1855
@@ -0,0 +1,59 @@
+io-qcow2-iothreads-commit-active test fails in a "minimal" build of QEMU
+Description of problem:
+The build fails because of the `io-qcow2-iothreads-commit-active` test failure:
+
+```
+343/412 qemu:block / io-qcow2-iothreads-commit-active                 ERROR           1.66s   exit status 1
+――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
+stderr:
+--- /tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/tests/qemu-iotests/tests/iothreads-commit-active.out
++++ /tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/scratch/qcow2-file-iothreads-commit-active/iothreads-commit-active.out.bad
+@@ -11,13 +11,27 @@
+ 10 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+ Launching VM...
+-Creating some background I/O...
+-{"return": {}}
+-Starting active commit...
+-{"return": {}}
+-{"execute": "job-complete", "arguments": {"id": "job1"}}
+-{"return": {}}
+-{"data": {"device": "job1", "len": 131072, "offset": 131072, "speed": 0, "type": "commit"}, "event": "BLOCK_JOB_READY", "timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
+-{"data": {"device": "job1", "len": 131072, "offset": 131072, "speed": 0, "type": "commit"}, "event": "BLOCK_JOB_COMPLETED", "timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
+-{"execute": "job-dismiss", "arguments": {"id": "job1"}}
+-{"return": {}}
++Traceback (most recent call last):
++  File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/python/qemu/machine/machine.py", line 436, in launch
++    self._launch()
++  File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/python/qemu/machine/machine.py", line 463, in _launch
++    self._pre_launch()
++  File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/tests/qemu-iotests/iotests.py", line 841, in _pre_launch
++    super()._pre_launch()
++  File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/python/qemu/machine/qtest.py", line 143, in _pre_launch
++    self._qtest = QEMUQtestProtocol(self._qtest_path, server=True)
++  File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/python/qemu/machine/qtest.py", line 54, in __init__
++    self._sock.bind(self._address)
++OSError: AF_UNIX path too long
++
++The above exception was the direct cause of the following exception:
++
++Traceback (most recent call last):
++  File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/tests/qemu-iotests/tests/iothreads-commit-active", line 65, in <module>
++    vm.launch()
++  File "/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/python/qemu/machine/machine.py", line 449, in launch
++    raise VMLaunchFailure(
++qemu.machine.machine.VMLaunchFailure: OSError: AF_UNIX path too long
++       Command: /tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/tests/qemu-iotests/../../qemu-system-x86_64 -display none -vga none -chardev socket,id=mon,fd=3 -mon chardev=mon,mode=control -qtest unix:path=/tmp/guix-build-qemu-minimal-8.1.0.drv-0/tmptfjmlerc/qcow2-file-iothreads-commit-active/qemu-58979-qtest.sock -accel qtest -nodefaults -display none -accel qtest -object iothread,id=iothread0 -object throttle-group,x-bps-write=1048576,id=tg0 -blockdev file,node-name=disk0-file,filename=/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/scratch/qcow2-file-iothreads-commit-active/58979-disk0.img -blockdev qcow2,node-name=disk0-fmt,file=disk0-file -drive if=none,id=drive0,file=/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/scratch/qcow2-file-iothreads-commit-active/58979-disk0-snap.img,format=qcow2,cache=writeback,aio=threads,backing=disk0-fmt,node-name=disk0 -device virtio-scsi,iothread=iothread0 -device scsi-hd,drive=drive0 -blockdev file,filename=/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/scratch/qcow2-file-iothreads-commit-active/58979-mirror-src.img,node-name=mirror-src-file -blockdev qcow2,file=mirror-src-file,node-name=mirror-src -blockdev file,filename=/tmp/guix-build-qemu-minimal-8.1.0.drv-0/qemu-8.1.0/b/qemu/scratch/qcow2-file-iothreads-commit-active/58979-mirror-dst.img,node-name=mirror-dst-file -blockdev qcow2,file=mirror-dst-file,node-name=mirror-dst-fmt -blockdev throttle,throttle-group=tg0,file=mirror-dst-fmt,node-name=mirror-dst -device scsi-hd,drive=mirror-src
++       Output:
++
+
+(test program exited with status code 1)
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+```
+Steps to reproduce:
+1. Install GNU Guix on your GNU/Linux machine.
+2. `guix time-machine --url=https://gitlab.com/Apteryks/guix --branch=qemu-minimal-io-qcow2-iothreads-commit-active-test-failure -- build qemu-minimal --keep-failed`
+3. Observe the test failure.  The build artifacts are left under /tmp/guix-build-qemu-minimal-8.1.0.drv-0 to inspect.
+Additional information:
+Attached is the complete build log
+[8xr1k7v10jp2wgbimib6f0s51ilqgj3z-qemu-minimal-8.1.0.drv.gz](/uploads/59a0f88a05715c18a6bdb44845b83a18/8xr1k7v10jp2wgbimib6f0s51ilqgj3z-qemu-minimal-8.1.0.drv.gz)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1859 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1859
new file mode 100644
index 00000000..1461e642
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1859
@@ -0,0 +1,8 @@
+Trying to boot Windows Server 2008 Windows Host
+Description of problem:
+On Windows 10 trying to boot Windows Server 2008 R2 I am just stuck on starting Windows if I do get past Starting Windows it just goes to 0x0000007F BSOD
+Steps to reproduce:
+1. Run Windows Server with my command line input
+2. Stuck on Starting Windows
+Additional information:
+![Capture](/uploads/d46fb1980c1b57fed6e0b7d1af98fbaa/Capture.PNG)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/186 b/gitlab/issues_text/target_missing/host_missing/accel_missing/186
new file mode 100644
index 00000000..29a596e3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/186
@@ -0,0 +1 @@
+Audit consistent option usage in documentation
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1860 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1860
new file mode 100644
index 00000000..33aae432
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1860
@@ -0,0 +1,10 @@
+virtio-gpu: Only black screen observed after resuming when guest vm do S3
+Description of problem:
+On Xen hypervisor, host(dom0) is PVH, guest(domU) is hvm, config virtio-gpu for guest.
+
+##
+Steps to reproduce:
+1. In guest vm run "sudo su root" & "echo mem \> /sys/power/state"
+2. In host run "sudo xl trigger \<guest id\> s3resume"
+Additional information:
+##
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1862 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1862
new file mode 100644
index 00000000..5e9f3ed9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1862
@@ -0,0 +1,18 @@
+SVGA/VESA strange colors (NetWare 6.x)
+Description of problem:
+The text mode part of the installation is correct but whenever the X server is starting, the display seems to be in 16 colors although GUI settings shows "SVGA/256 colors" (NetWare setup reports a "SVGA Plug & Play" display, VESA 2.0 compliance expected). Color depth issue with VESA? Telling NetWare to use explicitly the Cirrus Logic driver for a CL GD 5446 bring the display back to normal and colors are displayed as they should.
+Steps to reproduce:
+1. Grab a NetWare 6.0 installation ISO on some abandonware site (no need of a license key, unlicensed = 2 users max.)
+2. Execute the command line above
+3. Complete the text-mode part (defaults choices are fine)
+Additional information:
+NetWare 6.0 + Qemu => Same issue. SVGA PnP with wrong colors.
+NetWare 6.5 + Qemu => Same issue. SVGA PnP with wrong colors.
+NetWare 6.0 + PCem/86Box => does not exhibit the issue. Colors are normal.
+
+Using SeaBIOS 1.16.
+
+Screenshots:
+
+![NW60_SVGA_16_colors](/uploads/d72838ee709f97043c0f295b8e2d222c/NW60_SVGA_16_colors.png)
+![NW60_SVGA_Normal_colors](/uploads/6a0b36b2a2348f69ffd24206b1a54780/NW60_SVGA_Normal_colors.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1863 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1863
new file mode 100644
index 00000000..f02a41a8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1863
@@ -0,0 +1,72 @@
+Assertion `core->delayed_causes == 0` failed in hw/net/e1000e_core.c:353 during fuzzing
+Description of problem:
+Got an assertion failure `core->delayed_causes == 0` when fuzzing e1000e.
+Steps to reproduce:
+Minimized reproducer for the error:
+
+```plaintext
+cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -M q35 \
+-nodefaults -device e1000e,netdev=net0 -netdev user,id=net0 -qtest \
+/dev/null -qtest stdio
+outl 0xcf8 0x80000810
+outl 0xcfc 0xe0000000
+outl 0xcf8 0x80000804
+outw 0xcfc 0x06
+write 0xe000042a 0x2 0x0241
+write 0xe0000402 0x2 0x0200
+write 0x400b 0x1 0x88
+write 0xe0000438 0x4 0x01040000
+outl 0xcf8 0x800008a3
+outb 0xcfc 0x80
+EOF
+```
+Additional information:
+The crash report triggered by the reproducer is:
+
+```plaintext
+qemu-fuzz-x86_64: /../hw/net/e1000e_core.c:353: uint32_t e1000e_intmgr_collect_delayed_causes(E1000ECore *): Assertion `core->delayed_causes == 0' failed.
+==2036033== ERROR: libFuzzer: deadly signal
+    #0 0x5606ff6c555e in __sanitizer_print_stack_trace ../../../llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_stack.cpp:87:3
+    #1 0x5606ff607bb1 in fuzzer::PrintStackTrace() ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x5606ff5e2486 in fuzzer::Fuzzer::CrashCallback() (.part.0) ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:18
+    #3 0x5606ff5e254d in fuzzer::Fuzzer::CrashCallback() ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:205:1
+    #4 0x5606ff5e254d in fuzzer::Fuzzer::StaticCrashSignalCallback() ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:204:19
+    #5 0x7f7490e4e41f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466)
+    #6 0x7f7490c4200a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+    #7 0x7f7490c4200a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+    #8 0x7f7490c21858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
+    #9 0x7f7490c21728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3
+    #10 0x7f7490c32fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3
+    #11 0x5606ffd20c33 in e1000e_intmgr_collect_delayed_causes ../hw/net/e1000e_core.c:353:9
+    #12 0x5606ffd20c33 in e1000e_set_interrupt_cause ../hw/net/e1000e_core.c:2203:12
+    #13 0x5606ffd1bd1b in e1000e_receive_internal ../hw/net/e1000e_core.c:1751:9
+    #14 0x56070055a58a in qemu_deliver_packet_iov ../net/net.c:820:15
+    #15 0x56070055e215 in qemu_net_queue_deliver ../net/queue.c:164:11
+    #16 0x56070055f9ca in qemu_net_queue_flush ../net/queue.c:286:15
+    #17 0x56070054f5c8 in qemu_flush_or_purge_queued_packets ../net/net.c:681:9
+    #18 0x5606ffd14ff5 in e1000e_start_recv ../hw/net/e1000e_core.c:983:9
+    #19 0x5606ffd3c33b in e1000e_set_rx_control ../hw/net/e1000e_core.c:1959:9
+    #20 0x5606ffd20fe8 in e1000e_core_write ../hw/net/e1000e_core.c:3306:9
+    #21 0x560700caeb43 in memory_region_write_accessor ../softmmu/memory.c:493:5
+    #22 0x560700cae2ca in access_with_adjusted_size ../softmmu/memory.c:569:18
+    #23 0x560700cad670 in memory_region_dispatch_write ../softmmu/memory.c
+    #24 0x560700cf7d6f in flatview_write_continue ../softmmu/physmem.c:2677:23
+    #25 0x560700cef213 in flatview_write ../softmmu/physmem.c:2719:12
+    #26 0x560700ceef27 in address_space_write ../softmmu/physmem.c:2815:18
+    #27 0x560700420b2f in qtest_process_command ../softmmu/qtest.c:558:13
+    #28 0x56070041ecfb in qtest_process_inbuf ../softmmu/qtest.c:810:9
+    #29 0x56070041eb19 in qtest_server_inproc_recv ../softmmu/qtest.c:941:9
+    #30 0x56070126a792 in qtest_sendf ../tests/qtest/libqtest.c:607:5
+    #31 0x56070126ae9e in qtest_write ../tests/qtest/libqtest.c:1072:5
+    #32 0x56070126ae9e in qtest_writel ../tests/qtest/libqtest.c:1088:5
+    #33 0x5606ff7058cb in __wrap_qtest_writel ../tests/qtest/fuzz/qtest_wrappers.c:180:9
+    #34 0x5606ff70d5f2 in op_write ../tests/qtest/fuzz/generic_fuzz.c:485:13
+    #35 0x5606ff70bd2f in generic_fuzz ../tests/qtest/fuzz/generic_fuzz.c:666:13
+    #36 0x5606ff7008e7 in LLVMFuzzerTestOneInput ../tests/qtest/fuzz/fuzz.c:158:5
+    #37 0x5606ff5e2d08 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:612:15
+    #38 0x5606ff5c6124 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:21
+    #39 0x5606ff5d2b0a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:19
+    #40 0x5606ff5bd8d6 in main ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #41 0x7f7490c23082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #42 0x5606ff5bd95d in _start (./qemu-fuzz-x86_64+0x1ef595d)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1871 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1871
new file mode 100644
index 00000000..cd089087
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1871
@@ -0,0 +1 @@
+Browse qcow2 image contents and add/remove files
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1872 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1872
new file mode 100644
index 00000000..5411a055
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1872
@@ -0,0 +1 @@
+When I compile  package , I will report 'Could not open'/lib64/ld musl arch64. so. 1 ': No such file or directory
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1873 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1873
new file mode 100644
index 00000000..888aed0e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1873
@@ -0,0 +1,84 @@
+igb driver failed to change MTU
+Description of problem:
+I am using the new IGB model to test sriov inside a virtual machine.
+
+and when the operator tries to configure MTU of 9000 on the VF I get a kernel crash and the node goes into reboot
+
+```
+virsh console virt-cluster-worker-0
+Connected to domain 'virt-cluster-worker-0'
+Escape character is ^] (Ctrl + ])
+[  486.776188] kernel BUG at include/linux/skbuff.h:2420!
+[  486.779661] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
+[  486.781938] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.14.0-284.16.1.el9_2.x86_64 #1
+[  486.783847] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
+[  486.785681] RIP: 0010:eth_type_trans+0xd3/0x140
+[  486.787051] Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 c8 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48
+[  486.790542] RSP: 0018:ffffaef200114e30 EFLAGS: 00010283
+[  486.791726] RAX: 000000000000002e RBX: ffffaef206a38000 RCX: 0000000000000028
+[  486.793086] RDX: ffff90bb7767a840 RSI: ffff90bc7d6a0000 RDI: ffff90bb413bc600
+[  486.794430] RBP: ffff90bb413bc600 R08: 0000000000000000 R09: ffff90bc7d6a0980
+[  486.795779] R10: 000000000000003c R11: 00000001a8be8000 R12: 0000000000000001
+[  486.797132] R13: 0000000000000003 R14: ffff90bd3b94e400 R15: ffff90bdcbc8c000
+[  486.798499] FS:  0000000000000000(0000) GS:ffff90beafc40000(0000) knlGS:0000000000000000
+[  486.800325] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[  486.801520] CR2: 00007faf740ec058 CR3: 000000010a40c004 CR4: 0000000000770ee0
+[  486.802856] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[  486.804171] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[  486.805459] PKRU: 55555554
+[  486.806291] Call Trace:
+[  486.807083]  <IRQ>
+[  486.807822]  igbvf_clean_rx_irq.constprop.0.isra.0+0x1b4/0x600 [igbvf]
+[  486.809027]  igbvf_poll+0x3d/0x210 [igbvf]
+[  486.809981]  __napi_poll+0x27/0x170
+[  486.810886]  net_rx_action+0x233/0x2f0
+[  486.811777]  __do_softirq+0xc7/0x2ac
+[  486.812644]  __irq_exit_rcu+0xb5/0xe0
+[  486.813515]  common_interrupt+0x80/0xa0
+[  486.814404]  </IRQ>
+[  486.815113]  <TASK>
+[  486.815800]  asm_common_interrupt+0x22/0x40
+[  486.816710] RIP: 0010:default_idle+0x10/0x20
+[  486.817631] Code: cc 0f ae f0 0f ae 38 0f ae f0 eb b5 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 66 90 0f 00 2d 7e 3e 4d 00 fb f4 <c3> cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 65
+[  486.820523] RSP: 0018:ffffaef2000afed0 EFLAGS: 00000246
+[  486.821705] RAX: ffffffff99f36ea0 RBX: ffff90bb4032a300 RCX: ffff90bd581f2430
+[  486.822936] RDX: 000000000013bd13 RSI: 0000000000000001 RDI: 000000000013bd14
+[  486.824165] RBP: 0000000000000000 R08: 0000007155e9e493 R09: ffff90bb437f4800
+[  486.825374] R10: 0000000000000232 R11: 0000000000000000 R12: 0000000000000000
+[  486.826581] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
+[  486.827777]  ? mwait_idle+0x80/0x80
+[  486.828593]  default_idle_call+0x33/0xe0
+[  486.829479]  cpuidle_idle_call+0x15d/0x1c0
+[  486.830381]  ? kvm_sched_clock_read+0x14/0x40
+[  486.831289]  do_idle+0x7b/0xe0
+[  486.832035]  cpu_startup_entry+0x19/0x20
+[  486.833076]  start_secondary+0x116/0x140
+[  486.834527]  secondary_startup_64_no_verify+0xe5/0xeb
+[  486.835953]  </TASK>
+[  486.836991] Modules linked in: igbvf veth ipt_REJECT nf_reject_ipv4 xt_nat xt_CT vhost_net vhost vhost_iotlb tap tun nf_conntrack_netlink tls xt_MASQUERADE nft_chain_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables rfkill geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink openvswitch nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 overlay ext4 mbcache jbd2 intel_rapl_msr intel_rapl_common isst_if_common nfit libnvdimm kvm_intel kvm irqbypass rapl iTCO_wdt iTCO_vendor_support cirrus drm_shmem_helper drm_kms_helper pcspkr i2c_i801 syscopyarea sysfillrect i2c_smbus sysimgblt virtio_balloon lpc_ich fb_sys_fops joydev ip_tables drm xfs libcrc32c dm_multipath sr_mod cdrom sg igb nvme_tcp ahci nvme_fabrics nvme libahci nvme_core virtio_net crct10dif_pclmul libata i2c_algo_bit crc32_pclmul dca virtio_console net_failover nvme_common virtio_blk t10_pi crc32c_intel failover ghash_clmulni_intel serio_raw dm_mirror dm_region_hash dm_log dm_mod fuse
+[  486.852907] ---[ end trace d1f9cdb1a6c92411 ]---
+[  486.854263] RIP: 0010:eth_type_trans+0xd3/0x140
+[  486.855234] Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 c8 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48
+[  486.858732] RSP: 0018:ffffaef200114e30 EFLAGS: 00010283
+[  486.859777] RAX: 000000000000002e RBX: ffffaef206a38000 RCX: 0000000000000028
+[  486.861020] RDX: ffff90bb7767a840 RSI: ffff90bc7d6a0000 RDI: ffff90bb413bc600
+[  486.862238] RBP: ffff90bb413bc600 R08: 0000000000000000 R09: ffff90bc7d6a0980
+[  486.863478] R10: 000000000000003c R11: 00000001a8be8000 R12: 0000000000000001
+[  486.864718] R13: 0000000000000003 R14: ffff90bd3b94e400 R15: ffff90bdcbc8c000
+[  486.865969] FS:  0000000000000000(0000) GS:ffff90beafc40000(0000) knlGS:0000000000000000
+[  486.867317] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[  486.868458] CR2: 00007faf740ec058 CR3: 000000010a40c004 CR4: 0000000000770ee0
+[  486.869705] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[  486.870959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[  486.872212] PKRU: 55555554
+[  486.873040] Kernel panic - not syncing: Fatal exception in interrupt
+[  486.875441] Kernel Offset: 0x18400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
+[  486.877044] Rebooting in 10 seconds..
+```
+Steps to reproduce:
+1. create a vm using igb driver for the network interface
+2. change the MTU of the PF to 9000
+3. allocate virtual functions
+4. change the MTU on the virtual function (vm crash)
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1875 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1875
new file mode 100644
index 00000000..a24f5921
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1875
@@ -0,0 +1,9 @@
+qemu-system-x86_64: warning: no scancode found for keysym 65483
+Description of problem:
+qemu-system-x86_64: warning: no scancode found for keysym 65483
+
+I'm hoping this is something that could easily be added to qemu, rather than a limitation of windows:
+
+I want to bind F14 to an arbitrary key, in this case `keycode 148 = XF86Calculator`, but it's not happening, and qemu is giving the error: `qemu-system-x86_64: warning: no scancode found for keysym 65483`
+
+`xmodmap -e "keycode 148 = F14 F14 F14 F14 F14"` Executes with no error, and xev correctly shows as F14 pressed/released, but a windows 10 VM started afterwards cannot recognise this bind.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1876 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1876
new file mode 100644
index 00000000..bd6f8b3f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1876
@@ -0,0 +1 @@
+Host wayland gtk problem
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1877 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1877
new file mode 100644
index 00000000..c7b63f17
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1877
@@ -0,0 +1,243 @@
+virtiofs Illegal Seek Error because of ivshmem device of looking-glass
+Description of problem:
+tl;dr: The dev "gnif" from looking-glass does not want to analyse this problem which his config from the documentation is causing. He insists someone opens a issue here at qemu's, so thats what i did now :) He also insists this problem is not caused by his config (even though the config is needed for looking-glass) and does not want to help or analyse this whole mess. Sorry if i'm a bit salty. 
+
+Please see the following issues on his and the virtio-win github : \
+https://github.com/gnif/LookingGlass/issues/1089
+
+https://github.com/gnif/LookingGlass/issues/1083
+
+[https://github.com/virtio-win/kvm-guest-drivers-windows/issues/911](https://github.com/virtio-win/kvm-guest-drivers-windows/issues/911%5C)
+
+#
+Steps to reproduce:
+1. Create a VM
+2. enable looking-glass (i used the latest Beta6 release from github) with the mentioned kernel module (i use manjaro and can use looking-glass-module-dkms from AUR)
+3. add virtiofs from virt-manager
+Additional information:
+libvirt XML
+
+```plaintext
+<domain xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0" type="kvm">
+  <name>win10</name>
+  <uuid>a026f749-3adc-4ab8-a5cf-521a4e8ec9d6</uuid>
+  <metadata>
+    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
+      <libosinfo:os id="http://microsoft.com/win/10"/>
+    </libosinfo:libosinfo>
+  </metadata>
+  <memory unit="KiB">12582912</memory>
+  <currentMemory unit="KiB">12582912</currentMemory>
+  <memoryBacking>
+    <source type="memfd"/>
+    <access mode="shared"/>
+  </memoryBacking>
+  <vcpu placement="static">10</vcpu>
+  <os>
+    <type arch="x86_64" machine="pc-q35-5.1">hvm</type>
+    <loader readonly="yes" type="pflash">/usr/share/edk2-ovmf/x64/OVMF_CODE.fd</loader>
+    <nvram>/var/lib/libvirt/qemu/nvram/win10_VARS.fd</nvram>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+    <hyperv mode="custom">
+      <relaxed state="on"/>
+      <vapic state="on"/>
+      <spinlocks state="on" retries="8191"/>
+      <vendor_id state="on" value="ASRock"/>
+    </hyperv>
+    <vmport state="off"/>
+  </features>
+  <cpu mode="host-passthrough" check="none" migratable="on">
+    <topology sockets="1" dies="1" cores="5" threads="2"/>
+  </cpu>
+  <clock offset="localtime">
+    <timer name="hpet" present="yes"/>
+    <timer name="hypervclock" present="yes"/>
+  </clock>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>restart</on_crash>
+  <pm>
+    <suspend-to-mem enabled="no"/>
+    <suspend-to-disk enabled="yes"/>
+  </pm>
+  <devices>
+    <emulator>/usr/bin/qemu-system-x86_64</emulator>
+    <disk type="file" device="cdrom">
+      <driver name="qemu" type="raw"/>
+      <target dev="sdc" bus="sata"/>
+      <readonly/>
+      <boot order="1"/>
+      <address type="drive" controller="0" bus="0" target="0" unit="2"/>
+    </disk>
+    <disk type="file" device="disk">
+      <driver name="qemu" type="qcow2" cache="none" discard="unmap"/>
+      <source file="/opt/windowsos.qcow2"/>
+      <target dev="sdd" bus="scsi"/>
+      <boot order="2"/>
+      <address type="drive" controller="0" bus="0" target="0" unit="3"/>
+    </disk>
+    <disk type="block" device="disk">
+      <driver name="qemu" type="raw" cache="none" io="native" discard="unmap"/>
+      <source dev="/dev/zvol/satassd2tb/vms/windowsdata2"/>
+      <target dev="sde" bus="scsi"/>
+      <address type="drive" controller="0" bus="0" target="0" unit="4"/>
+    </disk>
+    <controller type="usb" index="0" model="qemu-xhci" ports="15">
+      <address type="pci" domain="0x0000" bus="0x02" slot="0x00" function="0x0"/>
+    </controller>
+    <controller type="pci" index="0" model="pcie-root"/>
+    <controller type="pci" index="1" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="1" port="0x10"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0" multifunction="on"/>
+    </controller>
+    <controller type="pci" index="2" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="2" port="0x11"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x1"/>
+    </controller>
+    <controller type="pci" index="3" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="3" port="0x12"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x2"/>
+    </controller>
+    <controller type="pci" index="4" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="4" port="0x13"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x3"/>
+    </controller>
+    <controller type="pci" index="5" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="5" port="0x14"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x4"/>
+    </controller>
+    <controller type="pci" index="6" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="6" port="0x15"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x5"/>
+    </controller>
+    <controller type="pci" index="7" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="7" port="0x16"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x6"/>
+    </controller>
+    <controller type="pci" index="8" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="8" port="0x17"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x7"/>
+    </controller>
+    <controller type="pci" index="9" model="pcie-to-pci-bridge">
+      <model name="pcie-pci-bridge"/>
+      <address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/>
+    </controller>
+    <controller type="pci" index="10" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="10" port="0x18"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0" multifunction="on"/>
+    </controller>
+    <controller type="pci" index="11" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="11" port="0x19"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x1"/>
+    </controller>
+    <controller type="pci" index="12" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="12" port="0x1a"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x2"/>
+    </controller>
+    <controller type="scsi" index="0" model="virtio-scsi">
+      <address type="pci" domain="0x0000" bus="0x08" slot="0x00" function="0x0"/>
+    </controller>
+    <controller type="sata" index="0">
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x1f" function="0x2"/>
+    </controller>
+    <controller type="virtio-serial" index="0">
+      <address type="pci" domain="0x0000" bus="0x0c" slot="0x00" function="0x0"/>
+    </controller>
+    <filesystem type="mount" accessmode="passthrough">
+      <driver type="virtiofs"/>
+      <source dir="/home/nemu/Downloads"/>
+      <target dir="nemu_downloads"/>
+      <address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/>
+    </filesystem>
+    <interface type="bridge">
+      <mac address="52:54:00:cc:75:be"/>
+      <source bridge="vmbr0"/>
+      <model type="virtio"/>
+      <link state="up"/>
+      <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
+    </interface>
+    <interface type="bridge">
+      <mac address="52:54:00:b8:8d:30"/>
+      <source bridge="vmbr1"/>
+      <model type="virtio"/>
+      <address type="pci" domain="0x0000" bus="0x07" slot="0x00" function="0x0"/>
+    </interface>
+    <channel type="spicevmc">
+      <target type="virtio" name="com.redhat.spice.0"/>
+      <address type="virtio-serial" controller="0" bus="0" port="1"/>
+    </channel>
+    <input type="mouse" bus="virtio">
+      <address type="pci" domain="0x0000" bus="0x0a" slot="0x00" function="0x0"/>
+    </input>
+    <input type="keyboard" bus="virtio">
+      <address type="pci" domain="0x0000" bus="0x0b" slot="0x00" function="0x0"/>
+    </input>
+    <input type="mouse" bus="ps2"/>
+    <input type="keyboard" bus="ps2"/>
+    <graphics type="spice" port="-1" autoport="no" listen="127.0.0.1">
+      <listen type="address" address="127.0.0.1"/>
+      <image compression="off"/>
+      <gl enable="no"/>
+    </graphics>
+    <sound model="ich9">
+      <audio id="1"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x1b" function="0x0"/>
+    </sound>
+    <audio id="1" type="spice"/>
+    <video>
+      <model type="vga" vram="16384" heads="1" primary="yes">
+        <acceleration accel3d="no"/>
+      </model>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
+    </video>
+    <hostdev mode="subsystem" type="pci" managed="yes">
+      <source>
+        <address domain="0x0000" bus="0x04" slot="0x00" function="0x0"/>
+      </source>
+      <address type="pci" domain="0x0000" bus="0x03" slot="0x00" function="0x0"/>
+    </hostdev>
+    <hostdev mode="subsystem" type="pci" managed="yes">
+      <source>
+        <address domain="0x0000" bus="0x04" slot="0x00" function="0x1"/>
+      </source>
+      <address type="pci" domain="0x0000" bus="0x06" slot="0x00" function="0x0"/>
+    </hostdev>
+    <redirdev bus="usb" type="spicevmc">
+      <address type="usb" bus="0" port="2"/>
+    </redirdev>
+    <redirdev bus="usb" type="spicevmc">
+      <address type="usb" bus="0" port="3"/>
+    </redirdev>
+    <redirdev bus="usb" type="spicevmc">
+      <address type="usb" bus="0" port="4"/>
+    </redirdev>
+    <redirdev bus="usb" type="spicevmc">
+      <address type="usb" bus="0" port="5"/>
+    </redirdev>
+    <watchdog model="itco" action="reset"/>
+    <memballoon model="none"/>
+  </devices>
+  <qemu:commandline>
+    <qemu:arg value="-device"/>
+    <qemu:arg value="{&quot;driver&quot;:&quot;ivshmem-plain&quot;,&quot;id&quot;:&quot;shmem1&quot;,&quot;memdev&quot;:&quot;looking-glass&quot;}"/>
+    <qemu:arg value="-object"/>
+    <qemu:arg value="{&quot;qom-type&quot;:&quot;memory-backend-file&quot;,&quot;id&quot;:&quot;looking-glass&quot;,&quot;mem-path&quot;:&quot;/dev/kvmfr0&quot;,&quot;size&quot;:134217728,&quot;share&quot;:true}"/>
+  </qemu:commandline>
+</domain>
+```
+
+If more logs are needed please just ask. I will gladly provide them.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1879 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1879
new file mode 100644
index 00000000..9abd277a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1879
@@ -0,0 +1,9 @@
+ARM Cortex-A15 Emulation Not Working
+Description of problem:
+I want to make a VM with Windows RT 8.1 but it fails because it can't find a file for the to-emulate ARM CPU.
+Steps to reproduce:
+1. Use virt-manager to make a VM with the ARM architecture.
+2. Make sure the emulated CPU is an ARM Cortex-A15.
+3. Try installing and making the VM, it will fail with the error.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1880 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1880
new file mode 100644
index 00000000..9fb2160f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1880
@@ -0,0 +1,13 @@
+CXL Mem enable error
+Description of problem:
+During the process of booting, the following info indicate that the CXL Mem is not enabled.
+```
+Media not active (-16)
+probe of mem0 failed with error -16
+```
+Steps to reproduce:
+1. Compile Linux kernel v5.18 as shown in the QEMU doc
+2. Run the above-mentioned script
+3. Check the booting script
+Additional information:
+Could you give me some hints of how to operate on the CXL device properly? Thanks a lot.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1881 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1881
new file mode 100644
index 00000000..feee0422
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1881
@@ -0,0 +1,15 @@
+netdev-socket test_stream_unix() is unreliable
+Description of problem:
+test_stream_unix is unreliable and causes random CI job failures such as this one:
+https://gitlab.com/qemu-project/qemu/-/jobs/5020899550
+
+```
+576/839 ERROR:../tests/qtest/netdev-socket.c:293:test_stream_unix: assertion failed (resp == expect): ("st0: index=0,type=stream,connection error\r\n" == "st0: index=0,type=stream,unix:/tmp/netdev-socket.UW5IA2/stream_unix\r\n") ERROR         
+576/839 qemu:qtest+qtest-sh4 / qtest-sh4/netdev-socket                            ERROR          62.85s   killed by signal 6 SIGABRT
+>>> MALLOC_PERTURB_=249 QTEST_QEMU_BINARY=./qemu-system-sh4 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon G_TEST_DBUS_DAEMON=/home/gitlab-runner/builds/-LCfcJ2T/0/qemu-project/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_IMG=./qemu-img /home/gitlab-runner/builds/-LCfcJ2T/0/qemu-project/qemu/build/tests/qtest/netdev-socket --tap -k
+――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
+stderr:
+**
+ERROR:../tests/qtest/netdev-socket.c:293:test_stream_unix: assertion failed (resp == expect): ("st0: index=0,type=stream,connection error\r\n" == "st0: index=0,type=stream,unix:/tmp/netdev-socket.UW5IA2/stream_unix\r\n")
+(test program exited with status code -6)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1882 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1882
new file mode 100644
index 00000000..babf3dc2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1882
@@ -0,0 +1,9 @@
+Test suite hangs on FreeBSD 13.2
+Description of problem:
+The 80 minute timeout for the x64-freebsd-13-build CI job is insufficient:
+https://gitlab.com/qemu-project/qemu/-/jobs/5058610599
+
+```
+672/832 qemu:block / io-qcow2-041              OK             39.77s   1 subtests passed
+Timed out!
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1883 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1883
new file mode 100644
index 00000000..80864432
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1883
@@ -0,0 +1,6 @@
+riscv64-debian-cross-container CI job fails
+Description of problem:
+The riscv64-debian-cross-container job is allowed to fail and has been failing for some time. If it fails all the time then running it is a waste of electricity and the test should be disabled. Or maybe someone familiar with the test can rectify things and get it passing again. Either way, it's time for someone familiar with the test to review it.
+
+Here it a recent CI failure:
+https://gitlab.com/qemu-project/qemu/-/jobs/5058610458
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1884 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1884
new file mode 100644
index 00000000..4a2d2eec
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1884
@@ -0,0 +1,10 @@
+avocado-system-* CI jobs are unreliable
+Description of problem:
+The avocado-system-* CI jobs fail randomly:
+https://gitlab.com/qemu-project/qemu/-/jobs/5058610614  
+https://gitlab.com/qemu-project/qemu/-/jobs/5058610654  
+https://gitlab.com/qemu-project/qemu/-/jobs/5030428571  
+
+I don't know how to interpret the test output. Until these CI jobs pass reliably it won't be possible for me to identify when a subtest that is actually healthy/reliable breaks.
+
+Please take a look at the logs and fix or remove unreliable test cases.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1885 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1885
new file mode 100644
index 00000000..02086fc2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1885
@@ -0,0 +1,24 @@
+mipsel malta machine is broken in avocado console tests
+Description of problem:
+As noted in #1884 we see failures of the boot_linux_console.py test. Unlikely other avocado failures, these ones are consistent and reproduce locally with 100% success
+
+```
+./configure --target-list=mipsel-softmmu
+make -j 20
+cd build
+./pyvenv/bin/python3 -B -m avocado --show=app run --job-results-dir=./tests/results -t arch:mipsel --failfast tests/avocado/boot_linux_console.py:BootLinuxConsole.test_mips_malta32el_nanomips_4k
+```
+
+This test will reliably fail with a timeout waiting for console output.
+
+Attempting to run the QEMU command manually
+
+```
+$ ./qemu-system-mipsel -display none -vga none -machine malta -chardev stdio,id=console -serial chardev:console -cpu I7200 -no-reboot -kernel /home/berrange/src/virt/qemu/build/tests/results/job-2023-09-13T17.14-77de093/test-results/tmp_dir520smana/1-tests_avocado_boot_linux_console.py_BootLinuxConsole.test_mips_malta32el_nanomips_4kkernel -append 'printk.time=0 mem=256m@@0x0 console=ttyS0'
+```
+
+results in no serial console output at all.
+
+IMHO either the MIPS malta machine has had a regression, or the kernel we're downloading for testing has had a regression.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1886 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1886
new file mode 100644
index 00000000..ccfe07b4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1886
@@ -0,0 +1,17 @@
+migration-test is unreliable
+Description of problem:
+The following intermittent failure occurred in the CI:
+
+```
+>>> QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=116 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_BINARY=./qemu-system-x86_64 /builds/qemu-project/qemu/build/tests/qtest/migration-test --tap -k
+――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
+stderr:
+qemu-system-x86_64: Unable to read from socket: Connection reset by peer
+Memory content inconsistency at 5b43000 first_byte = bd last_byte = bc current = 4f hit_edge = 1
+**
+ERROR:../tests/qtest/migration-test.c:300:check_guests_ram: assertion failed: (bad == 0)
+(test program exited with status code -6)
+```
+  
+You can find the full output here:
+https://gitlab.com/qemu-project/qemu/-/jobs/5080200417
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1887 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1887
new file mode 100644
index 00000000..7f198bb6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1887
@@ -0,0 +1,9 @@
+Window VM failed to resume when using GPU passthrough(GVT-d) on Intel platform if add 'hv-stimer' option, seems like it happened after V6.2.0
+Description of problem:
+Windows VM failed to be resumed if adding 'hv-stimer' after Qemu v6.2.0.
+Steps to reproduce:
+1.Set up GVTd env and launch Windows 10 VM as guest;
+2. Sleep the Windows VM with Sleep button;
+3. Resume Windows VM via telnet to qemu ,e.g.,'telnet 127.0.0.1 2222', then input 'system_wakeup' to resume Windows VM.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1888 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1888
new file mode 100644
index 00000000..d91223c4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1888
@@ -0,0 +1,12 @@
+megasas: Buffer I/O error on dev sda / critical target error, dev sda, sector 0 op 0x0:(READ)
+Description of problem:
+Since QEMU 7.2.0 when using `megasas` device the guest kernel is unable to I/O with the device (Input/output error) also producing errors messages in `dmesg` like these:
+```
+[   18.739344] critical target error, dev sda, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
+[   18.739925] Buffer I/O error on dev sda, logical block 0, async page read
+[   18.740374] Dev sda: unable to read RDB block 0
+```
+
+Relevant options are: `-device megasas -blockdev driver=null-co,read-zeroes=on,node-name=null -device scsi-hd,drive=null` then in guest `modprobe megaraid-sas`. With qcow2 images - errors are the same.
+
+I also tested that the same commands produce no errors on QEMU 6.0.0 - 7.1.0.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1889 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1889
new file mode 100644
index 00000000..ecf5eb93
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1889
@@ -0,0 +1,47 @@
+IO delays on live migration lv initialization
+Description of problem:
+Hi,
+
+When I live migrate a VM via Proxmox and the destination is an LVM thin pool I see that at the start of copying the disk it's first initialized.
+
+This leads the thin volume to be directly 100% allocated which needs to be discarded afterwards. Not ideal but ....
+
+The more annoying thing is that this initialization step used 100% of disk IO. In iotop I see it writing over 1000MB/sec. The nasty side effect is that other VM's on that host are negatively affected. It's not completely locked up, I can ssh in and look around, but storage intensive things see more delay. With e.g. http requests timing out. And even a simple ls command could take 10+ seconds which is normally instant.
+
+
+I've previously reported it on the [proxmox forum](https://forum.proxmox.com/threads/io-delays-on-live-migration-lv-initialization.132296/#post-582050) but the call was made that this is behavior from Qemu.
+
+> The zeroing happens, because of what QEMU does when the discard option is enabled:
+
+
+When I disable discard for the VM disk I can see that it's not pre-initialized during migration, but not having that defeats the purpose of having an lvm thin pool.
+
+For the (disk) migration itself I can set a bandwidth limit ... could we do something similar for initialization?
+
+
+Even better would be to not initialize at all when using LVM thin. As far as I understand it the new blocks allocated by lvm thin should always be empty.
+Steps to reproduce:
+1. Migrate a vm with a large disk
+2. look in iotop on the new host, would be see more write IO then the network could handle.. just before the disk content is transferred.
+3. look in another VM on the destination host, reading from disk would be significantly slower then normal.
+Additional information:
+An example VM config
+```
+agent: 1,fstrim_cloned_disks=1
+balloon: 512
+bootdisk: scsi0
+cores: 6
+ide2: none,media=cdrom
+memory: 8196
+name: ...
+net0: virtio=...,bridge=...
+numa: 0
+onboot: 1
+ostype: l26
+scsi0: thin_pool_hwraid:vm-301-disk-0,discard=on,format=raw,size=16192M
+scsi1: thin_pool_hwraid:vm-301-disk-1,discard=on,format=raw,size=26G
+scsihw: virtio-scsi-pci
+serial0: socket
+smbios1: uuid=...
+sockets: 1
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1892 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1892
new file mode 100644
index 00000000..dd8fabd8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1892
@@ -0,0 +1,33 @@
+docs/system/devices/cxl.rst suggests qemu-system-aarch64 command lines which fail with "Property 'virt-8.2-machine.cxl' not found"
+Description of problem:
+When trying to run qemu-system-aarch64 with "-M virt,gic-version=3,cxl=on -m 4g,maxmem=8G,slots=8 -cpu max", get the following problem:
+"qemu-system-aarch64: Property 'virt-8.2-machine.cxl' not found". Do I need to compile the QEMU with specific option?
+Steps to reproduce:
+1. Compile QEMU with "./config" "make -j6"
+2. Compile Linux
+```
+#!/bin/bash
+
+KERNEL_PATH=/users/LiuQun/linux/arch/arm64/boot/Image
+DISK_IMG=/users/LiuQun/ARM_img/disk-image-22.04-server-arm64.img
+
+./build/qemu-system-aarch64 \
+-M virt,gic-version=3,cxl=on -m 4g,maxmem=8G,slots=8 -cpu max \
+-bios /users/LiuQun/ARM_img/QEMU_EFI.fd \
+-kernel $KERNEL_PATH \
+-drive file=$DISK_IMG,format=raw,if=none,id=drive-sata0-0-0 \
+-device virtio-blk-device,drive=drive-sata0-0-0 \
+-append "console=ttyAMA0 root=/dev/vda1 rdinit=/init acpi=off" \
+-object memory-backend-file,id=cxl-mem1,share=on,mem-path=cxl-window1,size=512M \
+-object memory-backend-file,id=cxl-label1,share=on,mem-path=cxl-label1,size=1K \
+-object memory-backend-file,id=cxl-label2,share=on,mem-path=cxl-label2,size=1K \
+-device pxb-cxl,id=cxl.0,bus=pcie.0,bus_nr=52,uid=0,len-window-base=1,window-base[0]=0x4c00000000,memdev[0]=cxl-mem1 \
+-device cxl-rp,id=rp0,bus=cxl.0,addr=0.0,chassis=0,slot=0,port=0 \
+-device cxl-rp,id=rp1,bus=cxl.0,addr=1.0,chassis=0,slot=1,port=1 \
+-device cxl-type3,bus=rp0,memdev=cxl-mem1,id=cxl-pmem0,size=256M,lsa=cxl-label1 \
+-device cxl-type3,bus=rp1,memdev=cxl-mem1,id=cxl-pmem1,size=256M,lsa=cxl-label2 \
+-nographic
+
+```
+Additional information:
+The same problem happens with QEMU 8.1
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1893 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1893
new file mode 100644
index 00000000..2e92849c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1893
@@ -0,0 +1,13 @@
+assert on savevm
+Description of problem:
+
+Steps to reproduce:
+1. launch as above (n.b. qemu-img command: qemu-img create -f qcow2 rootfs.qcow2 60G
+2. from qemu monitor: savevm test
+3. On stderr
+
+```
+Assertion failed: (qemu_get_current_aio_context() == qemu_get_aio_context()), function bdrv_poll_co, file block-gen.h, line 43.
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1894 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1894
new file mode 100644
index 00000000..3aa706d5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1894
@@ -0,0 +1,11 @@
+Can't emulate audio with OpenCore Mac OS X 10.7
+Description of problem:
+OpenCore wants me to use `AppleALC`, but to use _that_, I need the layout ID of the motherboard or something and I'm not sure how I'd do that since it's a QEMU VM. All I want to do is have some audio :(
+
+So, how can I emulate audio with AppleALC + OpenCore/how can I get a layout ID that'll give me audio on a QEMU VM? Do note that I am using UTM (https://getutm.app/) (UTM uses QEMU and is basically a QEMU frontend).
+Steps to reproduce:
+1. Set up OpenCore and install Mac OS X 10.7
+2. Copy across a .mp3 file
+3. iTunes fails to play it due to no audio drivers/audio outputs
+Additional information:
+N/A
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1896 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1896
new file mode 100644
index 00000000..1bd81bc1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1896
@@ -0,0 +1,54 @@
+Use `qemu_exit()` function instead of `exit()`
+Additional information:
+I just saw the similar refactoring for the GDB part of QEMU and thought it might be useful in more general case too: https://lore.kernel.org/qemu-devel/20230907112640.292104-1-chigot@adacore.com/T/#m540552946cfa960b34c4d76d2302324f5de8627f
+
+```
+$ rg "exit\(0" -t c -l
+gdbstub/gdbstub.c
+qemu-edid.c
+subprojects/libvhost-user/libvhost-user.c
+semihosting/arm-compat-semi.c
+softmmu/async-teardown.c
+softmmu/device_tree.c
+softmmu/vl.c
+softmmu/runstate.c
+os-posix.c
+dtc/util.c
+dtc/dtc.c
+dtc/tests/dumptrees.c
+qemu-keymap.c
+qemu-io.c
+contrib/ivshmem-server/main.c
+contrib/rdmacm-mux/main.c
+tests/qtest/vhost-user-blk-test.c
+tests/qtest/fuzz/fuzz.c
+tests/qtest/fuzz/generic_fuzz.c
+tests/unit/test-seccomp.c
+tests/unit/test-rcu-list.c
+tests/unit/rcutorture.c
+tests/bench/qht-bench.c
+tests/bench/atomic64-bench.c
+tests/bench/atomic_add-bench.c
+tests/unit/test-iov.c
+tests/tcg/multiarch/linux/linux-test.c
+tests/tcg/aarch64/mte-3.c
+tests/tcg/aarch64/pauth-2.c
+tests/tcg/aarch64/mte-5.c
+tests/tcg/aarch64/mte-6.c
+tests/tcg/aarch64/mte-2.c
+tests/tcg/cris/libc/check_glibc_kernelversion.c
+tests/tcg/cris/libc/check_lz.c
+tests/tcg/s390x/signals-s390x.c
+tests/tcg/i386/hello-i386.c
+tests/tcg/cris/bare/sys.c
+tests/tcg/ppc64/mtfsf.c
+qemu-nbd.c
+net/net.c
+hw/nvram/eeprom93xx.c
+hw/arm/allwinner-r40.c
+hw/rdma/rdma_backend.c
+hw/watchdog/watchdog.c
+trace/control.c
+hw/pci/pci.c
+hw/misc/sifive_test.c
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1897 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1897
new file mode 100644
index 00000000..8f53876c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1897
@@ -0,0 +1,21 @@
+npcm7xx_timer-test.c is unreliable
+Description of problem:
+Sometimes npcm7xx_timer-test fails intermittently:
+https://gitlab.com/qemu-project/qemu/-/jobs/5121787250
+
+```
+38/96 qemu:qtest+qtest-arm / qtest-arm/npcm7xx_timer-test           ERROR           0.95s   exit status 1
+>>> QTEST_QEMU_BINARY=./qemu-system-arm QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=103 /builds/qemu-project/qemu/build/tests/qtest/npcm7xx_timer-test --tap -k
+――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
+stderr:
+**
+ERROR:../tests/qtest/npcm7xx_timer-test.c:475:test_periodic_interrupt: assertion failed (tim_read(td, TISR) == tim_timer_bit(td)): (0x00000000 == 0x00000004)
+**
+ERROR:../tests/qtest/npcm7xx_timer-test.c:476:test_periodic_interrupt: 'qtest_get_irq(global_qtest, tim_timer_irq(td))' should be TRUE
+(test program exited with status code 1)
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+```
+
+When I reran the CI job, it passed.
+
+Please investigate why this test is unreliable and fix it. Thanks!
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1898 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1898
new file mode 100644
index 00000000..f83309bb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1898
@@ -0,0 +1,32 @@
+Ninja makeserver support
+Description of problem:
+Building `qemu` using a patched version of `ninja`[0] to utilize `make`'s jobserver feature doesn't work when building `qemu`. Usually, when using a jobserver to control the number of jobs being built in parallel across multiple different builds (i.e. when building with `open-embedded` or `buildroot`), the `-j$(nproc)` argument is left out. In this case, the `Qemu` `Makefile` interprets the absent `-j` argument as a wish for a single process only, and adds a `-j1` argument to the `ninja` call.
+Steps to reproduce:
+1. Built/install the patched `ninja` from [0]: `export PATH=<path/to/ninja>:$PATH`
+2. Start the attached [jobserver.py](/uploads/8215e8a470c97cd456d2d14e2c71c6a5/jobserver.py) script: `python jobserver.py /tmp/jobserver 4`
+3. Configure `qemu`: `mkdir build; ../configure`
+4. Build `qemu`: `MAKEFLAGS="--jobserver-auth=fifo:/tmp/jobserver" make`
+5. Observe that only a single CPU/core is being used.
+
+Now, to avoid passing `-j1` to `ninja`, remove filtering of `-j` arguments from the `Makefile`:
+
+```patch
+diff --git a/Makefile b/Makefile
+index bfc4b2c8e9..d66141787e 100644
+--- a/Makefile
++++ b/Makefile
+@@ -142,7 +142,6 @@ MAKE.k = $(findstring k,$(firstword $(filter-out --%,$(MAKEFLAGS))))
+ MAKE.q = $(findstring q,$(firstword $(filter-out --%,$(MAKEFLAGS))))
+ MAKE.nq = $(if $(word 2, $(MAKE.n) $(MAKE.q)),nq)
+ NINJAFLAGS = $(if $V,-v) $(if $(MAKE.n), -n) $(if $(MAKE.k), -k0) \
+-        $(filter-out -j, $(lastword -j1 $(filter -l% -j%, $(MAKEFLAGS)))) \
+         -d keepdepfile
+ ninja-cmd-goals = $(or $(MAKECMDGOALS), all)
+ ninja-cmd-goals += $(foreach g, $(MAKECMDGOALS), $(.ninja-goals.$g))
+```
+
+Run the build again, and see four jobs being run in parallel:
+
+`make clean; MAKEFLAGS="--jobserver-auth=fifo:/tmp/jobserver" make`
+Additional information:
+[0] https://github.com/stefanb2/ninja/tree/topic-issue-1139-part-3-jobserver-fifo
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/190 b/gitlab/issues_text/target_missing/host_missing/accel_missing/190
new file mode 100644
index 00000000..484fb04d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/190
@@ -0,0 +1 @@
+'set_link net0 off' not working with e1000e driver
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1900 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1900
new file mode 100644
index 00000000..a68e7764
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1900
@@ -0,0 +1 @@
+8.1.0-r1: segfault at get_zones_wp() at ../block/file-posix.c:1337
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1902 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1902
new file mode 100644
index 00000000..ee1a5eb5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1902
@@ -0,0 +1,65 @@
+Crash on macOS when screen resolution changes when using SDL UI frontend
+Description of problem:
+In the above configuration, booting NetBSD works fine up to the point where the kernel sets the framebuffer resolution for the console, which results in a window size change. At this point, the OS terminates the qemu process with this error message:
+
+```
+*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow geometry should only be modified on the main thread!'
+*** First throw call stack:
+(
+	0   CoreFoundation                      0x00000001849208c0 __exceptionPreprocess + 176
+	1   libobjc.A.dylib                     0x0000000184419eb4 objc_exception_throw + 60
+	2   CoreFoundation                      0x0000000184945bac _CFBundleGetValueForInfoKey + 0
+	3   AppKit                              0x00000001880a6ab8 -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 240
+	4   AppKit                              0x00000001880b2a38 -[NSThemeFrame _tileTitlebarAndRedisplay:] + 88
+	5   AppKit                              0x00000001880c18a0 -[NSTitledFrame _titleDidChange] + 116
+	6   AppKit                              0x0000000188a92f04 -[NSTitledFrame setTitle:subtitle:] + 420
+	7   AppKit                              0x00000001880c1570 -[NSThemeFrame setTitle:] + 52
+	8   AppKit                              0x000000018866e0fc -[NSFrameView _updateTitleProperties:animated:] + 44
+	9   AppKit                              0x0000000188a85e98 -[NSThemeFrame _updateTitleProperties:animated:] + 156
+	10  CoreFoundation                      0x00000001848a0780 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148
+	11  CoreFoundation                      0x00000001849349a8 ___CFXRegistrationPost_block_invoke + 88
+	12  CoreFoundation                      0x00000001849348f0 _CFXRegistrationPost + 440
+	13  CoreFoundation                      0x000000018486f434 _CFXNotificationPost + 764
+	14  Foundation                          0x0000000185960c74 -[NSNotificationCenter postNotificationName:object:userInfo:] + 88
+	15  AppKit                              0x000000018881da88 -[NSWindowTitleController _propertiesChanged:] + 128
+	16  AppKit                              0x00000001880c1388 -[NSWindow _dosetTitle:andDefeatWrap:] + 156
+	17  libSDL2-2.0.0.dylib                 0x0000000106aa9abc Cocoa_SetWindowTitle + 104
+	18  qemu-system-aarch64                 0x0000000105006628 sdl_update_caption + 256
+	19  qemu-system-aarch64                 0x0000000105007838 sdl_mouse_mode_change + 168
+	20  qemu-system-aarch64                 0x00000001054ab100 notifier_list_notify + 36
+	21  qemu-system-aarch64                 0x0000000104d28124 qemu_input_check_mode_change + 96
+	22  qemu-system-aarch64                 0x0000000104e13a74 hid_pointer_activate + 32
+	23  qemu-system-aarch64                 0x0000000104f44c2c usb_process_one + 464
+	24  qemu-system-aarch64                 0x0000000104f4491c usb_handle_packet + 120
+	25  qemu-system-aarch64                 0x0000000104f58a94 xhci_kick_epctx + 1888
+	26  qemu-system-aarch64                 0x00000001052d8f78 memory_region_write_accessor + 264
+	27  qemu-system-aarch64                 0x00000001052d8db8 access_with_adjusted_size + 348
+	28  qemu-system-aarch64                 0x00000001052d8c04 memory_region_dispatch_write + 428
+	29  qemu-system-aarch64                 0x00000001052e6cfc flatview_write_continue + 344
+	30  qemu-system-aarch64                 0x00000001052e4068 flatview_write + 156
+	31  qemu-system-aarch64                 0x00000001052e9424 subpage_write + 124
+	32  qemu-system-aarch64                 0x00000001052d8db8 access_with_adjusted_size + 348
+	33  qemu-system-aarch64                 0x00000001052d8c04 memory_region_dispatch_write + 428
+	34  qemu-system-aarch64                 0x000000010532ebf4 io_writex + 184
+	35  qemu-system-aarch64                 0x000000010532ed44 do_st_mmio_leN + 104
+	36  qemu-system-aarch64                 0x0000000105323e78 do_st4_mmu + 536
+	37  ???                                 0x0000000108a91750 0x0 + 4440266576
+	38  qemu-system-aarch64                 0x00000001053108f0 cpu_tb_exec + 164
+	39  qemu-system-aarch64                 0x0000000105311754 cpu_exec_loop + 1084
+	40  qemu-system-aarch64                 0x0000000105310edc cpu_exec_setjmp + 48
+	41  qemu-system-aarch64                 0x0000000105310dcc cpu_exec + 560
+	42  qemu-system-aarch64                 0x0000000105332650 tcg_cpus_exec + 44
+	43  qemu-system-aarch64                 0x0000000105332c1c mttcg_cpu_thread_fn + 240
+	44  qemu-system-aarch64                 0x00000001054a7494 qemu_thread_start + 128
+	45  libsystem_pthread.dylib             0x00000001847cf034 _pthread_start + 136
+	46  libsystem_pthread.dylib             0x00000001847c9e3c thread_start + 8
+)
+libc++abi: terminating due to uncaught exception of type NSException
+```
+
+I think there have been other bugs of a similar nature in the past with the Cocoa UI. The regression may be because of stricter checks in the new macOS version.
+Steps to reproduce:
+1. Start qemu (the QEMU_EFI.fd is from Tianocore EDK2).
+2. Wait for the NetBSD kernel to set framebuffer resolution and observe the crash.
+
+With `-nographic`, the problem does not occur.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1903 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1903
new file mode 100644
index 00000000..65effad9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1903
@@ -0,0 +1,41 @@
+qemu/kvm are instantly SIGKILLed by systemd on shutdown, without wait.
+Description of problem:
+systemd assumes it cannot terminate qemu, and SIGKILLs it. Instantly.
+Steps to reproduce:
+1. Start qemu on a systemd managed host
+2. Shutdown/Reboot
+Additional information:
+Nothing on qemu's own log, besides that it is starting a vnc server.
+
+```plaintext
+# journalctl -b -1
+...
+Sep 22 18:38:04 local kernel: kvm_amd: TSC scaling supported
+Sep 22 18:38:04 local kernel: kvm_amd: Nested Virtualization enabled
+Sep 22 18:38:04 local kernel: kvm_amd: Nested Paging enabled
+Sep 22 18:38:04 local kernel: kvm_amd: Virtual VMLOAD VMSAVE supported
+Sep 22 18:38:04 local kernel: kvm_amd: Virtual GIF supported
+Sep 22 18:38:04 local kernel: kvm_amd: LBR virtualization supported
+...
+Sep 22 18:38:50 local systemd-logind[721]: The system will reboot now!
+Sep 22 18:38:50 local systemd-logind[721]: System is rebooting.
+Sep 22 18:38:50 local sddm-helper[850]: Signal received: SIGTERM
+...
+Sep 22 18:38:50 local systemd[1]: Stopping User Manager for UID 1000...
+Sep 22 18:38:50 local systemd-logind[721]: Removed session 1.
+Sep 22 18:38:50 local systemd[854]: Activating special unit Exit the Session...
+Sep 22 18:38:50 local systemd[854]: app-org.kde.konsole-1ab3dac6a1db4b29b55899b477b32975.scope: Failed to kill control group /user.slice/user-1000.slice/user@1000.service/app.slice/>
+Sep 22 18:38:50 local systemd[854]: app-org.kde.konsole-1ab3dac6a1db4b29b55899b477b32975.scope: Killing process 1708 (qemu-system-x86) with signal SIGKILL.
+Sep 22 18:38:50 local systemd[854]: app-org.kde.konsole-1ab3dac6a1db4b29b55899b477b32975.scope: Killing process 1712 (kvm-nx-lpage-recovery-1708) with signal SIGKILL.
+Sep 22 18:38:50 local systemd[854]: app-org.kde.konsole-1ab3dac6a1db4b29b55899b477b32975.scope: Failed to kill control group /user.slice/user-1000.slice/user@1000.service/app.slice/>
+Sep 22 18:38:50 local systemd[854]: Stopped Konsole - Terminal.
+... (some other applications terminanting normally )
+Sep 22 18:38:50 local systemd[854]: app-org.kde.konsole-1ab3dac6a1db4b29b55899b477b32975.scope: Consumed 10.068s CPU time.
+Sep 22 18:38:50 local systemd[854]: Removed slice User Background Tasks Slice.
+Sep 22 18:38:50 local systemd[854]: background.slice: Consumed 2.960s CPU time.
+...
+```
+
+I cannot explain why it sends SIGKILL to qemu/kvm... it is the same second as the shutdown started, their docs says there's a delay for that.
+
+Also, other processes owned by the user received a single SIGTERM after qemu was SIGKILLed. Some even take a couple seconds to exit and are not SIGKILLed.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1904 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1904
new file mode 100644
index 00000000..4b9c20e2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1904
@@ -0,0 +1,16 @@
+Windows LTO build fails
+Description of problem:
+LTO likes to delete `win32_close_exception_handler` which causes an error when linking
+```
+[2736/5786] Linking target qemu-system-avr.exe
+FAILED: qemu-system-avr.exe
+"cc" "-m64" "-mcx16" @qemu-system-avr.exe.rsp
+`win32_close_exception_handler' referenced in section `.xdata' of C:\msys64\tmp\cceRwR4N.ltrans59.ltrans.o: defined in discarded section `.text' of libqemuutil.a.p/util_oslib-win32.c.obj (symbol from plugin)
+collect2.exe: error: ld returned 1 exit status
+```
+Steps to reproduce:
+1. `./configure --enable-lto`
+2. `make`
+Additional information:
+Looks like the offending commit is d89f30b4df13dfe389a4d6cf8a30b2f87c4c166e "win32: wrap socket close() with an exception handler".
+Undoing the commit or marking the exception handler as `__attribute__ ((noinline, used))` both appear to fix the issue.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1905 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1905
new file mode 100644
index 00000000..61c0907b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1905
@@ -0,0 +1,3 @@
+Allow for copying text from serial output
+Additional information:
+In addition to the serial output, it would be beneficial if this copy feature could also be extended to the QEMU monitor and parallel output.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1906 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1906
new file mode 100644
index 00000000..5198e5bb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1906
@@ -0,0 +1,34 @@
+Failed to compile QEMU 7.0.0 source code.  recipe for target 'run-ninja' failed.
+Description of problem:
+Failed to compiling the download QEMU 7.0.0 source code. It seems to be due to something wrong with ninja.
+The followings are error logs after executing command "make -j$(nproc)":
+
+changing dir to build for make ""...  
+make[1]: Entering directory '/home/liangke/os-env/qemu-7.0.0/build'  
+/usr/bin/ninja  build.ninja && touch build.ninja.stamp  
+**ninja: no work to do.**  
+...  
+...  
+...  
+[1350/2396] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o  
+**FAILED: libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o**  
+cc -m64 -mcx16 -Ilibqemu-riscv64-softmmu.fa.p -I. -I.. -Itarget/riscv -I../target/riscv -I../dtc/libfdt -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/liangke/os-env/qemu-7.0.0/linux-headers -isystem linux-headers -iquote . -iquote /home/liangke/os-env/qemu-7.0.0 -iquote /home/liangke/os-env/qemu-7.0.0/include -iquote /home/liangke/os-env/qemu-7.0.0/disas/libvixl -iquote /home/liangke/os-env/qemu-7.0.0/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=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-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 -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="riscv64-softmmu-config-target.h"' '-DCONFIG_DEVICES="riscv64-softmmu-config-devices.h"' -MD -MQ libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o -MF libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o.d -o libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o -c ../target/riscv/translate.c  
+**cc: fatal error: Killed signal terminated program cc1**  
+**compilation terminated.**  
+**ninja: build stopped: subcommand failed.**  
+**Makefile:163: recipe for target 'run-ninja' failed**  
+**make[1]: *** [run-ninja] Error 1**  
+make[1]: Leaving directory '/home/liangke/os-env/qemu-7.0.0/build'  
+**GNUmakefile:10: recipe for target 'all' failed**  
+**make: *** [all] Error 2**
+Steps to reproduce:
+1. cd qemu-7.0.0 source code folder;
+2. ./configure --target-list=riscv64-softmmu,riscv64-linux-user;
+3. make -j$(nproc)
+Additional information:
+1. I downloaded the source code from https://download.qemu.org/qemu-7.0.0.tar.xz.
+2. my compiling prerequisites:
+sudo apt install autoconf automake autotools-dev curl libmpc-dev libmpfr-dev libgmp-dev \
+              gawk build-essential bison flex texinfo gperf libtool patchutils bc ninja-build \
+              zlib1g-dev libexpat-dev pkg-config  libglib2.0-dev libpixman-1-dev git tmux python3
+3. Found ninja-1.8.2 at /usr/bin/ninja
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1907 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1907
new file mode 100644
index 00000000..4691d56f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1907
@@ -0,0 +1,57 @@
+QEMU LoongArch regression after merging LASX changes
+Description of problem:
+After enabling LASX in qemu (@gaosong), booting Gentoo Linux with latest glibc master (w/ LSX & LASX optimized libc routines) will fail in systemd:
+
+```
+[   10.350207] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000085
+[   10.350557] CPU: 5 PID: 1 Comm: systemd Not tainted 6.5.2-gentoo #2
+[   10.350655] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
+[   10.350961] Stack : 0072617764726148 0000000000000000 9000000000223440 90000001000e4000
+[   10.351181]         90000001000e7990 90000001000e7998 0000000000000000 90000001000e7ad8
+[   10.351294]         90000001000e7ad0 90000001000e7ad0 90000001000e7900 0000000000000001
+[   10.351406]         0000000000000001 90000001000e7998 ec94a2e1446052e6 9000000100438140
+[   10.351519]         0000000000000001 0000000000000003 0000000000000000 0000000000000030
+[   10.351630]         0000000000000000 00000000000559bf 00000000056e0000 0000000000000004
+[   10.351745]         0000000000000000 0000000000000000 900000000162b438 900000000177e000
+[   10.351856]         00000000400004d8 0000000000000001 0000000000000018 90000001000e7c84
+[   10.351968]         0000000000020000 0000000000000000 9000000000223458 00007ffff0341af0
+[   10.352081]         00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c
+[   10.352196]         ...
+[   10.352277] Call Trace:
+[   10.352482] [<9000000000223458>] show_stack+0x5c/0x180
+[   10.353518] [<9000000001178d4c>] dump_stack_lvl+0x60/0x88
+[   10.353592] [<900000000115cd7c>] panic+0x13c/0x308
+[   10.353670] [<900000000024244c>] do_exit+0x860/0x868
+[   10.353735] [<900000000024261c>] do_group_exit+0x34/0x94
+[   10.353803] [<9000000000250514>] get_signal+0x75c/0x804
+[   10.353869] [<90000000002254c4>] arch_do_signal_or_restart+0x74/0xae0
+[   10.353944] [<90000000002c738c>] exit_to_user_mode_loop.isra.0+0x90/0x10c
+[   10.354041] [<9000000001179ff0>] irqentry_exit_to_user_mode+0x1c/0x28
+[   10.354119] [<90000000011792f8>] do_bp+0xcc/0x2ac
+[   10.354222] [<90000001005a1924>] 0x90000001005a1924
+[   10.354522] [<00007ffff0341af0>] 0x7ffff0341af0
+```
+
+Full log:
+
+[stderr](/uploads/61b9870ae2441c9a25f44791c67889b8/stderr)
+
+Instruction trace `-d in_asm,out_asm,op` (very large):
+
+[log.tar.zstd](https://cloud.tsinghua.edu.cn/f/a83eac6d44694ede8cb1/?dl=1)
+
+I also tried to boot LoongArchLinux whose glibc does not have LSX/LASX optimized C routines, and it can boot without problems. If I chroot from LoongArchLinux into Gentoo Linux, running `emerge` command will SIGSEGV.
+
+If I disable LASX in CPUCFG2, the problem is gone:
+
+```cpp
+//     data = FIELD_DP32(data, CPUCFG2, LASX, 1),
+```
+
+I guess the bug is related to LASX assemblies in [glibc](https://github.com/bminor/glibc/tree/master/sysdeps/loongarch/lp64/multiarch).
+Steps to reproduce:
+1. Launch qemu
+2. Wait for systemd to be killed
+3. Collect logs
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1914 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1914
new file mode 100644
index 00000000..9e10aa31
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1914
@@ -0,0 +1,7 @@
+x86 q35 machine type documentation is missing
+Description of problem:
+The x86 machine type of q35 was added in 2012 by commit
+df2d8b3ed4d2 ("q35: Introduce q35 pc based chipset emulator")
+but no documentation was added to docs/master/system/target-i386.html
+Additional information:
+There was development documentation at https://wiki.qemu.org/Features/Q35
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1915 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1915
new file mode 100644
index 00000000..e0f91d67
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1915
@@ -0,0 +1,11 @@
+whpx causes a blue screen on guest windows
+Description of problem:
+i wanted to install windows 7 with qemu, but qunad i tried i got a blue screen . Then I downgraded to version 5.0.2 and it worked perfectly, I also tried with windows 10 and it didn't boot.
+
+![image](/uploads/3b69a76f8b23ae49652b010b1ae31d83/image.png)
+Steps to reproduce:
+1. install windows 7 iso
+2. run the setup 
+3. and the bsod..
+Additional information:
+I tried it with qemu 5.0.2 and it worked perfectly.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1918 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1918
new file mode 100644
index 00000000..2166b756
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1918
@@ -0,0 +1,49 @@
+Build failure on FreeBSD 13.2-RELEASE-p3 amd64 with --vhost-user
+Description of problem:
+- Assumption that the python interpreter is in PATH as `python3`
+- Attempt to include Linux headers on a FreeBSD system
+Steps to reproduce:
+1. `$ ./configure --prefix=/opt/qemu --enable-vhost-user` (log attached below)
+2. `$ ninja -C build`
+3. See it running a python script without an explicit python interpreter
+4. Work around by invoking the python script through the interpreter that meson found:
+
+```diff
+diff --git a/ui/meson.build b/ui/meson.build
+index 0a1e8272a3..c6456f54c4 100644
+--- a/ui/meson.build
++++ b/ui/meson.build
+@@ -81,7 +81,7 @@ if dbus_display
+                       input: 'dbus-display1.xml',
+                       output: 'dbus-display1.xml',
+                       env: env,
+-                      command: [xml_pp, '@INPUT@', '@OUTPUT@'])
++                      command: [python, xml_pp, '@INPUT@', '@OUTPUT@'])
+   dbus_display1 = custom_target('dbus-display gdbus-codegen',
+                                 output: ['dbus-display1.h', 'dbus-display1.c'],
+                                 input: xml,
+
+```
+
+5. Then fails trying to include a Linux header:
+
+```console
+/usr/bin/cc -m64 -mcx16 -Ilibcommon.fa.p -I../common-user/host/x86_64 -I../bsd-user/include -Isubprojects/dtc/libfdt -I../subprojects/dtc/libfdt -Iui -I../ui -I/usr/local/include/capstone -I/usr/local/include/pixman-1 -I/usr/local/include/l
+ibpng16 -I/usr/local/include -I/usr/local/include/p11-kit-1 -I/usr/local/include/SDL2 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/gio-unix-2.0 -I/usr/local/include/slirp -I/usr/local/include/gtk-3.0 
+-I/usr/local/include/pango-1.0 -I/usr/local/include/harfbuzz -I/usr/local/include/freetype2 -I/usr/local/include/fribidi -I/usr/local/include/cairo -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/libepoll-shim -I/usr/local/include/
+atk-1.0 -I/usr/local/include/at-spi2-atk/2.0 -I/usr/local/include/at-spi-2.0 -I/usr/local/include/dbus-1.0 -I/usr/local/lib/dbus-1.0/include -I/usr/local/include/vte-2.91 -I/usr/local/include/webp -fcolor-diagnostics -Wall -Winvalid-pch -st
+d=gnu11 -O2 -g -fstack-protector-strong -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wn
+ested-externs -Wendif-labels -Wexpansion-to-defined -Wmissing-format-attribute -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compar
+e -Wno-psabi -Wno-gnu-variable-sized-type-not-at-end -Wthread-safety -iquote . -iquote /usr/home/nico/build/qemu -iquote /usr/home/nico/build/qemu/include -iquote /usr/home/nico/build/qemu/host/include/x86_64 -iquote /usr/home/nico/build/qe
+mu/host/include/generic -iquote /usr/home/nico/build/qemu/tcg/i386 -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -fPIE -DAVIF_DLL -DHWY_SHARED_DEFINE -D_REENTRANT -D_THREAD_SAFE -
+MD -MQ libcommon.fa.p/hw_net_vhost_net.c.o -MF libcommon.fa.p/hw_net_vhost_net.c.o.d -o libcommon.fa.p/hw_net_vhost_net.c.o -c ../hw/net/vhost_net.c
+In file included from ../hw/net/vhost_net.c:37:
+/usr/home/nico/build/qemu/linux-headers/linux/vhost.h:14:10: fatal error: 'linux/vhost_types.h' file not found
+#include <linux/vhost_types.h>
+         ^~~~~~~~~~~~~~~~~~~~~
+```
+
+I don't know what that is about. Full build log is attached below.
+Additional information:
+[config_log](/uploads/49d1c33d4b3951f79f826a701ceff1c2/config_log)
+[build_log_fail](/uploads/2cb3b49e7503a430457c4d99b1c60dbe/build_log_fail)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1923 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1923
new file mode 100644
index 00000000..c444722a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1923
@@ -0,0 +1,18 @@
+qemu breaks vmdk larger than 600GB.
+Description of problem:
+The vmdk larger than 600G is corrupted after an edit by qemu-nbd. If I open the corrupted vmdk file, I find an extra **^@** byte.
+```
+RW 4194304 SPARSE "disk-s289.vmdk"
+RW 4^@94304 SPARSE "disk-s290.vmdk"
+RW 4194304 SPARSE "disk-s291.vmdk"
+```
+Steps to reproduce:
+```
+   qemu-img create -f vmdk -o subformat=twoGbMaxExtentSparse disk.vmdk 1T
+   sudo qemu-nbd -c /dev/nbd0 disk.vmdk
+   sudo mkfs.btrfs /dev/nbd0
+   sudo qemu-nbd -d /dev/nbd0
+   qemu-img info disk.vmdk | head
+   ```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1924 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1924
new file mode 100644
index 00000000..2ea997d4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1924
@@ -0,0 +1,66 @@
+memory leak for pthread_create by valgrind
+Description of problem:
+qemu_thread_create calls pthread_create have memory leak 
+valgrind stack
+```
+==4075190== 1,776 bytes in 3 blocks are possibly lost in loss record 6,778 of 6,978
+==4075190==    at 0x4C3721A: calloc (vg_replace_malloc.c:760)
+==4075190==    by 0x40129EB: _dl_allocate_tls (in /usr/lib64/ld-2.28.so)
+==4075190==    by 0xADA3DA2: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.28.so)
+==4075190==    by 0x9B0DA5: qemu_thread_create (qemu-thread-posix.c:581)
+==4075190==    by 0x9C470C: do_spawn_thread (thread-pool.c:145)
+==4075190==    by 0x9C47C0: worker_thread (thread-pool.c:82)
+==4075190==    by 0x9AFD89: qemu_thread_start (qemu-thread-posix.c:541)
+==4075190==    by 0xADA3149: start_thread (in /usr/lib64/libpthread-2.28.so)
+==4075190==    by 0xB0B7DC2: clone (in /usr/lib64/libc-2.28.so)
+==4075190==
+==4075190== 2,368 bytes in 4 blocks are possibly lost in loss record 6,834 of 6,978
+==4075190==    at 0x4C3721A: calloc (vg_replace_malloc.c:760)
+==4075190==    by 0x40129EB: _dl_allocate_tls (in /usr/lib64/ld-2.28.so)
+==4075190==    by 0xADA3DA2: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.28.so)
+==4075190==    by 0x9B0DA5: qemu_thread_create (qemu-thread-posix.c:581)
+==4075190==    by 0x827FA8: kvm_start_vcpu_thread (kvm-accel-ops.c:75)
+==4075190==    by 0x633672: qemu_init_vcpu (cpus.c:642)
+==4075190==    by 0x722EA7: x86_cpu_realizefn (cpu.c:7430)
+==4075190==    by 0x833E2E: device_set_realized (qdev.c:510)
+==4075190==    by 0x8371D5: property_set_bool (object.c:2299)
+==4075190==    by 0x839512: object_property_set (object.c:1434)
+==4075190==    by 0x83C58E: object_property_set_qobject (qom-qobject.c:28)
+==4075190==    by 0x839783: object_property_set_bool (object.c:1503)
+```
+
+If we do vcpu hotplug and hot unplug for virtual machine continuously, the virtual memory and RES memory of qemu is increasing.
+Steps to reproduce:
+1. start qemu：
+valgrind   --tool=memcheck --leak-check=full /home/qemu-system-x86_64  -accel kvm -cpu host -m 4G -smp 4,maxcpus=64,sockets=8,dies=1,cores=8,threads=1  -drive file=/home/centosx861.qcow2,if=none,id=drive0,cache=none  -device virtio-blk,drive=drive0,bootindex=1  -monitor stdio -vnc :0
+2. after boot successful
+ctl+c kill qemu
+
+```
+==4075190== 1,776 bytes in 3 blocks are possibly lost in loss record 6,778 of 6,978
+==4075190==    at 0x4C3721A: calloc (vg_replace_malloc.c:760)
+==4075190==    by 0x40129EB: _dl_allocate_tls (in /usr/lib64/ld-2.28.so)
+==4075190==    by 0xADA3DA2: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.28.so)
+==4075190==    by 0x9B0DA5: qemu_thread_create (qemu-thread-posix.c:581)
+==4075190==    by 0x9C470C: do_spawn_thread (thread-pool.c:145)
+==4075190==    by 0x9C47C0: worker_thread (thread-pool.c:82)
+==4075190==    by 0x9AFD89: qemu_thread_start (qemu-thread-posix.c:541)
+==4075190==    by 0xADA3149: start_thread (in /usr/lib64/libpthread-2.28.so)
+==4075190==    by 0xB0B7DC2: clone (in /usr/lib64/libc-2.28.so)
+==4075190==
+==4075190== 2,368 bytes in 4 blocks are possibly lost in loss record 6,834 of 6,978
+==4075190==    at 0x4C3721A: calloc (vg_replace_malloc.c:760)
+==4075190==    by 0x40129EB: _dl_allocate_tls (in /usr/lib64/ld-2.28.so)
+==4075190==    by 0xADA3DA2: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.28.so)
+==4075190==    by 0x9B0DA5: qemu_thread_create (qemu-thread-posix.c:581)
+==4075190==    by 0x827FA8: kvm_start_vcpu_thread (kvm-accel-ops.c:75)
+==4075190==    by 0x633672: qemu_init_vcpu (cpus.c:642)
+==4075190==    by 0x722EA7: x86_cpu_realizefn (cpu.c:7430)
+==4075190==    by 0x833E2E: device_set_realized (qdev.c:510)
+==4075190==    by 0x8371D5: property_set_bool (object.c:2299)
+==4075190==    by 0x839512: object_property_set (object.c:1434)
+==4075190==    by 0x83C58E: object_property_set_qobject (qom-qobject.c:28)
+==4075190==    by 0x839783: object_property_set_bool (object.c:1503)
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1929 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1929
new file mode 100644
index 00000000..4b98489b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1929
@@ -0,0 +1,21 @@
+regression: 7.0.0 breaks registering process subreaper on Apple silicon
+Description of problem:
+When running any container on the QEMU virtual guest that is using a utility like `tini` which is trying to register itself as a process subreaper I get an error message like this:
+
+```
+[FATAL tini (1)] PR_SET_CHILD_SUBREAPER is unavailable on this platform. Are you using Linux >= 3.4?
+```
+
+The issue has been observed by multiple people on Apple silicon Macs, e.g. in these issues:
+https://github.com/docker/for-mac/issues/6620#issuecomment-1694380189
+https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/issues/1735
+Steps to reproduce:
+1. Install QEMU 7.0.0+ on an Apple silicon MAC
+2. Run a virtual guest
+3. Try to register a process subreaper, e.g. like `tini -s` does
+Additional information:
+the issue was introduced in QEMU 7.0.0 with this commit:
+https://gitlab.com/qemu-project/qemu/-/commit/220717a6f46a99031a5b1af964bbf4dec1310440
+
+tini readme talking about process subreaping:
+https://github.com/krallin/tini#subreaping
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1930 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1930
new file mode 100644
index 00000000..c0d76b30
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1930
@@ -0,0 +1,46 @@
+qemu-aarch64 results in segmentation fault while running a test binary compiled for QNX
+Description of problem:
+We have cross compiled a simple hello world program for QNX SDP 7.1.0 on Ubuntu Focal x86_64. Running the binary using qemu-aarch64 results in segmentation fault error.
+
+```
+   $ qemu-aarch64 -L /home/vsts/qnx710/target/qnx7/aarch64le ./hello-world
+   qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+   Segmentation fault (core dumped)
+```
+
+We also tried Ubuntu Jammy which has qemu-aarch64 v6.2.0 but got the same error.
+Can you tell us how we can emulate the binary using QEMU emulator that is built for QNX on x86_64 platform? Any help would be much appreciated.
+Steps to reproduce:
+1. Download QNX SDP from QNX software center https://www.qnx.com/download/group.html?programid=29178.
+2. Write a simple hello world program.
+
+```
+     #include <stdio.h>
+     
+     int main(void) {
+         return printf("Hello World!");
+     }
+```
+
+3. Source QNX SDP to set some environment variables.
+
+   `$ source ./qnx710/qnxsdp-env.sh`
+
+4. Compile using the QNX compiler.
+
+   `$ qcc -Vgcc_ntoaarch64le -o hello-world hello-world.c`
+
+5. Running the binary as it is results to:
+
+```
+   $ ./hello-world
+   aarch64-binfmt-P: Could not open '/usr/lib/ldqnx-64.so.2': No such file or directory
+```
+
+5. Running using QEMU emulator results to segmentation fault.
+
+```
+   $ qemu-aarch64 -L /home/vsts/qnx710/target/qnx7/aarch64le ./hello-world
+   qemu: uncaught target signal 11 (Segmentation fault) - core dumped  
+   Segmentation fault (core dumped)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1931 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1931
new file mode 100644
index 00000000..efe28140
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1931
@@ -0,0 +1,3 @@
+dbus: Support multiple QEMU instances
+Additional information:
+cc @marcandre.lureau
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1933 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1933
new file mode 100644
index 00000000..56c73793
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1933
@@ -0,0 +1,41 @@
+qemu 8.1.1 and 7.2.6 live migration with qcow2 attached to vm using postcopy crashes
+Description of problem:
+Live migrating a vm with a qcow2 disk attached using postcopy will cause vm to crash during migration.
+Steps to reproduce:
+1. Create a generic vm and attach a qcow2 file to the vm.
+<disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2' cache='none'/>
+      <source file='/var/lib/libvirt/images/jlow2.qcow2'/>
+      <target dev='vda' bus='virtio'/>
+      <boot order='1'/>
+</disk>
+
+2. virsh migrate jlow2 --change-protection --persistent --live --verbose --undefinesource --abort-on-error --postcopy --postcopy-after-precopy --timeout 1 --timeout-postcopy qemu+tcp://10.18.64.118/system
+
+vm will start migrating and then pause on the source and be shut down on the target once migration switches to postcopy
+
+Migration: [33.08 %]error: internal error: QEMU unexpectedly closed the monitor (vm='jlow2'): 2023-10-12T06:23:44.354387Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable
+2023-10-12T06:23:44.354538Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable
+qemu-system-x86_64: ../block/qcow2.c:5257: qcow2_get_specific_info: Assertion `false' failed.
+
+
+Logs from source
+
+2023-10-12 06:23:43.412+0000: initiating migration
+
+2023-10-12T06:23:44.362392Z qemu-system-x86_64: failed to save SaveStateEntry with id(name): 3(ram): -5
+
+2023-10-12T06:23:44.362485Z qemu-system-x86_64: Detected IO failure for postcopy. Migration paused.
+
+Logs from target
+
+2023-10-12T06:23:44.354387Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable
+
+2023-10-12T06:23:44.354538Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable
+
+qemu-system-x86_64: ../block/qcow2.c:5257: qcow2_get_specific_info: Assertion `false' failed.
+2023-10-12 06:23:44.408+0000: shutting down, reason=failed
+
+If postcopy is disabled with command below, migration will succeed:
+
+virsh migrate jlow2 --change-protection --persistent --live --verbose --undefinesource --abort-on-error  qemu+tcp://10.18.64.118/system
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1935 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1935
new file mode 100644
index 00000000..8eba8784
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1935
@@ -0,0 +1,5 @@
+migrate problem when add SCSI reservations with iSCSI backed disks
+Description of problem:
+When performing migrations with QEMU using iSCSI as the backend, it's common for the migration to start successfully. However, in scenarios where Persistent Reservations are added in the guest, the target host, under the precopy mode, preempts the Persistent Reservations right from the beginning, causing migration issues. Is there a way to control the Persistent Reservations lock within QEMU at an appropriate time, ensuring that it's only preempted during the switchover phase？
+
+Isn't libiscsi thread-safe? Can multiple threads operate on Persistent Reservations lock simultaneously?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1937 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1937
new file mode 100644
index 00000000..e4983ab7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1937
@@ -0,0 +1,11 @@
+Live migration with TLS fail (GNUTLS AUTO_REKEY)
+Description of problem:
+Live migration with TLS fail in postcopy stage when:
+
+#
+Steps to reproduce:
+1. run VM with heavy RAM load: `nohup stress-ng --vm 6 --vm-bytes 12G &`
+2. run precopy for more that 80sec
+3. switch into post-copy stage
+Additional information:
+This only occurs with TLS transport, if clear qemu+tcp is used then everything works.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1939 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1939
new file mode 100644
index 00000000..9368672a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1939
@@ -0,0 +1,64 @@
+qemu master git can no longer be compiled under MacOs Sonoma 14.0
+Description of problem:
+
+Steps to reproduce:
+Qemu master git fails to compile under MacOs M1/2, I already tested it with "git-bisect" "git bisect good" and "git bisect bad".All dependencies for qemu are fulfilled and were installed using Homebrew under MacOs.It fails with these commits:
+
+
+`>>>>> commit 7c3fb52bcdaef85b15a91b3ca4d1516f9d9b5402
+>>>>> Author: Paolo Bonzini <pbonzini@redhat.com>
+>>>>> Date: Tue Aug 8 20:28:25 2023 +0200
+>>>>>
+>>>>> configure: never use PyPI for Meson
+>>>>>
+>>>>> Since there is a vendored copy, there is no point in choosing
+>> online
+>>>>
+>>>>> operation.
+>>>>>
+>>>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+>>
+>>>>>
+>>>>> configure | 6 ------
+>>>>> 1 file changed, 6 deletions(-)
+>>>>>`
+Additional information:
+Older sources Qemu 8.1 can be compiled without problems. The only thing that has changed is that I did a major system update and Xcode was also updated. Since then compiling on qemu master version 8.1.50 breaks.
+
+```
+`On branch master
+Your branch is up to date with 'origin/master'.
+
+nothing to commit, working tree clean
+Mac-Studio qemu % ./configure --target-list=ppc-softmmu
+Using './build' as the directory for build output
+python determined to be '/Library/Frameworks/Python.framework/Versions/3.10/bin/python3'
+python version: Python 3.10.8
+mkvenv: Creating non-isolated virtual environment at 'pyvenv'
+mkvenv: checking for tomli>=1.2.0
+mkvenv: installing tomli>=1.2.0
+mkvenv: checking for meson>=0.63.0
+mkvenv: installing meson==0.63.3
+mkvenv: checking for sphinx>=1.6
+mkvenv: checking for sphinx_rtd_theme>=0.5
+
+'sphinx==5.3.0' not found:
+• Python package 'sphinx' was not found nor installed.
+• mkvenv was configured to operate offline and did not check PyPI.
+
+
+Sphinx not found/usable, disabling docs.
+Disabling PIE due to missing toolchain support
+The Meson build system
+Version: 0.63.3
+Source dir: /Users/qemu
+Build dir: /Users/qemu/build
+Build type: native build
+Project name: qemu
+Project version: 8.1.50
+
+../meson.build:1:0: ERROR: Unable to detect linker for compiler `cc -Wl,--version`
+stdout:
+stderr: ld: unknown options: --version
+clang: error: linker command failed with exit code 1 (use -v to see invocation)`
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/194 b/gitlab/issues_text/target_missing/host_missing/accel_missing/194
new file mode 100644
index 00000000..6fce8d2d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/194
@@ -0,0 +1 @@
+Qemu fails to start with error " There is no option group 'spice'"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1940 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1940
new file mode 100644
index 00000000..df077593
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1940
@@ -0,0 +1,20 @@
+Saving vm with shared folder results in Error: State blocked by non-migratable device  '000.../vhost-user-fs'
+Description of problem:
+Saving a vm with savevm in the QEMU Monitor with a shared folder causes the following error message:
+`Error: State blocked by non-migratable device '0000:00:05.0/vhost-user-fs'`
+Steps to reproduce:
+1. Get an qcow2 image that can boot (not sure if working qcow2 image is actually needed)
+2. Start virtiofsd with this /usr/libexec/virtiofsd --socket-path=/tmp/virtiofs_socket -o source=/path/to/share
+3. Run qemu-system-x86_64 -m 4G -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on -numa node,memdev=mem  -smp 2 -hda image.qcow2 -vga qxl -virtfs local,path=/path/to/share,mount_tag=share,security_model=passthrough,id=virtiofs -chardev socket,id=char0,path=/tmp/virtiofs_socket -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=share
+4. Let the image boot and/or go into the QEMU monitor.
+5. type savevm testvm
+6. See error.
+Additional information:
+This happens with both the legacy virtio-fs and the rust version.
+
+According to the first reply to https://gitlab.com/virtio-fs/virtiofsd/-/issues/81 there needs to be "a lot of changes not only in virtiofsd but also in the rust-vmm crates and qemu (and maybe in the vhost-user protocol)" so I'm reporting this here in the hopes it will speed something up.
+
+I followed the following to get virtiofsd working with command line QEMU:
+https://github.com/virtio-win/kvm-guest-drivers-windows/wiki/Virtiofs:-Shared-file-system
+
+This is blocking our migration from VirtualBox because it doesn't have problems like this. The least I need is a work around or alternative shared filesystem. We are trying to avoid networked shares.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1943 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1943
new file mode 100644
index 00000000..c44870bc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1943
@@ -0,0 +1,24 @@
+Weird error trying to autodetect CHS disk geometry
+Description of problem:
+Error: "SSD Read Error"
+
+Something about the contents of the disk causes qemu to wildly misdetect the disk geometry.
+This disk started as a blank disk, and had a FAT filesystem written to it from inside it; thus
+writing the detected geometry to the disk. And this caused the detected geometry to change to
+something nonsensical.
+Steps to reproduce:
+1. Unpack the attached [hd.bz2](/uploads/53f5bb00cdd563223bea1f7a0f86fe1c/hd.bz2) to hd.img
+2. Run qemu -hda hd.img
+3. Observe error
+Additional information:
+The following command appears to fix the problem; however it is wrong:
+
+qemu -drive if=none,id=dr,file=hd.img -device ide-hd,drive=dr,cyls=1023,heads=16,secs=63
+
+The problem with this command is this command yields only 504MB instead of the 512MB the
+disk is actually formatted to be. CHS translation should be enabled on this disk but won't
+be with this command.
+
+This command was copied essentially blindly from "Removed features" because that's what comes
+up for a google search for "qemu specify geometry" and I don't understand the command well
+enough to correct it.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1944 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1944
new file mode 100644
index 00000000..0f678ba7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1944
@@ -0,0 +1,71 @@
+Deadlock on snapshot removal (bdrv_graph_wrlock)
+Description of problem:
+VM was hanging during snapshot removal.
+There was an attempt to shutdown the VM, but that did hang.
+
+gdb shows me:
+```
+(gdb) bt full
+#0  0x00007f20493427fe in __ppoll (fds=0x557e630718b0, nfds=2, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:43
+        sc_ret = -514
+        sc_cancel_oldtype = 0
+        sc_ret = <optimized out>
+        tval = {tv_sec = 139776632323420, tv_nsec = 139776632323432}
+#1  0x0000557e619cab52 in fdmon_poll_wait.llvm ()
+No symbol table info available.
+#2  0x0000557e619ca0b6 in aio_poll ()
+No symbol table info available.
+#3  0x0000557e61801651 in bdrv_graph_wrlock ()
+No symbol table info available.
+#4  0x0000557e617c873b in bdrv_replace_child_noperm.llvm ()
+No symbol table info available.
+#5  0x0000557e617c8601 in bdrv_root_unref_child ()
+No symbol table info available.
+#6  0x0000557e617f6333 in blk_unref ()
+No symbol table info available.
+#7  0x0000557e6181b0d1 in mirror_exit_common ()
+No symbol table info available.
+#8  0x0000557e617dbdb4 in job_do_finalize_locked.llvm ()
+No symbol table info available.
+#9  0x0000557e617dd72b in job_exit ()
+No symbol table info available.
+#10 0x0000557e619e5101 in aio_bh_poll ()
+No symbol table info available.
+#11 0x0000557e619c95a4 in aio_dispatch ()
+No symbol table info available.
+#12 0x0000557e619e655f in aio_ctx_dispatch ()
+No symbol table info available.
+#13 0x00007f2049546e2f in g_main_dispatch (context=0x557e62ecebd0) at ../glib/gmain.c:3337
+        dispatch = 0x557e619e6550 <aio_ctx_dispatch>
+        prev_source = 0x0
+        begin_time_nsec = 232172181173336
+        was_in_call = <optimized out>
+        user_data = 0x0
+        callback = 0x0
+        cb_funcs = 0x0
+        cb_data = 0x0
+        need_destroy = <optimized out>
+        source = 0x557e62ec73e0
+        current = 0x557e63e4b600
+        i = 0
+        __func__ = {<optimized out> <repeats 16 times>}
+#14 g_main_context_dispatch (context=0x557e62ecebd0) at ../glib/gmain.c:4055
+No locals.
+#15 0x0000557e619e74be in main_loop_wait ()
+No symbol table info available.
+#16 0x0000557e615201e7 in qemu_main_loop ()
+No symbol table info available.
+#17 0x0000557e61374c6a in qemu_default_main ()
+No symbol table info available.
+#18 0x00007f204923feb0 in __libc_start_call_main (main=main@entry=0x557e61374c80 <main>, argc=argc@entry=153, argv=argv@entry=0x7ffe07495238) at ../sysdeps/nptl/libc_start_call_main.h:58
+        self = <optimized out>
+        result = <optimized out>
+        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -6145724763479124305, 140729020666424, 94001285254272, 94001294953808, 139776661151744, 6145708635144279727, 6121919821307926191}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7f204954cb41 <g_malloc0+33>, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 1230293825}}}
+        not_first_call = <optimized out>
+#19 0x00007f204923ff60 in __libc_start_main_impl (main=0x557e61374c80 <main>, argc=153, argv=0x7ffe07495238, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe07495228) at ../csu/libc-start.c:389
+No locals.
+#20 0x0000557e613743d5 in _start ()
+No symbol table info available.
+```
+Steps to reproduce:
+Still trying to reproduce in lab.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1949 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1949
new file mode 100644
index 00000000..d7a5e7db
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1949
@@ -0,0 +1,12 @@
+chardev zombie TCP session
+Description of problem:
+When user terminates TCP session ungracefully (eg: power-cycle or network cable disconnect), the TCP session keeps in established status forever. In this state, new sessions can't access the chardev, since the zombie TCP session keeps exclusive access to chardev.
+Steps to reproduce:
+1.Establish client session to chardev TCP socket.  
+2.Power-off the client machine.  
+3.Establish a new client session  
+4.Observe that old TCP session is never killed and new session can connect but not interact with chardev.
+Additional information:
+Suggestions to resolve this and improve the chardev feature:
+- enable TCP keep-alive for chardev server.
+- allow multiple client sessions concurrently, where chardev output is broadcasted to all client sessions, and chardev input is shared by all clients.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/195 b/gitlab/issues_text/target_missing/host_missing/accel_missing/195
new file mode 100644
index 00000000..e0f9d8a5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/195
@@ -0,0 +1 @@
+wavcapture does not record silence
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1951 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1951
new file mode 100644
index 00000000..dfbc54fa
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1951
@@ -0,0 +1,138 @@
+MacOS requires root to pass through USB devices properly
+Description of problem:
+If I run qemu as a normal user, the PlutoSDR USB device will not work in the VM.  For example, the umass device will remain attached to the host system, and will not appear in the guest system.  The device will appear in the guest system, but it will fail to be configured:
+```
+usb_alloc_device: Failure selecting configuration index 0:USB_ERR_STALLED, port 2, addr 2 (ignored)
+```
+
+I believe that similar issues are happening w/ guest OS's Ubuntu 20.04 and 22.04, but I have not tested them to confirm.
+
+There is no error message (that I noticed) that reports that this might be an issue and that you need to run qemu as root.
+Steps to reproduce:
+1. Run qemu like above
+2. Plug in a PlutoSDR
+3. See that the device appears in the guest, but does not attach completely
+Additional information:
+The confusing part is that a simple device, an RTL-SDR device will appear to work fine when passed through w/o running as root making things more confusing to debug.
+
+When run qemu as a normal user, the console (includes FreeBSD kernel messages:
+```
+login: qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+usb_alloc_device: Failure selecting configuration index 0:USB_ERR_STALLED, port 2, addr 2 (ignored)
+ugen1.2: <Analog Devices Inc. PlutoSDR (ADALM-PLUTO)> at usbus1
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_detach_kernel_driver: -3 [ACCESS]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+```
+
+It's not clear what action, if any needs to be taken w/ these error messages.  At a minimum, qemu should complain loudly about needing to be run as root, but would be best if it didn't need to run as root, like other VM systems.
+
+If I run qemu as root (via sudo), it attachs as expected:
+```
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+qemu-system-aarch64: libusb_kernel_driver_active: -5 [NOT_FOUND]
+ugen1.2: <Analog Devices Inc. PlutoSDR (ADALM-PLUTO)> at usbus1
+umass0 on uhub0
+umass0: <Mass Storage> on usbus1
+umass0:  SCSI over Bulk-Only; quirks = 0x0000
+umass0:0:0: Attached to scbus0
+da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
+da0: <Linux File-Stor Gadget 0414> Removable Direct Access SCSI-2 device
+da0: 40.000MB/s transfers
+da0: 30MB (61441 512 byte sectors)
+da0: quirks=0x2<NO_6_BYTE>
+urndis0 on uhub0
+urndis0: <RNDIS Communications Control> on usbus1
+umodem0 on uhub0
+umodem0: <CDC Abstract Control Model (ACM)> on usbus1
+umodem0: data interface 4, has no CM over data, has no break
+```
+
+Trying root was inspired by:
+https://github.com/libusb/libusb/issues/1014
+
+From that issue, it appears that this is a qemu build issue and does not have the proper entitlements.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1954 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1954
new file mode 100644
index 00000000..35076404
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1954
@@ -0,0 +1,28 @@
+guest-fsfreeze can't work well on windows
+Description of problem:
+I used qemu 5.0 to cross-compile windows gqa on the fedroa30 system.And install it on guest with windows10,but i can't work well.
+Steps to reproduce:
+1. ./configure --cross-prefix=x86_64-w64-mingw32- --enable-guest-agent-msi --with-vss-sdk=/root/vssdk/VSSSDK72 
+   
+  my vssdk download from:[vssdk](https://www.microsoft.com/en-us/download/details.aspx?id=23490),i install it on my pc and copy to /root/vssdk/VSSSDK72 
+   
+2. make qemu-ga -j4
+
+3. and then install qemu-ga-x86_64.msi on windows10,it report the error:
+   ![image](/uploads/b03b95e7b1b4519a153deadfbbaec751/image.png)
+
+4.then I ./configure not with "--with-vss-sdk",the qemu-ga-x86_64.msi can install successfully.
+
+5.So, I install gga first. Then ./configure with "--with-vss-sdk" to make get the qemu-ga.exe
+
+6.replace qemu-ga.exe and reboot gga service,then execute the command "virsh domfsfreeze" on host,but it report error:
+
+   error: Unable to freeze filesystems
+   error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to add \\?\Volume{d1ee1072-0000-0000-0000-100000000000}\ to snapshot set: 
+
+
+**I looked at the windows Event Viewer,it get the error:**
+
+   Unexpected error querying for the IVssWriterCallback interface. hr = 0x80070005, Access is denied.
+
+I have referred to this [document](https://www.ryadel.com/en/volume-shadow-copy-service-error-unexpected-error-querying-for-the-ivsswritercallback-interface-how-to-fix-that/),but it not work.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1957 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1957
new file mode 100644
index 00000000..ea997db3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1957
@@ -0,0 +1,20 @@
+Reading files failed from QEMU TFTP server
+Description of problem:
+QEMU TFTP server on Linux is sensitive to the filename delimiters:
+
+After building QEMU UEFI firmware with the entire NetworkPkg stack and booting to UEFI shell, one can use `tftp` command to read files from the QEMU TFTP server specified during QEMU launching. i.e. `tftp 10.0.2.2 Boot\BCD`. However, when setting up the TFTP folder to be exactly the same (Linux and Windows), the result for running this command is different. On Windows host, this tftp command from emulated UEFI shell will proceed properly. But on Linux host, this will fail with "File Not Found".
+
+The issue seems to be around the slirp engine used by QEMU: the received packet will hand off to slirp as is, which leads to a host specific libc implementation of "open" function call: https://git.launchpad.net/ubuntu/+source/libslirp/tree/src/tftp.c#n113. Thus the server result would be different when the host is different.
+
+This will cause the PXE boot to fail when setting up the PXE folder on through QEMU on Linux because Windows will attempt to read BCD file at the same directory of the initial boot file, with a `\` in between.
+
+As TFTP protocol seems to be folder agnostic (just file names), in this case, should the TFTP server (QEMU here) handle the path normalization to make sure the file lookup to go through? Otherwise, Windows PXE boot on QEMU Linux host will always fail.
+
+Any suggestion here? Thanks in advance!
+Steps to reproduce:
+1. Build OVMF UEFI with full network stack
+2. Launch QEMU with the built UEFI with nic enabled, boot to UEFI shell.
+3. Invoke `tftp 10.0.2.2 Boot\BCD` from UEFI shell.
+4. When performing step 1-3 on Windows, this will succeed. But on Linux, this will fail with "File Not Found"
+Additional information:
+Attached is a wireshark dump from QEMU on Linux host. The same command sequence will all be successful on Windows host.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1959 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1959
new file mode 100644
index 00000000..f8cfeb41
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1959
@@ -0,0 +1 @@
+qemu-img: support ZSTD compression level customization
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/196 b/gitlab/issues_text/target_missing/host_missing/accel_missing/196
new file mode 100644
index 00000000..026a90a3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/196
@@ -0,0 +1 @@
+Improve UX for macOS when launching from a fullscreen app
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1962 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1962
new file mode 100644
index 00000000..e5623d19
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1962
@@ -0,0 +1,29 @@
+systemd-tmpfiles-setup-dev-early.service fails in emulated systemd-nspawn container
+Description of problem:
+When booting a fresh `debootstrap`ed Debian Trixie/testing rootfs with foreign architecture via `systemd-nspawn` and `qemu-user-static`, invoked via `systemd-binfmt`, the `systemd-tmpfiles-setup-dev-early.service` service within the guest fails, which leads to `/dev` not existing (respectively no default content), so that several other guest system components fail as well, like any console/shell access:
+```
+Starting systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully...
+systemd-tmpfiles-setup-dev-early.service: Failed to set up credentials: Invalid argument
+systemd-tmpfiles-setup-dev-early.service: Main process exited, code=exited, status=243/CREDENTIALS
+systemd-tmpfiles-setup-dev-early.service: Failed with result 'exit-code'.
+[FAILED] Failed to start systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully.
+See 'systemctl status systemd-tmpfiles-setup-dev-early.service' for details.
+Starting systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev...
+systemd-tmpfiles-setup-dev.service: Failed to set up credentials: Invalid argument
+systemd-tmpfiles-setup-dev.service: Main process exited, code=exited, status=243/CREDENTIALS
+systemd-tmpfiles-setup-dev.service: Failed with result 'exit-code'.
+[FAILED] Failed to start systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev.
+See 'systemctl status systemd-tmpfiles-setup-dev.service' for details.
+```
+Steps to reproduce:
+1. `apt install debootstrap systemd-container qemu-user-static`
+2. `systemctl restart systemd-binfmt`
+3. `mkdir rootfs`
+4. `debootstrap --variant=minbase --include=systemd-sysv --arch=arm64 trixie ./rootfs 'https://deb.debian.org/debian'`
+5. `systemd-nspawn -bD rootfs`
+Additional information:
+On Bookworm guest systems and/or without QEMU emulation, this works without issues, so I guess systemd recently started to use a certain syscall for the `ImportCredential=tmpfiles.*` method in systemd units, which is not supported by QEMU, probably similar to https://github.com/systemd/systemd/pull/28954?
+
+I hope it is fine to report it here. Always difficult to decide whether to report to the distribution (Debian) or one, and in case which, of the related projects, which do not work together.
+
+Debian Trixie currently ships `systemd 254.4-1` btw. I am not sure whether the issue was introduced with 253 or 254, since the linked issue prevented booting such containers on an earlier stage with 253, which was fixed in 254, which has the here reported issue.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1963 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1963
new file mode 100644
index 00000000..08d34929
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1963
@@ -0,0 +1,28 @@
+EOF is not detected, when semihosting is reading from stdin
+Description of problem:
+QEMU hangs.
+Steps to reproduce:
+1. Run the program with stdin from a pipe.
+Additional information:
+The code is compiled from this source:
+```
+#include <stdio.h>
+
+int main(int argc, char** argv) {
+    int i = -1;
+    int result = scanf("%d", &i);
+    printf("result = %d, i = %d\n", result, i);
+    return 0;
+}
+```
+compiled with GCC and picolibc:
+```
+arm-none-eabi-gcc --specs=picolibc.specs -march=armv7-m ~/sources/picolibc/git/test-stdin.c -o test-stdin -lc -lsemihost --crt0=hosted -O0 -g
+```
+[test-stdin](/uploads/dbd2650c8e0aaca353fd7630ac9c8440/test-stdin)
+The execution hangs at semihosting SYS_READC(0x7) call:
+```
+	movs r0, #7
+(...)
+	bkpt #0xab
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1967 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1967
new file mode 100644
index 00000000..ecee5be4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1967
@@ -0,0 +1 @@
+Guest SIGRTMIN remapped incorrectly
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1968 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1968
new file mode 100644
index 00000000..ae09d2aa
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1968
@@ -0,0 +1 @@
+scripts (checkpatch): make braces {} necessary for 'for' loops
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1969 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1969
new file mode 100644
index 00000000..1bbd1a2b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1969
@@ -0,0 +1 @@
+Test fails with SIGSEGV because of use-after-free
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1971 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1971
new file mode 100644
index 00000000..8f0c1a9c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1971
@@ -0,0 +1,148 @@
+Cannot build QEMU on MSYS2 on Windows 10 22H2
+Description of problem:
+I have followed build instructions on Wiki, section Native builds with MSYS2. MSYS2 and other tools are installed without any errors. But when run `./configure --enable-sdl --enable-gtk`, I have this error that I have never seen before:
+
+```
+# ./configure --enable-sdl --enable-gtk
+Using './build' as the directory for build output
+ln: failed to create symbolic link 'aarch64-softmmu/qemu-system-aarch64.exe': No such file or directory
+ln: failed to create symbolic link 'alpha-softmmu/qemu-system-alpha.exe': No such file or directory
+ln: failed to create symbolic link 'arm-softmmu/qemu-system-arm.exe': No such file or directory
+ln: failed to create symbolic link 'avr-softmmu/qemu-system-avr.exe': No such file or directory
+ln: failed to create symbolic link 'cris-softmmu/qemu-system-cris.exe': No such file or directory
+ln: failed to create symbolic link 'hppa-softmmu/qemu-system-hppa.exe': No such file or directory
+ln: failed to create symbolic link 'i386-softmmu/qemu-system-i386.exe': No such file or directory
+ln: failed to create symbolic link 'loongarch64-softmmu/qemu-system-loongarch64.exe': No such file or directory
+ln: failed to create symbolic link 'm68k-softmmu/qemu-system-m68k.exe': No such file or directory
+ln: failed to create symbolic link 'microblaze-softmmu/qemu-system-microblaze.exe': No such file or directory
+ln: failed to create symbolic link 'microblazeel-softmmu/qemu-system-microblazeel.exe': No such file or directory
+ln: failed to create symbolic link 'mips-softmmu/qemu-system-mips.exe': No such file or directory
+ln: failed to create symbolic link 'mips64-softmmu/qemu-system-mips64.exe': No such file or directory
+ln: failed to create symbolic link 'mips64el-softmmu/qemu-system-mips64el.exe': No such file or directory
+ln: failed to create symbolic link 'mipsel-softmmu/qemu-system-mipsel.exe': No such file or directory
+ln: failed to create symbolic link 'nios2-softmmu/qemu-system-nios2.exe': No such file or directory
+ln: failed to create symbolic link 'or1k-softmmu/qemu-system-or1k.exe': No such file or directory
+ln: failed to create symbolic link 'ppc-softmmu/qemu-system-ppc.exe': No such file or directory
+ln: failed to create symbolic link 'ppc64-softmmu/qemu-system-ppc64.exe': No such file or directory
+ln: failed to create symbolic link 'riscv32-softmmu/qemu-system-riscv32.exe': No such file or directory
+ln: failed to create symbolic link 'riscv64-softmmu/qemu-system-riscv64.exe': No such file or directory
+ln: failed to create symbolic link 'rx-softmmu/qemu-system-rx.exe': No such file or directory
+ln: failed to create symbolic link 's390x-softmmu/qemu-system-s390x.exe': No such file or directory
+ln: failed to create symbolic link 'sh4-softmmu/qemu-system-sh4.exe': No such file or directory
+ln: failed to create symbolic link 'sh4eb-softmmu/qemu-system-sh4eb.exe': No such file or directory
+ln: failed to create symbolic link 'sparc-softmmu/qemu-system-sparc.exe': No such file or directory
+ln: failed to create symbolic link 'sparc64-softmmu/qemu-system-sparc64.exe': No such file or directory
+ln: failed to create symbolic link 'tricore-softmmu/qemu-system-tricore.exe': No such file or directory
+ln: failed to create symbolic link 'x86_64-softmmu/qemu-system-x86_64.exe': No such file or directory
+ln: failed to create symbolic link 'xtensa-softmmu/qemu-system-xtensa.exe': No such file or directory
+ln: failed to create symbolic link 'xtensaeb-softmmu/qemu-system-xtensaeb.exe': No such file or directory
+The Meson build system
+Version: 1.2.3
+Source dir: C:/msys64/home/DuyThanh/qemu-ios
+Build dir: C:/msys64/home/DuyThanh/qemu-ios/build
+Build type: native build
+Project name: qemu
+Project version: 7.2.50
+C compiler for the host machine: cc -m64 -mcx16 (gcc 13.2.0 "cc (Rev2, Built by MSYS2 project) 13.2.0")
+C linker for the host machine: cc -m64 -mcx16 ld.bfd 2.41
+Host machine cpu family: x86_64
+Host machine cpu: x86_64
+Program scripts/symlink-install-tree.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/DuyThanh/qemu-ios/scripts/symlink-install-tree.py)
+Program sh found: YES (C:\msys64\usr\bin/sh.EXE)
+Program python3 found: YES (C:/msys64/mingw64/bin/python.exe)
+Program bzip2 found: YES (C:\msys64\mingw64\bin/bzip2.EXE)
+Program iasl found: NO
+Compiler for C supports link arguments -Wl,-z,relro: NO
+Compiler for C supports link arguments -Wl,-z,now: NO
+Compiler for C supports link arguments -Wl,--no-seh: YES
+Compiler for C supports link arguments -Wl,--nxcompat: YES
+C++ compiler for the host machine: c++ -m64 -mcx16 (gcc 13.2.0 "c++ (Rev2, Built by MSYS2 project) 13.2.0")
+C++ linker for the host machine: c++ -m64 -mcx16 ld.bfd 2.41
+Compiler for C++ supports link arguments -Wl,--warn-common: YES
+Program cgcc found: NO
+Library m found: YES
+Run-time dependency threads found: YES
+Traceback (most recent call last):
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/mesonmain.py", line 194, in run
+    return options.run_func(options)
+           ^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/msetup.py", line 358, in run
+    app.generate()
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/msetup.py", line 183, in generate
+    return self._generate(env, capture, vslite_ctx)
+           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/msetup.py", line 228, in _generate
+    intr.run()
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreter/interpreter.py", line 3002, in run
+    super().run()
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 164, in run
+    self.evaluate_codeblock(self.ast, start=1)
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 190, in evaluate_codeblock
+    raise e
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 182, in evaluate_codeblock
+    self.evaluate_statement(cur)
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 198, in evaluate_statement
+    self.assignment(cur)
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 635, in assignment
+    value = self.evaluate_statement(node.value)
+            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 200, in evaluate_statement
+    return self.method_call(cur)
+           ^^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 550, in method_call
+    res = obj.method_call(method_name, args, kwargs)
+          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/baseobjects.py", line 94, in method_call
+    return method(args, kwargs)
+           ^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/decorators.py", line 109, in wrapped
+    ret = f(*wrapped_args, **wrapped_kwargs)
+          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/decorators.py", line 277, in wrapper
+    return f(*nargs, **wrapped_kwargs)
+           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/decorators.py", line 596, in wrapper
+    return f(*wrapped_args, **wrapped_kwargs)
+           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreter/compiler.py", line 635, in find_library_method
+    linkargs = self.compiler.find_library(libname, self.environment, search_dirs, libtype)
+               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/compilers/mixins/clike.py", line 1191, in find_library
+    return self._find_library_impl(libname, env, extra_dirs, code, libtype, lib_prefix_warning)
+           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/compilers/mixins/clike.py", line 1180, in _find_library_impl
+    value = self._find_library_real(libname, env, extra_dirs, code, libtype, lib_prefix_warning)
+            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/compilers/mixins/clike.py", line 1158, in _find_library_real
+    for d in itertools.chain(extra_dirs, self.get_library_dirs(env, elf_class)):
+                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/compilers/mixins/clike.py", line 261, in get_library_dirs
+    return self._get_library_dirs(env, elf_class).copy()
+           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/compilers/mixins/clike.py", line 220, in _get_library_dirs
+    dirs = self.get_compiler_dirs(env, 'libraries')
+           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/compilers/mixins/gnu.py", line 515, in get_compiler_dirs
+    return self._split_fetch_real_dirs(line.split('=', 1)[1])
+           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/compilers/mixins/gnu.py", line 497, in _split_fetch_real_dirs
+    if pobj.exists():
+       ^^^^^^^^^^^^^
+  File "C:/msys64/mingw64/lib/python3.11/pathlib.py", line 1237, in exists
+    self.stat()
+  File "C:/msys64/mingw64/lib/python3.11/pathlib.py", line 1015, in stat
+    return os.stat(self, follow_symlinks=follow_symlinks)
+           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+OSError: [WinError 1005] The volume does not contain a recognized file system.
+Please make sure that all required file system drivers are loaded and that the volume is not corrupted: 'D:/a/msys64/mingw64/lib/x86_64-w64-mingw32/13.2.0'
+
+ERROR: Unhandled python OSError. This is probably not a Meson bug, but an issue with your build environment.
+
+ERROR: meson setup failed
+```
+Steps to reproduce:
+1. Install MSYS2 and follow the wiki page
+2. Git clone
+3. Run configure then error
+Additional information:
+No
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1972 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1972
new file mode 100644
index 00000000..11e722f4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1972
@@ -0,0 +1,39 @@
+Windows TCG plugin build fails with mingw cross-compile images
+Description of problem:
+It looks like the mingw variants of the compiler are sensitive to the order of linking:
+
+```
+bash-5.2$ x86_64-w64-mingw32-gcc -m64 -mcx16 plugins/qemu_plugin_api.lib -o tests/plugin/libinsn.dll tests/plugin/libinsn.dll.p/insn.c.obj tests/plugin/libinsn.dll.p/.._.._contrib_plugins_win32_linker.c.obj plugins/qemu_plugin_api.lib -Wl,--allow-shlib-undefined -shared -Wl,--start-group -Wl,--out-implib=tests/plugin/libinsn.dll.a -fstack-protector-strong -Wl,--no-seh -Wl,--nxcompat -Wl,--dynamicbase -Wl,--high-entropy-va -Wl,--warn-common /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libglib-2.0.dll.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libintl.dll.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libgmodule-2.0.dll.a -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -Wl,--end-group
+bash-5.2$ x86_64-w64-mingw32-gcc -m64 -mcx16 plugins/qemu_plugin_api.lib -o tests/plugin/libinsn.dll tests/plugin/libinsn.dll.p/insn.c.obj tests/plugin/libinsn.dll.p/.._.._contrib_plugins_win32_linker.c.obj -Wl,--allow-shlib-undefined -shared -Wl,--start-group -Wl,--out-implib=tests/plugin/libinsn.dll.a -fstack-protector-strong -Wl,--no-seh -Wl,--nxcompat -Wl,--dynamicbase -Wl,--high-entropy-va -Wl,--warn-common /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libglib-2.0.dll.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libintl.dll.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libgmodule-2.0.dll.a -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -Wl,--end-group
+/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: tests/plugin/libinsn.dll.p/insn.c.obj: in function `vcpu_tb_trans':
+/tmp/qemu-test/build/../src/tests/plugin/insn.c:90: undefined reference to `__imp_qemu_plugin_tb_n_insns'
+/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:100: undefined reference to `__imp_qemu_plugin_insn_vaddr'
+/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:97: undefined reference to `__imp_qemu_plugin_register_vcpu_insn_exec_inline'
+/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:94: undefined reference to `__imp_qemu_plugin_tb_get_insn'
+/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:101: undefined reference to `__imp_qemu_plugin_register_vcpu_insn_exec_cb'
+/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:107: undefined reference to `__imp_qemu_plugin_insn_size'
+/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:121: undefined reference to `__imp_qemu_plugin_insn_disas'
+/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:130: undefined reference to `__imp_qemu_plugin_register_vcpu_insn_exec_cb'
+/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: tests/plugin/libinsn.dll.p/insn.c.obj: in function `plugin_exit':
+/tmp/qemu-test/build/../src/tests/plugin/insn.c:168: undefined reference to `__imp_qemu_plugin_outs'
+/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:168: undefined reference to `__imp_qemu_plugin_outs'
+/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:168: undefined reference to `__imp_qemu_plugin_outs'
+/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: tests/plugin/libinsn.dll.p/insn.c.obj: in function `vcpu_insn_matched_exec_before':
+/tmp/qemu-test/build/../src/tests/plugin/insn.c:83: undefined reference to `__imp_qemu_plugin_outs'
+/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: tests/plugin/libinsn.dll.p/insn.c.obj: in function `qemu_plugin_install':
+/tmp/qemu-test/build/../src/tests/plugin/insn.c:199: undefined reference to `__imp_qemu_plugin_bool_parse'
+/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:215: undefined reference to `__imp_qemu_plugin_register_vcpu_tb_trans_cb'
+/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:216: undefined reference to `__imp_qemu_plugin_register_atexit_cb'
+collect2: error: ld returned 1 exit status
+ 
+ 
+If you move the qemu_plugin_api.lib to after the other .obj files, it works:
+ 
+bash-5.2$ x86_64-w64-mingw32-gcc -m64 -mcx16 plugins/qemu_plugin_api.lib -o tests/plugin/libinsn.dll tests/plugin/libinsn.dll.p/insn.c.obj tests/plugin/libinsn.dll.p/.._.._contrib_plugins_win32_linker.c.obj plugins/qemu_plugin_api.lib -Wl,--allow-shlib-undefined -shared -Wl,--start-group -Wl,--out-implib=tests/plugin/libinsn.dll.a -fstack-protector-strong -Wl,--no-seh -Wl,--nxcompat -Wl,--dynamicbase -Wl,--high-entropy-va -Wl,--warn-common /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libglib-2.0.dll.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libintl.dll.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libgmodule-2.0.dll.a -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -Wl,--end-group
+bash-5.2$ echo $?
+0
+```
+Steps to reproduce:
+```
+make docker-test-build@fedora-win64-cross J=30 V=1 EXTRA_CONFIGURE_OPTS="--enable-fdt=internal --enable-plugins" NETWORK=1
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1973 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1973
new file mode 100644
index 00000000..22a6c350
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1973
@@ -0,0 +1 @@
+Issues with dmabuf use in dbus interface
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1974 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1974
new file mode 100644
index 00000000..8bb0ccb1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1974
@@ -0,0 +1 @@
+Default console changes break Xen command-line
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1975 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1975
new file mode 100644
index 00000000..b98bd36a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1975
@@ -0,0 +1,37 @@
+SEGV on exit: net_cleanup() frees devices it doesn't own.
+Description of problem:
+On exiting QEMU, the `net_cleanup()` function iterates over all existing `net_clients`, both netdevs and nics, and deletes them all. Freeing the netdevs is fine, and they are correctly detached from their peer nic as appropriate. But the nics belong to an actual device and this can cause a use-after-free or double-free.
+
+Mostly this doesn't happen because emulated devices *don't* bother to clean up after themselves on exit; none of their state is going to outlast the QEMU process so there's no point. But XenBus devices interact with the external XenStore and do need to perform a cleanup. The `xen_netdev_unrealize()` function calls `qemu_del_nic()` on the nic which `net_cleanup()` already stole from it, and crashes...
+
+```
+QEMU: Terminated
+
+Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
+qemu_del_nic (nic=0x55555846ab00) at ../net/net.c:451
+451	    int i, queues = MAX(nic->conf->peers.queues, 1);
+(gdb) bt
+#0  qemu_del_nic (nic=0x55555846ab00) at ../net/net.c:451
+#1  0x0000555555a89ce3 in xen_device_unrealize (dev=<optimized out>) at ../hw/xen/xen-bus.c:973
+#2  0x0000555555e5c847 in notifier_list_notify (list=<optimized out>, data=0x0) at ../util/notify.c:39
+#3  0x00007ffff5fe51e6 in __run_exit_handlers (status=0, listp=<optimized out>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:111
+#4  0x00007ffff5fe532e in __GI_exit (status=<optimized out>) at exit.c:141
+#5  0x00007ffff5fccb91 in __libc_start_call_main (main=main@entry=0x5555558837a0 <main>, argc=argc@entry=23, argv=argv@entry=0x7fffffffd7a8) at ../sysdeps/nptl/libc_start_call_main.h:74
+#6  0x00007ffff5fccc4b in __libc_start_main_impl
+    (main=0x5555558837a0 <main>, argc=23, argv=0x7fffffffd7a8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd798) at ../csu/libc-start.c:360
+#7  0x0000555555885345 in _start ()
+```
+Steps to reproduce:
+1. Launch a Xen guest as described at https://qemu-project.gitlab.io/qemu/system/i386/xen.html (which will get a Xen NIC by default).
+2. Terminate QEMU.
+
+It doesn't need to boot, doesn't need to do anything. Just launch a completely non-functional guest and then hit `Ctrl-a x` on the default monitor:
+```
+$ ./qemu-system-x86_64 -accel kvm,xen-version=0x40010,kernel-irqchip=split -display none
+QEMU: Terminated
+Segmentation fault
+
+```
+
+For `net_cleanup()` to clean up the *netdevs* makes sense, because those might have state which persists in the system after QEMU exits, and need to be cleaned up. But deleting the nics doesn't seem to be necessary. 
+Fix at https://lore.kernel.org/qemu-devel/61ea91785772a8138ad12b305cbd5aac4aa1e86a.camel@infradead.org
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1977 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1977
new file mode 100644
index 00000000..1d46f73d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1977
@@ -0,0 +1,30 @@
+MSYS2 build fails with link errors on Window 10  22H2
+Description of problem:
+Linking target tests/plugin/libbb.dll fails with undefined references in below attached output
+Steps to reproduce:
+1. Open MSYS2 build environment on Windows 10
+2. mkdir build && cd build && ../configure --prefix=/home/Admin --enable-sdl --enable-gtk --target-list=arm-softmmu
+3. make -j4
+Additional information:
+[2300/2631] Linking target tests/plugin/libbb.dll
+FAILED: tests/plugin/libbb.dll
+"cc" "-m64" "-mcx16"  -o tests/plugin/libbb.dll plugins/qemu_plugin_api.lib tests/plugin/libbb.dll.p/bb.c.obj tests/plugin/libbb.dll.p/.._.._contrib_plugins_win32_linker.c.obj "-Wl,--allow-shlib-undefined" "-shared" "-Wl,--start-group" "-Wl,--out-implib=tests/plugin/libbb.dll.a" "-fstack-protector-strong" "-Wl,--no-seh" "-Wl,--nxcompat" "-Wl,--dynamicbase" "-Wl,--high-entropy-va" "-Wl,--warn-common" "C:/msys64/ucrt64/lib/libglib-2.0.dll.a" "C:/msys64/ucrt64/lib/libintl.dll.a" "C:/msys64/ucrt64/lib/libgmodule-2.0.dll.a" "-lkernel32" "-luser32" "-lgdi32" "-lwinspool" "-lshell32" "-lole32" "-loleaut32" "-luuid" "-lcomdlg32" "-ladvapi32" "-Wl,--end-group"
+C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: tests/plugin/libbb.dll.p/bb.c.obj: in function `vcpu_tb_trans':
+C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:84:(.text+0x4f): undefined reference to `__imp_qemu_plugin_tb_n_insns'
+C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:87:(.text+0x62): undefined reference to `__imp_qemu_plugin_register_vcpu_tb_exec_inline'
+C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:93:(.text+0xba): undefined reference to `__imp_qemu_plugin_register_vcpu_tb_exec_cb'
+C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: tests/plugin/libbb.dll.p/bb.c.obj: in function `plugin_exit':
+C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:55:(.text+0x1cb): undefined reference to `__imp_qemu_plugin_outs'
+C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:55:(.text+0x204): undefined reference to `__imp_qemu_plugin_outs'
+C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: tests/plugin/libbb.dll.p/bb.c.obj: in function `vcpu_idle':
+C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:66:(.text+0x299): undefined reference to `__imp_qemu_plugin_outs'
+C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: tests/plugin/libbb.dll.p/bb.c.obj: in function `qemu_plugin_install':
+C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:114:(.text+0x2e8): undefined reference to `__imp_qemu_plugin_bool_parse'
+C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:141:(.text+0x3d5): undefined reference to `__imp_qemu_plugin_register_vcpu_tb_trans_cb'
+C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:142:(.text+0x3ea): undefined reference to `__imp_qemu_plugin_register_atexit_cb'
+C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:138:(.text+0x420): undefined reference to `__imp_qemu_plugin_register_vcpu_idle_cb'
+collect2.exe: error: ld returned 1 exit status
+[2301/2631] Compiling C object tests/plugin/libempty.dll.p/.._.._contrib_plugins_win32_linker.c.obj
+[2302/2631] Compiling C object tests/libtestqapi.a.p/meson-generated_.._test-qapi-visit.c.obj
+[2303/2631] Compiling C object tests/plugin/libinsn.dll.p/.._.._contrib_plugins_win32_linker.c.obj
+ninja: build stopped: subcommand failed.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1979 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1979
new file mode 100644
index 00000000..da73ab7a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1979
@@ -0,0 +1,31 @@
+pc-q35-7.2 breaks the pcie hot plugin
+Description of problem:
+the new pc-q35 version >6.0 break the pcie hot plug feature
+if I use 5.2, 6.0, it works fine. `dmesg | grep pcieport` shows that:
+there is pciehp which provide functionality of hot plug for PCIE device
+```
+[test@localhost ~]$ dmesg | grep pcieport
+[    1.161129] pcieport 0000:00:02.0: PME: Signaling with IRQ 24
+[    1.162254] pcieport 0000:00:02.0: AER: enabled with IRQ 24
+[    1.163218] pcieport 0000:00:02.0: pciehp: Slot #0 AttnBtn+ PwrCtrl+ MRL- AttnInd+ PwrInd+ HotPlug+ Surprise+ Interlock+ NoCompl- IbPresDis- LLActRep+
+```
+
+if I switch to 6.1, 6.2, 7.0, 7.1 ,7.2, the pciehp does not show any control slot.
+```
+[test@localhost ~]$ dmesg | grep pcieport
+[    1.164311] pcieport 0000:00:02.0: PME: Signaling with IRQ 24
+[    1.165446] pcieport 0000:00:02.0: AER: enabled with IRQ 24
+```
+Steps to reproduce:
+1. run the qemu command as I produced
+2. connect to console
+3. run `dmesg | grep pcieport`
+4. you can try to plug in a GPU or something else, the device initialization will fail because there is no pciehp slow to power it on, normall you will see something like following, with >6.0 you cannot see them:
+  ```
+  pciehp: Slot(0-8): Attention button pressed
+  pciehp: Slot(0-8) Powering on due to button press
+  pciehp: Slot(0-8): Card present
+  pciehp: Slot(0-8): Link Up
+  ```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1980 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1980
new file mode 100644
index 00000000..265ddb47
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1980
@@ -0,0 +1,13 @@
+pipewire backend, bad mic sound
+Description of problem:
+Qemu VM and openSUSE share the webcam mic.
+Pipewire is used by openSUSE.
+
+If using qemu with pa backend, there is no sound problem when mic is used by Skype in openSUSE.
+If using qemu with pipewire backend and Skype used the mic then my contact says he does not recognize my voice and there are cracks.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1982 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1982
new file mode 100644
index 00000000..c089f782
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1982
@@ -0,0 +1,9 @@
+PS/2 mouse and keyboard not disabled when adding USB devices
+Description of problem:
+Documentation (such as https://www.qemu.org/docs/master/system/qemu-manpage.html or https://www.qemu.org/docs/master/system/devices/usb.html) says that enabling a USB keyboard or mouse (or tablet) will disable the PS/2 equivalent, but it seems both are present instead.
+Steps to reproduce:
+1. Pass a `-usbdevice` or `-device` option to QEMU.
+2. Boot Haiku.
+3. Find two identical devices in Preferences > Input, both `Extended PS/2 Mouse 1` and `USB Tablet 1`, as well as `AT Keyboard 1` and `USB Keyboard 1`.
+Additional information:
+The content of /var/log/syslog, which shows discovery of PS/2 devices: [syslog.zst](/uploads/7ed067538c94edfdbaf35ec92a422c68/syslog.zst)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1983 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1983
new file mode 100644
index 00000000..6f645021
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1983
@@ -0,0 +1,30 @@
+Guest boot displays "virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1" and then happens Call Trace
+Description of problem:
+Guest boot displays "FATAL: Module scsi_wait_scan not found", and then happens Call Trace.
+
+```
+Call Trace:
+ dump_stack+0x4f/0x66
+ panic+0xa2/0x258
+ do_exit+0x858/0xab0
+ do_group_exit+0x2f/0x90
+ ? do_page_fault+0x18c/0x4c0
+ sys_exit_group+0x11/0x20
+ do_fast_syscall_32+0x8b/0x1c2
+ entry_SYSENTER_32+0xa5/0xf8
+EIP: 0xb7fcec71
+Code: 89 01 31 c0 89 51 04 89 71 08 89 79 0c eb 03 83 c8 ff 83 c4 28 5b 5e 5f 5d c3 8b 1c 24 c3 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
+EAX: ffffffda EBX: 00000001 ECX: 034c4745 EDX: 00000000
+ESI: 00000000 EDI: 00000000 EBP: bff7db18 ESP: bff7da3c
+DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246
+Kernel Offset: 0x16c00000 from 0xc0400000 (relocation range: 0xc0000000-0xf75fdfff)
+```
+Steps to reproduce:
+1.Create guest by using the command
+   ```
+   ./qemu-system-x86_64 -accel kvm -m 4096 -smp 4 -cpu host  -drive file=test-img.qcow2,format=qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0,bootindex=0 -monitor pty -daemonize -vnc :32137 -device virtio-net-pci,netdev=nic0,mac=00:c2:58:38:8e:f0 -netdev tap,id=nic0,br=virbr0,helper=/usr/local/libexec/qemu-bridge-helper,vhost=on
+   ```
+Additional information:
+Suspected to be a QEMU regression issue, the first bad commit id: 14f5a7bae4cb5ca45a03e16b5bb0c5d766fd51b7.
+
+Latest successful version commit id: cea3ea670fe265421131aad90c36fbb87bc4d206
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1984 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1984
new file mode 100644
index 00000000..8ca10d58
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1984
@@ -0,0 +1 @@
+Fails to start dataplane while using vdpa-dev with vduse backend
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1988 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1988
new file mode 100644
index 00000000..5fdac05f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1988
@@ -0,0 +1,26 @@
+8.2.0rc0 Regression: '-display vnc' opens gtk display as well
+Description of problem:
+A VNC display is requested, but a GTK frontend is opened as well. A VNC client is able to connect.
+Steps to reproduce:
+1. /configure --enable-fdt=internal --target-list=x86_64-softmmu
+2. make 
+3. build/qemu-system-x86_64 -display vnc=:05 -k de
+Additional information:
+git bisect finally shows
+```
+484629fc8141eaa257f961b5e5e310a1bbd0f1a2 is the first bad commit
+commit 484629fc8141eaa257f961b5e5e310a1bbd0f1a2
+Author: Marc-André Lureau <marcandre.lureau@redhat.com>
+Date:   Wed Oct 25 17:21:17 2023 +0400
+
+    vl: simplify display_remote logic
+    
+    Bump the display_remote variable when the -vnc option is parsed, just
+    like -spice.
+    
+    Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
+    Reviewed-by: Thomas Huth <thuth@redhat.com>
+
+ system/vl.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1989 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1989
new file mode 100644
index 00000000..1e0de3e1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1989
@@ -0,0 +1,32 @@
+Regression: by default qemu opens both vnc and stdout console
+Description of problem:
+Running qemu with a vnc display (by default I'm not using the -display option) and -monitor stdio,
+it fails because the display also wants the std output (it fails even if a pass the -vnc option).
+If I remove the monitor I have both the vnc and the std output console at the same time.
+I was able to use `-monitor stdio`, passing `-serial telent:...`
+Steps to reproduce:
+1. ./configure --enable-slirp --target-list=x86_64-softmmu --disable-user --disable-docs
+2. make -j 4
+3. qemu-system-x86_64 ... (without `-display` as shown above)
+Additional information:
+After bisecting I found the following commit changed the behavior:
+
+```
+commit 1bec1cc0da497e55c16e2a7b50f94cdb2a02197f
+Author: Marc-André Lureau <marcandre.lureau@redhat.com>
+Date:   Tue Sep 5 23:18:08 2023 +0400
+
+    ui/console: allow to override the default VC
+
+    If a display is backed by a specialized VC, allow to override the
+    default "vc:80Cx24C".
+
+    As suggested by Paolo, if the display doesn't implement a VC (get_vc()
+    returns NULL), use a fallback that will use a muxed console on stdio.
+
+    This changes the behaviour of "qemu -display none", to create a muxed
+    serial/monitor by default (on TTY & not daemonized).
+
+    Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
+    Reviewed-by: Thomas Huth <thuth@redhat.com>
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/199 b/gitlab/issues_text/target_missing/host_missing/accel_missing/199
new file mode 100644
index 00000000..f19f46d3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/199
@@ -0,0 +1 @@
+Convert QAPI to static types
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1994 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1994
new file mode 100644
index 00000000..3ba76b2d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1994
@@ -0,0 +1 @@
+MacOS window sizing bug
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1995 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1995
new file mode 100644
index 00000000..349d24d7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1995
@@ -0,0 +1 @@
+No equivalent of `-boot once` for `bootindex`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1996 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1996
new file mode 100644
index 00000000..7f889966
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1996
@@ -0,0 +1,67 @@
+[Regression in v8.2.0-rc0] [macOS] configure: `ld: unknown options: --version `
+Description of problem:
+On macOS, `./configure` fails since v8.2.0-rc0 due to `ld: unknown options: --version`
+Steps to reproduce:
+```console
+$ ./configure 
+Using './build' as the directory for build output
+python determined to be '/usr/local/bin/python3'
+python version: Python 3.11.6
+mkvenv: Creating non-isolated virtual environment at 'pyvenv'
+mkvenv: checking for meson>=0.63.0
+mkvenv: installing meson==0.63.3
+mkvenv: checking for sphinx>=1.6
+mkvenv: checking for sphinx_rtd_theme>=0.5
+
+'sphinx==5.3.0' not found:
+ • Python package 'sphinx' was not found nor installed.
+ • mkvenv was configured to operate offline and did not check PyPI.
+
+
+Sphinx not found/usable, disabling docs.
+Disabling PIE due to missing toolchain support
+The Meson build system
+Version: 0.63.3
+Source dir: /Users/suda/gopath/src/gitlab.com/qemu-project/qemu
+Build dir: /Users/suda/gopath/src/gitlab.com/qemu-project/qemu/build
+Build type: native build
+Project name: qemu
+Project version: 8.1.90
+
+../meson.build:1:0: ERROR: Unable to detect linker for compiler `cc -m64 -mcx16 -Wl,--version`
+stdout: 
+stderr: ld: unknown options: --version 
+clang: error: linker command failed with exit code 1 (use -v to see invocation)
+
+
+A full log can be found at /Users/suda/gopath/src/gitlab.com/qemu-project/qemu/build/meson-logs/meson-log.txt
+
+ERROR: meson setup failed
+
+
+```
+Additional information:
+```console
+$ cc -m64 -mcx16 -Wl,--version
+ld: unknown options: --version 
+clang: error: linker command failed with exit code 1 (use -v to see invocation)
+
+$ cc --version
+Apple clang version 15.0.0 (clang-1500.0.40.1)
+Target: x86_64-apple-darwin23.1.0
+Thread model: posix
+InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bi
+
+$ ld --version
+ld: unknown option: --version
+
+$ ld -v
+@(#)PROGRAM:ld  PROJECT:dyld-1015.7
+BUILD 16:59:22 Oct  1 2023
+configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
+will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k armv7m armv7em
+LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 29)
+TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.3)
+Library search paths:
+Framework search paths:
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1997 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1997
new file mode 100644
index 00000000..6befbcce
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/1997
@@ -0,0 +1,20 @@
+Disk corruption on ARM64 (Apple Silicon) Linux VMs
+Description of problem:
+aarch64 Linux VMs will encounter disk corruption if they're set up with a filesystem that will notice it when it happens, e.g. BTRFS.  This seems to be across the board with products, including Apple Hypervisor Framework, or just QEMU, so it very well might be an aarch64 Linux bug.
+Steps to reproduce:
+1. Install an aarch64 Linux VM using BTRFS as the root filesystem.  ZFS might recognize silent corruption readily as well.
+2. Run `stress-ng --iomix 4`
+3. Check your `dmesg` and/or `btrfs check --force <device>` to check for filesystem corruption.
+Additional information:
+This is discussed in two other tickets, but I'm hoping to get more attention to the problem here.
+[https://github.com/lima-vm/lima/issues/1957](https://github.com/lima-vm/lima/issues/1957)
+[](https://github.com/utmapp/UTM/issues/4840)
+
+![Screenshot_2023-11-22_at_10.20.23_AM](/uploads/ae8ed51c7adb59933c4f7f9673dddd3d/Screenshot_2023-11-22_at_10.20.23_AM.png)
+
+![Screenshot_2023-11-22_at_10.20.23_AM](https://i.imgur.com/HwqrFQE.png)
+
+I can't seem to figure out how to upload images, but you can probably get to the image that I'm trying to share somehow...
+
+
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/200 b/gitlab/issues_text/target_missing/host_missing/accel_missing/200
new file mode 100644
index 00000000..e0376078
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/200
@@ -0,0 +1 @@
+Add Python linters (mypy, pylint, isort, flake8) to Gitlab CI
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2001 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2001
new file mode 100644
index 00000000..22c0923b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2001
@@ -0,0 +1,43 @@
+qemu_img convert and drive mirror migrate the same raw disk to rbd volume, will get the different USED size in ceph cluster.
+Description of problem:
+qemu_img convert and drive mirror migrate the same raw disk to rbd volume, will get the different USED size in ceph cluster.
+Steps to reproduce:
+create raw and qcow2 disk
+
+1. qemu-img create -f raw lvm_volume_1.raw 12G
+2. qemu-img create -f qcow2 lvm_volume_1.qcow2 12G
+
+   install a centos OS
+
+3. qemu-system-x86_64 -m 4096 -drive file=lvm_volume_1.qcow2,format=qcow2,index=0 -nographic -cdrom CentOS-8.3.2011-x86_64-dvd1.iso -vnc :25
+
+   convert the qcow2 OS disk to q raw OS disk
+
+4. qemu-img convert -f qcow2 -O raw ./lvm_volume_1.qcow2 ./lvm_volume_1.raw
+
+   create a qemu-rbd process
+
+5. qemu-nbd --fork  -x node1 -p 1238 rbd:cephpool- test/volume_1:id=xxx:key=xxx:mon_host=xxx:auth_supported=cephx
+
+   boot the raw OS disk
+
+6. qemu-system-x86_64 -hda ./lvm_volume_1.raw -m 4096 -smp 4 -vnc :25 -monitor stdio
+   
+   migrate the raw OS disk to a ceph volume
+
+7. drive_mirror -n  -f #block125 nbd:localhost:1238:exportname=node1 raw
+   
+   check the rbd volume USED size in ceph cluster
+   "rbd du cephpool-test/volume_1"
+   the ceph rbd volume PROVISION and USED are the same size
+
+   convert the raw OS disk to a ceph volume
+
+8. qemu-img convert -n -f raw -O raw ./lvm_volume_1.raw rbd:cephpool- 
+test/volume_2:id=xxx:key=xxx:mon_host=xxx:auth_supported=cephx
+
+   check the rbd volume USED size in ceph cluster 
+   "rbd du cephpool-test/volume_2"
+   the ceph rbd volume PROVISION and USED are different PROVISION > USED
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2002 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2002
new file mode 100644
index 00000000..20631211
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2002
@@ -0,0 +1,3 @@
+Need to be able to set WM_CLASS under X11
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2004 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2004
new file mode 100644
index 00000000..1b4b0cf6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2004
@@ -0,0 +1,33 @@
+do_guest_openat /proc interposition doesn't work for openat
+Description of problem:
+For instance, trying with hppa emulated on top of x86:
+
+```
+$ hppa-linux-gnu-gcc test.c -o test
+$ qemu-hppa-static ./test
+```
+
+One gets the host cpu information:
+
+```
+processor	: 0
+vendor_id	: GenuineIntel
+cpu family	: 6
+model		: 142
+model name	: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz
+[...]
+```
+
+while we would want to see the guest cpu information, like the test program does when `#if 0` is turned into `#if 1`:
+
+```
+processor	: 0            
+cpu family	: PA-RISC 1.1e
+cpu		: PA7300LC (PCX-L2)
+capabilities	: os32
+model		: 9000/778/B160L - Merlin L2 160 QEMU (9000/778/B160L)
+```
+
+This is because `do_guest_openat` only checks for the path, and does not look at `dirfd`, so it doesn't recognize that `openat(dirfd, "cpuinfo", O_RDONLY)` is actually opening a file in `/proc`.
+
+We could probably, when `dirfd` is not `AT_FDCWD`, try to `fstat()` it, open `/proc` with `O_DIRECTORY` and `fstat()` that too, and compare their `st_dev` and `st_ino`?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2006 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2006
new file mode 100644
index 00000000..b22555fd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2006
@@ -0,0 +1,42 @@
+migrating failed with rcu_preempt message on proxmox 8
+Description of problem:
+when i migrate the VM from one host to another, it fails and give messages:
+
+   ```
+[  584.109502] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
+[  584.109534] rcu: 	1-...!: (0 ticks this GP) idle=1408/0/0x0 softirq=8428/8428 fqs=0 (false positive?)
+[  584.109556] 	(detected by 0, t=5252 jiffies, g=2953, q=74 ncpus=2)
+[  584.109561] Sending NMI from CPU 0 to CPUs 1:
+[  584.109587] NMI backtrace for cpu 1 skipped: idling at native_safe_halt+0xb/0x10
+[  584.110564] rcu: rcu_preempt kthread timer wakeup didn't happen for 5251 jiffies! g2953 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
+[  584.110585] rcu: 	Possible timer handling issue on cpu=1 timer-softirq=8006
+[  584.110597] rcu: rcu_preempt kthread starved for 5252 jiffies! g2953 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=1
+[  584.110614] rcu: 	Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
+[  584.110645] rcu: RCU grace-period kthread stack dump:
+[  584.110658] task:rcu_preempt     state:I stack:0     pid:15    ppid:2      flags:0x00004000
+[  584.110667] Call Trace:
+[  584.110672]  <TASK>
+[  584.110688]  __schedule+0x351/0xa20
+[  584.110699]  ? rcu_gp_cleanup+0x480/0x480
+[  584.110704]  schedule+0x5d/0xe0
+[  584.110705]  schedule_timeout+0x94/0x150
+[  584.110709]  ? __bpf_trace_tick_stop+0x10/0x10
+[  584.110714]  rcu_gp_fqs_loop+0x141/0x4c0
+[  584.110717]  rcu_gp_kthread+0xd0/0x190
+[  584.110720]  kthread+0xe9/0x110
+[  584.110725]  ? kthread_complete_and_exit+0x20/0x20
+[  584.110728]  ret_from_fork+0x22/0x30
+[  584.110735]  </TASK>
+[  584.110736] rcu: Stack dump where RCU GP kthread last ran:
+[  584.110747] Sending NMI from CPU 0 to CPUs 1:
+[  584.110757] NMI backtrace for cpu 1 skipped: idling at native_safe_halt+0xb/0x10
+
+   ```
+
+we can reproduce on our R630 cluster easily, but it is OK on R730 cluster and R740 cluster.
+Steps to reproduce:
+1. create and run an VM
+2. migrate the vm to other host
+3. it failed with message
+Additional information:
+i downgrade the pve-qemu-kvm from 8.1.2-4 to 8.0.2-3, same problem.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2009 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2009
new file mode 100644
index 00000000..87bda221
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2009
@@ -0,0 +1 @@
+ld: warning: -undefined error is deprecated
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/201 b/gitlab/issues_text/target_missing/host_missing/accel_missing/201
new file mode 100644
index 00000000..eb7bc889
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/201
@@ -0,0 +1 @@
+Create an asynchronous Python QMP library
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2011 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2011
new file mode 100644
index 00000000..04a4a23f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2011
@@ -0,0 +1 @@
+ARM emulation layer for Windows x86_64 OS request
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2012 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2012
new file mode 100644
index 00000000..193ce0c1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2012
@@ -0,0 +1,12 @@
+Possible regression: Windows 95 setup fails on show of license
+Description of problem:
+Install of Windows 95 fails when showing the license. Qemu v8.1.0 is fine, Qemu 8.1.3 and later failes. Git bisect suggest the problem may have been introduced at 9fb45b05582438dcd52d2d48d48feb05de680c37
+Steps to reproduce:
+1. Find install CD for Windows 95 and a DOS boot floppy
+2. Create a harddrive (size 300MB)
+3. Boot from floppy, create and format partition C: using all available space
+4. change to the CD at D: and run command SETUP.EXE
+5. follow instructions until display of license
+6. See error: SUWIN caused a General Protection Fault in module <unknown>
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2014 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2014
new file mode 100644
index 00000000..b3cc9db9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2014
@@ -0,0 +1,53 @@
+virtio: bounce.in_use==true in virtqueue_map_desc()
+Description of problem:
+
+Steps to reproduce:
+1. Build EDK II (edk2-stable202311) for riscv64
+2. Build UEFI SCT (commit 81dfa8d53d4290) for riscv64
+3. Run the UEFI SCT
+4. Observe the message "qemu: virtio: bogus descriptor or out of resources" after which the execution stalls.
+
+The full procedure is described in https://github.com/xypron/sct_release_test
+
+To save time you can call `sct -u` and select only test 'MediaAccessTest\\BlockIOProtocolTest'. Run it with `F9`.
+Additional information:
+virtqueue_map_desc() may be called for a large buffers size `sz`. It will then call dma_memory_map() multiple times in a loop. In address_space_map() `bounce.in_use` is set to `true` on the first call. Each subsequent call is bound to fail.
+
+To verify this is the cause I applied the following diff:
+
+```plaintext
+diff --git a/system/physmem.c b/system/physmem.c
+index a63853a7bc..12b3c2f828 100644
+--- a/system/physmem.c
++++ b/system/physmem.c
+@@ -3151,12 +3151,16 @@ void *address_space_map(AddressSpace *as,
+ 
+     if (!memory_access_is_direct(mr, is_write)) {
+         if (qatomic_xchg(&bounce.in_use, true)) {
++           fprintf(stderr, "bounce.in_use in address_space_map\n");
++
+             *plen = 0;
+             return NULL;
+         }
+         /* Avoid unbounded allocations */
+         l = MIN(l, TARGET_PAGE_SIZE);
+         bounce.buffer = qemu_memalign(TARGET_PAGE_SIZE, l);
++       if (!bounce.buffer)
++           fprintf(stderr, "Out of memory in address_space_map\n");
+         bounce.addr = addr;
+         bounce.len = l;
+```
+
+and saw this output:
+
+```plaintext
+Logfile: "\sct\Log\MediaAccessTest\BlockIOProtocolTest0\ReadBlocks_Conf_0_0_8261
+59D3-04A5-4CCE-8431-344707A8B57A.log"
+Test Started: 12/02/23  08:43a
+------------------------------------------------------------
+Current Device: Acpi(PNP0A03,0)/Pci(3|0)
+Bounce.in_use in address_space_map
+qemu: virtio: bogus descriptor or out of resources
+```
+
+See related bug #850.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2016 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2016
new file mode 100644
index 00000000..73b8a5b8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2016
@@ -0,0 +1,9 @@
+-virtfs not working on windows
+Description of problem:
+performing the above returns
+qemu-system-aarch64.exe: -virtfs abc: There is no option group 'virtfs'
+qemu-system-aarch64.exe: -virtfs abc: virtfs support is disabled
+Steps to reproduce:
+1.qemu-system-aarch64.exe -virtfs abc
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2018 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2018
new file mode 100644
index 00000000..b60d0dfc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2018
@@ -0,0 +1,18 @@
+QEMU would not start when trying to create two UFS host controllers
+Description of problem:
+This issue is reported by Akinobu Mita.
+https://lore.kernel.org/qemu-devel/20231204150543.48252-1-akinobu.mita@gmail.com/
+
+> QEMU would not start when trying to create two UFS host controllers and a UFS logical unit for each with the following options:
+> 
+> -device ufs,id=bus0 \
+> -device ufs-lu,drive=drive1,bus=bus0,lun=0 \
+> -device ufs,id=bus1 \
+> -device ufs-lu,drive=drive2,bus=bus1,lun=0 \
+> 
+> This is because the same ID string ("0:0:0/scsi-disk") is generated
+> for both UFS logical units.
+> 
+> To fix this issue, prepend the parent pci device's path to make
+> the ID string unique.
+> ("0000:00:03.0/0:0:0/scsi-disk" and "0000:00:04.0/0:0:0/scsi-disk")
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2019 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2019
new file mode 100644
index 00000000..986dcf9d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2019
@@ -0,0 +1,26 @@
+Additional network device is not recognized on windows guest vm
+Description of problem:
+I have a problem for using Windows 2019/2022 guest vm as QEMU.
+When I add a network device more online, it isn't work and recognized.
+There is an error occurs at the Device Manager.
+
+![l_65244916_3042_e9293618b64f73fb24d04ad6d99834d6](/uploads/9cbbc08f33653bf79ed6709adafcefae/l_65244916_3042_e9293618b64f73fb24d04ad6d99834d6.png)
+
+I added network device with this qmp command
+```
+'{ "execute": "chardev-add", "arguments":{"id":"charnet_35", "backend": { "type" : "socket", "data" : { "addr" : { "type" : "unix", "data" : {"path" : "/tmp/17115.1''"}}, "server" : true, "wait" : false }}}}' | nc -U $socket -N
+'{ "execute": "netdev_add", "arguments":{"type":"vhost-user", "id":"'hostnet_35", "chardev":"charnet_35", "queues":2 }}' | nc -U $socket -N
+'{ "execute" : "device_add", "arguments" : {"driver" : "virtio-net-pci", "mq":"on" ,"vectors":6, "netdev":"hostnet_35", "id":"dpdk_35", "mac":"F2:20:AF:40:12:65", "bus" : "bridge", "addr" : "0x8", "page-per-vq": "on", "rx_queue_size" : 1024, "tx_queue_size": 1024, "mrg_rxbuf" : "on", "disable-legacy": "on",  "disable-modern" : "off" , "host_mtu" : 1500, "csum" : "on", "guest_csum" : "on", "host_tso4" : "on", "host_tso6" : "on"}}' |  nc -U $socket -N
+```
+
+But, I can check recognized additional Network device after Windows guest vm rebooted.
+Steps to reproduce:
+1. Boot Windows 2019/2022 guest vm
+2. Add chardev, netdev, device more with qmp command as hotplug
+3. Check Network device recognition on the guest os
+Additional information:
+- I'm using hardware vDPA offloading with mellanox NIC card.
+And When I use tap device instead vhost-user at the netdev, I don't have any problem. That error does not occured
+
+- And second, when I disable the first NIC, The additional NIC is recognized.
+![l_81109386_136_4cb3ca427f2fe03fa2d941476cfd188e](/uploads/14448b3a6dc4b5da94c557b2521a688f/l_81109386_136_4cb3ca427f2fe03fa2d941476cfd188e.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/202 b/gitlab/issues_text/target_missing/host_missing/accel_missing/202
new file mode 100644
index 00000000..a2b5a704
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/202
@@ -0,0 +1 @@
+Move scripts/qmp/qom-* tooling into qemu.qmp.*
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2021 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2021
new file mode 100644
index 00000000..b1fe0a47
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2021
@@ -0,0 +1 @@
+crashing when trying to read data from sensor though usb
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2023 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2023
new file mode 100644
index 00000000..12d573d2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2023
@@ -0,0 +1 @@
+[block jobs]qemu hang when creating snapshot target node(iothread enable)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2024 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2024
new file mode 100644
index 00000000..46870ebb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2024
@@ -0,0 +1,30 @@
+IPv6 DHCPv6 DUID-UUID Generation Issue with iPXE on QEMU 8.1.2 and SMBIOS 3.0
+Description of problem:
+I'm creating this ticket in both projects affected as I'm unsure which side needs to resolve it. I discovered this bug after upgrading Proxmox to version 8.1. I use iPXE to boot in IPv6 and retrieve the configuration from a web server. I have a DHCPv6 and SLAAC server configured.
+
+In this configuration, iPXE is unable to generate the necessary DUID-UUID for IPv6. If I revert to the previous QEMU version (using the machine: pc-i440fx-8.0 option in Proxmox), I have no issues. The only difference I notice and understand is the switch to SMBIOS 3.0, which is 64 bits, compared to SMBIOS 2.8, which is 32 bits. It appears to be the same issue with Libvirt. By default, it uses pc-q35-8.1, and I encounter the bug. However, if I switch to pc-q35-8.0, the problem is resolved.
+
+I've included two sets of information in the first part. The first one is from my local computer using libvirt, making it easier to reproduce the bug. The second set is from my production environment.
+
+Here's the iPXE trace:
+
+```plaintext
+iPXE>  ifconf --configurator ipv6
+Configuring [ipv6] (net0 66:b5:3e:97:7d:4e)...
+DHCPv6 net0 could not create DUID-UUID: No such file or directory (https://ipxe.org/2d0c203b)
+No such file or directory (https://ipxe.org/2d0c203b)
+```
+Steps to reproduce:
+1. Create a PXE ISO with IPv6 debug options:
+   1. Clone the iPXE repository with the following command:
+      * `git clone https://github.com/ipxe/ipxe`
+   2. Navigate to the src directory:
+      * `cd ipxe/src`
+   3. Build the iPXE ISO with IPv6 debug options using the following command:
+      * `DEBUG='dhcpv6,neighbour' make bin/ipxe.iso`
+2. Set up a Libvirt network with DHCPv6 enabled (example configuration provided in the next section).
+3. Create a virtual machine with the generated iPXE ISO and the network configured for IPv6.
+4. Press `Ctrl+B` to access the iPXE shell.
+5. Execute the command `ifconf --configurator ipv6` in the iPXE shell.
+Additional information:
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2025 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2025
new file mode 100644
index 00000000..06612008
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2025
@@ -0,0 +1,26 @@
+Can't make the touchscreen work in Windows VM, device virtio-multitouch-pci not starting
+Description of problem:
+I tried the multitouch on qemu 8, by adding "-device virtio-multitouch-pci" to the qemu cmd line
+I could make the multitouch work for an Ubuntu VM, but not for a Windows VM
+Last version of Virtio drivers are installed in Windows.
+
+Here are the issues i can see in windows : 
+![image](/uploads/9865057934d3668850742905e646bbcc/image.png)
+
+Windows Events of virtio input driver device :
+
+```
+Device PCI\VEN_1AF4&DEV_1052&SUBSYS_11001AF4&REV_01\3&2411e6fe&0&18 had a problem starting.
+Driver Name: oem7.inf
+Class Guid: {745a17a0-74d3-11d0-b6fe-00a0c90f57da}
+Service: VirtioInput
+Lower Filters:
+Upper Filters:
+Problem: 0xA
+Problem Status: 0xC000009A
+```
+Qemu didnt produce any logs regarding this PCI 
+
+Do I miss something ? 
+
+Thanks for your help
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2026 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2026
new file mode 100644
index 00000000..d38bc90e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2026
@@ -0,0 +1,8 @@
+Virtio-vga-gl: If xres/yres is set, Qemu should not inherit the resolution of the window
+Description of problem:
+Despite setting xres=1920,yres-1080 when the VM the resolution the VM gets set to is inherited from the window.
+Steps to reproduce:
+1. Launch VM with xres/yres set
+2. check display size
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2028 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2028
new file mode 100644
index 00000000..76b53ddb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2028
@@ -0,0 +1 @@
+CAN sja1000 standard frame filter bug
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2029 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2029
new file mode 100644
index 00000000..b06a3e0d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2029
@@ -0,0 +1 @@
+[block jobs]Guest hang when dd file on snapshot overlay(iothread enable)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/203 b/gitlab/issues_text/target_missing/host_missing/accel_missing/203
new file mode 100644
index 00000000..826ccd1f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/203
@@ -0,0 +1 @@
+move ./scripts/qapi/ to ./python/qemu/qapi/
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2031 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2031
new file mode 100644
index 00000000..85db5b66
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2031
@@ -0,0 +1,13 @@
+Redundant comparison
+Description of problem:
+The result of the function `qdev_get_hotplug_handler` is always __NULL__. That is why the comparison in the line №502 is redundant:
+
+https://gitlab.com/qemu-project/qemu/-/blob/master/hw/core/qdev.c#L501
+
+This code will never be executed:
+
+https://gitlab.com/qemu-project/qemu/-/blob/master/hw/core/qdev.c#L502-L507
+
+Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
+
+Author A. Voronin.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2032 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2032
new file mode 100644
index 00000000..32cd6035
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2032
@@ -0,0 +1,31 @@
+qemu-guest-agent not starting
+Description of problem:
+Trace found in syslog :
+```
+syslog:Dec 11 13:45:08 mail systemd[1]: dev-virtio\x2dports-org.qemu.guest_agent.0.device: Job dev-virtio\x2dports-org.qemu.guest_agent.0.device/start timed out.
+syslog:Dec 11 13:45:08 mail systemd[1]: Timed out waiting for device /dev/virtio-ports/org.qemu.guest_agent.0.
+syslog:Dec 11 13:45:08 mail systemd[1]: qemu-guest-agent.service: Job qemu-guest-agent.service/start failed with result 'dependency'.
+syslog:Dec 11 13:45:08 mail systemd[1]: dev-virtio\x2dports-org.qemu.guest_agent.0.device: Job dev-virtio\x2dports-org.qemu.guest_agent.0.device/start failed with result 'timeout'.
+```
+Steps to reproduce:
+systemctl start qemu-guest-agent
+Additional information:
+Messages when installing the systemd unit : 
+```
+systemctl enable qemu-guest-agent
+Synchronizing state of qemu-guest-agent.service with SysV service script with /lib/systemd/systemd-sysv-install.
+Executing: /lib/systemd/systemd-sysv-install enable qemu-guest-agent
+The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
+Alias= settings in the [Install] section, and DefaultInstance= for template
+units). This means they are not meant to be enabled using systemctl.
+
+Possible reasons for having this kind of units are:
+• A unit may be statically enabled by being symlinked from another unit's
+  .wants/ or .requires/ directory.
+• A unit's purpose may be to act as a helper for some other unit which has
+  a requirement dependency on it.
+• A unit may be started when needed via activation (socket, path, timer,
+  D-Bus, udev, scripted systemctl call, ...).
+• In case of template units, the unit is meant to be enabled with some
+  instance name specified.
+ ```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2033 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2033
new file mode 100644
index 00000000..304bc46a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2033
@@ -0,0 +1 @@
+goldfish_rtc device incorrectly migrates tick offset as an offset from QEMU_CLOCK_VIRTUAL
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2035 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2035
new file mode 100644
index 00000000..b6cb5ef3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2035
@@ -0,0 +1,54 @@
+TCG Plugin exit callback not executing
+Description of problem:
+I cannot get the plugin exit callback to register/execute. I should see "Goodbye from plugin" but dont. I have also tried using `qemu_plugin_outs` without success.
+
+**Update: If I make my test binary an infinite loop and kill it with CTRL-C, then the callback is called as expected. Am I just using it wrong?**
+Steps to reproduce:
+1. Configured QEMU with `--target-list=riscv32-linux-user,riscv64-linux-user --enable-plugins --disable-system`
+2. Compiled plugin with 
+```
+gcc -I./qemu/include/qemu `pkg-config --libs glib-2.0` -O0 -fvisibility=hidden -Wall -shared -fPIC `pkg-config --cflags glib-2.0`
+```
+3. Compiled test binary (just a hello world) with `riscv64-unknown-elf-gcc test_qemu.c -o test_qemu`
+4. Ran ./qemu/build/qemu-riscv64 -plugin ./test_plugin.so -d plugin ./test_qemu
+Additional information:
+test_plugin.c
+```
+#include <inttypes.h>
+#include <assert.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <stdio.h>
+#include <qemu-plugin.h>
+
+QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION;
+
+static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb)
+{
+    int n_insns = qemu_plugin_tb_n_insns(tb);
+    printf("> New TB of size %d\n", n_insns);
+
+    for (int i = 0; i < n_insns; i++) {
+        struct qemu_plugin_insn * insn = qemu_plugin_tb_get_insn(tb, i);
+        char * disassembly = qemu_plugin_insn_disas(insn);
+        printf(" > Instruciton: %s\n", disassembly);
+    }
+}
+
+static void plugin_exit(qemu_plugin_id_t id, void *p)
+{
+    printf("> Goodbye from plugin. %d\n", id);
+}
+
+QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id,
+                                           const qemu_info_t *info,
+                                           int argc, char **argv)
+{
+    printf("> Hello From Plugin!\n");
+    qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans);
+    qemu_plugin_register_atexit_cb(id, plugin_exit, NULL);
+    printf("> Everything was registered\n");
+    return 0;
+}
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2036 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2036
new file mode 100644
index 00000000..cad6b7c0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2036
@@ -0,0 +1,11 @@
+`edk2-riscv-code.fd.bz2` is included in the repo but not installed to `$PREFIX/share/qemu`
+Description of problem:
+`edk2-riscv-code.fd.bz2` is included in the repo (https://gitlab.com/qemu-project/qemu/-/blob/v8.2.0-rc4/pc-bios/edk2-riscv-code.fd.bz2), but this file is not installed to `$PREFIX/share/qemu`.
+
+The binaries for other architectures (aarch64, arm, i386, x86\_64) are installed as expected.
+https://gitlab.com/qemu-project/qemu/-/blob/v8.2.0-rc4/pc-bios/meson.build?ref_type=tags#L3-L12
+Steps to reproduce:
+`ls $PREFIX/share/qemu/edk2-*`
+Additional information:
+- Not sure if this is intentional or a bug.
+- The descriptor JSON file is missing for riscv: https://gitlab.com/qemu-project/qemu/-/tree/v8.2.0-rc4/pc-bios/descriptors
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2038 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2038
new file mode 100644
index 00000000..55381d49
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2038
@@ -0,0 +1,16 @@
+simpletrace.py does nothing, and syntax error when called from bash script
+Description of problem:
+The simpletrace python script appears to do nothing when I run it as above. 
+
+It appears to run (but do nothing) when called from my terminal but there is also a syntax error when I run it from the bash script above.
+
+```
+SyntaxError: invalid syntax
+  File "<fstring>", line 1
+    (pid=)
+        ^
+```
+
+I think this syntax error is caused by the line `print(f'{event.name} {delta_ns / 1000:0.3f} {pid=} ' + ' '.join(fields))`
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2039 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2039
new file mode 100644
index 00000000..bd38d970
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2039
@@ -0,0 +1,11 @@
+there is no 'write' lock checked when exec `qemu-img check lvqcow2`
+Description of problem:
+There is a difference between a qcow2 file image and a lvqcow2 img.
+
+'write' lock will be checked when using a normal qcow2-format image (/path/to/img/test.qcow2) to avoid some risky operations. However, when I create a qcow2 img on a lv, there is not any write lock checked when I perform `qemu-img check` on this lvqcow2 even though it was attached to a vm.
+Steps to reproduce:
+1. create a lvqcow2: `qemu-img create -f qcow2 /path/to/lv  xxG`
+2. create a vm using this lvqcow2
+3. exec `qemu-img check` on this lvqcow2, there is no any perm (such as 'write' lock) check and notifaction even though this lvqcow2 is using in qemu vm.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/204 b/gitlab/issues_text/target_missing/host_missing/accel_missing/204
new file mode 100644
index 00000000..9be001c6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/204
@@ -0,0 +1 @@
+Dos Keypad is not working for numbers - numlock is not working
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2042 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2042
new file mode 100644
index 00000000..9a02801b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2042
@@ -0,0 +1,18 @@
+Not able to reboot Linux guest on Windows host
+Description of problem:
+I am running Linux Mint on Windows, but when I try to reboot the machine, I get the following error:
+
+qemu: WHPX: Unexpected VP exit code 4
+
+I did some experiments changing the flags I use when I launch Qemu and I realized that if I set -smp 1 it does not fail. Furthermore, if I set the irqchip to off (kernel-irqchip=off) it does not fail either, but both options do not have good performance at all. I realized too that if I set 4 cores (-smp 4), the error might appear up to 4 times.
+
+What seems to be failing then is the APIC emulation that Hyper-V provides. Does anyone know if:
+
+1. Am I missing a flag when launching Qemu?
+2. Is it there a patch to solve this?
+
+Any leads for solving this problem would be highly appreciated.
+Steps to reproduce:
+1. Install MSYS
+2. Open MSYS and run pacman -S mingw-w64-x86_64-qemu
+3. Launch Qemu and reboot machine
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2043 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2043
new file mode 100644
index 00000000..4fa216ec
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2043
@@ -0,0 +1,74 @@
+QEMU hangs sometimes during TRIM command
+Description of problem:
+I encountered a virtual machine freeze when map cache invalidation request was received while executing a TRIM command.
+
+I did some research and i think i found the problem.
+
+1. `xen_invalidate_map_cache` calls `bdrv_drain_all` before invalidation
+2. All BlockBackend devices run into quiesce mode (increment of `blk->quiesce_counter` in `blk_root_drained_begin`)
+3. When processing another block in TRIM command coroutine `blk_co_do_pdiscard` calls `blk_wait_while_drained`
+4. In `blk_wait_while_drained` we go under tre condition, decrement `in_flight` counter and yield the coroutine
+5. After return from `blk_aio_complete_bh` `in_flight` counter of `BlockBackend` device remains with value 1, which prevents `AIO_WAIT_WHILE_UNLOCKED(NULL, bdrv_drain_all_poll());` loop from exiting
+6. So QEMU stays in `bdrv_drain_all_begin` method
+
+Now why `in_flight` counter does not go to zero in point 5?
+
+Below is a call diagram for TRIM command. For example, consider processing of 2 blocks.
+
+![qemu_no_quiesce](/uploads/ddf7c0eca2147988f5bd9e8009b7eb71/qemu_no_quiesce.png)
+
+s can be seen from the diagram `in_flight` counter of BlockBackend at first increments at start of command in `ide_issue_trim`, and next in `blk_aio_prwv` before start of coroutine. But for second and next blocks we get into BH method `blk_aio_complete_bh` and before decrementing `in_flight` we call `acb->common.cb` callback, that is in fact `ide_issue_trim_cb`, so we incrementing `in_flight` again to value of 3. And decrementing to value of 2 before return from `blk_aio_complete`.
+
+So, the value of `blk->in_flight` varies in range [2..3] during block processing.
+
+Now consider the situation when map cache invalidation request is received during a block processing in TRIM command. Below is a call diagram for this situation.
+
+![qemu_quiesce](/uploads/a029c0b6aa0398815dcf761cc4a708e2/qemu_quiesce.png)
+
+In this example we get invalidation request before second block processing. Our BlockBackend device run into quiesce mode, and we yielding the coroutine in `blk_wait_while_drained`, decrementing `in_flight` counter from 3 to 2. Second decrement is made in `blk_aio_complete` (2 to 1).
+
+And now we get in situation, when we not scheduling any block processing methods, as they must be called later from `bdrv_drain_all_end`, and on the other hand, `bdrv_drain_all_poll` always returns true, as we have non-zero `in_flight` counter on one of BlockBackend devices.
+
+As one of possible solutions i try to call `blk_set_disable_request_queuing(s->blk, true);` in `ide_issue_trim` and corresponding `blk_set_disable_request_queuing(blk, false);` in `ide_trim_bh_cb`. Looks like it solves the problem, so TRIM command always process completely, as is ignore quiesce mode and not do coroutine yielding. But i think is not optimal.
+
+I try also remove incrementing and decrementing of `in_flight` counter in `ide_issue_trim` and `ide_trim_bh_cb`, so value of counter varies in range [1..2] during block processing. This also works, but i started to get warings like `Locked DMA mapping while invalidating mapcache!`, as TRIM command probably uses map cache and is not completed before actual map cache invalidation.
+Steps to reproduce:
+1. Run virtual machine
+2. Run progrms, work with files, etc.
+Additional information:
+QEMU trace logs. Enabled trace events: handle_ioreq, ide_dma_cb, dma_blk_io, dma_blk_cb, dma_complete, qemu_coroutime_yield.
+
+Log of TRIM command without freeze excerpt:
+
+```
+…
+handle_ioreq I/O=0x7ffc51d5e160 type=0 dir=0 df=0 ptr=0 port=0x1f4 data=0x0 count=1 size=1
+handle_ioreq I/O=0x7ffc51d5e160 type=0 dir=0 df=0 ptr=0 port=0x1f5 data=0x0 count=1 size=1
+handle_ioreq I/O=0x7ffc51d5e160 type=0 dir=0 df=0 ptr=0 port=0x1f7 data=0x6 count=1 size=1
+handle_ioreq I/O=0x7ffc51d5e160 type=0 dir=0 df=0 ptr=0 port=0xc160 data=0x1 count=1 size=1
+ide_dma_cb IDEState 0x5559d513ff98; sector_num=0 n=1 cmd=DMA TRIM
+dma_blk_io dbs=0x5559d5c6f350 bs=0x5559d513ff98 offset=0 to_dev=1
+dma_blk_cb dbs=0x5559d5c6f350 ret=0
+dma_blk_cb dbs=0x5559d5c6f350 ret=0
+dma_complete dbs=0x5559d5c6f350 ret=0 cb=0x5559d1585620
+handle_ioreq I/O=0x7ffc51d5e160 type=0 dir=1 df=0 ptr=0 port=0xc162 data=0x0 count=1 size=1
+handle_ioreq I/O=0x7ffc51d5e160 type=0 dir=1 df=0 ptr=0 port=0xc162 data=0x0 count=1 size=1
+handle_ioreq I/O=0x7ffc51d5e160 type=0 dir=0 df=0 ptr=0 port=0xc160 data=0x0 count=1 size=1
+…
+```
+
+Log of TRIM command with freeze:
+
+```
+…
+handle_ioreq I/O=0x7ffc52722ae0 type=8 dir=0 df=0 ptr=0 port=0x0 data=0xffffffffffffffff count=0 size=4
+handle_ioreq I/O=0x7ffc52722ae0 type=8 dir=0 df=0 ptr=0 port=0x0 data=0xffffffffffffffff count=0 size=4
+handle_ioreq I/O=0x7ffc52722ae0 type=8 dir=0 df=0 ptr=0 port=0x0 data=0xffffffffffffffff count=0 size=4
+handle_ioreq I/O=0x7ffc52722ae0 type=0 dir=0 df=0 ptr=0 port=0xc160 data=0x1 count=1 size=1
+ide_dma_cb IDEState 0x55c76faccf98; sector_num=0 n=1 cmd=DMA TRIM
+dma_blk_io dbs=0x55c770425b50 bs=0x55c76faccf98 offset=0 to_dev=1
+dma_blk_cb dbs=0x55c770425b50 ret=0
+handle_ioreq I/O=0x7ffc52722ae0 type=8 dir=0 df=0 ptr=0 port=0x0 data=0xffffffffffffffff count=0 size=4
+qemu_coroutine_yield from 0x55c76f4207f0 to 0x7f7fb099e0c0
+[end of log, no more events]
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2045 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2045
new file mode 100644
index 00000000..7c57179b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2045
@@ -0,0 +1 @@
+virtio-gpu-*-pci Support reset of virtual GPU from /sys/bus/pci/devices/$NUMBER/reset
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2046 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2046
new file mode 100644
index 00000000..607101a7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2046
@@ -0,0 +1 @@
+live migration error : qemu-kvm: Missing section footer for 0000:00:01.3/piix4_pm
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2047 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2047
new file mode 100644
index 00000000..5ffa31a6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2047
@@ -0,0 +1,3 @@
+Support of LibVF.IO - vendor neutral GPU multiplexing tool driven by YAML & VFIO.
+Additional information:
+Git: https://github.com/Arc-Compute/LibVF.IO/tree/master/
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2048 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2048
new file mode 100644
index 00000000..76520a9f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2048
@@ -0,0 +1 @@
+Host: Wayland sdl display problem
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2049 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2049
new file mode 100644
index 00000000..603872a9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2049
@@ -0,0 +1,11 @@
+drive-mirror RBD thin
+Description of problem:
+I found that this problem was first discovered in 2014. There was a post 
+[2014 bug description](https://lists.gnu.org/archive/html/qemu-devel/2014-10/msg01231.html )、
+[2014 patch](https://patchwork.ozlabs.org/project/qemu-devel/patch/1433747185-16797-2-git-send-email-famz@redhat.com/)
+mentioning this bug. 
+The patch in the post said that this problem had been solved, but after trying and asking, I found that the problem had not been solved.
+Later, I saw this problem in the [2017 bug description](https://forum.proxmox.com/threads/drive-mirror-rbd-thin.33250/#post-613502) forum and it was said that there was a patch to fix it, but it was not.
+I tried the latest qemu version and found that this problem has not been solved.
+Additional information:
+nbd is normal, but rbd is wrong！
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/205 b/gitlab/issues_text/target_missing/host_missing/accel_missing/205
new file mode 100644
index 00000000..e258c406
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/205
@@ -0,0 +1 @@
+Arrow keys press is double in some programs in Dos
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2050 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2050
new file mode 100644
index 00000000..703249b3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2050
@@ -0,0 +1,7 @@
+Graphical glitch on boot screen of ubuntu aarch64
+Description of problem:
+Glitches on boot screen.
+Additional information:
+![image](/uploads/e681648f2a82668ba22a49622ed794fa/image.png)
+
+(The "TIANO Core" screen before this has similar issues)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2051 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2051
new file mode 100644
index 00000000..fae44e28
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2051
@@ -0,0 +1 @@
+virtio-gpu redraw issue
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2052 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2052
new file mode 100644
index 00000000..e75c20e1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2052
@@ -0,0 +1 @@
+sdl window partially catches mouse cursor
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2055 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2055
new file mode 100644
index 00000000..9aee4a8b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2055
@@ -0,0 +1,7 @@
+Unable to set the PBMTE bit in the menvcfg register for RISCV 64 bit
+Description of problem:
+We are unable to program the PBMTE bit in the menvcfg register of a RV64 machine. The following is the command that was used to do this.
+ 
+write_csr(menvcfg,PTE_PBMT);
+Steps to reproduce:
+1. A simple test program with the above command should be able to reproduce this issue.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2056 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2056
new file mode 100644
index 00000000..35d968cd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2056
@@ -0,0 +1,14 @@
+macOS Cocoa title bar covers top of VM screen
+Description of problem:
+When using the Cocoa interface the title bar covers the top part of the VM screen. In Windows XP, using show-cursor=on and USB tablet (-usb -device usb-tablet,bus=usb-bus.0), the mouse cursor seems to be off by the height of the title bar; to click on a target the mouse cursor has to be below the target by about the height of the top bar.
+Steps to reproduce:
+1. Run Qemu using the Cocoa-interface (-display cocoa)
+Additional information:
+The problem exists in both Qemu 8.2.0 (compiled from source) as well as in the MacPorts version (version 8.0.5). Further testing shows the same problem in versions 6.2.0, 7.0.0, and 7.1.0. This problem did not exist in previous versions of macOS.
+
+A screenshot is enclosed:
+![Screenshot_2023-12-24_at_20.54.33](/uploads/c240185856ba412c71250d0c424345c0/Screenshot_2023-12-24_at_20.54.33.png)
+
+For similar reports, see: https://www.emaculation.com/forum/viewtopic.php?p=77350#p77350 and https://github.com/phil-opp/blog_os/issues/1249#issuecomment-1825933581 and https://68kmla.org/bb/index.php?threads/a-self-contained-qemu-based-a-ux-system-for-macos.45106/post-504970
+
+The problem exists on both Apple Silicon and Intel hardware.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2057 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2057
new file mode 100644
index 00000000..4e5fcfc2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2057
@@ -0,0 +1,5 @@
+QEMU 8.2 configure error
+Description of problem:
+please see output upper
+Steps to reproduce:
+1. Just run ./configure
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2058 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2058
new file mode 100644
index 00000000..9713d019
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2058
@@ -0,0 +1,52 @@
+QEMU should pad Ethernet frames from vmnet.framework on macOS hosts
+Description of problem:
+When using a `vmnet` network device on a macOS host, the host’s [ARP](https://en.wikipedia.org/wiki/Address_Resolution_Protocol) replies are smaller than the 64-octet minimum frame size defined for Ethernet in IEEE Std 802.3-2022 (subclause 4.2.3.3 and Table 4–2).
+
+When QEMU presents such frames to a guest, the guest’s Ethernet device driver may drop them with “frame too short” or “runt” errors, since they are smaller than actual Ethernet frames should ever be. This prevents the guest from resolving the host’s MAC address, so the guest and host can’t communicate as expected.
+
+I observed this problem with a Mac OS X 10.4.11 guest using a `sungem` or `rtl8139` virtual network device, but it might also affect other guests and virtual network devices.
+Additional information:
+To prevent this problem, QEMU should pad Ethernet frames received from `vmnet` to the minimum size, 60 bytes before the frame check sequence, before handing them off to a guest. (QEMU’s virtual network devices used to add such padding, but that was changed earlier this year in commits such as 63b901bf and aee87b43.)
+
+Here is a patch for `net/vmnet-common.m` that calls `eth_pad_short_frame()` for this, as `net/tap.c` and `net/slirp.c` already do:
+
+```
+--- net/vmnet-common.m.orig	2023-12-19 13:24:34.000000000 -0800
++++ net/vmnet-common.m	2023-12-27 13:30:15.000000000 -0800
+@@ -18,6 +18,7 @@
+ #include "qemu/error-report.h"
+ #include "qapi/error.h"
+ #include "sysemu/runstate.h"
++#include "net/eth.h"
+ 
+ #include <vmnet/vmnet.h>
+ #include <dispatch/dispatch.h>
+@@ -150,10 +151,23 @@
+  */
+ static void vmnet_write_packets_to_qemu(VmnetState *s)
+ {
++    uint8_t *pkt;
++    size_t pktsz;
++    uint8_t min_pkt[ETH_ZLEN];
++    size_t min_pktsz = sizeof(min_pkt);
++
+     while (s->packets_send_current_pos < s->packets_send_end_pos) {
+-        ssize_t size = qemu_send_packet_async(&s->nc,
+-                                      s->iov_buf[s->packets_send_current_pos].iov_base,
+-                                      s->packets_buf[s->packets_send_current_pos].vm_pkt_size,
++        pkt = s->iov_buf[s->packets_send_current_pos].iov_base;
++        pktsz = s->packets_buf[s->packets_send_current_pos].vm_pkt_size;
++
++        if (net_peer_needs_padding(&s->nc)) {
++            if (eth_pad_short_frame(min_pkt, &min_pktsz, pkt, pktsz)) {
++                pkt = min_pkt;
++                pktsz = min_pktsz;
++            }
++        }
++
++        ssize_t size = qemu_send_packet_async(&s->nc, pkt, pktsz,
+                                       vmnet_send_completed);
+ 
+         if (size == 0) {
+
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/206 b/gitlab/issues_text/target_missing/host_missing/accel_missing/206
new file mode 100644
index 00000000..ba05720c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/206
@@ -0,0 +1 @@
+Dos on the fly CD image replacement is not Working with DOS
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2060 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2060
new file mode 100644
index 00000000..f7f7ff88
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2060
@@ -0,0 +1,3 @@
+memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set
+Additional information:
+i'm using pve-qemu-kvm 8.1.2-6 on 6.5.11-7-pve kernel
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2061 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2061
new file mode 100644
index 00000000..675e416f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2061
@@ -0,0 +1,13 @@
+Regression: QEMU 8.2.0 VFIO GPU guests cannot reboot due to improper reset
+Description of problem:
+Prior to QEMU 8.2.0 (i.e. 8.1.4), rebooting the guest with VFIO GPU passed through would result in a proper reboot.
+After updating to QEMU 8.2.0, rebooting the guest results in a black screen due to improper reset behaviour.
+I was able to narrow this down to commit #3d779ab. Compiling and running with commit #0bddd88 results in the correct behaviour.
+That is, the GPU properly resets on guest reboot and boots successfully to Windows.
+Steps to reproduce:
+1. Update to QEMU 8.2.0
+2. Boot Windows 11 23H2
+3. Reboot
+4. Notice a black screen
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2062 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2062
new file mode 100644
index 00000000..9d2fe560
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2062
@@ -0,0 +1 @@
+qemu-img snapshot -l output formatting is broken (field to small / whitespace missing)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2065 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2065
new file mode 100644
index 00000000..9b6b4fe9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2065
@@ -0,0 +1 @@
+rfe: Cygwin support
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2067 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2067
new file mode 100644
index 00000000..75490346
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2067
@@ -0,0 +1 @@
+screen unblanking issue with debian 12 gui
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2068 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2068
new file mode 100644
index 00000000..48272728
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2068
@@ -0,0 +1,15 @@
+Regression: 8.1.3 -> 8.2.0 breaks virtio vga driver
+Description of problem:
+I have a number of emulated arch linuxes using the same x11/kde configuration. After updating from 8.1.3 to 8.2.0, they all broke in the following way:
+- screen tearing/artifacts seen from bios up until sddm
+- sddm is possibly affected
+- kde/x11 has so many artifacts that its unusable. if i attempt to write in a console window, i can only see parts of what ive written if i attempt to gently resize the bottom of the window. clicking the menu item will only render the menu 1/6 times and only partly. however if I click where I remember the shutdown button to be, the system shuts down immediately, so thi seems to be purely a graphics issue.
+- starting with -vga qxl fixes all issues.
+Steps to reproduce:
+1. make new qemu, install arch/kde
+2. boot said qemu with -vga virtio option
+3. observe issue from the moment it boots
+Additional information:
+Using nVidia card and drivers on host.
+
+Removing x86-video-vesa on the guest system seemed to significant improve performance. There are still many artifacts but its almost usable with this driver removed.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2069 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2069
new file mode 100644
index 00000000..84ac55e7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2069
@@ -0,0 +1,352 @@
+[virtio_blk:iothread-vq-mapping]Qemu core dump when checking the deleted device via "info qtree"
+Description of problem:
+[virtio_blk:iothread-vq-mapping]Qemu core dump when checking the deleted device via "info qtree"
+Steps to reproduce:
+1.Start guest with qemu cmds: \
+  qemu-system-x86_64 \
+    -S  \
+    -name 'avocado-vt-vm1' \
+    -machine pc,memory-backend=mem-machine_mem  \
+    -nodefaults \
+    -device '{"driver": "VGA", "bus": "pci.0", "addr": "0x2"}' \
+    -m 30720 \
+    -object '{"size": 32212254720, "id": "mem-machine_mem", "qom-type": "memory-backend-ram"}'  \
+    -smp 10,maxcpus=10,cores=5,threads=1,dies=1,sockets=2  \
+    -cpu 'Cascadelake-Server-noTSX',+kvm_pv_unhalt \
+    -chardev socket,path=/tmp/monitor-qmpmonitor1-20240104-043347-5Miq4hMP,wait=off,server=on,id=qmp_id_qmpmonitor1  \
+    -mon chardev=qmp_id_qmpmonitor1,mode=control \
+    -chardev socket,path=tmp/monitor-catch_monitor-20240104-043347-5Miq4hMP,wait=off,server=on,id=qmp_id_catch_monitor  \
+    -mon chardev=qmp_id_catch_monitor,mode=control \
+    -device '{"ioport": 1285, "driver": "pvpanic", "id": "id3KTLMV"}' \
+    -chardev socket,path=/tmp/serial-serial0-20240104-043347-5Miq4hMP,wait=off,server=on,id=chardev_serial0 \
+    -device '{"id": "serial0", "driver": "isa-serial", "chardev": "chardev_serial0"}'  \
+    -chardev socket,id=seabioslog_id_20240104-043347-5Miq4hMP,path=/tmp/seabios-20240104-043347-5Miq4hMP,server=on,wait=off \
+    -device isa-debugcon,chardev=seabioslog_id_20240104-043347-5Miq4hMP,iobase=0x402 \
+    -device '{"driver": "ich9-usb-ehci1", "id": "usb1", "addr": "0x1d.0x7", "multifunction": true, "bus": "pci.0"}' \
+    -device '{"driver": "ich9-usb-uhci1", "id": "usb1.0", "multifunction": true, "masterbus": "usb1.0", "addr": "0x1d.0x0", "firstport": 0, "bus": "pci.0"}' \
+    -device '{"driver": "ich9-usb-uhci2", "id": "usb1.1", "multifunction": true, "masterbus": "usb1.0", "addr": "0x1d.0x2", "firstport": 2, "bus": "pci.0"}' \
+    -device '{"driver": "ich9-usb-uhci3", "id": "usb1.2", "multifunction": true, "masterbus": "usb1.0", "addr": "0x1d.0x4", "firstport": 4, "bus": "pci.0"}' \
+    -device '{"driver": "usb-tablet", "id": "usb-tablet1", "bus": "usb1.0", "port": "1"}' \
+    -object '{"qom-type": "iothread", "id": "t1"}' \
+    -object '{"qom-type": "iothread", "id": "t2"}' \
+    -object '{"qom-type": "iothread", "id": "t3"}' \
+    -object '{"qom-type": "iothread", "id": "t4"}' \
+    -blockdev '{"node-name": "file_image1", "driver": "file", "auto-read-only": true, "discard": "unmap", "aio": "threads", "filename": "/home/kvm_autotest_root/images/rhel9-virtio.qcow2", "cache": {"direct": true, "no-flush": false}}' \
+    -blockdev '{"node-name": "drive_image1", "driver": "qcow2", "read-only": false, "cache": {"direct": true, "no-flush": false}, "file": "file_image1"}' \
+    -device '{"driver": "virtio-blk-pci", "id": "image1", "drive": "drive_image1", "bootindex": 0, "write-cache": "on", "bus": "pci.0", "addr": "0x3"}' \
+    -blockdev '{"node-name": "file_stg1", "driver": "file", "auto-read-only": true, "discard": "unmap", "aio": "threads", "filename": "/home/kvm_autotest_root/images/stg1.qcow2", "cache": {"direct": true, "no-flush": false}}' \
+    -blockdev '{"node-name": "drive_stg1", "driver": "qcow2", "read-only": false, "cache": {"direct": true, "no-flush": false}, "file": "file_stg1"}' \
+    -device '{"driver": "virtio-blk-pci", "id": "stg1", "drive": "drive_stg1", "bootindex": 1, "write-cache": "on", "serial": "stg1", "bus": "pci.0", "addr": "0x4", "iothread-vq-mapping": [{"iothread": "t2"}, {"iothread": "t3"}]}' \
+    -blockdev '{"node-name": "file_stg2", "driver": "file", "auto-read-only": true, "discard": "unmap", "aio": "threads", "filename": "/home/kvm_autotest_root/images/stg2.qcow2", "cache": {"direct": true, "no-flush": false}}' \
+    -blockdev '{"node-name": "drive_stg2", "driver": "qcow2", "read-only": false, "cache": {"direct": true, "no-flush": false}, "file": "file_stg2"}' \
+    -device '{"driver": "virtio-blk-pci", "id": "stg2", "drive": "drive_stg2", "bootindex": 2, "write-cache": "on", "serial": "stg2", "num-queues": 6, "iothread-vq-mapping": [{"iothread": "t1", "vqs": [0, 1, 2]}, {"iothread": "t2", "vqs": [3]}, {"iothread": "t4", "vqs": [4, 5]}], "bus": "pci.0", "addr": "0x5"}' \
+    -device '{"driver": "virtio-net-pci", "mac": "9a:5b:6c:5f:5b:5b", "id": "iddNmpYv", "netdev": "idG9Emyl", "bus": "pci.0", "addr": "0x6"}' \
+    -netdev  '{"id": "idG9Emyl", "type": "tap", "vhost": true}'  \
+    -vnc :0  \
+    -rtc base=utc,clock=host,driftfix=slew  \
+    -boot menu=off,order=cdn,once=c,strict=off \
+    -enable-kvm \
+  
+2. Continue VM: \
+   {"execute": "cont"} \
+
+3. Check disk info before hot unplug: \
+   (guest)#ls /dev/[vhs]d* | grep -v [0-9]$ \
+
+4. Unplug device from vm: \
+   {"execute": "device_del", "arguments": {"id": "stg1"}} \
+   {"timestamp": {"seconds": 1704360854, "microseconds": 751289}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/stg1/virtio-backend"}} \
+   {"timestamp": {"seconds": 1704360854, "microseconds": 752078}, "event": "DEVICE_DELETED", "data": {"device": "stg1", "path": "/machine/peripheral/stg1"}} \
+
+5. Check device info via "info qtree": \
+   {"execute": "human-monitor-command", "arguments": {"command-line": "info qtree"}} \
+
+Actual Result: \
+  After step5, qemu core dump with info: \
+    qemu-system-x86_64: ../qapi/string-output-visitor.c:316: start_list: Assertion `sov->list_mode == LM_NONE' failed. \
+    /tmp/aexpect_fNRmaiS3/aexpect-okx056xs.sh: line 1: 480254 Aborted                 (core dumped) MALLOC_PERTURB_=1  qemu-system-x86_64 -S -name 'avocado-vt-vm1' -machine pc,memory-backend=mem-machine_mem ... \
+
+Coredump info as bellow: \
+ #coredumpctl debug 480254 \
+   Stack trace of thread 480254:
+                #0  0x00007f9397ea365c __pthread_kill_implementation (libc.so.6 + 0xa365c) \
+                #1  0x00007f9397e54d06 __GI_raise (libc.so.6 + 0x54d06) \
+                #2  0x00007f9397e287f3 __GI_abort (libc.so.6 + 0x287f3) \
+                #3  0x00007f9397e2871b __assert_fail_base (libc.so.6 + 0x2871b) \
+                #4  0x00007f9397e4dca6 __assert_fail (libc.so.6 + 0x4dca6) \
+                #5  0x000056472e810e0d start_list (qemu-system-x86_64 + 0xa92e0d) \
+                #6  0x000056472e80acb9 visit_start_list (qemu-system-x86_64 + 0xa8ccb9) \
+                #7  0x000056472e75e9c0 visit_type_uint16List (qemu-system-x86_64 + 0x9e09c0) \
+                #8  0x000056472e7e9955 visit_type_IOThreadVirtQueueMapping_members (qemu-system-x86_64 + 0xa6b955) \
+                #9  0x000056472e7e9a1b visit_type_IOThreadVirtQueueMapping (qemu-system-x86_64 + 0xa6ba1b) \
+                #10 0x000056472e7e9b0d visit_type_IOThreadVirtQueueMappingList (qemu-system-x86_64 + 0xa6bb0d) \
+                #11 0x000056472e1519b2 get_iothread_vq_mapping_list (qemu-system-x86_64 + 0x3d39b2) \
+                #12 0x000056472e629d0f field_prop_get (qemu-system-x86_64 + 0x8abd0f) \
+                #13 0x000056472e635b24 object_property_get (qemu-system-x86_64 + 0x8b7b24) \
+                #14 0x000056472e6368b3 object_property_print (qemu-system-x86_64 + 0x8b88b3) \
+                #15 0x000056472e38f97a qdev_print_props (qemu-system-x86_64 + 0x61197a) \
+                #16 0x000056472e38fc9f qdev_print (qemu-system-x86_64 + 0x611c9f) \
+                #17 0x000056472e38fdd9 qbus_print (qemu-system-x86_64 + 0x611dd9) \
+                #18 0x000056472e38fd03 qdev_print (qemu-system-x86_64 + 0x611d03) \
+                #19 0x000056472e38fdd9 qbus_print (qemu-system-x86_64 + 0x611dd9) \
+                #20 0x000056472e38fd03 qdev_print (qemu-system-x86_64 + 0x611d03) \
+                #21 0x000056472e38fdd9 qbus_print (qemu-system-x86_64 + 0x611dd9) \
+                #22 0x000056472e38fe26 hmp_info_qtree (qemu-system-x86_64 + 0x611e26) \
+                #23 0x000056472e3ed6ed handle_hmp_command_exec (qemu-system-x86_64 + 0x66f6ed) \
+                #24 0x000056472e3ed91a handle_hmp_command (qemu-system-x86_64 + 0x66f91a) \
+                #25 0x000056472e3eef02 qmp_human_monitor_command (qemu-system-x86_64 + 0x670f02) \
+                #26 0x000056472e7cc89b qmp_marshal_human_monitor_command (qemu-system-x86_64 + 0xa4e89b) \
+                #27 0x000056472e8117d0 do_qmp_dispatch_bh (qemu-system-x86_64 + 0xa937d0) \
+                #28 0x000056472e83be78 aio_bh_call (qemu-system-x86_64 + 0xabde78) \
+                #29 0x000056472e83bf93 aio_bh_poll (qemu-system-x86_64 + 0xabdf93) \
+                #30 0x000056472e81eb3e aio_dispatch (qemu-system-x86_64 + 0xaa0b3e) \
+                #31 0x000056472e83c3d2 aio_ctx_dispatch (qemu-system-x86_64 + 0xabe3d2) \
+                #32 0x00007f939829ff4f g_main_dispatch (libglib-2.0.so.0 + 0x54f4f) \
+                #33 0x000056472e83d8a8 glib_pollfds_poll (qemu-system-x86_64 + 0xabf8a8) \
+                #34 0x000056472e83d925 os_host_main_loop_wait (qemu-system-x86_64 + 0xabf925) \
+                #35 0x000056472e83da33 main_loop_wait (qemu-system-x86_64 + 0xabfa33) \
+                #36 0x000056472e396150 qemu_main_loop (qemu-system-x86_64 + 0x618150) \
+                #37 0x000056472e628b7f qemu_default_main (qemu-system-x86_64 + 0x8aab7f) \
+                #38 0x000056472e628bba main (qemu-system-x86_64 + 0x8aabba) \
+                #39 0x00007f9397e3feb0 __libc_start_call_main (libc.so.6 + 0x3feb0) \
+                #40 0x00007f9397e3ff60 __libc_start_main_impl (libc.so.6 + 0x3ff60) \
+                #41 0x000056472e08e435 _start (qemu-system-x86_64 + 0x310435) \
+                \
+                Stack trace of thread 480255: \
+                #0  0x00007f9397e3ee5d syscall (libc.so.6 + 0x3ee5d) \
+                #1  0x000056472e82343c qemu_futex_wait (qemu-system-x86_64 + 0xaa543c) \
+                #2  0x000056472e823623 qemu_event_wait (qemu-system-x86_64 + 0xaa5623) \
+                #3  0x000056472e830d03 call_rcu_thread (qemu-system-x86_64 + 0xab2d03) \
+                #4  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #5  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #6  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480258: \
+                #0  0x00007f9397f429be __ppoll (libc.so.6 + 0x1429be) \
+                #1  0x000056472e841cf0 qemu_poll_ns (qemu-system-x86_64 + 0xac3cf0) \
+                #2  0x000056472e81f95f fdmon_poll_wait (qemu-system-x86_64 + 0xaa195f) \
+                #3  0x000056472e81f29b aio_poll (qemu-system-x86_64 + 0xaa129b) \
+                #4  0x000056472e67440c iothread_run (qemu-system-x86_64 + 0x8f640c) \
+                #5  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #6  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #7  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480266: \
+                #0  0x00007f9397e3ec6b ioctl (libc.so.6 + 0x3ec6b) \
+                #1  0x000056472e619a24 kvm_vcpu_ioctl (qemu-system-x86_64 + 0x89ba24) \
+                #2  0x000056472e619236 kvm_cpu_exec (qemu-system-x86_64 + 0x89b236) \
+                #3  0x000056472e61c0fc kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x89e0fc) \
+                #4  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #5  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #6  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480267: \
+                #0  0x00007f9397e3ec6b ioctl (libc.so.6 + 0x3ec6b) \
+                #1  0x000056472e619a24 kvm_vcpu_ioctl (qemu-system-x86_64 + 0x89ba24) \
+                #2  0x000056472e619236 kvm_cpu_exec (qemu-system-x86_64 + 0x89b236) \
+                #3  0x000056472e61c0fc kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x89e0fc) \
+                #4  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #5  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #6  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480257: \
+                #0  0x00007f9397f429be __ppoll (libc.so.6 + 0x1429be) \
+                #1  0x000056472e841cf0 qemu_poll_ns (qemu-system-x86_64 + 0xac3cf0) \
+                #2  0x000056472e81f95f fdmon_poll_wait (qemu-system-x86_64 + 0xaa195f) \
+                #3  0x000056472e81f29b aio_poll (qemu-system-x86_64 + 0xaa129b) \
+                #4  0x000056472e67440c iothread_run (qemu-system-x86_64 + 0x8f640c) \
+                #5  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #6  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #7  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480256: \
+                #0  0x00007f9397f429be __ppoll (libc.so.6 + 0x1429be) \
+                #1  0x000056472e841d87 qemu_poll_ns (qemu-system-x86_64 + 0xac3d87) \
+                #2  0x000056472e81f95f fdmon_poll_wait (qemu-system-x86_64 + 0xaa195f) \
+                #3  0x000056472e81f29b aio_poll (qemu-system-x86_64 + 0xaa129b) \
+                #4  0x000056472e67440c iothread_run (qemu-system-x86_64 + 0x8f640c) \
+                #5  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #6  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #7  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480260: \
+                #0  0x00007f9397e9e4aa __futex_abstimed_wait_common64 (libc.so.6 + 0x9e4aa) \
+                #1  0x00007f9397ea0fb4 __pthread_cond_wait_common (libc.so.6 + 0xa0fb4) \
+                #2  0x000056472e823041 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0xaa5041) \
+                #3  0x000056472e8230dc qemu_cond_timedwait_impl (qemu-system-x86_64 + 0xaa50dc) \
+                #4  0x000056472e840595 worker_thread (qemu-system-x86_64 + 0xac2595) \
+                #5  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #6  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #7  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480264: \
+                #0  0x00007f9397f428bf __GI___poll (libc.so.6 + 0x1428bf) \
+                #1  0x00007f93982f51fc g_main_context_poll (libglib-2.0.so.0 + 0xaa1fc) \
+                #2  0x00007f939829f5a3 g_main_loop_run (libglib-2.0.so.0 + 0x545a3) \
+                #3  0x000056472e67443f iothread_run (qemu-system-x86_64 + 0x8f643f) \
+                #4  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #5  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #6  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480274: \
+                #0  0x00007f9397e3ec6b ioctl (libc.so.6 + 0x3ec6b) \
+                #1  0x000056472e619a24 kvm_vcpu_ioctl (qemu-system-x86_64 + 0x89ba24) \
+                #2  0x000056472e619236 kvm_cpu_exec (qemu-system-x86_64 + 0x89b236) \
+                #3  0x000056472e61c0fc kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x89e0fc) \
+                #4  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #5  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #6  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480337: \
+                #0  0x00007f9397e9e4aa __futex_abstimed_wait_common64 (libc.so.6 + 0x9e4aa) \
+                #1  0x00007f9397ea0fb4 __pthread_cond_wait_common (libc.so.6 + 0xa0fb4) \
+                #2  0x000056472e823041 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0xaa5041) \
+                #3  0x000056472e8230dc qemu_cond_timedwait_impl (qemu-system-x86_64 + 0xaa50dc) \
+                #4  0x000056472e840595 worker_thread (qemu-system-x86_64 + 0xac2595) \
+                #5  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #6  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #7  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480273: \
+                #0  0x00007f9397e3ec6b ioctl (libc.so.6 + 0x3ec6b) \
+                #1  0x000056472e619a24 kvm_vcpu_ioctl (qemu-system-x86_64 + 0x89ba24) \
+                #2  0x000056472e619236 kvm_cpu_exec (qemu-system-x86_64 + 0x89b236) \
+                #3  0x000056472e61c0fc kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x89e0fc) \
+                #4  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #5  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #6  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480358: \
+                #0  0x00007f9397e9e4aa __futex_abstimed_wait_common64 (libc.so.6 + 0x9e4aa) \
+                #1  0x00007f9397ea0fb4 __pthread_cond_wait_common (libc.so.6 + 0xa0fb4) \
+                #2  0x000056472e823041 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0xaa5041) \
+                #3  0x000056472e8230dc qemu_cond_timedwait_impl (qemu-system-x86_64 + 0xaa50dc) \
+                #4  0x000056472e840595 worker_thread (qemu-system-x86_64 + 0xac2595) \
+                #5  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #6  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #7  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480276: \
+                #0  0x00007f9397e9e4aa __futex_abstimed_wait_common64 (libc.so.6 + 0x9e4aa) \
+                #1  0x00007f9397ea0cb0 __pthread_cond_wait_common (libc.so.6 + 0xa0cb0) \
+                #2  0x000056472e822f8e qemu_cond_wait_impl (qemu-system-x86_64 + 0xaa4f8e) \
+                #3  0x000056472e0c6f39 vnc_worker_thread_loop (qemu-system-x86_64 + 0x348f39) \
+                #4  0x000056472e0c7544 vnc_worker_thread (qemu-system-x86_64 + 0x349544) \
+                #5  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #6  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #7  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480259: \
+                #0  0x00007f9397f429be __ppoll (libc.so.6 + 0x1429be) \
+                #1  0x000056472e841cf0 qemu_poll_ns (qemu-system-x86_64 + 0xac3cf0) \
+                #2  0x000056472e81f95f fdmon_poll_wait (qemu-system-x86_64 + 0xaa195f) \
+                #3  0x000056472e81f29b aio_poll (qemu-system-x86_64 + 0xaa129b) \
+                #4  0x000056472e67440c iothread_run (qemu-system-x86_64 + 0x8f640c) \
+                #5  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #6  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #7  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480357: \
+                #0  0x00007f9397e9e4aa __futex_abstimed_wait_common64 (libc.so.6 + 0x9e4aa) \
+                #1  0x00007f9397ea0fb4 __pthread_cond_wait_common (libc.so.6 + 0xa0fb4) \
+                #2  0x000056472e823041 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0xaa5041) \
+                #3  0x000056472e8230dc qemu_cond_timedwait_impl (qemu-system-x86_64 + 0xaa50dc) \
+                #4  0x000056472e840595 worker_thread (qemu-system-x86_64 + 0xac2595) \
+                #5  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #6  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912)\
+                #7  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480268: \
+                #0  0x00007f9397e3ec6b ioctl (libc.so.6 + 0x3ec6b) \
+                #1  0x000056472e619a24 kvm_vcpu_ioctl (qemu-system-x86_64 + 0x89ba24) \
+                #2  0x000056472e619236 kvm_cpu_exec (qemu-system-x86_64 + 0x89b236) \
+                #3  0x000056472e61c0fc kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x89e0fc) \
+                #4  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #5  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #6  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480269: \
+                #0  0x00007f9397e3ec6b ioctl (libc.so.6 + 0x3ec6b) \
+                #1  0x000056472e619a24 kvm_vcpu_ioctl (qemu-system-x86_64 + 0x89ba24) \
+                #2  0x000056472e619236 kvm_cpu_exec (qemu-system-x86_64 + 0x89b236) \
+                #3  0x000056472e61c0fc kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x89e0fc) \
+                #4  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #5  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #6  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480353: \
+                #0  0x00007f9397e9e4aa __futex_abstimed_wait_common64 (libc.so.6 + 0x9e4aa) \
+                #1  0x00007f9397ea0fb4 __pthread_cond_wait_common (libc.so.6 + 0xa0fb4) \
+                #2  0x000056472e823041 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0xaa5041) \
+                #3  0x000056472e8230dc qemu_cond_timedwait_impl (qemu-system-x86_64 + 0xaa50dc) \
+                #4  0x000056472e840595 worker_thread (qemu-system-x86_64 + 0xac2595) \
+                #5  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #6  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #7  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480271: \
+                #0  0x00007f9397e3ec6b ioctl (libc.so.6 + 0x3ec6b) \
+                #1  0x000056472e619a24 kvm_vcpu_ioctl (qemu-system-x86_64 + 0x89ba24) \
+                #2  0x000056472e619236 kvm_cpu_exec (qemu-system-x86_64 + 0x89b236) \
+                #3  0x000056472e61c0fc kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x89e0fc) \
+                #4  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #5  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #6  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480354: \
+                #0  0x00007f9397e9e4aa __futex_abstimed_wait_common64 (libc.so.6 + 0x9e4aa) \
+                #1  0x00007f9397ea0fb4 __pthread_cond_wait_common (libc.so.6 + 0xa0fb4) \
+                #2  0x000056472e823041 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0xaa5041) \
+                #3  0x000056472e8230dc qemu_cond_timedwait_impl (qemu-system-x86_64 + 0xaa50dc) \
+                #4  0x000056472e840595 worker_thread (qemu-system-x86_64 + 0xac2595) \
+                #5  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #6  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #7  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480356: \
+                #0  0x00007f9397e9e4aa __futex_abstimed_wait_common64 (libc.so.6 + 0x9e4aa) \
+                #1  0x00007f9397ea0fb4 __pthread_cond_wait_common (libc.so.6 + 0xa0fb4) \
+                #2  0x000056472e823041 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0xaa5041) \
+                #3  0x000056472e8230dc qemu_cond_timedwait_impl (qemu-system-x86_64 + 0xaa50dc) \
+                #4  0x000056472e840595 worker_thread (qemu-system-x86_64 + 0xac2595) \
+                #5  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #6  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #7  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480355: \
+                #0  0x00007f9397e9e4aa __futex_abstimed_wait_common64 (libc.so.6 + 0x9e4aa) \
+                #1  0x00007f9397ea0fb4 __pthread_cond_wait_common (libc.so.6 + 0xa0fb4) \
+                #2  0x000056472e823041 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0xaa5041) \
+                #3  0x000056472e8230dc qemu_cond_timedwait_impl (qemu-system-x86_64 + 0xaa50dc) \
+                #4  0x000056472e840595 worker_thread (qemu-system-x86_64 + 0xac2595) \
+                #5  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #6  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #7  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480270: \
+                #0  0x00007f9397e3ec6b ioctl (libc.so.6 + 0x3ec6b) \
+                #1  0x000056472e619a24 kvm_vcpu_ioctl (qemu-system-x86_64 + 0x89ba24) \
+                #2  0x000056472e619236 kvm_cpu_exec (qemu-system-x86_64 + 0x89b236) \
+                #3  0x000056472e61c0fc kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x89e0fc) \
+                #4  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #5  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #6  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480272: \
+                #0  0x00007f9397e3ec6b ioctl (libc.so.6 + 0x3ec6b) \
+                #1  0x000056472e619a24 kvm_vcpu_ioctl (qemu-system-x86_64 + 0x89ba24) \
+                #2  0x000056472e619236 kvm_cpu_exec (qemu-system-x86_64 + 0x89b236) \
+                #3  0x000056472e61c0fc kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x89e0fc) \
+                #4  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #5  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #6  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                \
+                Stack trace of thread 480265: \
+                #0  0x00007f9397e3ec6b ioctl (libc.so.6 + 0x3ec6b) \
+                #1  0x000056472e619a24 kvm_vcpu_ioctl (qemu-system-x86_64 + 0x89ba24) \
+                #2  0x000056472e619236 kvm_cpu_exec (qemu-system-x86_64 + 0x89b236) \
+                #3  0x000056472e61c0fc kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x89e0fc) \
+                #4  0x000056472e8237d6 qemu_thread_start (qemu-system-x86_64 + 0xaa57d6) \
+                #5  0x00007f9397ea1912 start_thread (libc.so.6 + 0xa1912) \
+                #6  0x00007f9397e3f450 __clone3 (libc.so.6 + 0x3f450) \
+                ELF object binary architecture: AMD x86-64 \
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/207 b/gitlab/issues_text/target_missing/host_missing/accel_missing/207
new file mode 100644
index 00000000..0f29d617
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/207
@@ -0,0 +1 @@
+move ./scripts/qmp to ./python/qemu/qmp
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2071 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2071
new file mode 100644
index 00000000..481d11ba
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2071
@@ -0,0 +1,112 @@
+Segfault when starting a guest with spice configured to listen on a unix socket
+Description of problem:
+Guest crash immediately when spice is configured to listen on a unix socket.
+Steps to reproduce:
+1. Configure spice to listen on a unix socket
+2. Start the guest
+Additional information:
+Here's the log when I start the guest:
+
+```
+[root@localhost ~]# virsh start fedora-waydroid
+error: Failed to start domain 'fedora-waydroid'
+error: internal error: qemu unexpectedly closed the monitor
+```
+Here's the relevant output in journald:
+
+`SECCOMP auid=4294967295 uid=107 gid=107 ses=4294967295 pid=17930 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 arch=c000003e syscall=56 compat=0 ip=0x7f7b95459397 code=0x80000000`
+
+<details><summary>Full journald</summary>
+
+```
+Jan 04 11:59:03 localhost polkitd[1436]: Registered Authentication Agent for unix-process:17895:5747660 (system bus name :1.160 [/usr/bin/pkttyagent --process 17895 --notify-fd 4 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
+Jan 04 11:59:03 localhost audit[1595]: VIRT_MACHINE_ID pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 vm-ctx=+107:+107 img-ctx=+107:+107 model=dac exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost virtlogd[1659]: Client hit max requests limit 1. This may result in keep-alive timeouts. Consider tuning the max_client_requests server parameter
+Jan 04 11:59:03 localhost virtlogd[1659]: Client hit max requests limit 1. This may result in keep-alive timeouts. Consider tuning the max_client_requests server parameter
+Jan 04 11:59:03 localhost polkitd[1436]: Unregistered Authentication Agent for unix-process:17895:5747660 (system bus name :1.160, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
+Jan 04 11:59:03 localhost audit: ANOM_PROMISCUOUS dev=vnet12 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=net reason=open vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 net=52:54:00:72:c3:92 path="/dev/net/tun" rdev=0A:C8 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=net reason=open vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 net=52:54:00:72:c3:92 path="/dev/vhost-net" rdev=0A:EE exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost NetworkManager[1338]: <info>  [1704394743.2422] manager: (vnet12): new Tun device (/org/freedesktop/NetworkManager/Devices/19)
+Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered blocking state
+Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered disabled state
+Jan 04 11:59:03 localhost kernel: vnet12: entered allmulticast mode
+Jan 04 11:59:03 localhost kernel: vnet12: entered promiscuous mode
+Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered blocking state
+Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered forwarding state
+Jan 04 11:59:03 localhost NetworkManager[1338]: <info>  [1704394743.2468] device (vnet12): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'external')
+Jan 04 11:59:03 localhost NetworkManager[1338]: <info>  [1704394743.2470] device (vnet12): state change: unavailable -> disconnected (reason 'connection-assumed', sys-iface-state: 'external')
+Jan 04 11:59:03 localhost NetworkManager[1338]: <info>  [1704394743.2473] device (vnet12): Activation: starting connection 'vnet12' (abcdefgh-ijkl-mnop-qrst-uvwx12345679)
+Jan 04 11:59:03 localhost NetworkManager[1338]: <info>  [1704394743.2478] device (vnet12): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'external')
+Jan 04 11:59:03 localhost NetworkManager[1338]: <info>  [1704394743.2479] device (vnet12): state change: prepare -> config (reason 'none', sys-iface-state: 'external')
+Jan 04 11:59:03 localhost NetworkManager[1338]: <info>  [1704394743.2480] device (vnet12): state change: config -> ip-config (reason 'none', sys-iface-state: 'external')
+Jan 04 11:59:03 localhost NetworkManager[1338]: <info>  [1704394743.2480] device (br-dmz): bridge port vnet12 was attached
+Jan 04 11:59:03 localhost NetworkManager[1338]: <info>  [1704394743.2480] device (vnet12): Activation: connection 'vnet12' enslaved, continuing activation
+Jan 04 11:59:03 localhost NetworkManager[1338]: <info>  [1704394743.2481] device (vnet12): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'external')
+Jan 04 11:59:03 localhost systemd-machined[1368]: New machine qemu-10-fedora-waydroid.
+Jan 04 11:59:03 localhost systemd[1]: Started machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope - Virtual Machine qemu-10-fedora-waydroid.
+Jan 04 11:59:03 localhost systemd[1]: Starting NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service...
+Jan 04 11:59:03 localhost audit: BPF prog-id=112 op=LOAD
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=deny vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=all exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/null" rdev=01:03 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/full" rdev=01:07 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/zero" rdev=01:05 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/random" rdev=01:08 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/urandom" rdev=01:09 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/ptmx" rdev=05:02 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/kvm" rdev=0A:E8 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=major category=pty maj=88 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/dri/by-path/pci-0000:00:02.0-render" rdev=E2:80 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/urandom" rdev=01:09 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost systemd[1]: Started NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service.
+Jan 04 11:59:03 localhost audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost NetworkManager[1338]: <info>  [1704394743.2796] device (vnet12): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'external')
+Jan 04 11:59:03 localhost NetworkManager[1338]: <info>  [1704394743.2797] device (vnet12): state change: secondaries -> activated (reason 'none', sys-iface-state: 'external')
+Jan 04 11:59:03 localhost NetworkManager[1338]: <info>  [1704394743.2799] device (vnet12): Activation: successful, device activated.
+Jan 04 11:59:03 localhost systemd[1]: iscsi.service: Unit cannot be reloaded because it is inactive.
+Jan 04 11:59:03 localhost audit[17930]: SECCOMP auid=4294967295 uid=107 gid=107 ses=4294967295 pid=17930 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 arch=c000003e syscall=56 compat=0 ip=0x7f7b95459397 code=0x80000000
+Jan 04 11:59:03 localhost audit[17930]: ANOM_ABEND auid=4294967295 uid=107 gid=107 ses=4294967295 pid=17930 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 res=1
+Jan 04 11:59:03 localhost audit: BPF prog-id=113 op=LOAD
+Jan 04 11:59:03 localhost audit: BPF prog-id=114 op=LOAD
+Jan 04 11:59:03 localhost audit: BPF prog-id=115 op=LOAD
+Jan 04 11:59:03 localhost systemd[1]: Started systemd-coredump@3-17978-0.service - Process Core Dump (PID 17978/UID 0).
+Jan 04 11:59:03 localhost audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@3-17978-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost systemd-coredump[17980]: Resource limits disable core dumping for process 17930 (qemu-system-x86).
+Jan 04 11:59:03 localhost systemd-coredump[17980]: [🡕] Process 17930 (qemu-system-x86) of user 107 terminated abnormally without generating a coredump.
+Jan 04 11:59:03 localhost systemd[1]: systemd-coredump@3-17978-0.service: Deactivated successfully.
+Jan 04 11:59:03 localhost audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@3-17978-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit: ANOM_PROMISCUOUS dev=vnet12 prom=0 old_prom=256 auid=4294967295 uid=107 gid=107 ses=4294967295
+Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered disabled state
+Jan 04 11:59:03 localhost kernel: vnet12 (unregistering): left allmulticast mode
+Jan 04 11:59:03 localhost kernel: vnet12 (unregistering): left promiscuous mode
+Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered disabled state
+Jan 04 11:59:03 localhost NetworkManager[1338]: <info>  [1704394743.3895] device (vnet12): state change: activated -> unmanaged (reason 'unmanaged', sys-iface-state: 'removed')
+Jan 04 11:59:03 localhost NetworkManager[1338]: <info>  [1704394743.3897] device (vnet12): released from master device br-dmz
+Jan 04 11:59:03 localhost virtqemud[1595]: Unable to read from monitor: Connection reset by peer
+Jan 04 11:59:03 localhost virtqemud[1595]: internal error: qemu unexpectedly closed the monitor
+Jan 04 11:59:03 localhost virtqemud[1595]: internal error: process exited while connecting to monitor
+Jan 04 11:59:03 localhost virtlogd[1659]: Client hit max requests limit 1. This may result in keep-alive timeouts. Consider tuning the max_client_requests server parameter
+Jan 04 11:59:03 localhost virtqemud[1595]: Failed to acquire pid file '/run/libvirt/qemu/swtpm/10-fedora-waydroid-swtpm.pid': Resource temporarily unavailable
+Jan 04 11:59:03 localhost systemd[1]: machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope: Deactivated successfully.
+Jan 04 11:59:03 localhost systemd-machined[1368]: Machine qemu-10-fedora-waydroid terminated.
+Jan 04 11:59:03 localhost audit: BPF prog-id=115 op=UNLOAD
+Jan 04 11:59:03 localhost audit: BPF prog-id=114 op=UNLOAD
+Jan 04 11:59:03 localhost audit: BPF prog-id=113 op=UNLOAD
+Jan 04 11:59:03 localhost audit: BPF prog-id=112 op=UNLOAD
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=disk reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 old-disk="?" new-disk="/var/lib/libvirt/images/fedora-waydroid.img" exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=net reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 old-net="?" new-net="52:54:00:72:c3:92" exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=dev reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 bus=usb device=555342207265646972646576 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=dev reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 bus=usb device=555342207265646972646576 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=rng reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 old-rng="?" new-rng="/dev/urandom" exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=tpm-emulator reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 device="?" exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=mem reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 old-mem=0 new-mem=4194304 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=vcpu reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 old-vcpu=0 new-vcpu=4 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success'
+Jan 04 11:59:03 localhost audit[1595]: VIRT_CONTROL pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm op=start reason=booted vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 vm-pid=0 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=failed'
+```
+
+<details>
+
+For the record I filed a bug earlier in libvirt (https://gitlab.com/libvirt/libvirt/-/issues/573) but I now think it's qemu related.
+
+
+/label ~"kind::Bug"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2073 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2073
new file mode 100644
index 00000000..7461f611
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2073
@@ -0,0 +1,16 @@
+Audio: missing ability to disable microphone input from host?
+Description of problem:
+**It appears there is no way to disable the microphone / input to the audio backend device(s).**
+
+
+There are at least two cases where this matters:
+1. The host has no microphone input (e.g. only HDMI audio output with video).
+2. The host has a microphone input, but the user doesn't want the guest VM to have access to the microphone/input.
+
+I tried the option in.channels=0, as that seemed the most obvious way, though that doesn't work.
+
+For -audio dsound, it appears that CLSID_DirectSoundCapture is unconditionally acquired.
+
+There will also be later periodic warning/text outputs from QEMU "Could not create a backend for voice virtio.in", if you're running on a host system with no audio input device.
+
+Adding a couple backend checks for channels > 0 may work well.  Not sure if it matters that audio front end device in the VM still thinks there is an audio input.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2075 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2075
new file mode 100644
index 00000000..7e6089df
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2075
@@ -0,0 +1,10 @@
+QGA guest-get-fsinfo can not return windows dynamic volumes
+Description of problem:
+Install qemu-ga (newest version) in Windows, create multiple dynamic volumes（containing multiple disks）,
+![Xnip2024-01-05_17-54-06](/uploads/0f88fba59fb90e224d59e3e2353e5cf9/Xnip2024-01-05_17-54-06.jpg)
+
+get them information via guest-get-fsinfo, but guest-get-fsinfo does not return the the dynamic volume.
+Steps to reproduce:
+virsh qemu-agent-command {domain} --pretty '{ "execute": "guest-get-fsinfo" }'
+Additional information:
+Please see if this bug can be fixed by [qga-win: Fix guest-get-fsinfo multi-disks collection](https://patchew.org/QEMU/20231227071540.4035803-1-peng.ji@smartx.com/)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2076 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2076
new file mode 100644
index 00000000..814aa86e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2076
@@ -0,0 +1 @@
+stringop-overread warning in tests/tcg/multiarch/sha1.c
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2077 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2077
new file mode 100644
index 00000000..ed943d9e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2077
@@ -0,0 +1 @@
+flaky CI test: acpiBitsTest.test_acpi_smbios_bits
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/208 b/gitlab/issues_text/target_missing/host_missing/accel_missing/208
new file mode 100644
index 00000000..bc026d28
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/208
@@ -0,0 +1 @@
+Write a new, asynchronous qmp-shell TUI
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2080 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2080
new file mode 100644
index 00000000..164f817e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2080
@@ -0,0 +1 @@
+CI 'pages' job sometimes fails with "htags: Negative exec line limit"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2081 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2081
new file mode 100644
index 00000000..538976cb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2081
@@ -0,0 +1,9 @@
+[OHCI] OHCI_CC_DEVICENOTRESPONDING not set when transferring to a disconnected device
+Description of problem:
+If a USB device is disconnected and is cleaned up by qemu, subsequent transfers to that device address are ignored. On a real OHCI controller `OHCI_CC_DEVICENOTRESPONDING` bit is set and is reported as an error to the host.
+
+qemu attempts to set it here https://github.com/qemu/qemu/blob/ffd454c67e38cc6df792733ebc5d967eee28ac0d/hw/usb/hcd-ohci.c#L795 which would work fine on a valid device handle.
+
+However this check https://github.com/qemu/qemu/blob/ffd454c67e38cc6df792733ebc5d967eee28ac0d/hw/usb/hcd-ohci.c#L975 leaves early if no device handle is found so the error code is never set.
+
+Fix is to set `OHCI_CC_DEVICENOTRESPONDING` if `ohci_find_device` fails before returning.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2082 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2082
new file mode 100644
index 00000000..db6b3fdc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2082
@@ -0,0 +1,44 @@
+"Unable to find a guest_base to satisfy all guest address mapping requirements" running certain x86_64 binaries on aarch64 host
+Description of problem:
+Copying from:
+
+  https://bugzilla.redhat.com/show_bug.cgi?id=2256916
+
+With ``qemu-x86_64-static`` from ``qemu-8.1.3-1.fc39``, I can no longer run on the m1 the ``x86_64`` binary created by https://github.com/containers/PodmanHello
+
+If I try with ``qemu-x86_64-static`` from ``qemu-7.2.7-1.fc38`` then this works.
+
+If I build the binary manually on a fc39 x86 system with ``gcc -O2 -static -o podman_hello_world podman_hello_world.c``, then I can also run it successfully with ``qemu-8.1.3-1.fc39``.
+It's only the static binary built inside the alpine container which cannot be run on the M1.
+
+
+Misc tests I ran:
+
+```
+$ ./qemu-x86_64-static-8.1.3 podman_hello_world.alpine 
+qemu-x86_64-static-8.1.3: /var/roothome/podman_hello_world.alpine: Unable to find a guest_base to satisfy all guest address mapping requirements
+  0000000000000000-0000000000000fff
+  0000000000400000-00000000004047ef
+
+$ ./qemu-x86_64-static-7.2.7 podman_hello_world.alpine 
+!... Hello Podman World ...!
+[...]
+
+$ ./qemu-x86_64-static-8.1.3 podman_hello_world.fc39 
+!... Hello Podman World ...!
+[...]
+```
+
+The issue is still present with ``qemu-8.2.0-0.3.rc2.fc40``
+
+I also could not reproduce on ``x86_64`` machines. I just tried it on fc39 installed on non-Apple ``aarch64`` hardware, and I'm seeing the same issue:
+
+```
+# rpm -qf /usr/bin/qemu-x86_64-static 
+qemu-user-static-x86-8.1.3-1.fc39.aarch64
+
+# qemu-x86_64-static ./podman_hello_world.alpine 
+qemu-x86_64-static: /root/podman_hello_world.alpine: Unable to find a guest_base to satisfy all guest address mapping requirements
+  0000000000000000-0000000000000fff
+  0000000000400000-00000000004047ef
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2085 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2085
new file mode 100644
index 00000000..a24e5cdd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2085
@@ -0,0 +1,22 @@
+screen doesn't update fully wth spice + virtio-vga graphics
+Description of problem:
+When using spice graphics with virtio-vga, display updates and missing and/or delayed making interaction unusable
+Steps to reproduce:
+Create a VM with spice graphics and virtio-vga with earlier mentioned command line
+
+Open ``remote-viewer spice://localhost:5900``
+
+Boot the Fedora 39 server network installer CDROM ISO
+
+When Ananconda starts, select 'continue' at the first language choice screen
+
+Select 'Root Account' config option
+
+Toggle between "Disable root account" and "Enable root account" options
+
+Observe when the password entry box is shown/hidden, the screen does not redraw correctly
+Additional information:
+See also
+
+https://bugzilla.redhat.com/show_bug.cgi?id=2256884
+https://bbs.archlinux.org/viewtopic.php?id=291606
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2086 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2086
new file mode 100644
index 00000000..ca7f7229
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2086
@@ -0,0 +1,15 @@
+qemu-img created VMDK files lead to "Unsupported or invalid disk type 7" on ESXi
+Description of problem:
+Trying to start the VM using vmdk converted with qemu-img fails with
+
+Failed to start the virtual machine.
+Module DevicePowerOn power on failed.
+Unable to create virtual SCSI device for scsi0:1, '/vmfs/volumes/5cca0155-bdddf31d-2714-00215acbeb1e/AppD-VM01/AppDdisk1-VM01.vmdk'
+Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported.
+Steps to reproduce:
+1. Convert booting OS (in both Qemu and VMWare with the help of drivers) to vmdk 
+2. Push vmdk file to ESXi datastore 
+3. Try to boot
+![image](/uploads/68bea874d75b1a8f6ad7f89f28feb176/image.png)
+Additional information:
+ESXi seem to use a specific implementation of vmdk, with a *name*.vmdk file being the descriptor of the virtual disk and a *name*-flat.vmdk.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2087 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2087
new file mode 100644
index 00000000..623a3318
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2087
@@ -0,0 +1,28 @@
+usb-host / libusb: handling of clear_halt leads to slow device attach, possibly unusable VMs (edit:fix within)
+Description of problem:
+When passing through a common JMicron USB SATA IDE brige storage device to a windows guest, the windows VM and the attached device become unusable. It appears to take several minutes to identify the connected device, and many minutes to pull up the device properties (though they are correct). The trace log seems to indicate a retry/reset retry loop is occuring.
+
+The device works fine passed through to a fedora guest VM. Device also work fine when used by the Windows host system.
+
+The primary difference may be the XHCI controller device behavior in the Windows and fedora guest VMs.\
+It appears there may possibly be 2 separate issues:
+
+1. Incompatible handling of this type of storage device in usb-host / libusb.
+2. Windows XHCI not properly handling malformed or possibly mis-behaved devices.
+
+I also tried the nec-usb-xhci device instead of qemu-xhci, and also tried the ICH9 usb device; no difference in behavior in the Windows VM. (Though windows appears to use the same xhci device driver in all cases).
+
+A simple USB 3.x storage stick (at speed 5000) works fine passed through to the Windows guest VM, configured in the same way, with both cases using WinUSB to allow passthrough/attach to work.
+Additional information:
+lsusb output in the working Fedora VM case:
+
+only the debug descriptor fails to dump, running as root
+
+[lsusb.txt](/uploads/c1a702bc628ed9bc983dba3e703e8af4/lsusb.txt)
+
+\-trace enable=usb_host\_\* output (fragment of logfile) from the non-working Windows VM case:
+
+[usb_noprogress.txt](/uploads/f66b2ff7d4658f9569859ac122413d9f/usb_noprogress.txt)
+
+```plaintext
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2088 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2088
new file mode 100644
index 00000000..f1aa2d67
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2088
@@ -0,0 +1,21 @@
+Building qemu fails on Solaris 11.4
+Description of problem:
+Building qemu-system-hppa on Solaris 11.4 (details above) fails because in qga/commands-posix.c
+
+(1) Solaris does not have net/ethernet.h
+```
+ #if defined(__NetBSD__) || defined(__OpenBSD__)
+ #include <net/if_arp.h>
+ #include <netinet/if_ether.h>
+ #else
+ #include <net/ethernet.h>
+ #endif
+```
+Solaris *does* have net/if_arp.h and netinet/if_ether.h
+
+(2) Solaris does not define ETHER_ADDR_LEN, instead it defines ETHERADDRL
+Steps to reproduce:
+1. '../configure' '--disable-docs' '--disable-rdma' '--target-list=hppa-softmmu'
+2. gmake
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/209 b/gitlab/issues_text/target_missing/host_missing/accel_missing/209
new file mode 100644
index 00000000..b86663a3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/209
@@ -0,0 +1 @@
+the version number of qemu 6.0.0 is still 5.2.0
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2090 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2090
new file mode 100644
index 00000000..c2aafda1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2090
@@ -0,0 +1,7 @@
+Long initialisation of VM before boot.
+Description of problem:
+When i start VM in "Virtual machine manager" I got black screen, which hang there approximately one minute. After this delay VM begin booted and all work properly. Some time ago VMs booted immediately without mentioned delay after starting of VM. I checked all relevant log files, changed 3 times kernel, rebuilded Qemu, but problem persist. I don't know when problem began.
+
+![image.png](/uploads/1db2c4ebf070c71e3cd3838b13c0b190/image.png)
+
+##
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2095 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2095
new file mode 100644
index 00000000..d2acc2cb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2095
@@ -0,0 +1 @@
+RFE: support AF_UNIX userspace backend for virtio-vsock matching firecracker
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2099 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2099
new file mode 100644
index 00000000..0ce01ce4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2099
@@ -0,0 +1,11 @@
+Setting for initial GTK window size?
+Description of problem:
+
+Steps to reproduce:
+1. When starting QEMU on Windows, the GTK window size appears to be sized to approx 640x480, which is very hard to see on a 4k+ monitor.  So interacting with the boot, reading BIOS messages, etc, isn't great.
+2. It would be great to be able to specify the dimensions of the GTK window, say 2560x1600, and then just set "Zoom to Fit".
+3. This way, the visible window area remains constant, and all stages of graphical interaction get scaled to a workable size.
+4. The OS can be configured to say 2560x1600 once setup.
+5. Perhaps I've overlook settings to accomplish this?
+
+Thank you.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/210 b/gitlab/issues_text/target_missing/host_missing/accel_missing/210
new file mode 100644
index 00000000..530b3251
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/210
@@ -0,0 +1 @@
+Function not implemented when using libaio
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2100 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2100
new file mode 100644
index 00000000..87698c7f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2100
@@ -0,0 +1,6 @@
+Add option to skip quit confirmation with Cocoa display
+Additional information:
+This change was originally requested in back in 2016, but got lost in the issue tracker migration: https://bugs.launchpad.net/qemu/+bug/1556372
+
+Patch in question:
+https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg05031.html
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2102 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2102
new file mode 100644
index 00000000..f05765fe
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2102
@@ -0,0 +1,40 @@
+"qemu-img resize -f qcow2" produces broken disk images
+Description of problem:
+The documentation of `qemu-img` at
+<https://www.qemu.org/docs/master/tools/qemu-img.html>
+makes it sound like `qemu-img resize` supports various image formats
+(raw, qcow2, etc.) in the same way.
+
+But it doesn't. While `qemu-img resize -f raw` works as expected,
+`qemu-img resize -f qcow2` produces broken disk images.
+Steps to reproduce:
+```
+$ wget http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/evbarm-aarch64/binary/gzimg/arm64.img.gz
+$ gunzip arm64.img
+```
+
+First resize, then convert:
+```
+$ cp arm64.img arm64-rc.img
+$ qemu-img resize -f raw arm64-rc.img 10G
+$ qemu-img convert -f raw -O qcow2 arm64-rc.img arm64-rc.qcow2
+$ rm -f arm64-rc.img
+```
+
+First convert, then resize:
+```
+$ qemu-img convert -f raw -O qcow2 arm64.img arm64-cr.qcow2
+$ qemu-img resize -f qcow2 arm64-cr.qcow2 10G
+```
+
+Attach to a VM in VirtualBox (as an additional SATA disk) and start that VM.
+
+arm64-rc.qcow2 =>
+`# fdisk /dev/sdb` => it has two partitions.
+
+arm64-cr.qcow2 =>
+`# fdisk /dev/sdb` => it has no partitions!
+And the VM cannot be cleanly shut down. I had to manually kill the VirtualBoxVM
+process.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2103 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2103
new file mode 100644
index 00000000..502fcea7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2103
@@ -0,0 +1 @@
+docs/system/keys.rst.inc still refers to removed options -alt-grab and -ctrl-grab
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2104 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2104
new file mode 100644
index 00000000..8eca4fa8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2104
@@ -0,0 +1 @@
+source code of function trace_memory_region_ops_write()
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2109 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2109
new file mode 100644
index 00000000..fa7f624c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2109
@@ -0,0 +1 @@
+NetBSD VM fails to install due to missing py311-expat package
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2110 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2110
new file mode 100644
index 00000000..8287251b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2110
@@ -0,0 +1,11 @@
+live migrations fail qemu-kvm
+Description of problem:
+live migrations fail between two identical hosts
+```
+2024-01-18T00:16:31.582070Z qemu-kvm: Missing section footer for 0000:00:01.3/piix4_pm
+2024-01-18T00:16:31.582169Z qemu-kvm: load of migration failed: Invalid argument
+2024-01-18 00:16:31.611+0000: shutting down, reason=failed
+```
+Additional information:
+source log for vm [source.log](/uploads/5816f929a5e543f423bb909a0df23fb7/source.log)
+dest log for vm   [dest.log](/uploads/a1b6ae02e4c8235536e740b86d16ddd6/dest.log)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2111 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2111
new file mode 100644
index 00000000..aecf4467
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2111
@@ -0,0 +1,59 @@
+Assertion failure with active vhost NIC when snapshot_save_job_bh() is executed as part of a vCPU thread's aio_poll()
+Description of problem:
+During a `snapshot-save` QMP command the `snapshot_save_job_bh()` bottom half can end up being executed as part of a vCPU thread's `aio_poll()`. This is problematic and can lead to an assertion failure (see below for backtrace) when there is an active vhost network device:
+
+```
+qemu-system-x86_64: ../hw/net/virtio-net.c:3835: virtio_net_pre_save: Assertion `!n->vhost_started' failed.
+```
+Steps to reproduce:
+It is very racy and very difficult to reproduce when actually taking snapshots. So the way I can get it pretty reliably is: 
+
+1. Issue `snapshot-save` QMP commands with an invalid device ID in a loop. At the same time, have the guest write to the pflash.
+2. In GDB, wait for `snapshot_save_job_bh()` to be hit by a vCPU thread.
+3. Manually change the device ID to a valid one (`scsi1` in the example) so that taking a snapshot will actually be attempted.
+4. Continue in GDB and the assertion failure will happen.
+Additional information:
+Full backtrace:
+
+```
+ #0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
+ #1  0x00007f1de5ae3d9f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
+ #2  0x00007f1de5a94f32 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
+ #3  0x00007f1de5a7f472 in __GI_abort () at ./stdlib/abort.c:79
+ #4  0x00007f1de5a7f395 in __assert_fail_base (fmt=0x7f1de5bf3a90 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x563cb92d56e7 "!n->vhost_started", 
+    file=file@entry=0x563cb92d56d0 "../hw/net/virtio-net.c", line=line@entry=3835, function=function@entry=0x563cb92d65a0 <__PRETTY_FUNCTION__.2> "virtio_net_pre_save") at ./assert/assert.c:92
+ #5  0x00007f1de5a8de32 in __GI___assert_fail (assertion=assertion@entry=0x563cb92d56e7 "!n->vhost_started", file=file@entry=0x563cb92d56d0 "../hw/net/virtio-net.c", line=line@entry=3835, 
+    function=function@entry=0x563cb92d65a0 <__PRETTY_FUNCTION__.2> "virtio_net_pre_save") at ./assert/assert.c:101
+ #6  0x0000563cb8ebf23c in virtio_net_pre_save (opaque=<optimized out>) at ../hw/net/virtio-net.c:3835
+ #7  virtio_net_pre_save (opaque=<optimized out>) at ../hw/net/virtio-net.c:3829
+ #8  0x0000563cb917515b in vmstate_save_state_v (f=0x7f1dc43aec30, vmsd=0x563cb9e5a580 <vmstate_virtio_net>, opaque=0x563cbbb6eb40, vmdesc=0x7f1dc4080040, version_id=11, errp=0x7f1dcbdf9908)
+    at ../migration/vmstate.c:359
+ #9  0x0000563cb9175d0c in vmstate_save_state_with_err (f=<optimized out>, vmsd=<optimized out>, opaque=<optimized out>, vmdesc_id=<optimized out>, errp=<optimized out>) at ../migration/vmstate.c:347
+ #10 0x0000563cb8d9a1b2 in vmstate_save (f=f@entry=0x7f1dc43aec30, se=se@entry=0x563cbbcbdc70, vmdesc=vmdesc@entry=0x7f1dc4080040) at ../migration/savevm.c:1037
+ #11 0x0000563cb8d9d6e6 in qemu_savevm_state_complete_precopy_non_iterable (f=f@entry=0x7f1dc43aec30, in_postcopy=in_postcopy@entry=false, inactivate_disks=inactivate_disks@entry=false)
+    at ../migration/savevm.c:1553
+ #12 0x0000563cb8d9daa2 in qemu_savevm_state_complete_precopy (f=f@entry=0x7f1dc43aec30, iterable_only=iterable_only@entry=false, inactivate_disks=inactivate_disks@entry=false) at ../migration/savevm.c:1628
+ #13 0x0000563cb8da076e in qemu_savevm_state (errp=0x7f1dc42c59f0, f=0x7f1dc43aec30) at ../migration/savevm.c:1734
+ #14 save_snapshot (name=<optimized out>, overwrite=overwrite@entry=false, vmstate=<optimized out>, has_devices=has_devices@entry=true, devices=0x7f1dc4096600, errp=0x7f1dc42c59f0) at ../migration/savevm.c:3131
+ #15 0x0000563cb8da0926 in snapshot_save_job_bh (opaque=0x7f1dc42c5930) at ../migration/savevm.c:3430
+ #16 0x0000563cb9110036 in aio_bh_poll (ctx=ctx@entry=0x563cba818b40) at ../util/async.c:216
+ #17 0x0000563cb90fa09a in aio_poll (ctx=ctx@entry=0x563cba818b40, blocking=blocking@entry=true) at ../util/aio-posix.c:722
+ #18 0x0000563cb8fb1015 in bdrv_poll_co (s=0x7f1dcbdf9db0) at /home/febner/repos/qemu/block/block-gen.h:43
+ #19 blk_pwrite (blk=<optimized out>, offset=offset@entry=91136, bytes=bytes@entry=512, buf=0x7f1dc9a16400, flags=flags@entry=0) at block/block-gen.c:2012
+ #20 0x0000563cb8bb8985 in pflash_update (pfl=pfl@entry=0x563cbaa84bf0, offset=91136, offset@entry=91526, size=size@entry=1) at ../hw/block/pflash_cfi01.c:394
+ #21 0x0000563cb8bbacd8 in pflash_write (be=0, width=1, value=63, offset=91526, pfl=0x563cbaa84bf0) at ../hw/block/pflash_cfi01.c:522
+ #22 pflash_mem_write_with_attrs (opaque=0x563cbaa84bf0, addr=91526, value=<optimized out>, len=1, attrs=...) at ../hw/block/pflash_cfi01.c:681
+ #23 0x0000563cb8f06e2e in access_with_adjusted_size (addr=addr@entry=91526, value=value@entry=0x7f1dcbdf9f58, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, 
+    access_fn=0x563cb8f06710 <memory_region_write_with_attrs_accessor>, mr=<optimized out>, attrs=...) at ../system/memory.c:573
+ #24 0x0000563cb8f07e59 in memory_region_dispatch_write (mr=mr@entry=0x563cbaa84fb0, addr=addr@entry=91526, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../system/memory.c:1528
+ #25 0x0000563cb8f0f43c in flatview_write_continue (fv=fv@entry=0x7f1dc42e4720, addr=addr@entry=4290864518, attrs=..., attrs@entry=..., ptr=ptr@entry=0x7f1de7946028, len=len@entry=1, addr1=<optimized out>, 
+    l=<optimized out>, mr=0x563cbaa84fb0) at ../system/physmem.c:2714
+ #26 0x0000563cb8f0f6b3 in flatview_write (fv=0x7f1dc42e4720, addr=addr@entry=4290864518, attrs=attrs@entry=..., buf=buf@entry=0x7f1de7946028, len=len@entry=1) at ../system/physmem.c:2756
+ #27 0x0000563cb8f12959 in address_space_write (len=1, buf=0x7f1de7946028, attrs=..., addr=4290864518, as=0x563cb9fd8ec0 <address_space_memory>) at ../system/physmem.c:2863
+ #28 address_space_rw (as=0x563cb9fd8ec0 <address_space_memory>, addr=4290864518, attrs=attrs@entry=..., buf=buf@entry=0x7f1de7946028, len=1, is_write=<optimized out>) at ../system/physmem.c:2873
+ #29 0x0000563cb8f64ab8 in kvm_cpu_exec (cpu=cpu@entry=0x563cbac066d0) at ../accel/kvm/kvm-all.c:2915
+ #30 0x0000563cb8f65ce5 in kvm_vcpu_thread_fn (arg=arg@entry=0x563cbac066d0) at ../accel/kvm/kvm-accel-ops.c:51
+ #31 0x0000563cb90fd1c8 in qemu_thread_start (args=0x563cbaac33c0) at ../util/qemu-thread-posix.c:541
+ #32 0x00007f1de5ae2044 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
+ #33 0x00007f1de5b6261c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2112 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2112
new file mode 100644
index 00000000..a3bfe569
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2112
@@ -0,0 +1,26 @@
+Limited Support for MIPS clone syscall in QEMU User Mode
+Description of problem:
+Hello,
+
+I have been working with QEMU user mode to run programs based on the MIPS architecture and have encountered a limitation regarding the support for the MIPS clone syscall in the current implementation of QEMU user mode. Specifically, when invoking the clone syscall with certain flags, it results in the error "errno=22 (Invalid argument)" due to the absence of corresponding handling code in QEMU.
+
+Upon further investigation, I pinpointed the probable cause. QEMU user mode appears to check if the flags for the clone syscall include all the flags defined in CLONE_THREAD_FLAGS. If there is a mismatch, it returns "-TARGET_EINVAL".
+
+[source code](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c?ref_type=heads#L6564)
+
+The current CLONE_THREAD_FLAGS in QEMU are set to include: (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_THREAD | CLONE_SYSVSEM).
+
+However, in my MIPS program, the flags are only: (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND).
+
+Aligning my MIPS program to include all the flags as per CLONE_THREAD_FLAGS alters the clone syscall's behavior, deviating from the original semantics required by my MIPS program.
+
+I am seeking guidance on whether there is a way in QEMU user mode's MIPS syscall handling to exclusively use the flags (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND). Alternatively, I am interested in any possible approach to enable support for the MIPS architecture's clone syscall in QEMU user mode.
+
+Thank you for your time and assistance.
+Steps to reproduce:
+1. Write a C program that utilizes the clone function, specifying the flags as: CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND.
+
+strace output: 
+```
+clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND,child_stack=0x009359a8,parent_tidptr=0x00000f00,tls=0x00000003,child_tidptr=0x2b36d510) = -1 errno=22 (Invalid argument)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2113 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2113
new file mode 100644
index 00000000..1850391e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2113
@@ -0,0 +1 @@
+x64-freebsd-13-build CI job fails with "/usr/local/lib/libtasn1.so: undefined reference to strverscmp@FBSD_1.7"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2116 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2116
new file mode 100644
index 00000000..a47655df
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2116
@@ -0,0 +1,28 @@
+[CRASH] OpenGL acceleration except gtk: bad interaction between NVIDIA usermode opengl libraries and QEMU seccomp -sandbox on,spawn=deny, crashes immediately on startup with Bad system call
+Description of problem:
+When running any of the above command lines, QEMU crashes with Bad system call (core dumped). Not exclusive to spice; it seems this is caused by QEMU forking during OpenGL initialization after seccomp takes effect.
+Steps to reproduce:
+1. Run the above commandline
+2. Notice a Bad system call (core dumped)
+Additional information:
+This crash only happens if spawn=deny is set, resourcecontrol/obsolete/elevateprivileges don't cause crashes.
+
+The crash happens around the same time as an audit event is generated in dmesg: `audit: type=1326 audit(1705775880.776:14): auid=MYUSERID uid=MYUID gid=MYGID ses=REDACTED pid=REDACTED comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 arch=c000003e syscall=56 compat=0 ip=REDACTED code=REDACTED`
+
+`ausyscall c000003e 56` tells me it's `clone` which (iirc) is the syscall used by glibc to implement fork() (I might be wrong about glibc part)
+
+Suggested solution: move seccomp activation until just before guest code starts executing? make frontends (ie -display gtk/sdl/whatever, including -spice) initialize before seccomp?
+
+Workaround: `chmod -x /bin/nvidia-modprobe` if not using the NVIDIA gpu or use this wrapper script (untested, not enterprise-ready, I am not responsible if unexpected things happen):
+- rename /bin/qemu-system-x86_64 to qemu-system-x86_64.real
+- put this in /bin/qemu-system-x86_64 and chmod +x it
+```sh
+#!/usr/bin/env sh
+chmod -x /bin/nvidia-modprobe
+qemu-system-x86_64.real $@ & disown
+sleep 10 # excessive but maybe safer?
+chmod +x /bin/nvidia-modprobe
+```
+Also, you can use -display gtk,gl=on instead, or (unknown security implications) remove spawn=deny from -sandbox args
+
+original bug report was https://gitlab.com/libvirt/libvirt/-/issues/585 but I realized this was more of a qemu issue than a libvirt one
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2117 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2117
new file mode 100644
index 00000000..17e7980c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2117
@@ -0,0 +1,27 @@
+Unraid, Ubuntu, 9P/virtio and memory issues
+Description of problem:
+I am running an Ubuntu VM on Unraid - which is using Qemu. I am exposing my shares through "9p Mode" to the VM.
+
+The logs shows:
+-fsdev local,security_model=passthrough,id=fsdev-fs0,path=/mnt/user/backup \
+-device '{"driver":"virtio-9p-pci","id":"fs0","fsdev":"fsdev-fs0","mount_tag":"backup","bus":"pci.1","addr":"0x0"}' \
+
+Inside Ubuntu, I mount the exposed shares like this:
+
+sudo mount -t 9p -o trans=virtio "backup" /media/share/backup
+
+I have a script that uses rsync to sync the files from these mounted shares onto an internal disk drive. 
+
+The issues that I am facing, is that rsync sometimes reports "cannot allocate memory":
+
+rsync: [sender] readdir("/media/share/backup/myfolder"): Cannot allocate memory (12)
+ 
+There are "ten thousands" of files in that folder hierarchy, but there are plenty of memory available on the VM (many GBs), so that is no issue. The next time I run the job, it might go through as normal. But I would like to get rid of these issues.
+
+The question is: Is there some kind of memory allocation/limit to the virtio/9p as well? If yes - is there some way to increase it to avoid these errors?
+Steps to reproduce:
+1. Mount as shown
+2. Run rsync on folder with lots of files
+3. See error
+Additional information:
+N/A
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2118 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2118
new file mode 100644
index 00000000..883b5a74
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2118
@@ -0,0 +1 @@
+make vm-build-openbsd reinstalls OpenBSD every time
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2119 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2119
new file mode 100644
index 00000000..77f4a54a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2119
@@ -0,0 +1 @@
+target/riscv/gdbstub.c：The V registers in gdb debugging mode can only be accessed  when the single-letter V is enabled
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2121 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2121
new file mode 100644
index 00000000..80e7bd30
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2121
@@ -0,0 +1 @@
+tests/qtest/ahci-test.c:89:verify_state: assertion failed (ahci_fingerprint == ahci->fingerprint): (0xe0000000 == 0x29228086)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2122 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2122
new file mode 100644
index 00000000..defbe24e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2122
@@ -0,0 +1,7 @@
+qemu-user-static segfault running ldconfig on host x86_64 with client arm64
+Description of problem:
+qemu segfault
+Steps to reproduce:
+1. download ubuntu jammy arm64 rootfs (I assume any will do)
+2. mount it (with /proc from host so apt is happy)
+3. execute an apt uninstall that triggers libc-bin processing
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2123 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2123
new file mode 100644
index 00000000..cfe83933
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2123
@@ -0,0 +1,31 @@
+Invalid subprocess commands spawns successfully when running under QEMU
+Description of problem:
+When executing a subprocess from with a non-existing command EQMU still spawns a process.
+
+Consider this small rust program for instance:
+```rust
+use std::process::Command;
+
+fn main() {
+    match Command::new("thisdoesnotexist").spawn() {
+        Ok(child) => {
+            println!("Child process id is {}", child.id());
+        }
+        Err(_) => {
+            println!("This should happen");
+        }
+    }
+}
+```
+
+**Executing with `qemu-aarch64`:**
+```shell
+qemu-aarch64 ./rust-app
+Child process id is 20182
+```
+
+**Executing regularly:**
+```shell
+./rust-app
+This should happen
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2124 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2124
new file mode 100644
index 00000000..5bf12536
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2124
@@ -0,0 +1 @@
+Use watchdog_perform_action() for watchdogs currently using qemu_system_reset_request()
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2125 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2125
new file mode 100644
index 00000000..c71352c0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2125
@@ -0,0 +1,14 @@
+The value of 'tx_queue_size' is set to only 256 in the network device option on qemu 8.2.
+Description of problem:
+I have been using the 'tx_queue_size' value set to 1024 in the network device option on qemu 7.2 without any issues.\
+but when I upgrade to qemu 8.2 I got this error message (and also qemu 8.1) and I cannot use any value other than 256
+```
+qemu-system-x86_64: -device virtio-net-pci,mq=on,vectors=6,netdev=hostnet_34,id=dpdk_34,mac=F2:20:AF:40:12:65,bus=bridge,addr=0x7,page-per-vq=on,rx_queue_size=1024,tx_queue_size=1024,mrg_rxbuf=on,disable-legacy=on,disable-modern=off,host_mtu=1500,csum=on,guest_csum=on,host_tso4=on,host_tso6=on: Invalid tx_queue_size (= 1024), must be a power of 2 between 256 and 256
+```
+
+and I think virtqueue max size value has never changed from 1024.\
+https://gitlab.com/qemu-project/qemu/-/blob/staging-8.2/include/hw/virtio/virtio.h?ref_type=heads#L62
+Steps to reproduce:
+1. boot qemu-system-x86_64 on qemu 8.2 and network device option set tx_queue_size value over 256
+Additional information:
+- I'm using hardware vDPA offloading with mellanox NIC card.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2126 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2126
new file mode 100644
index 00000000..1a3f3781
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2126
@@ -0,0 +1 @@
+iotest-144 sometimes fails due to minor reordering of output
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2127 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2127
new file mode 100644
index 00000000..e09c1e5d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2127
@@ -0,0 +1 @@
+test-aio-multithread.c:371:test_multi_fair_mutex: assertion failed (counter == atomic_counter): (316636 == 316637)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2128 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2128
new file mode 100644
index 00000000..1fa647a6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2128
@@ -0,0 +1 @@
+avocado tests using landley.net URLs sometimes time out fetching assets
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2129 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2129
new file mode 100644
index 00000000..973286d7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2129
@@ -0,0 +1 @@
+migration-test sometimes fails
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/213 b/gitlab/issues_text/target_missing/host_missing/accel_missing/213
new file mode 100644
index 00000000..03561239
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/213
@@ -0,0 +1 @@
+memory writes via gdb don't work for memory mapped hardware
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2130 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2130
new file mode 100644
index 00000000..30264d3e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2130
@@ -0,0 +1 @@
+latest code missing "singlestep"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2131 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2131
new file mode 100644
index 00000000..d9f26a84
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2131
@@ -0,0 +1 @@
+tcg mem plugin, udata always zero
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2132 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2132
new file mode 100644
index 00000000..1ef3f972
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2132
@@ -0,0 +1,11 @@
+USB Hub as USB Host Device: Child devices not recognized in Win11
+Description of problem:
+I wanted to give the Windows environment direct access to some of the physical USB ports on my pc. So I mapped a selection of ports to Windows via the associated hub. Windows correctly recognizes the hub. Also, when devices are plugged into or removed from the associated ports, Windows recognizes the connection of a new device or its removal. However, regardless of the device, Windows reports:
+"USB device not recognized.
+The last USB device you connected to this computer has malfunctioned, and Windows does not recognize it."
+Steps to reproduce:
+1. Add one of the hosts USB hubs to a Windows VM as a USB Host Device.
+2. Verify that Windows recognizes the host hub in device manager.
+3. Try plugging in a USB device into one of the corresponding physical ports.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2134 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2134
new file mode 100644
index 00000000..17615889
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2134
@@ -0,0 +1 @@
+[Tricore Board]How to map LOCAL. DSPR/LOCAL.PSPR to other CPU globle_DSPR/globle_PSPR
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2135 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2135
new file mode 100644
index 00000000..29a66bb7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2135
@@ -0,0 +1,24 @@
+Looking for ways to bypass MPS3-AN547 bootram size limit
+Description of problem:
+Could not boot MPS3-AN547 machine with images larger than 512KiB. 
+
+I've tried to move part of the symbols to other memory area, but the memories were discontinuous and this resulted in a large image which covers the reserved area in-between and wouldn't boot. I'm looking for advice on how to put more code in bootram. 
+
+I've also noticed the 8MB QSPI rom area, but AN547 does not have the remapping capability as AN524 and cannot use that as bootram. What is the best way to solve this?
+Steps to reproduce:
+1.Generate an image which goes beyond 0x00000000~(0+512K)
+
+2.```qemu-system-arm -M mps3-an547 -nographic -kernel big-image.bin```
+
+3."```qemu-system-arm: Could not load kernel 'nuttx/nuttx.bin'```"
+Additional information:
+Current working linker script:
+```
+MEMORY
+{
+  flash (rx)  : ORIGIN = 0x00000000, LENGTH = 512K
+  sram1 (rwx) : ORIGIN = 0x01000000, LENGTH = 2M
+  sram2 (rwx) : ORIGIN = 0x21000000, LENGTH = 4M
+}
+```
+Problem X is that the flash will overflow.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2138 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2138
new file mode 100644
index 00000000..58480f34
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2138
@@ -0,0 +1,22 @@
+Build failure on macOS when using --disable-cocoa
+Description of problem:
+Build fails:
+
+```
+../qemu-8.2.1/meson.build:3741:13: ERROR: No host machine compiler for 'audio/coreaudio.m'
+```
+Steps to reproduce:
+1. On macOS run `./configure --disable-cocoa`
+
+Result:
+
+```
+Compiler for language objc skipped: feature cocoa disabled
+```
+```
+../meson.build:3741:13: ERROR: No host machine compiler for 'audio/coreaudio.m'
+```
+Additional information:
+It seems your build script contains the assumption that an Objective-C compiler is not needed when the Cocoa UI is disabled, but it still appears to be needed to compile the CoreAudio code regardless of UI.
+
+This was originally reported to MacPorts here: https://trac.macports.org/ticket/67984
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2139 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2139
new file mode 100644
index 00000000..5390181c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2139
@@ -0,0 +1,9 @@
+Super/Win key seems to release immediately on sdl+windows
+Description of problem:
+Currently on windows when trying SerenityOS the super key releases immediately so you can't use the shortcuts, with the GTK gui (gl off) it works though. but GTK has other problems with mouse which sometimes doesn't work at all, SDL seems to work well besides from this one issue.
+Steps to reproduce:
+1. Boot with default settings on wsl2 which launches qemu on windows if it's installed
+2. Try to use any of the superkey shortcuts like superkey+space for a search popup https://github.com/SerenityOS/serenity/blob/dc47d01fdc62a1ee319310e2b11c26b8ebe8899d/Base/usr/share/man/man7/KeyboardShortcuts.md#L4
+3. Fail because it immediately opens the menu blocking the shortcuts.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/214 b/gitlab/issues_text/target_missing/host_missing/accel_missing/214
new file mode 100644
index 00000000..ada6d81e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/214
@@ -0,0 +1 @@
+QEMU manpages provoke man(1) "can't break line" warnings
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2140 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2140
new file mode 100644
index 00000000..1b6421b2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2140
@@ -0,0 +1 @@
+Compiling object tests/fp - Can't create tests/fp Is directory Centos 7
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2142 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2142
new file mode 100644
index 00000000..a301e943
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2142
@@ -0,0 +1 @@
+`-machine microvm -cpu host` crashes when guest attempts to check CPUID SGX bits
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2144 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2144
new file mode 100644
index 00000000..d72c3a7f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2144
@@ -0,0 +1,22 @@
+macOS build fails when using --enable-debug
+Description of problem:
+the build fails because a symbol can't be found:
+
+```
+ld: Undefined symbols:
+  _lasi_82596_init, referenced from:
+      _machine_HP_common_init_tail in hw_hppa_machine.c.o
+```
+Steps to reproduce:
+1. on macOS 14.3 in build folder
+2. ../configure --enable-debug
+3. make -j12
+Additional information:
+the default build with
+
+```
+../configure
+make -j12
+```
+
+succeeds normally.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2147 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2147
new file mode 100644
index 00000000..36c3edd0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2147
@@ -0,0 +1,9 @@
+The Windows version of QEMU runs the semihost project without printing
+Description of problem:
+In Linux, running this command to execute the Semihost project will print `Hello World` in the console, but running in Windows will not print anything.
+
+I'd like to know if it's the windows version of qemu that doesn't have perfect support for semihost, or if I need to adjust the input parameters.
+Steps to reproduce:
+
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2148 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2148
new file mode 100644
index 00000000..0c456807
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2148
@@ -0,0 +1,9 @@
+vdso.so is required to build vdso.so since 8.2.0
+Description of problem:
+Removing binaries from the "source" distribution makes it unable to compile. It used to work in 8.1.4.
+Steps to reproduce:
+1. remove **/vdso.so
+2. configure, build
+3. `../linux-user/i386/meson.build:7:20: ERROR: File vdso.so does not exist.`
+Additional information:
+Build log in my Gentoo harness: [build.log](/uploads/da1933173b39dd6e5f9f90de09adc3a1/build.log)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2149 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2149
new file mode 100644
index 00000000..7a1dc95a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2149
@@ -0,0 +1,11 @@
+Segfault in libvhost-user and libvduse because of invalid pointer arithmetic with indirect read
+Description of problem:
+Hello, this is my first experience communicating with open-source community. I have already reported the problem and have submitted patches through qemu-devel mailing list https://mail.gnu.org/archive/html/qemu-devel/2024-01/msg02533.html, as instructed in https://www.qemu.org/docs/master/devel/submitting-a-patch.html, albeit getting no response from any maintainer. I know, that everyone are very busy and are spammed everyday from millions of threads, but I am getting very upset, that such a trivial bug lives in code base for many years and even have been copied to "sister"-library without proper review. So, excuse me, if I am taking this issue too personally.
+
+The problem - when one tries to use libvhost-user\libvduse and triggers for some reason non-zero-copy mode (like pushing a lot of data) of indirect descriptor reading routine `virtqueue_read_indirect_desc`, any time one got to read more than one descriptor - one would overwrite stack and depending on one's luck getting some weird behaviour, or simple crash moments later, when other code tries to access broken data.
+
+Steps to reproduce are non-trivial, because depends on one's host and VM (one simply gets random crashes here and there, with core dumps pointing somewhere around given libraries), but anyone who can read C code, can clearly see that pointer arithmetic of `struct vring_desc *desc` is wrong.
+
+Maybe, I got instructions wrong and posted fixes to wrong mailing list, maybe, nobody cares, so thank you for attention. I'll be glad to hear any advice on how can I help with fixing this simple error, besides what has been done already.
+
+Thank you.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2151 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2151
new file mode 100644
index 00000000..feee5a9d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2151
@@ -0,0 +1,195 @@
+Nested vIOMMU PCI Passthrough kernel panics
+Description of problem:
+In an effort to test vIOMMU according to <https://wiki.qemu.org/Features/VT-d> I've run into a kernel panic on an L2 guest receiving the L1 hypervisor's PCI passed virtual macvtap hostdev. Upon an `ifup` inside the L2 guest, on the network device passed through from the L1 host, the following kernel panic occurs and the L2 guest reboots:
+
+```
+[  OK  ] Started ifup@enp0s2.service - ifup for enp0s2.
+[  OK  ] Started ifup@enp0s3.service - ifup for enp0s3.[   24.019839] audit: type=1400 audit(1707113302.472:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=457 comm="apparmor_parser"
+
+         Starting networking.service - Raise network interfaces...
+[   24.255671] audit: type=1400 audit(1707113302.472:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=457 comm="apparmor_parser"
+[  OK  ] Finished systemd-tmpfiles-…te Volatile Files and Directories.
+[   24.361355] audit: type=1400 audit(1707113302.472:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=457 comm="apparmor_parser"
+         Starting systemd-timesyncd… - Network Time Synchronization...
+         Starting systemd-update-ut…rd System Boot/Shutdown in UTMP...
+[  OK  ] Finished systemd-update-ut…cord System Boot/Shutdown in UTMP.
+[  OK  ] Finished networking.service - Raise network interfaces.
+[  OK  ] Reached target network.target - Network.
+[  OK  ] Started systemd-timesyncd.…0m - Network Time Synchronization.
+[  OK  ] Reached target sysinit.target - System Initialization.
+[  OK  ] Started etckeeper.timermit of changes in /etc directory.
+[  OK  ] Started systemd-tmpfiles-c… Cleanup of Temporary Directories.
+[  OK  ] Reached target time-set.target - System Time Set.
+[  OK  ] Started apt-daily.timer - Daily apt download activities.[   46.187450] rcu: INFO: rcu_preempt self-detected stall on CPU
+[   46.187522] rcu:     0-...!: (5250 ticks this GP) idle=3774/1/0x4000000000000000 softirq=12350/12350 fqs=0
+[   46.187522]  (t=5250 jiffies g=8669 q=7 ncpus=1)
+[   46.187522] rcu: rcu_preempt kthread timer wakeup didn't happen for 5249 jiffies! g8669 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
+[   46.187522] rcu:     Possible timer handling issue on cpu=0 timer-softirq=2282
+[   46.187522] rcu: rcu_preempt kthread starved for 5250 jiffies! g8669 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
+[   46.187522] rcu:     Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
+[   46.187522] rcu: RCU grace-period kthread stack dump:
+[   46.187522] task:rcu_preempt     state:I stack:0     pid:15    ppid:2      flags:0x00004000
+[   46.187522] Call Trace:
+[   46.187522]  <TASK>
+[   46.187522]  __schedule+0x34d/0x9e0
+[   46.187522]  ? rcu_gp_cleanup+0x460/0x460
+[   46.187522]  schedule+0x5a/0xd0
+[   46.187522]  schedule_timeout+0x94/0x150
+[   46.187522]  ? __bpf_trace_tick_stop+0x10/0x10
+[   46.187522]  rcu_gp_fqs_loop+0x141/0x550
+[   46.187522]  rcu_gp_kthread+0xd0/0x190
+[   46.187522]  kthread+0xda/0x100
+[   46.187522]  ? kthread_complete_and_exit+0x20/0x20
+[   46.187522]  ret_from_fork+0x22/0x30
+[   46.187522]  </TASK>
+[   46.187522] rcu: Stack dump where RCU GP kthread last ran:
+[   46.187522] CPU: 0 PID: 487 Comm: ip Not tainted 6.1.0-17-amd64 #1  Debian 6.1.69-1
+[   46.187522] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014
+[   46.187522] RIP: 0010:virtqueue_get_buf_ctx_split+0x94/0xd0 [virtio_ring]
+[   46.187522] Code: 42 fe ff ff 0f b7 43 58 83 c0 01 66 89 43 58 f6 83 80 00 00 00 01 75 12 80 7b 4a 00 48 8b 4b 70 8b 53 60 74 0f 66 87 44 51 04 <48> 89 e8 5b 5d c3 cc cc cc cc 66 89 44 51 04 0f ae f0 48 89 e8 5b
+[   46.187522] RSP: 0018:ffff960c408135c8 EFLAGS: 00000246
+[   46.187522] RAX: 0000000000000000 RBX: ffff88e04e976100 RCX: 0000000000000001
+[   46.187522] RDX: 0000000000000000 RSI: ffff960c408135e4 RDI: ffff88e04e976100
+[   46.187522] RBP: 0000000000000000 R08: 0000000000000004 R09: ffff88e0034fa980
+[   46.187522] R10: 0000000000000003 R11: ffff960c40813628 R12: 0000000000000002
+[   46.187522] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
+[   46.187522] FS:  00007f11d16da2c0(0000) GS:ffff88e07dc00000(0000) knlGS:0000000000000000
+[   46.187522] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[   46.187522] CR2: 00007f11d17ff8d0 CR3: 0000000004ac6000 CR4: 00000000000006f0
+[   46.187522] Call Trace:
+[   46.187522]  <IRQ>
+[   46.187522]  ? rcu_check_gp_kthread_starvation+0xec/0xfd
+[   46.187522]  ? rcu_sched_clock_irq.cold+0xe3/0x459
+[   46.187522]  ? update_load_avg+0x7e/0x780
+[   46.187522]  ? sched_slice+0x87/0x140
+[   46.187522]  ? timekeeping_update+0xdd/0x130
+[   46.187522]  ? timekeeping_advance+0x377/0x570
+[   46.187522]  ? update_process_times+0x70/0xb0
+[   46.187522]  ? tick_sched_handle+0x22/0x60
+[   46.187522]  ? tick_sched_timer+0x63/0x80
+[   46.187522]  ? tick_sched_do_timer+0xa0/0xa0
+[   46.187522]  ? __hrtimer_run_queues+0x112/0x2b0
+[   46.187522]  ? hrtimer_interrupt+0xf4/0x210
+[   46.187522]  ? __sysvec_apic_timer_interrupt+0x5d/0x110
+[   46.187522]  ? sysvec_apic_timer_interrupt+0x69/0x90
+[   46.187522]  </IRQ>
+[   46.187522]  <TASK>
+[   46.187522]  ? asm_sysvec_apic_timer_interrupt+0x16/0x20
+[   46.187522]  ? virtqueue_get_buf_ctx_split+0x94/0xd0 [virtio_ring]
+[   46.187522]  virtnet_send_command+0x18e/0x1e0 [virtio_net]
+[   46.187522]  virtnet_set_rx_mode+0xd4/0x2d0 [virtio_net]
+[   46.187522]  __dev_open+0x12b/0x1a0
+[   46.187522]  __dev_change_flags+0x1d2/0x240
+[   46.187522]  dev_change_flags+0x22/0x60
+[   46.187522]  do_setlink+0x37c/0x12b0
+[   46.187522]  ? __nla_validate_parse+0x61/0xc00
+[   46.187522]  __rtnl_newlink+0x623/0x9e0
+[   46.187522]  ? __kmem_cache_alloc_node+0x191/0x2a0
+[   46.187522]  rtnl_newlink+0x43/0x70
+[   46.187522]  rtnetlink_rcv_msg+0x14e/0x3b0
+[   46.187522]  ? __kmem_cache_alloc_node+0x191/0x2a0
+[   46.187522]  ? __alloc_skb+0x88/0x1a0
+[   46.187522]  ? rtnl_calcit.isra.0+0x140/0x140
+[   46.187522]  netlink_rcv_skb+0x51/0x100
+[   46.187522]  netlink_unicast+0x24a/0x390
+[   46.187522]  netlink_sendmsg+0x250/0x4c0
+[   46.187522]  __sock_sendmsg+0x5f/0x70
+[   46.187522]  ____sys_sendmsg+0x277/0x2f0
+[   46.187522]  ? copy_msghdr_from_user+0x7d/0xc0
+[   46.187522]  ___sys_sendmsg+0x9a/0xe0
+[   46.187522]  __sys_sendmsg+0x76/0xc0
+[   46.187522]  do_syscall_64+0x5b/0xc0
+[   46.187522]  ? exit_to_user_mode_prepare+0x40/0x1e0
+[   46.187522]  ? syscall_exit_to_user_mode+0x27/0x40
+[   46.187522]  ? do_syscall_64+0x67/0xc0
+[   46.187522]  ? do_user_addr_fault+0x1b0/0x580
+[   46.187522]  ? exit_to_user_mode_prepare+0x40/0x1e0
+[   46.187522]  entry_SYSCALL_64_after_hwframe+0x64/0xce
+[   46.187522] RIP: 0033:0x7f11d1811af0
+[   46.187522] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 66 2e 0f 1f 84 00 00 00 00 00 90 80 3d f1 fa 0c 00 00 74 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 89 54
+[   46.187522] RSP: 002b:00007ffe21b533a8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e
+[   46.187522] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f11d1811af0
+[   46.187522] RDX: 0000000000000000 RSI: 00007ffe21b53410 RDI: 0000000000000003
+[   46.187522] RBP: 0000000000000003 R08: 0000000065c07b57 R09: 00005580e154e2a0
+[   46.187522] R10: 00007ffe21b52e34 R11: 0000000000000202 R12: 0000000065c07b58
+[   46.187522] R13: 00005580e016e020 R14: 0000000000000001 R15: 0000000000000000
+[   46.187522]  </TASK>
+[   46.187522] CPU: 0 PID: 487 Comm: ip Not tainted 6.1.0-17-amd64 #1  Debian 6.1.69-1
+[   46.187522] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014
+[   46.187522] RIP: 0010:virtqueue_get_buf_ctx_split+0x94/0xd0 [virtio_ring]
+[   46.187522] Code: 42 fe ff ff 0f b7 43 58 83 c0 01 66 89 43 58 f6 83 80 00 00 00 01 75 12 80 7b 4a 00 48 8b 4b 70 8b 53 60 74 0f 66 87 44 51 04 <48> 89 e8 5b 5d c3 cc cc cc cc 66 89 44 51 04 0f ae f0 48 89 e8 5b
+[   46.187522] RSP: 0018:ffff960c408135c8 EFLAGS: 00000246
+[   46.187522] RAX: 0000000000000000 RBX: ffff88e04e976100 RCX: 0000000000000001
+[   46.187522] RDX: 0000000000000000 RSI: ffff960c408135e4 RDI: ffff88e04e976100
+[   46.187522] RBP: 0000000000000000 R08: 0000000000000004 R09: ffff88e0034fa980
+[   46.187522] R10: 0000000000000003 R11: ffff960c40813628 R12: 0000000000000002
+[   46.187522] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
+[   46.187522] FS:  00007f11d16da2c0(0000) GS:ffff88e07dc00000(0000) knlGS:0000000000000000
+[   46.187522] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[   46.187522] CR2: 00007f11d17ff8d0 CR3: 0000000004ac6000 CR4: 00000000000006f0
+[   46.187522] Call Trace:
+[   46.187522]  <IRQ>
+[   46.187522]  ? rcu_dump_cpu_stacks+0xa4/0xe0
+[   46.187522]  ? rcu_sched_clock_irq.cold+0xe8/0x459
+[   46.187522]  ? update_load_avg+0x7e/0x780
+[   46.187522]  ? sched_slice+0x87/0x140
+[   46.187522]  ? timekeeping_update+0xdd/0x130
+[   46.187522]  ? timekeeping_advance+0x377/0x570
+[   46.187522]  ? update_process_times+0x70/0xb0
+[   46.187522]  ? tick_sched_handle+0x22/0x60
+[   46.187522]  ? tick_sched_timer+0x63/0x80
+[   46.187522]  ? tick_sched_do_timer+0xa0/0xa0
+[   46.187522]  ? __hrtimer_run_queues+0x112/0x2b0
+[   46.187522]  ? hrtimer_interrupt+0xf4/0x210
+[   46.187522]  ? __sysvec_apic_timer_interrupt+0x5d/0x110
+[   46.187522]  ? sysvec_apic_timer_interrupt+0x69/0x90
+[   46.187522]  </IRQ>
+[   46.187522]  <TASK>
+[   46.187522]  ? asm_sysvec_apic_timer_interrupt+0x16/0x20
+[   46.187522]  ? virtqueue_get_buf_ctx_split+0x94/0xd0 [virtio_ring]
+[   46.187522]  virtnet_send_command+0x18e/0x1e0 [virtio_net]
+[   46.187522]  virtnet_set_rx_mode+0xd4/0x2d0 [virtio_net]
+[   46.187522]  __dev_open+0x12b/0x1a0
+[   46.187522]  __dev_change_flags+0x1d2/0x240
+[   46.187522]  dev_change_flags+0x22/0x60
+[   46.187522]  do_setlink+0x37c/0x12b0
+[   46.187522]  ? __nla_validate_parse+0x61/0xc00
+[   46.187522]  __rtnl_newlink+0x623/0x9e0
+[   46.187522]  ? __kmem_cache_alloc_node+0x191/0x2a0
+[   46.187522]  rtnl_newlink+0x43/0x70
+[   46.187522]  rtnetlink_rcv_msg+0x14e/0x3b0
+[   46.187522]  ? __kmem_cache_alloc_node+0x191/0x2a0
+[   46.187522]  ? __alloc_skb+0x88/0x1a0
+[   46.187522]  ? rtnl_calcit.isra.0+0x140/0x140
+[   46.187522]  netlink_rcv_skb+0x51/0x100
+[   46.187522]  netlink_unicast+0x24a/0x390
+[   46.187522]  netlink_sendmsg+0x250/0x4c0
+[   46.187522]  __sock_sendmsg+0x5f/0x70
+[   46.187522]  ____sys_sendmsg+0x277/0x2f0
+[   46.187522]  ? copy_msghdr_from_user+0x7d/0xc0
+[   46.187522]  ___sys_sendmsg+0x9a/0xe0
+[   46.187522]  __sys_sendmsg+0x76/0xc0
+[   46.187522]  do_syscall_64+0x5b/0xc0
+[   46.187522]  ? exit_to_user_mode_prepare+0x40/0x1e0
+[   46.187522]  ? syscall_exit_to_user_mode+0x27/0x40
+[   46.187522]  ? do_syscall_64+0x67/0xc0
+[   46.187522]  ? do_user_addr_fault+0x1b0/0x580
+[   46.187522]  ? exit_to_user_mode_prepare+0x40/0x1e0
+[   46.187522]  entry_SYSCALL_64_after_hwframe+0x64/0xce
+[   46.187522] RIP: 0033:0x7f11d1811af0
+[   46.187522] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 66 2e 0f 1f 84 00 00 00 00 00 90 80 3d f1 fa 0c 00 00 74 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 89 54
+[   46.187522] RSP: 002b:00007ffe21b533a8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e
+[   46.187522] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f11d1811af0
+[   46.187522] RDX: 0000000000000000 RSI: 00007ffe21b53410 RDI: 0000000000000003
+[   46.187522] RBP: 0000000000000003 R08: 0000000065c07b57 R09: 00005580e154e2a0
+[   46.187522] R10: 00007ffe21b52e34 R11: 0000000000000202 R12: 0000000065c07b58
+[   46.187522] R13: 00005580e016e020 R14: 0000000000000001 R15: 0000000000000000
+[   46.187522]  </TASK>
+```
+Steps to reproduce:
+1. Create the following nested passthrough configuration
+2. Attempt to configure the L1 network hostdev interface inside the L2 guest
+
+Any attempt will cause the kernel panics documented.
+Additional information:
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2153 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2153
new file mode 100644
index 00000000..c1837b13
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2153
@@ -0,0 +1 @@
+ubuntu-20.04-s390x-all CI job is very flaky
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2154 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2154
new file mode 100644
index 00000000..5f595295
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2154
@@ -0,0 +1,7 @@
+ID_AA64MMFR2_EL1 is all zeros
+Description of problem:
+When the `ID_AA64MMFR2_EL1` register is read via `mrs x[n], ID_AA64MMFR2_EL1`, it is read as all zeros. This is at the very least not correct for `ID_AA64MMFR2_EL1.ST`, which describes support for small translation tables (FEAT_TTST).
+Steps to reproduce:
+1. Run `mrs x[n], ID_AA64MMFR2_EL1` within qemu-system-aarch64
+Additional information:
+FEAT_TTST is a relatively new aarch64 feature that appears to have caused many problems basically everywhere. However, [qemu has reportedly implemented it](https://www.qemu.org/2021/04/30/qemu-6-0-0/).
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2156 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2156
new file mode 100644
index 00000000..50fb9a34
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2156
@@ -0,0 +1,15 @@
+Userland QEMU segfaults when emulating itself thrice
+Description of problem:
+See title. 
+```
+$ qemu-x86_64-static qemu-x86_64-static qemu-x86_64-static /bin/true
+qemu-x86_64-static: QEMU internal SIGSEGV {code=ACCERR, addr=0x7f9ae80001a0}
+[1]    15705 segmentation fault (core dumped)  qemu-x86_64-static qemu-x86_64-static qemu-x86_64-static /bin/true
+```
+Steps to reproduce:
+1. Execute command above
+Additional information:
+Coredump (~322MB uncompressed)
+[qemu_qemu-x86_64-static_20240208-123447_15705.core.xz](/uploads/a6723aaf956dfd1efc434303e62c25e2/qemu_qemu-x86_64-static_20240208-123447_15705.core.xz)
+
+SHA1: 31c2b06a61f63dca5199b64b767aa2fdeefbeec6
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2157 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2157
new file mode 100644
index 00000000..3ec2175d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2157
@@ -0,0 +1,43 @@
+qemu-user fails to run 32-bit x86 binaries on hosts with a page size > 4KB
+Description of problem:
+`qemu-i386` refuses to run 32-bit x86 binaries on hosts with a page size > 4KB
+(such as LoongArch, ppc64le, arm64 with 3 level page tables).
+Steps to reproduce:
+1. Compile x86 binary which makes a single exit(0) syscall:
+   ```
+   cat > exit0.S << EOF
+   #include <sys/syscall.h>
+   .text
+   .global _start
+    _start:
+      movl $__NR_exit, %eax
+      movl $0, %ebx
+      int $0x80
+   EOF
+   i586-linux-gnu-gcc -nostdlib -static -no-pie -o exit0 exit0.S
+   ```
+   Alternatively one might compile it on a x86 host:
+   ```
+   gcc -m32 -nostdlib -static -no-pie -o exit0 exit0.S
+   ```
+   and transfer the `exit0` binary to ppc64/LoongArch/arm64 system
+
+   2. Run the `exit0` binary with `qemu-i386`
+   ```
+   qemu-i386-static ./exit0
+   ```
+
+   #
+Additional information:
+`.text` segment of (32-bit) x86 binaries is typically aligned at 4KB:
+```
+Program Headers:
+  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
+  LOAD           0x000000 0x08048000 0x08048000 0x00100 0x00100 R   0x1000
+  LOAD           0x001000 0x08049000 0x08049000 0x0000c 0x0000c R E 0x1000
+  NOTE           0x0000b4 0x080480b4 0x080480b4 0x0004c 0x0004c R   0x4
+  GNU_PROPERTY   0x0000d8 0x080480d8 0x080480d8 0x00028 0x00028 R   0x4
+```
+
+Thus on a host with a page size being 64 KB (ppc64, arm64 with 3 level page tables) or 16 KB (LoongArch)
+alignment requirements in [pbg_dynamic](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c?ref_type=heads#L3020) can not be satisfied.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2158 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2158
new file mode 100644
index 00000000..a2d5d259
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2158
@@ -0,0 +1,9 @@
+Qemu will not release mouse even after using the release mouse keybind
+Description of problem:
+There wasn't a crash but this is an annoying problem. The mouse does not release when the VM sizes the window larger because, as far as I know, qemu moves the window and relies on the user to click to release the mouse.
+Steps to reproduce:
+1. Open qemu 
+2. Try to release the mouse using the keybind shown.
+3. It move the window and won't release.
+Additional information:
+In case it's really needed, I am using a custom QEMU VM Manager called "QEMU Manager".
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2160 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2160
new file mode 100644
index 00000000..79003d03
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2160
@@ -0,0 +1 @@
+msys2-32bit CI job fails with "error: target not found: mingw-w64-i686-libusb"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2161 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2161
new file mode 100644
index 00000000..7b0ecb23
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2161
@@ -0,0 +1 @@
+warnings when building lockstep plugin on s390
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2162 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2162
new file mode 100644
index 00000000..43f62483
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2162
@@ -0,0 +1 @@
+Some subtests have over-optimistic timeouts and time out on the s390 runner
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2167 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2167
new file mode 100644
index 00000000..61e5b939
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2167
@@ -0,0 +1,40 @@
+The GPIO controllers connected to the emulated PCIe bus via vhost-user can't generate interrupts.
+Description of problem:
+The problem is related to emulation of GPIO controllers using the vhost-user protocol for GPIO. The problem was detected when using the [vhost-device-gpio](https://github.com/rust-vmm/vhost-device) software. I have described the whole issue in https://github.com/rust-vmm/vhost-device/issues/613 , but it is QEMU related, and therefore I describe it here as well.
+The broader context is described in https://stackoverflow.com/questions/75906208/how-to-connect-via-virtio-gui-running-on-host-with-gpio-in-a-qemu-emulated-virtu .
+Steps to reproduce:
+1. For Debian/testing you need to compile a libgpiod-2.1.1 (I assume that the following is done in the home directory directory of the `dev` user: `/home/dev`):
+
+    ```
+    wget https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/snapshot/libgpiod-2.1.tar.gz ; \
+    tar -xzf libgpiod-2.1.tar.gz ; \
+    cd libgpiod-2.1 ; \
+    autoupdate ; \
+    ./autogen.sh ; \
+    make
+    ```
+ 2. Download the vhost-device-gpio (`git clone https://github.com/rust-vmm/vhost-device.git`)
+ 3. Build the vhost-device-gpio (in the `vhost-device-gpio` subdirectory)
+
+    ```
+    export PATH_TO_LIBGPIOD=/home/dev/libgpiod-2.1
+    export SYSTEM_DEPS_LIBGPIOD_NO_PKG_CONFIG=1
+    export SYSTEM_DEPS_LIBGPIOD_SEARCH_NATIVE="${PATH_TO_LIBGPIOD}/lib/.libs/"
+    export SYSTEM_DEPS_LIBGPIOD_LIB=gpiod
+    export SYSTEM_DEPS_LIBGPIOD_INCLUDE="${PATH_TO_LIBGPIOD}/include/"
+    cargo build --features "mock_gpio"
+    ```
+ 4. Start vhost-device-gpio: (`LD_LIBRARY_PATH=/home/emb/libgpiod-2.1/lib/.libs/ ./vhost-device-gpio -s /tmp/gpio.sock -l s4`)
+ 5. Download the Buildroot 2023.11.1 (`wget https://buildroot.org/downloads/buildroot-2023.11.1.tar.xz` in another directory) and unpack it. Buildroot and the main directory of Buildroot tree are denoted by BR if the following description.
+ 6. Configure BR (run `make qemu_aarch64_virt_defconfig` in the main BR directory, run `make menuconfig` and select external toolchain, `BR2_PACKAGE_LIBGPIOD=y`, `BR2_PACKAGE_LIBGPIOD_TOOLS=y`, run `make linux-menuconfig` and select `CONFIG_GPIO_VIRTIO=m` in the kernel configuration)
+ 7. Build the Linux and QEMU (run `make` in the BR directory).
+ 8. Run the emulation in BR/output/images, using the command line given above.
+ 9. After the virtual machine starts, log in as root and load the driver: `modprobe gpio-virtio`
+10. Try to monitor changes of one of the emulated pins: `gpiomon 0 0`
+11. You'll get the error message:
+
+    ```
+    gpiomon: error waiting for events: No such device
+    ```
+Additional information:
+[0009-enable-F-IRQ-in-virtio-pci.patch](/uploads/39bc04b2d94063ccd539c5cfbc9cd105/0009-enable-F-IRQ-in-virtio-pci.patch)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2171 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2171
new file mode 100644
index 00000000..6c6fd66b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2171
@@ -0,0 +1,25 @@
+VPS Disk space over use
+Description of problem:
+\# qemu-img info -U v1001-dluw9EHRDbmMd8fQ-CACjC7FWnMhISeDM.qcow2
+
+file format: qcow2
+
+virtual size: 800G (858993459200 bytes)
+
+disk size: **812G**
+
+cluster_size: 65536
+
+Format specific information:
+
+compat: 1.1
+
+lazy refcounts: false
+
+refcount bits: 16
+
+corrupt: false
+
+Disk size is using beyond the Virtual size.
+
+How is that even possible ?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2172 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2172
new file mode 100644
index 00000000..b483a7ea
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2172
@@ -0,0 +1 @@
+Error "cannot enable SPICE if pixman is not available"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2176 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2176
new file mode 100644
index 00000000..00e1cc78
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2176
@@ -0,0 +1 @@
+Events delivered during Capabilities Negotiation mode
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2177 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2177
new file mode 100644
index 00000000..659e2316
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2177
@@ -0,0 +1 @@
+msys2-32bit CI job fails with "error: target not found: mingw-w64-i686-dtc"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2178 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2178
new file mode 100644
index 00000000..835a38d3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2178
@@ -0,0 +1,17 @@
+USB passthrough on Apple Silicon is unusable
+Description of problem:
+I can't get USB passthrough to work sufficiently well with wifi modems such as the RTL8187L or Atheros AR 9271.
+
+I only use the VM as a router since the host OS doesn't have drivers for any external wifi modems. This is a setup I've used flawlessly many times in the past with other VMs on x86 platforms for many years, but with ARM it's been one fail after another. Parallels does work with the exact same host and guest, but fails in the networking area (plus it's expensive and overkill for something this simple). I mention this because I know the guest drivers work 100% with a different VM.
+Steps to reproduce:
+1. Run any Linux on QEMU on any Apple Silicon mac
+2. Attempt to use a Atheros AR 9271 USB device
+3. Various fails including 
+      a) USB device not showing up (lsusb)
+      b) device shows up and Linux attempts to attach driver, but fails (lsmod shows driver loaded but no interface listed on iwconfig)
+      c) interface shows up (never got the Atheros this far, but RealTek does) but the interface is slow, corrupts data, etc. 
+      d) after re-attaching several times it will eventually stop attaching at all requiring a MacOS system reboot, which is really annoying for my workflow.
+
+It's basically non-functional for me. Atheros is 100% non-functional and RealTek 10% works (well enough to *sometimes* connect to the AP, but usually craps the bed if you try to do anything as simple as run a dhcp client to fetch the IP).
+
+If anyone knows of any other Linux ARM on Mac ARM vm solutions that allow USB passthrough please let me know. Unfortunately, VirtualBox os currently not one of them.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2179 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2179
new file mode 100644
index 00000000..a04432f3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2179
@@ -0,0 +1,51 @@
+qemu-storage-daemon: fuse export deadlock
+Steps to reproduce:
+1. Start QSD
+2. Issue a `block-stream` and a read from the fuse export at the same time 
+
+```
+Term 1:
+(QEMU) block-stream device=root job-id=job1
+{"return": {}}
+(QEMU) 
+{'timestamp': {'seconds': 1708386076, 'microseconds': 965781}, 'event': 'JOB_STATUS_CHANGE', 'data': {'status': 'created', 'id': 'job1'}}
+{'timestamp': {'seconds': 1708386076, 'microseconds': 965838}, 'event': 'JOB_STATUS_CHANGE', 'data': {'status': 'running', 'id': 'job1'}}
+(QEMU) 
+(QEMU) 
+(QEMU) 
+(QEMU) query-block-jobs
+
+<HANGS>
+
+
+Term 2:
+dd if=/tmp/fuse_exp of=/dev/null bs=1M skip=2000
+<HANGS>
+```
+
+```
+$ pidof qemu-storage-daemon 
+ 92313
+$ sudo cat /proc/92313/task/92313/stack 
+[<0>] do_sys_poll+0x4e1/0x5d0
+[<0>] __x64_sys_ppoll+0xe2/0x170
+[<0>] do_syscall_64+0x64/0xe0
+[<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
+
+$ sudo cat /proc/92313/task/92314/stack 
+[<0>] futex_wait_queue+0x63/0x90
+[<0>] __futex_wait+0x14f/0x1c0
+[<0>] futex_wait+0x77/0x110
+[<0>] do_futex+0xcb/0x190
+[<0>] __x64_sys_futex+0x129/0x1e0
+[<0>] do_syscall_64+0x64/0xe0
+[<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
+```
+Additional information:
+This might also be a general between `block-stream` and `copy-on-read` but I could only trigger the problem with FUSE and not NBD. E.g this command does not deadlock:
+```
+--export type=nbd,id=nbd-root,node-name=root_crw,name=root_crw,writable=off 
+
+nbdfuse /tmp/tmp.69dRvNXj1O/disk nbd://localhost:10809/root_crw
+dd if=/tmp/tmp.69dRvNXj1O/disk of=/dev/null bs=1M skip=2000
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/218 b/gitlab/issues_text/target_missing/host_missing/accel_missing/218
new file mode 100644
index 00000000..1336b754
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/218
@@ -0,0 +1 @@
+qemu-storage-daemon --nbd-server fails with "too many connections" error
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2182 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2182
new file mode 100644
index 00000000..f9b4bce5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2182
@@ -0,0 +1 @@
+Replication and Network
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2184 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2184
new file mode 100644
index 00000000..479dd27f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2184
@@ -0,0 +1,53 @@
+NVMe differences between QEMU v4.1.0 and v8.2.1
+Description of problem:
+We are currently upgrading QEMU from v4.1.0 to v8.2.1. In order to keep compatibility between the two QEMUs, we are adding ``-machine pc-q35-4.1``. One of our test is to ensure a guest that has hibernated on the previous QEMU is able to resume on the new one.
+
+When resuming, we get the following error:
+
+```
+[    7.394709] nvme nvme0: Device not ready; aborting reset, CSTS=0x1
+[    7.926188] nvme nvme0: Device not ready; aborting reset, CSTS=0x1
+[    7.938235] Read-error on swap-device (259:0:4874880)
+[    7.938237] Read-error on swap-device (259:0:4620184)
+[    7.938240] Read-error on swap-device (259:0:5536464)
+[    7.938311] Read-error on swap-device (259:0:5006840)
+[    7.938316] Read-error on swap-device (259:0:5791888)
+[    7.938386] Read-error on swap-device (259:0:6579728)
+[    7.938391] Read-error on swap-device (259:0:5536680)
+[    7.938431] Read-error on swap-device (259:0:4877384)
+[    7.938434] Read-error on swap-device (259:0:5005376)
+[    7.938457] Read-error on swap-device (259:0:5269328)
+[    7.939200] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
+[    7.939267] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
+[    7.946359] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
+[    8.063186] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
+[    8.069556] Aborting journal on device nvme0n1p1-8.
+[    8.069561] Buffer I/O error on dev nvme0n1p1, logical block 262144, lost sync page write
+[    8.069564] JBD2: Error -5 detected when updating journal superblock for nvme0n1p1-8.
+[    8.081218] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
+[    8.081242] Buffer I/O error on dev nvme0n1p1, logical block 0, lost sync page write
+[    8.081247] EXT4-fs (nvme0n1p1): I/O error while writing superblock
+[    8.147693] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
+[    8.147753] Buffer I/O error on dev nvme0n1p1, logical block 0, lost sync page write
+[    8.163478] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
+[    8.174179] EXT4-fs (nvme0n1p1): I/O error while writing superblock
+[    8.198741] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:2: reading directory lblock 0
+[    8.214483] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
+[    8.230322] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:2: reading directory lblock 0
+[    8.246249] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
+[    8.246269] Core dump to |/usr/share/apport/apport pipe failed
+[    8.246291] Core dump to |/usr/share/apport/apport pipe failed
+[    8.246336] Core dump to |/usr/share/apport/apport pipe failed
+[    8.246826] Core dump to |/usr/share/apport/apport pipe failed
+[    8.249232] Core dump to |/usr/share/apport/apport pipe failed
+[    8.249320] Core dump to |/usr/share/apport/apport pipe failed
+[    8.249880] Core dump to |/usr/share/apport/apport pipe failed
+```
+
+Digging throw the NVMe code, I have found one [patch](https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg04202.html) changing the BAR layout. It doesn't look like there is a way to select the previous BAR layout.
+
+When selecting the ``-machine``, I was expecting that the underlying HW (including devices) would not change. Can you clarify if hibernating from QEMU A and resuming to QEMU B is meant to be supported?
+Steps to reproduce:
+1. Start the guest with qemu v4.1.0 and an NVME disk
+2. Hibernate the OS
+3. Resume the guest with qemu v8.2.1
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2186 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2186
new file mode 100644
index 00000000..c153ebf3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2186
@@ -0,0 +1,34 @@
+riscv virt pflash0 writes not supported
+Description of problem:
+I am using GDB to debug some Firmware related stuff. At some point in the execution my BIOS/Firmware writes into some global variable (at 0x2000525C)  inside the .bss section which is linked to be inside the memory mapped pflash0. But when I step forward with GDB to the exact location where the store instruction (sw) is executed, QEMU prints the following:
+```
+pflash_write: Unimplemented flash cmd sequence (offset 000000000000525c, wcycle 0x0 cmd 0x0 value 0x1)
+```
+According to the top of `hw/block/pflash_cfi01.c` Flash writes are supported. I was also under the impression that the flash is memory mapped, but maybe that is not true? I am probably missing something here so it would be nice if someone could point me in the right direction. I would also gladly contribute if there is something missing in the riscv virt target. 
+
+I made a simple program to more easily reproduce this:
+```
+.section .text
+.global _start
+_start:
+	lui a5, 0x20000
+	li a4, 5
+	sw a4, 24(a5)
+
+```
+results in QEMU error msg:
+```
+pflash_write: Unimplemented flash cmd sequence (offset 0000000000000018, wcycle 0x0 cmd 0x0 value 0x5)
+```
+Steps to reproduce:
+1. compile above assembly program like this:
+```
+riscv64-unknown-elf-gcc -nostdlib -O0 bios.S
+riscv64-unknown-elf-objcopy -O binary a.out
+truncate -s 33554432 a.out
+```
+2. start QEMU like this:
+```
+qemu-system-riscv64 -M virt -bios none -drive if=pflash,format=raw,unit=0,file=a.out -nographic -d unimp
+```
+3. notice the error message printed by QEMU
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2187 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2187
new file mode 100644
index 00000000..83a67c45
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2187
@@ -0,0 +1 @@
+system/cpu: deadlock in pause_all_vcpus()
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2188 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2188
new file mode 100644
index 00000000..9ac35823
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2188
@@ -0,0 +1,10 @@
+virtio_gpu_gl_update_cursor_data() ignores the cursor resource's pixel format
+Description of problem:
+The function virtio_gpu_gl_update_cursor_data() ignores the pixel format of the resource it's reading from. It literally uses memcpy() to copy the pointer data. This works just fins if both the guest OS and the display backend use the same pixel format. 
+
+The SDL backend seems to use a different pixel format to the GTK display backend. So, you'll get the correct colours in one, but not the other.
+Steps to reproduce:
+1. Run a VM using Virtio GPU using the GTK backend. Set the guest OS' mouse pointer to one that's red instead of white, and note the mouse pointer's actual colour
+2. Now run the same VM using the SDL display backend. Check the colour of the mouse pointer (that should be red)
+
+NOTE: The choice of guest OS shouldn't matter.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2189 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2189
new file mode 100644
index 00000000..2bd6fdd8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2189
@@ -0,0 +1,14 @@
+vhost_user:When configure queues of vhost-user NIC exceeds max_queues, the virtual machine is always paused
+Description of problem:
+When the virtual machine uses the vhost-user network card and sets the queue number of the network card to exceed the maximum number of supported queues, the virtual machine fails to start and stays in the paused state.
+And the virtual machine log file kept print "qemu - system - x86_64: -netdev host-user,chardev=charnet0,queues=5,id=hostnet0:you are asking more queues than supported:4”
+Steps to reproduce:
+1.Configure vhost-user network cards for VMS and use multiple queues.
+2.The number of NIC queues configured in the VM xml file is greater than the maximum number of queues supported by the VM, that is, the number of Vcpus on the VM.
+3.Execute "virsh create VM_xml_file" cmd to start VM.
+Additional information:
+According to normal logic, if the number of configured vhost-user NIC queues exceeds max-queues, the qemu process should be stopped, rather than paused the virtual machine.
+I am confused about this patch:https://github.com/qemu/qemu/commit/c89804d674e4e3804bd3ac1fe79650896044b4e8
+The process will remain in the do...while loop, when vhost_user_start is called in net_vhost_user_event, if queues > max_queues in vhost_user_start.
+/label ~"kind::Bug"
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/219 b/gitlab/issues_text/target_missing/host_missing/accel_missing/219
new file mode 100644
index 00000000..d71ae53e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/219
@@ -0,0 +1 @@
+Request A Port of QEMU to UWP for xbox dev mode
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2190 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2190
new file mode 100644
index 00000000..0065e581
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2190
@@ -0,0 +1,7 @@
+qemu-block-drivers.rst.inc is embedded twice
+Description of problem:
+`qemu-block-drivers.rst.inc` is included both in `docs/system/qemu-block-drivers.rst` and in `docs/system/images.rst`, so it is repeated both at https://www.qemu.org/docs/master/system/qemu-block-drivers.html and at https://www.qemu.org/docs/master/system/images.html .
+
+This also makes the generation of the sphinx `objects.inv` search index nondeterministic: it will point to one page or the other depending on random chance at build time.
+
+Perhaps instead of embedding the drivers, `images.rst` should point to https://www.qemu.org/docs/master/system/qemu-block-drivers.html for the list?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2191 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2191
new file mode 100644
index 00000000..308f5470
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2191
@@ -0,0 +1 @@
+Support exposing exports based on authentication
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2192 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2192
new file mode 100644
index 00000000..fbd69220
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2192
@@ -0,0 +1 @@
+make vm-build-openbsd tries to download nonexistent 7.2 install ISO: need to update to 7.4
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2194 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2194
new file mode 100644
index 00000000..7dcf208e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2194
@@ -0,0 +1,94 @@
+qemu-system-mips64el loongson3-virt fails to complete boot
+Description of problem:
+I try to install Debian 12 using the netboot kernel (6.1.0) and initrd:
+```
+NETBOOT=http://ftp.debian.org/debian/dists/stable/main/installer-mips64el/current/images/loongson-3/netboot
+wget $NETBOOT/initrd.gz
+wget $NETBOOT/vmlinuz-6.1.0-18-loongson-3 -O vmlinuz
+qemu-img create -f qcow2 disk.qcow2 30G
+```
+
+Then I boot the installer:
+```
+qemu-system-mips64el \
+     -machine loongson3-virt -cpu Loongson-3A1000 -smp 4 -m 6G -nographic \
+     -kernel vmlinuz -initrd initrd.gz \
+     -drive file=disk.qcow2,if=none,id=drive-virtio-disk0 \
+     -device virtio-blk-pci,drive=drive-virtio-disk0 \
+     -append "root=/dev/sda1"
+```
+
+The boot stops after this:
+```
+[    0.000000] Linux version 6.1.0-18-loongson-3 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT Debian 6.1.76-1 (2024-02-01)
+[    0.000000] Firmware: Coherent DMA: on
+[    0.000000] CpuClock = 800000000
+[    0.000000] The bridge chip is VIRTUAL
+[    0.000000] CP0_Config3: CP0 16.3 (0x80)
+[    0.000000] CP0_PageGrain: CP0 5.1 (0x20000000)
+[    0.000000] NUMA: Discovered 4 cpus on 1 nodes
+[    0.000000] Node 0, mem_type:1	[0x0000000000000000], 0x000000000f000000 bytes usable
+[    0.000000] Node 0, mem_type:2	[0x0000000090000000], 0x0000000170000000 bytes usable
+[    0.000000] Node0's addrspace_offset is 0x0
+[    0.000000] Node0: start_pfn=0x0, end_pfn=0x80000
+[    0.000000] NUMA: set cpumask cpu 0 on node 0
+[    0.000000] NUMA: set cpumask cpu 1 on node 0
+[    0.000000] NUMA: set cpumask cpu 2 on node 0
+[    0.000000] NUMA: set cpumask cpu 3 on node 0
+[    0.000000] printk: bootconsole [early0] enabled
+[    0.000000] CPU0 revision is: 00006305 (ICT Loongson-3)
+[    0.000000] FPU revision is: 00770501
+[    0.000000] MIPS: machine is loongson,loongson64v-4core-virtio
+[    0.000000] Initial ramdisk at: 0x9800000004000000 (28553950 bytes)
+[    0.000000] software IO TLB: area num 1.
+[    0.000000] software IO TLB: mapped [mem 0x0000000005b3c000-0x0000000009b3c000] (64MB)
+[    0.000000] DMI not present or invalid.
+[    0.000000] Detected 4 available CPU(s)
+[    0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
+[    0.000000] Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 32 bytes
+[    0.000000] Unified victim cache 0kB direct mapped, linesize 0 bytes.
+[    0.000000] Unified secondary cache 4096kB 4-way, linesize 32 bytes.
+[    0.000000] Zone ranges:
+[    0.000000]   DMA32    [mem 0x0000000000000000-0x00000000ffffffff]
+[    0.000000]   Normal   [mem 0x0000000100000000-0x00000001ffffffff]
+[    0.000000] Movable zone start for each node
+[    0.000000] Early memory node ranges
+[    0.000000]   node   0: [mem 0x0000000000000000-0x000000000effffff]
+[    0.000000]   node   0: [mem 0x0000000090000000-0x00000001ffffffff]
+[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000001ffffffff]
+[    0.000000] On node 0, zone DMA32: 1024 pages in unavailable ranges
+[    0.000000] percpu: Embedded 13 pages/cpu s170800 r8192 d34000 u212992
+[    0.000000] Fallback order for Node 0: 0 
+[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 390660
+[    0.000000] Policy zone: Normal
+[    0.000000] Kernel command line: rd_start=0xffffffff84000000 rd_size=28553950 root=/dev/sda1 nokaslr
+[    0.000000] Unknown kernel command line parameters "nokaslr", will be passed to user space.
+[    0.000000] Dentry cache hash table entries: 1048576 (order: 9, 8388608 bytes, linear)
+[    0.000000] Inode-cache hash table entries: 524288 (order: 8, 4194304 bytes, linear)
+[    0.000000] mem auto-init: stack:all(zero), heap alloc:on, heap free:off
+[    0.000000] Memory: 2183328K/6275072K available (11247K kernel code, 1773K rwdata, 3152K rodata, 2688K init, 547K bss, 184208K reserved, 0K cma-reserved)
+[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
+[    0.000000] ftrace: allocating 32150 entries in 32 pages
+[    0.000000] ftrace: allocated 32 pages with 1 groups
+[    0.000000] trace event string verifier disabled
+[    0.000000] rcu: Preemptible hierarchical RCU implementation.
+[    0.000000] rcu: 	RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=4.
+[    0.000000] 	Trampoline variant of Tasks RCU enabled.
+[    0.000000] 	Rude variant of Tasks RCU enabled.
+[    0.000000] 	Tracing variant of Tasks RCU enabled.
+[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
+[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
+[    0.000000] NR_IRQS: 320
+[    0.000000] ISA Bridge: /bus@10000000/isa@18000000
+[    0.000000]  IO 0x0000000018000000..0x0000000018003fff  ->  0x0000000000000000
+[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
+[    0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 4778151116 ns
+[    0.000072] sched_clock: 32 bits at 400MHz, resolution 2ns, wraps every 5368709118ns
+[    0.002813] Console: colour dummy device 80x25
+[    0.003195] printk: console [tty0] enabled
+[    0.005876] printk: bootconsole [early0] disabled
+```
+
+Then, nothing happens. The qemu process uses 100% CPU on the host.
+
+I tried with `-smp 1` and got the same result.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2196 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2196
new file mode 100644
index 00000000..b16d477e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2196
@@ -0,0 +1 @@
+Missing support for video hardware accelerate support in virgl (virtio-gpu)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2197 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2197
new file mode 100644
index 00000000..789c6a25
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2197
@@ -0,0 +1,58 @@
+qemu user space emulator handles syscall `setsockopt()` with `optlen=0` incorrectly
+Description of problem:
+Note that despite I have only tested with the parameters/environments above, this problem probably **affects ALL architectures on Linux**.
+
+When user program calls `setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0)`, qemu intercepts the syscall and returns `-1` with `errno = ENOMEM`, which should have completed successfully returning zero.
+Steps to reproduce:
+1. compile this code to binary executable:
+```c
+#include <unistd.h>
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <linux/if_alg.h>
+
+int create_alg(const char *alg)
+{
+        struct sockaddr_alg salg;
+        int sk;
+
+        sk = socket(PF_ALG, SOCK_SEQPACKET | SOCK_CLOEXEC, 0);
+        if (sk < 0)
+                return -1;
+
+        memset(&salg, 0, sizeof(salg));
+        salg.salg_family = AF_ALG;
+        strcpy((char *) salg.salg_type, "hash");
+        strcpy((char *) salg.salg_name, alg);
+
+        if (bind(sk, (struct sockaddr *) &salg, sizeof(salg)) < 0) {
+                close(sk);
+                return -1;
+        }
+
+        return sk;
+}
+
+int main() {
+        int fd = create_alg("hmac(sha1)");
+        char buf[10];
+        int ret = setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0);
+        if(ret < 0){
+                perror("err");
+        }
+        else{
+                puts("SUCCESS!");
+        }
+        return 0;
+}
+```
+2. run it in any qemu user space emulator
+
+On real Linux kernel, this program outputs a `SUCCESS!` while in qemu it prints `err: Cannot allocate memory`.
+
+The error is neither informative nor intuitive and could be misleading for user programs.
+Additional information:
+I already have a patch which fixes the issue and I'm willing to send it to mailing list as soon as I have done the testing.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2199 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2199
new file mode 100644
index 00000000..84b5b488
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2199
@@ -0,0 +1,12 @@
+QEMU8 not working properly for Win9x guest
+Description of problem:
+Cannot boot to Win9x desktop. Enter safe mode of Win9x, then open C:\Windows\system\iosubsys, then rename drvwq117.vxd to drvwq117.vxd.bak, this problem solved.<br />
+Sound card and network card not found in Win9x Device Manager.<br />
+Cannot change resolution in Win9x Control Panel, this will cause "RUNDLL32 program error".
+
+We found that Plug-and-Play (\$PNP) and PCI IRQ Routing (\$PIR) functions of SeaBIOS are buggy for Win9x guest.
+Steps to reproduce:
+1.Install Win98 RTM on QEMU8, it cannot boot to Win98 desktop.<br />
+2.Install WinME on QEMU8, it will stuck on "copying files".
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/220 b/gitlab/issues_text/target_missing/host_missing/accel_missing/220
new file mode 100644
index 00000000..1782727e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/220
@@ -0,0 +1 @@
+Broken mouse movement inside MS-DOS for at least one program
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2201 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2201
new file mode 100644
index 00000000..b830cca4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2201
@@ -0,0 +1,11 @@
+Windows 11 Guests ExtendedDesktopSize Not Working
+Description of problem:
+Windows 11 VM with the latest virtio-win drivers installed (v0.1.240) does not respond to remote resize requests.
+Steps to reproduce:
+1. Create a Windows 11 VM with virtio-win drivers installed and virtio video enabled.
+2. Create a VNC session with resizeSession enabled.
+3. Try resizing the window.
+Additional information:
+The resolution can be resized within the VM itself (i.e., from display settings), just doesn't automatically resize when the viewing window changes. Other VMs (including Windows 10) created and viewed within the same setup do change with the window resize.
+
+The Chrome console log has a number of `Server did not accept resize request: Unknown reason` errors in it.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2202 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2202
new file mode 100644
index 00000000..840aa6c9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2202
@@ -0,0 +1,33 @@
+Crash in contrib/elf2dmp
+Description of problem:
+The elf2dmp program crash.
+```
+$ ./contrib/elf2dmp/elf2dmp ./crash_1 /dev/null
+Using Linux mmap
+[1]    994585 segmentation fault  ./contrib/elf2dmp/elf2dmp ./crash_1 /dev/null
+```
+Steps to reproduce:
+1. build the qemu project following standard steps
+2. navigate to the `build` directory and run `./contrib/elf2dmp/elf2dmp ./crash_1 /dev/null`
+
+The [crash_1](/uploads/d0890c0f8873b8264c417b0f98ee83a4/crash_1) file.
+Additional information:
+Run in GDB.
+```
+$ gdb ./contrib/elf2dmp/elf2dmp
+...
+(gdb) set args ./crash_1 /dev/null
+(gdb) r
+Starting program: /data/share/qemu_latest/build/contrib/elf2dmp/elf2dmp ./crash_1 /dev/null
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+Using Linux mmap
+
+Program received signal SIGSEGV, Segmentation fault.
+init_states (qe=0x7fffffff83f0) at ../contrib/elf2dmp/qemu_elf.c:66
+66          Elf64_Nhdr *start = (void *)((uint8_t *)qe->map + phdr[0].p_offset);
+(gdb) bt
+#0  init_states (qe=0x7fffffff83f0) at ../contrib/elf2dmp/qemu_elf.c:66
+#1  QEMU_Elf_init (qe=qe@entry=0x7fffffff83f0, filename=<optimized out>) at ../contrib/elf2dmp/qemu_elf.c:235
+#2  0x0000555555555508 in main (argc=<optimized out>, argv=0x7fffffffdb58) at ../contrib/elf2dmp/main.c:538
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2204 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2204
new file mode 100644
index 00000000..f66253dd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2204
@@ -0,0 +1,73 @@
+Hyper-V on Windows Server 2022 cannot load images converted from OVA to VHDX by qemu-img: Boot failure. Reboot and Select proper Boot device or Insert Boot Media in selected Boot device
+Description of problem:
+We have reference OVA image: https://storage.googleapis.com/fastnetmon_advanced_vm_images/fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova and we want to convert it to VMDX format.
+Steps to reproduce:
+I downloaded reference OVA and converted it to VMDX with three possible options.
+
+With subformat dynamic:
+```
+qemu-img convert fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova -O vhdx -o subformat=dynamic fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx
+```
+
+And without it:
+```
+qemu-img convert fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova -O vhdx fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx
+```
+
+And with explicitly setting fixed:
+```
+qemu-img convert fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova -O vhdx -o subformat=fixed fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx
+```
+
+In all cases I tried loading images using VM of Generation 1 and Generation 2:
+```
+The application encountered an error while attempting to change the state of
+'New Virtual Machine'.
+
+'New Virtual Machine' failed to start.
+
+Microsoft Emulated IDE Controller (Instance ID 83F8638B-8DCA-4152-9EDA-2CA8B33039B4): Failed to Power on with Error 'The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and unencrypted and must not be sparse..
+
+Failed to open attachment 'C:\Program Files\qemu\fastnetmon_non_dynamic.hdx''. Error: 'The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and unencrypted and must not be sparse..
+
+Failed to open attachment 'C:\Program Files\qemu\fastnetmon_non_dynamic.vhdx'. Error: 'The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and unencrypted and must not be sparse.'.
+```
+
+I noticed some similarities with https://gitlab.com/qemu-project/qemu/-/issues/136 and applied workaround to fix it:
+```
+fsutil sparse setflag fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx 0
+``` 
+
+It started complaining that file is being used by another app. I waited long enough and then rebooted server. 
+
+After that error changed to:
+```
+Boot failure. Reboot and Select proper Boot device or Insert Boot Media in selected Boot device_
+```
+
+As image:
+
+![Screenshot_from_2024-03-02_21-15-10](/uploads/9e172b941d160d2538cf903c1249e9d8/Screenshot_from_2024-03-02_21-15-10.png)
+
+For Generation 2 error is slightly different:
+```
+Virtual Machine Boot Summary
+1. SCSI Disk
+(0,0)
+The boot loader did not load an operating system.
+2. Network Adapter (00155D01770C)
+A boot image was not found.
+```
+
+As image: ![Screenshot_from_2024-03-02_21-36-37](/uploads/d3bc3ac142096e0ef6fc25e91c299ebc/Screenshot_from_2024-03-02_21-36-37.png)
+
+I tried doing conversion from VirtualBox with same OVA and it worked just fine:
+```
+VBoxManage clonehd fastnetmon-ubuntu-22.04-amd64-disk1.vmdk fastnetmon.vhd --format vhd
+```
+
+I believe something is wrong with boot records for VMDX images.
+
+Example of converted VHDX with dynamic flag can be found here: https://storage.googleapis.com/fastnetmon_advanced_vm_images/fastnetmon-ubuntu-22.04-amd64-2.0.356.0.vhdx 
+
+By Pavel Odintsov at FastNetMon.com
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2205 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2205
new file mode 100644
index 00000000..e7661af1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2205
@@ -0,0 +1,50 @@
+9p rootfs issues
+Description of problem:
+I've created qemu guest per https://wiki.qemu.org/Documentation/9p_root_fs guidelines. debootstrap fails on this guest.
+Steps to reproduce:
+```
+root@ubuntu-dev:~# debootstrap --arch amd64 --variant=minbase noble /var/tmp/new_root/
+I: Retrieving InRelease 
+I: Checking Release signature
+E: Error executing gpgv to check Release signature
+root@ubuntu-dev:~# 
+```
+Additional information:
+I noticed, that gpg key extracted by debootstrap from the InRelease is corrupted:
+```
+root@ubuntu-dev:~# head /var/tmp/new_root/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_noble_Release.gpg
+-----BEGIN PGP SIGNATURE-----
+-----BEGIN PGP SIGNATURE-----
+
+-----BEGIN PGP SIGNATURE-----
+-----BEGIN PGP SIGNATURE-----
+
+iQIzBAEBCgAdFiEE9uyzdiR07anSG3Aihxkg0ZkbyTwFAmXkbkUACgkQhxkg0Zkb
+-----BEGIN PGP SIGNATURE-----
+-----BEGIN PGP SIGNATURE-----
+
+root@ubuntu-dev:~# 
+```
+I also noticed that on the 9p filesystem appending to files corrupts them:
+```
+root@ubuntu-dev:~# echo 1 >/var/tmp/test
+root@ubuntu-dev:~# cat /var/tmp/test
+1
+root@ubuntu-dev:~# echo 2 >>/var/tmp/test
+root@ubuntu-dev:~# cat /var/tmp/test
+1
+1
+2
+root@ubuntu-dev:~# 
+```
+This is not happening on the tmpfs:
+```
+root@ubuntu-dev:~# echo 1 >/tmp/test
+root@ubuntu-dev:~# cat /tmp/test
+1
+root@ubuntu-dev:~# echo 2 >>/tmp/test
+root@ubuntu-dev:~# cat /tmp/test
+1
+2
+root@ubuntu-dev:~# 
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2209 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2209
new file mode 100644
index 00000000..ad4ab0a1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2209
@@ -0,0 +1,47 @@
+no 'system' llibfdt (or too old), subprojects/dtc/ populated, ./configure --disable-download fails
+Description of problem:
+./configure ... --disable-download, with subprojects/ pre-populated, fails.
+Steps to reproduce:
+1. ensure libfdt/dtc files/libs/binaries are *not* found in system
+2. have subprojects/dtc pre-populated
+3. ./configure --target-list=riscv32-softmmu --prefix=/opt/riscv --enable-debug --without-default-features --without-default-devices --disable-download
+
+configure fails with:
+```
+../meson.build:3171:13: ERROR: C shared or static library 'fdt' not found
+
+A full log can be found at /home/too/vc/ext/qemu/build/meson-logs/meson-log.txt
+
+ERROR: meson setup failed
+```
+
+If I outcomment the following lines in meson.build:
+```
+    #if get_option('wrap_mode') == 'nodownload'
+    #  fdt_opt = 'system'
+    #endif
+```
+Then the above command line works (with --disable-download)
+Additional information:
+The case is where one wants to ensure that configure does not try to access
+network while doing its job. And in a system where dtc/libfdt is not available,
+(or is too old, line in Centos/RHEL 7) one has dowloaded the files already in
+subprojects/dtc/.
+
+The meson.build clearly sets (as of 2024-03-05) expectation that dtc/libfdt/
+has to come from 'system' if 'wrap_mode' is set to 'nodownload'.
+
+Without this check it it works nicely -- and if subprojects/dtc/ was not populated,
+the error message is 
+
+```
+Library fdt found: NO
+
+../meson.build:3187:18: ERROR: Automatic wrap-based subproject downloading is disabled
+
+A full log can be found at /home/too/vc/ext/qemu/build/meson-logs/meson-log.txt
+
+ERROR: meson setup failed
+```
+
+So -- to me -- that looks like it could be a suitable solution to this problem.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2210 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2210
new file mode 100644
index 00000000..b259cacc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2210
@@ -0,0 +1,55 @@
+contrib/plugins/execlog.c: warning: passing argument 2 of ‘g_ptr_array_add’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
+Description of problem:
+Hit some warning messages when compiling upstream qemu
+Steps to reproduce:
+1. Clone repo and compile it
+
+  1.1 git clone https://gitlab.com/qemu-project/qemu.git 
+ 
+  1.2 mkdir build
+
+  1.3 cd build/
+
+  1.4 ../configure --target-list=x86_64-softmmu  --enable-debug-info
+
+  1.5 make
+
+2. It will print the following warning messages:
+```
+[2767/2767] Linking target tests/qtest/netdev-socket
+/root/qemu/contrib/plugins/execlog.c: In function ‘registers_init’:
+/root/qemu/contrib/plugins/execlog.c:339:63: warning: passing argument 2 of ‘g_ptr_array_add’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
+  339 |                             g_ptr_array_add(all_reg_names, reg->name);
+      |                                                            ~~~^~~~~~
+In file included from /usr/include/glib-2.0/glib.h:31,
+                 from /root/qemu/contrib/plugins/execlog.c:9:
+/usr/include/glib-2.0/glib/garray.h:192:62: note: expected ‘gpointer’ {aka ‘void *’} but argument is of type ‘const char *’
+  192 |                                            gpointer          data);
+      |                                            ~~~~~~~~~~~~~~~~~~^~~~
+```
+Additional information:
+1. After Eugenio Perez Martin (eperezma@redhat.com) debug, we found this problem introduced by this commit:
+```
+commit af6e4e0a22c18a7cc97650caec56ed99c9899dd7
+Author: Alex Bennée <alex.bennee@linaro.org>
+Date:   Tue Feb 27 14:43:32 2024 +0000
+
+    contrib/plugins: extend execlog to track register changes
+```
+2. The latest commit in my env:
+```
+commit db596ae19040574e41d086e78469014191d7d7fc (origin/staging, origin/master, origin/HEAD)
+Merge: 7d4e29ef80 7558300c53
+Author: Peter Maydell <peter.maydell@linaro.org>
+Date:   Tue Mar 5 13:54:54 2024 +0000
+
+    Merge tag 'pull-target-arm-20240305' of https://git.linaro.org/people/pmaydell/qemu-arm into staging
+    
+    target-arm queue:
+     * raspi: Implement Broadcom Serial Controller (BSC) for BCM2835 boards
+     * hw/char/pl011: Add support for loopback
+     * STM32L4x5: Implement RCC clock control device
+     * target/arm: Do memory type alignment checks
+     * atomic.h: Reword confusing comment for qatomic_cmpxchg
+     * qemu-options.hx: Don't claim "-serial" has limit of 4 serial ports
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2211 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2211
new file mode 100644
index 00000000..961caa6a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2211
@@ -0,0 +1,27 @@
+Live Migration Issue - get_pci_config_device: Bad config data
+Description of problem:
+Hello everybody,
+recently i have updated my environment from QEMU 7.1 (Build based from Upstream Code) to QEMU 7.2 (Build based from Upstream Code).
+Since the patching went very well, i noticed that Live Migrations are not possible anymore.
+It looks like that the Migration Process itself is running fine, but at the moment where QEMU wants to get the VM back live on the destination node, it crashes with the following error:
+
+```
+internal error: qemu unexpectedly closed the monitor: 2024-03-06T16:05:46.118520Z qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x34 read: c8 device: dc cmask: ff wmask: 0 w1cmask:0
+2024-03-06T16:05:46.118804Z qemu-system-x86_64: Failed to load PCIDevice:config
+2024-03-06T16:05:46.118813Z qemu-system-x86_64: Failed to load virtio-rng:virtio
+2024-03-06T16:05:46.118821Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:02.5:00.0/virtio-rng'
+2024-03-06T16:05:46.120947Z qemu-system-x86_64: load of migration failed: Invalid argument
+```
+
+If i would stop/start the instance in question, live migration is back working.
+This let me think that this might be an issue caused by the VM emulation process isn't running with the latest source of QEMU 7.2?
+
+Could someone please help me to figure out how i could resolve this issue to unblock the live migration capability without restarting all of my instances?
+Steps to reproduce:
+1. Prepare to Test Systems
+ - SOURCE      = Install with QEMU 7.1
+ - DESTINATION = Install with QEMU 7.2
+2. Start an example VM instance on the SOURCE
+3. Update QEMU to 7.2 on the SOURCE
+4. Start Live Migration from SOURCE to DESTINATION.
+5. Error should be raised like mentioned above
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2212 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2212
new file mode 100644
index 00000000..77b8f446
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2212
@@ -0,0 +1,17 @@
+"pci_hp_register failed with error -16" was found in Guest when launching VM with pci-bridge and "-machine q35"
+Description of problem:
+Host and guest config file configuration:
+  CONFIG_HOTPLUG_PCI_CPCI=y
+  CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m
+  CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m
+  CONFIG_HOTPLUG_PCI_SHPC=y
+Use this configuration kernel to boot QEMU, with the QEMU parameter "-machine q35 -device pci-bridge,id=bridge0,chassis_nr=1". After the guest boot, dmesg will display "shpchp 0000:00:04.0: pci_hp_register failed with error -16".
+Steps to reproduce:
+1.Boot QEMU
+
+2.Check dmesg in VM
+Additional information:
+Error log:
+[root@localhost ~]# dmesg | grep pci_hp_register
+[    0.723893] shpchp 0000:00:04.0: pci_hp_register failed with error -16
+[dmesg.log](/uploads/8ce302f996255544b4327d27ea4ac555/dmesg.log)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2214 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2214
new file mode 100644
index 00000000..48af3e9a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2214
@@ -0,0 +1 @@
+QEMU gdbstub does not report SIGALRM
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2215 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2215
new file mode 100644
index 00000000..913d4da2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2215
@@ -0,0 +1 @@
+qemu-8.2.2 compile failure against musl
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2216 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2216
new file mode 100644
index 00000000..b30f438e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2216
@@ -0,0 +1,3 @@
+Incresaed artifacts generation speed with paralleled process
+Additional information:
+`parallel-jobs` was referenced `main`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2217 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2217
new file mode 100644
index 00000000..b053f108
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2217
@@ -0,0 +1 @@
+Changing screen grab
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2219 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2219
new file mode 100644
index 00000000..9fdbb1fb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2219
@@ -0,0 +1 @@
+Core dump instead of error when starting on nohz_full system with enable-membarrier
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/222 b/gitlab/issues_text/target_missing/host_missing/accel_missing/222
new file mode 100644
index 00000000..05a60821
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/222
@@ -0,0 +1 @@
+Reading /proc/self/task/<pid>/maps is not remapped to the target
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2221 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2221
new file mode 100644
index 00000000..5c1b94f5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2221
@@ -0,0 +1 @@
+CI timeouts on 'gcov' job: test-bufferiszero, test-crypto-tlscredsx509
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2222 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2222
new file mode 100644
index 00000000..4203146a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2222
@@ -0,0 +1 @@
+elf2dmp has endianness bugs
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2225 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2225
new file mode 100644
index 00000000..395e7efa
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2225
@@ -0,0 +1,11 @@
+Mouse capture doesn't actually capture (GTK)
+Description of problem:
+The mouse is never actually captured by the window, you can always move it off screen, and because the guest OS has no awareness of the absolute mouse position there are many situations where you can't actually click something in the guest OS because the host mouse cursor is out of the window so clicking clicks on another program's window. It's unusable.
+
+It's clear that the problem is that the cursor isn't actually captured, if it ever was then the problem wouldn't occur. When the mouse is "uncaptured" we see the host cursor at all times and the guest cursor simply doesn't move, but when it's """captured""" the guest cursor still moves freely, it's just hidden while hovering the entire window (and not just the guest rectangle but really the whole thing) and the host cursor moves too at its own pace.
+
+It happens with `-display gtk` but not `-display sdl`.
+Steps to reproduce:
+1. Launch windowed guest
+2. Click on window
+3. Try to move mouse out of the window
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2231 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2231
new file mode 100644
index 00000000..8cf78950
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2231
@@ -0,0 +1,14 @@
+GNOME/Mutter - Wayland Fractional Scaling Breaks VM Resolution
+Description of problem:
+VMs are rendered at a higher resolution than the pixel count of their window, seemingly because mutter is upscaling for fractional scaling.
+Steps to reproduce:
+1. Enable GNOME Mutter experimental fractional scaling
+2. Launch VM
+Additional information:
+This only occurs when wayland fractional scaling is enabled, not when text is scaled. Since GNOME/mutter accomplishes fractional scaling by upscaling, I think the VM is being told its window has a higher resolution than it actually has, so it is rendering the VM at a higher resolution, which is then displayed at the display's real resolution.
+
+In the screenshot below, my resolution is 2256 x 1504 and I have set fractional scaling to 125%. It is worth noting (2256 / 1.25) / 3606 is approximately 0.5.
+
+![image](/uploads/0014f068f6491175c00449093c40cd8c/image.png)
+
+I apologize if the report is unsatisfactory. I will provide more detail if instructed. I tried reporting to GNOME Boxes and Virt-manager, which both use QEMU, but it seems the problem is upstream.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2232 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2232
new file mode 100644
index 00000000..65be2e2a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2232
@@ -0,0 +1 @@
+ui/qemu.desktop is nonconformant with the desktop entry specification
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2233 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2233
new file mode 100644
index 00000000..d8e703ea
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2233
@@ -0,0 +1,49 @@
+EDK2 BIOS images have wrong version string
+Description of problem:
+cosmetic, low priority, but maybe easy to fix  
+I think the displayed version inside the edk2 bios interface is not updating from version to version.  
+The updated version number is useful for the qemu-user to be assured that the updated bios file is in use.  
+
+There is also some unreliability in whether the bios screen is entered on pressing F2. I need to try do it a few times, that is restart qemu, for it to succeed and reach the bios interface. No issue with registering the F2 keystroke, starting screen does react to it. Sometimes it stops on a intermediate bios screen that does probing. I documented this as a different bug #2234 . 
+
+The reason I am trying out these bios files is because I am having trouble booting an iso image, which I filed as a different bug #2235. 
+
+This is how I create a bios file on update of a qemu version.   
+I have extracted and overwritten the 8.2.0 files in the scoop installed qemu folder with 9.0.0-rc0 files from gitlab artifact.   
+I have used ```qemu-setup-v9.0.0-rc0-42-g54294b23e1.exe``` which should include kraxel's 20240320 pull request ```[PULL 0/5] Edk2 20240320 patches Gerd Hoffmann```.  
+In a command prompt window   
+```C:\vol\scoop_01\scoopg\apps\qemu\8.2.0\share> C:\vol\scoop_01\scoopg\apps\git\current\usr\bin\cat.exe .\edk2-i386-vars.fd .\edk2-x86_64-code.fd > D:\vstorage\win_m01_qemu_2403_edk2-x86_64.fd```
+
+so far following files have been created
+```
+D:\vstorage>dir D:\vstorage\win_m01_qemu_2*
+ Volume in drive D is VD_15KJ
+ Volume Serial Number is 1EA6-2771
+
+ Directory of D:\vstorage
+
+04/17/2023  09:23 PM         4,194,304 win_m01_qemu_2302_edk2-x86_64.fd   # 8.0.0
+03/20/2024  10:31 AM         4,194,304 win_m01_qemu_2308_edk2-x86_64.fd   # 8.1.0
+03/20/2024  01:18 PM         4,194,304 win_m01_qemu_2402_edk2-x86_64.fd   # 8.2.0
+03/21/2024  11:24 AM         4,194,304 win_m01_qemu_2403_edk2-x86_64.fd   # 9.0.0-rc0
+               4 File(s)     16,777,216 bytes
+               0 Dir(s)  140,732,907,520 bytes free
+
+D:\vstorage>C:\vol\scoop_01\scoopg\apps\git\current\usr\bin\cmp.exe win_m01_qemu_2302_edk2-x86_64.fd win_m01_qemu_2403_edk2-x86_64.fd
+win_m01_qemu_2302_edk2-x86_64.fd win_m01_qemu_2403_edk2-x86_64.fd differ: char 540809, line 1
+
+D:\vstorage>C:\vol\scoop_01\scoopg\apps\git\current\usr\bin\cmp.exe win_m01_qemu_2402_edk2-x86_64.fd win_m01_qemu_2403_edk2-x86_64.fd
+D:\vstorage>
+```
+
+The above indicate to me that nothing has changed in edk2 binaries between 8.2.0 and 9.0.0. Is that correct?
+Steps to reproduce:
+1. start qemu
+2. press F2 when qemu guest display window pops up. When it works, it brings up the edk2 bios interface. 
+3. observe guest display screen . Notice that the displayed version still says `edk2-stable202302-for-qemu`. The displayed version has remained the same regardless of the bios file being used to boot qemu be they from 8.0.0 upto 9.0.0  
+   I expect it to show `edk2-stable202302-for-qemu`, `edk2-stable202308-for-qemu`, `edk2-stable202402-for-qemu`, `edk2-stable202403-for-qemu` etc
+
+guest display screen
+![QEMU_3_21_2024_11_25_00_AM](/uploads/3f7d55ff6e4dbd4a0bc00535027c0b2c/QEMU_3_21_2024_11_25_00_AM.png)
+Additional information:
+herein notifying @kraxel
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2234 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2234
new file mode 100644
index 00000000..55298a8d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2234
@@ -0,0 +1,23 @@
+upon pressing F2 failures in loading the edk2 bios interface app
+Description of problem:
+Cosmetic, low priority, but maybe easy to fix  
+Occasional failures to load the edk2 bios interface app  
+Workaround, retry until success
+Steps to reproduce:
+1. start qemu
+2. press F2 when qemu guest display window pops up. When it works, it brings up the edk2 bios interface. 
+   This bug concerns the case when it does not work
+
+For reasons not clear, sometimes, after pressing F2, and after qemu registered the key-stroke (F2) and responded by changing the window size, the bios interface loading process seems to abruptly stop at the following guest-display-screen with the following message.  
+```BdsDxe: Loading Boot0000 "UiApp" From Fv(7CB8BDC9-F8EB-F434-AAEA-3EE4AF6516A1)/FvFile(462CAA21-7614-4503-836E-8AB6F4662311)```  
+![QEMU_3_21_2024_12_52_10_PM](/uploads/4f9f9a751eb2496c6c9947b34cf24893/QEMU_3_21_2024_12_52_10_PM.png)
+
+When the bios interface loading process does succeed, it goes to the expected screen:  
+![QEMU_3_21_2024_11_25_00_AM](/uploads/38b4ad718357debc798c3a804954a52d/QEMU_3_21_2024_11_25_00_AM.png)
+Additional information:
+Unsure if this sort of bug should go upstream to https://github.com/tianocore/edk2/issues   
+Herein notifying @kraxel 
+
+Not a measured statistic, but on basis of feeling, I'd qualitatively say 4 out of 5 times it fails to bring up the bios interface. Its a bit frustrating because it feels like one has no control over it and a successful event is left to chance.  
+
+This isn't a recent introduction/regression. I've noticed this since 8.0.0, so its been this way maybe longer.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2235 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2235
new file mode 100644
index 00000000..167ff307
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2235
@@ -0,0 +1,57 @@
+Hiren's Bootcd PE LiveCD not booting in windows qemu
+Description of problem:
+Hiren's Bootcd PE LiveCD not booting up in windows qemu.  
+PE stands for pre-execution environment which is like a minimal boot environment like windows-recovery.  
+The ram drive it makes is about 3.5 GiB.  
+Being able to boot something like Hiren BootCD PE is like a simple test of qemu.   
+
+I've tried many things, but I can't figure out if it's because I can't get the arguments right or if it is because of something else.
+ 
+So far, using windows-qemu, I have not tried to boot a win10-guest-OS on win10 host-OS.
+Steps to reproduce:
+1. Try to start qemu as per command. Try figure out what the right arguments/options are.
+
+The live cd boot process is as follows
+1. First the livecd bootloader loads files from the cdrom and unpacks them into a ramdrive
+   During this phase, in the taskmgr it can be seen that the memory of the qemu process grows to about 1.5 GiB
+2. Then the boot process should transfer to the unpacked OS in the ramdrive.  
+   In the center of the screen, if one is doing efi-boot, then one can see the tianocore logo, else if one is doing legacy boot, then one can see the windows logo.  
+   The windows loading animation, dots in circle, does not start. In some boot attempts, it seems to have put only 1 dot, in other boot attempts nothing at all.  
+   Even after the expansion phase, the qemu process in the taskmgr shows a 11% use (which 1 cpu in a hyperthreading i7 quadcore cpu).  
+   This means emulator is doing something. But, despite waiting for a long time, nothing seems to happen in the guest-display-window.  
+
+```
+PS F:\> dir D:\bootable\hb*.iso
+
+    Directory: D:\bootable
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           9/17/2021  7:29 PM     3099203584 HBCD_PE_x64_v1.0.2_20210701.iso
+-a---           3/13/2024  4:45 PM     3291686912 HBCD_PE_x64_v1.0.8_20240305.iso
+
+PS F:\> Get-FileHash -Algorithm SHA256 D:\bootable\HBCD_PE_x64_v1.0.2_20210701.iso
+
+Algorithm       Hash                                                                   Path
+---------       ----                                                                   ----
+SHA256          8281107683E81BE362AFD213026D05B2219BC6A7CA9AF4D2856663F3FFC17BFD       D:\bootable\HBCD_PE_x64_v1.0.2_…
+
+PS F:\> Get-FileHash -Algorithm SHA256 D:\bootable\HBCD_PE_x64_v1.0.8_20240305.iso
+
+Algorithm       Hash                                                                   Path
+---------       ----                                                                   ----
+SHA256          8C4C670C9C84D6C4B5A9C32E0AA5A55D8C23DE851D259207D54679EA774C2498       D:\bootable\HBCD_PE_x64_v1.0.8_…
+
+PS F:\> Get-Content D:\bootable\HBCD_PE_x64_v1.0.2_20210701.iso.sha256
+8281107683E81BE362AFD213026D05B2219BC6A7CA9AF4D2856663F3FFC17BFD  HBCD_PE_x64_v1.0.2_20210701.iso
+PS F:\> Get-Content D:\bootable\HBCD_PE_x64_v1.0.8_20240305.iso.sha256
+8c4c670c9c84d6c4b5a9c32e0aa5a55d8c23de851d259207d54679ea774c2498  HBCD_PE_x64_v1.0.8_20240305.iso
+```
+Additional information:
+- https://www.hirensbootcd.org/download/
+- method to create the bios file is explained in #2233 
+- I have booted into v1.0.2 in native, so I know v1.0.2 works.  
+- I have tried qemu with and without EFI bios. 
+- The more recent v1.0.8 released on 20240305 is Win11 PE based (>22621)
+- Virtualbox-7.0.14 is able to boot HBCDPE as normal, but with EFI disabled, and not when enabled.  
+- As of this issue creation, not yet checked whether under Linux if qemu-kvm can boot HBCDPE.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2237 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2237
new file mode 100644
index 00000000..84381a32
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2237
@@ -0,0 +1,39 @@
+mirror block job memory leak
+Description of problem:
+After creating a background mirror job, and then the connection to the mirror target storage be interrupted and writing cannot be performed, the qemu process memory will increase significantly every time the mirror job performs a write. When the target stroage is restored, the data writing will be completed normally, but the memory will not be reduced.
+Steps to reproduce:
+1. start a virtual machine with libvirt(virsh start file)
+2. add a target mirror block dev, configure io timeout to 2 sec(virsh qemu-monitor-command file --pretty '{"execute": "blockdev-add", "arguments": {"driver": "raw", "cache": {"direct": true}, "node-name": "node-target","file": {"driver": "rbd", "conf":"/etc/ceph/ceph.node53.conf", "pool": "test", "image": "rbd1", "auth-client-required": ["none"], "server": [{"host": "10.0.12.53", "port": "6789"}]}}}')
+3. create a background mirror block job(virsh qemu-monitor-command file --pretty '{ "execute": "blockdev-mirror", "arguments": {"device": "libvirt-1-format", "target": "node-target", "sync": "full", "copy-mode": "background", "on-target-error": "ignore", "job-id": "job0"}}')
+4. wait for the initial full synchronization to complete
+5. write a large number of random ios in the virtual machine with the fio program(fio -filename=/dev/vdb -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=4k -size=4G -numjobs=1 -runtime=300 -group_reporting -name=sep)
+6. break the connection with the remote storage or shutdown the remote storage while fio program is running(if the connection is interrupted first and then written io, the probability of reproduce is very low)
+7. qemu will report an error indicating that io writing failed and try to write again(qemu-kvm: rbd request failed: cmd 1 offset 1421803520 bytes 1048576 flags 0 task.ret -110 (Connection timed out))
+8. use the numastat command to continuously observe the memory usage of the process and find that the heap memory has increased significantly.
+
+```
+Per-node process memory usage (in MBs) for PID 946492 (qemu-kvm)
+                           Node 0           Total
+                  --------------- ---------------
+Huge                      2048.00         2048.00
+Heap                      2698.13         2698.13
+Stack                        0.71            0.71
+Private                    781.48          781.48
+----------------  --------------- ---------------
+Total                     5528.32         5528.32
+
+after a while
+
+Per-node process memory usage (in MBs) for PID 1059068 (qemu-kvm)
+                           Node 0           Total
+                  --------------- ---------------
+Huge                      2048.00         2048.00
+Heap                     21769.94        21769.94
+Stack                        0.71            0.71
+Private                    827.22          827.22
+----------------  --------------- ---------------
+Total                    24645.87        24645.87
+```
+Additional information:
+libvirt xml:
+[file.xml](/uploads/82ff2e410183f94fde7cbaf19e7911dc/file.xml)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2238 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2238
new file mode 100644
index 00000000..8f73f13a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2238
@@ -0,0 +1,47 @@
+The `rw` parameter of `qemu_plugin_register_vcpu_mem_cb()` is not properly honored
+Description of problem:
+The `rw` parameter of `qemu_plugin_register_vcpu_mem_cb()` is not properly honored.
+Steps to reproduce:
+1. Register a callback with `qemu_plugin_register_vcpu_mem_cb()`
+2. In the callback, print the return of `qemu_plugin_mem_is_store()` (either `true` or `false`)
+3. Change the value of `rw` parameter of `qemu_plugin_register_vcpu_mem_cb()` and look whether the callback prints `true` and/or `false` to determine if this is inline with `rw`.
+
+In the callback, we don't we get what we asked for.
+
+| Requested with rw   | Observed in the callback   |
+|---------------------|----------------------------|
+| QEMU_PLUGIN_MEM_R   | Only writes                |
+| QEMU_PLUGIN_MEM_W   | Both reads and writes      |
+| QEMU_PLUGIN_MEM_RW  | Both reads and writes      |
+Additional information:
+In `plugin-gen.c`, line 497, there is the following function:
+
+```cpp
+static bool op_rw(const TCGOp *op, const struct qemu_plugin_dyn_cb *cb)
+{
+    int w;
+
+    w = op->args[2];
+    return !!(cb->rw & (w + 1));
+}
+```
+
+The issue described above seems to be caused by the `+ 1`. I removed it and got the expected results.
+
+This function is used in the same file, line 526, like this:
+
+```cpp
+        if (!ok(begin_op, cb)) {
+            continue;
+        }
+```
+
+This isn't consistent with `core.c`, line 509, where the same flag is checked like this:
+
+```cpp
+        if (!(rw & cb->rw)) {
+                break;
+        }
+```
+
+Inconsistent because of the `+1` and also because of `break`/`continue`.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2239 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2239
new file mode 100644
index 00000000..3b25b973
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2239
@@ -0,0 +1 @@
+Legacy system requirments: iptables
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2240 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2240
new file mode 100644
index 00000000..cbdf0298
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2240
@@ -0,0 +1,4 @@
+Please provide useful defaults for machine and cpu
+Additional information:
+See https://bugs.debian.org/1040212 and https://salsa.debian.org/helmutg/debvm/-/issues/15 for the preceding discussion and
+https://salsa.debian.org/helmutg/debvm/-/blob/main/bin/debvm-run and https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/80 for the used machine and cpu values.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2241 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2241
new file mode 100644
index 00000000..2aec892b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2241
@@ -0,0 +1 @@
+QMP Commands dont't work properly
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2242 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2242
new file mode 100644
index 00000000..4d881d4b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2242
@@ -0,0 +1,14 @@
+Hugepages are not released after windows guest shutdown
+Description of problem:
+* Hugepages are not released after windows guest shutdown (tested with server 2019 and 2022), everything is ok with linux guests
+* Issue is present in both cases: shutdown is initiated by guest, and with the qemu monitor command ``system_shutdown``
+* If the guest is configured with 4G as memory size, hugepages not released may vary but in most cases, only 1G are not released
+* Host is a x86_64 linux system, with 1G hugepages only : kernel cmline contains ``default_hugepagesz=1G hugepagesz=1G hugepages=88``
+* I've done many tests with qemu components disabled (network, monitor, vnc), issue is still present with basic command line (launched as root) ``qemu-system-x86_64 -cpu host -enable-kvm -smp 4 -machine type=q35,accel=kvm -m 4G -mem-path /mnt/hugepages -drive id=drv0,file=win.qcow2 -nodefaults``
+* Same issue with args in command line, with or without prealloc:
+
+        -m 4G -mem-path /mnt/hugepages [-mem-prealloc]
+        -m 4G -machine memory-backend=mem0 -object memory-backend-memfd,id=mem0,size=4G,hugetlb=on,hugetlbsize=1G[,prealloc=on]
+Additional information:
+* Hugepages release process is audited with command ``cat /proc/meminfo``
+* I can't find any online documentation to help to troubleshoot used hugepages : articles suggest to audit /proc/[pid]/smaps, but here, issue is raised after qemu process terminates
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2243 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2243
new file mode 100644
index 00000000..faf8f666
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2243
@@ -0,0 +1,9 @@
+ES1370 sound card can crash the Windows 2000 and Windows XP guest.
+Description of problem:
+If using ES1370 sound card with Windows 2000 and Windows XP guest, it will crash the Windows 2000 and Windows XP guest. Windows 2000 and Windows XP have built in ES1370 driver.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2247 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2247
new file mode 100644
index 00000000..89a10112
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2247
@@ -0,0 +1,6 @@
+virsh qemu-monitor-command --hmp help information missing  inject-nmi for watchdog_action
+Description of problem:
+watchdog_action missing inject-nmi which already supported in Commit [795dc6e4](https://gitlab.com/qemu-project/qemu/-/commit/795dc6e46d953d70b4b7ddd3f4956f8f4b9d8565)
+Steps to reproduce:
+1. virsh qemu-monitor-command <id> --hmp help |grep watchdog
+2. change watchdog action to inject-nmi
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/225 b/gitlab/issues_text/target_missing/host_missing/accel_missing/225
new file mode 100644
index 00000000..97512637
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/225
@@ -0,0 +1 @@
+Menu is not clickable on OSX Catalina
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2251 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2251
new file mode 100644
index 00000000..637b501a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2251
@@ -0,0 +1,14 @@
+Windows 11 VM with VBS enabled crashes
+Description of problem:
+
+Steps to reproduce:
+1. Run a Windows 11 VM on a node (both VM domain XML and node capabilities XML is provided below). 
+2. Enable VBS on the guest. For doing so you can use https://github.com/MicrosoftDocs/windows-itpro-docs/files/4020040/DG_Readinessv3.7.zip. Then, in Windows terminal, run DG_Readiness_Tool_{version}.ps1 -Enable.
+3. Reboot the guest.
+4. Windows cannot start (see picture below).
+Additional information:
+- Domain Capabilities: https://pastebin.com/GdQGQ639
+- VMX capabilities: https://pastebin.com/5nbUH0ev
+- contents of /proc/cpuinfo: https://pastebin.com/xZM4x89z
+- Domain XML: https://pastebin.com/s4VehTXK
+- Windows crash at boot: https://ibb.co/Ny1xRbz
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2252 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2252
new file mode 100644
index 00000000..b74b57a4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2252
@@ -0,0 +1,11 @@
+Poor VGA graphics when passing through a graphics card to a BIOS guest using the x-vga flag
+Description of problem:
+When passing through a GPU (in my case an Nvidia RTX 2070 Super) to a guest with BIOS firmware (using the x-vga flag to get a display out in BIOS mode), the VGA graphics used before an operating system loads proper graphics drivers seems to perform very poorly. Some symptoms of this are: GRUB and Windows Boot Manager are invisible, only showing a black screen (not sure if it affects all bootloaders) Windows 7 falls back to the more basic Vista boot animation during startup instead of the proper Starting Windows + orbs animation Windows 7 while using VGA graphics looks very low quality, with a pixelated look and a low color depth (attached below in additional information) Windows 10's setup just shows a black screen and fails to even boot. It seems to just restart after a bit (with any potential errors being invisible) Once graphics drivers are loaded inside Windows 7 or Linux in the guest, everything works fine. Seems like it's a firmware bug maybe?
+
+I've tested, and QEMU version 8.1 seems to be the last version without this bug, as 8.2 and up all have this issue. I'm not sure if this affects all graphics cards, as I've only tested this on an RTX 2070 super.
+Steps to reproduce:
+1. Create a guest with SeaBIOS firmware
+2. Pass through a graphics card using -vfio-pci
+3. Enable the x-vga flag
+Additional information:
+![notsogreatlookingwindows7](/uploads/ab6f7806f43dd0714e60b824cadec916/notsogreatlookingwindows7.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2253 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2253
new file mode 100644
index 00000000..c805f792
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2253
@@ -0,0 +1 @@
+NO_CAST.INTEGER_OVERFLOW in /hw/net/eepro100.c
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2254 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2254
new file mode 100644
index 00000000..549b9b12
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2254
@@ -0,0 +1 @@
+UNCHECKED_FUNC_RES.LIB.STRICT in /io/channel-socket.c
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2255 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2255
new file mode 100644
index 00000000..ed74da6e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2255
@@ -0,0 +1 @@
+INVARIANT_RESULT in /qapi/opts-visitor.c
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2256 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2256
new file mode 100644
index 00000000..515061c9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2256
@@ -0,0 +1 @@
+cirrus CI jobs failing
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2257 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2257
new file mode 100644
index 00000000..9fb7e6f7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2257
@@ -0,0 +1 @@
+STRING_OVERFLOW in /qapi/opts-visitor.c
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/226 b/gitlab/issues_text/target_missing/host_missing/accel_missing/226
new file mode 100644
index 00000000..d48aa42c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/226
@@ -0,0 +1 @@
+host window size does not change when guest video screen size changes while moving host window
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2260 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2260
new file mode 100644
index 00000000..a4a8ccee
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2260
@@ -0,0 +1,25 @@
+Storage device missing/Not recognized by driver (regression)
+Description of problem:
+Installation CD boots but can not find any storage/harddrive to install to.
+This works in qemu 8.2.2, so it seems like a regression.
+Steps to reproduce:
+1.
+2.
+3.
+Get virtio iso from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/
+
+Install swtpm like: brew install swtpm
+
+Use CrystalFetch from https://docs.getutm.app/guides/windows/ to download Windows ISO.
+
+Create storage: qemu-img create -f qcow2 Win11.qcow2 80G
+
+dd if=/dev/zero of=vars-pflash.raw bs=1M count=64
+
+start tpm like: /opt/homebrew/bin/swtpm socket --tpm2 --tpmstate dir=/Users/jonas/qw11arm/mytpm --ctrl type=unixio,path=/Users/jonas/qw11arm/mytpm/swtpm-sock
+
+start qemu like: \~/qemu/qemu/build/qemu-system-aarch64 --machine virt,virtualization=on --cpu neoverse-n1 --monitor stdio -smp cpus=4,sockets=1,cores=4,threads=1 -m 5G -device nec-usb-xhci -device qemu-xhci -device usb-kbd -device usb-tablet -device usb-storage,drive=windows,serial=windows -drive if=none,id=windows,format=raw,media=cdrom,file=/Users/jonas/ISOs/22631.2861.231204-0538.23H2_NI_RELEASE_SVC_REFRESH_CLIENTCONSUMER_RET_A64FRE_en-us.iso,readonly=on -device virtio-scsi -device scsi-hd,drive=boot,serial=boot -drive if=none,id=boot,format=qcow2,file=./Win11.qcow2 -drive if=pflash,format=raw,unit=0,file=/Users/jonas/qemu/qemu/build/pc-bios/edk2-aarch64-code.fd,readonly=on -drive file=vars-pflash.raw,format=raw,if=pflash,unit=1 -chardev socket,id=chrtpm,path=/Users/jonas/qw11arm/mytpm/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis-device,tpmdev=tpm0 --display cocoa -rtc base=localtime -device ramfb -boot menu=on -device usb-storage,drive=virtio,serial=virtio -drive if=none,id=virtio,format=raw,media=cdrom,file=/Users/jonas/Downloads/virtio-win-0.1.240.iso,readonly=on -nic user,model=virtio-net-pci,mac=52:54:98:76:54:32
+
+Adjust paths and be ready to bypass windows checks as described on https://docs.getutm.app/guides/windows/#this-pc-cant-run-windows-11
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2261 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2261
new file mode 100644
index 00000000..51ca737b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2261
@@ -0,0 +1,87 @@
+qemu-system-x86_64 crashs in cursor_put functions
+Description of problem:
+This problem cannot be stably reproduced，but we try enable --enable-sanitizers and catch the following information，why qemu_spice_cursor_refresh_bh be called twice at the same time？
+
+==57296==ERROR: AddressSanitizer: heap-use-after-free on address 0x623000738110 at pc 0x55cec2ed06aa bp 0x7ffc54d1fea0 sp 0x7ffc54d1fe90
+READ of size 4 at 0x623000738110 thread T0
+    #0 0x55cec2ed06a9 in cursor_put ../qemu-6.0.1/ui/cursor.c:112
+    #1 0x55cec2f05d40 in vnc_dpy_cursor_define ../qemu-6.0.1/ui/vnc.c:1041
+    #2 0x55cec2ec6352 in dpy_cursor_define ../qemu-6.0.1/ui/console.c:1841
+    #3 0x55cec3ab176c in qemu_spice_cursor_refresh_bh ../qemu-6.0.1/ui/spice-display.c:469
+    #4 0x55cec4abc6eb in aio_bh_call ../qemu-6.0.1/util/async.c:136
+    #5 0x55cec4abce43 in aio_bh_poll ../qemu-6.0.1/util/async.c:164
+    #6 0x55cec4a5f457 in aio_dispatch ../qemu-6.0.1/util/aio-posix.c:381
+    #7 0x55cec4abe386 in aio_ctx_dispatch ../qemu-6.0.1/util/async.c:306
+    #8 0x7fa4fadcdd3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55d3a)
+    #9 0x55cec4b0b5d6 in glib_pollfds_poll ../qemu-6.0.1/util/main-loop.c:231
+    #10 0x55cec4b0b7c0 in os_host_main_loop_wait ../qemu-6.0.1/util/main-loop.c:254
+    #11 0x55cec4b0bac5 in main_loop_wait ../qemu-6.0.1/util/main-loop.c:530
+    #12 0x55cec3f49e70 in qemu_main_loop ../qemu-6.0.1/softmmu/runstate.c:786
+    #13 0x55cec2e7f679 in main ../qemu-6.0.1/softmmu/main.c:50
+    #14 0x7fa4f96f4d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
+    #15 0x7fa4f96f4e3f in __libc_start_main_impl ../csu/libc-start.c:392
+    #16 0x55cec2e7f584 in _start (/usr/bin/qemu-system-x86_64+0x298a584)
+
+0x623000738110 is located 16 bytes inside of 6416-byte region [0x623000738100,0x623000739a10)
+freed by thread T0 here:
+    #0 0x7fa4fb7d9537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127
+    #1 0x55cec2ed0769 in cursor_put ../qemu-6.0.1/ui/cursor.c:115
+    #2 0x55cec3ab1818 in qemu_spice_cursor_refresh_bh ../qemu-6.0.1/ui/spice-display.c:471
+    #3 0x55cec4abc6eb in aio_bh_call ../qemu-6.0.1/util/async.c:136
+    #4 0x55cec4abce43 in aio_bh_poll ../qemu-6.0.1/util/async.c:164
+    #5 0x55cec4a5f457 in aio_dispatch ../qemu-6.0.1/util/aio-posix.c:381
+    #6 0x55cec4abe386 in aio_ctx_dispatch ../qemu-6.0.1/util/async.c:306
+    #7 0x7fa4fadcdd3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55d3a)
+
+previously allocated by thread T14 here:
+    #0 0x7fa4fb7d9a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
+    #1 0x7fa4fadd6c50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50)
+    #2 0x55cec3b16918 in qxl_cursor ../qemu-6.0.1/hw/display/qxl-render.c:361
+    #3 0x55cec3b18698 in qxl_render_cursor ../qemu-6.0.1/hw/display/qxl-render.c:448
+    #4 0x55cec3af53a5 in interface_get_cursor_command ../qemu-6.0.1/hw/display/qxl.c:856
+    #5 0x7fa4fb39ca1f in red_process_cursor ../../server/red-worker.c:152
+    #6 0x7fa4fb39ca1f in red_process_cursor ../../server/red-worker.c:140
+
+Thread T14 created by T0 here:
+    #0 0x7fa4fb77d685 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cpp:216
+    #1 0x7fa4fb39ece5 in red_worker_run ../../server/red-worker.c:1588
+    #2 0x62100002d94f  (<unknown module>)
+
+SUMMARY: AddressSanitizer: heap-use-after-free ../qemu-6.0.1/ui/cursor.c:112 in cursor_put
+Shadow bytes around the buggy address:
+  0x0c46800defd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c46800defe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c46800deff0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c46800df000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c46800df010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+=>0x0c46800df020: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c46800df030: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c46800df040: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c46800df050: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c46800df060: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c46800df070: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+Shadow byte legend (one shadow byte represents 8 application bytes):
+  Addressable:           00
+  Partially addressable: 01 02 03 04 05 06 07
+  Heap left redzone:       fa
+  Freed heap region:       fd
+  Stack left redzone:      f1
+  Stack mid redzone:       f2
+  Stack right redzone:     f3
+  Stack after return:      f5
+  Stack use after scope:   f8
+  Global redzone:          f9
+  Global init order:       f6
+  Poisoned by user:        f7
+  Container overflow:      fc
+  Array cookie:            ac
+  Intra object redzone:    bb
+  ASan internal:           fe
+  Left alloca redzone:     ca
+  Right alloca redzone:    cb
+  Shadow gap:              cc
+==57296==ABORTING
+Steps to reproduce:
+This problem cannot be stably reproduced
+Additional information:
+/label ~"kind::Bug"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2264 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2264
new file mode 100644
index 00000000..18a27462
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2264
@@ -0,0 +1,57 @@
+tests fail in staging-7.2 after "fix direction of "32-bit MMU" patch
+Description of problem:
+Running the tests with current staging-7.2 sources after compiling, it results in failing some tests after introduction of the following patches:
+
+- [target/i386: introduce function to query MMU indices](https://gitlab.com/qemu-project/qemu/-/commit/6332f3c12f7fc6c01fae1eaa59d661fef280f499)
+
+- [target/i386: use separate MMU indexes for 32-bit accesses](https://gitlab.com/qemu-project/qemu/-/commit/6b9875b03c81351c5f0268f571e011cf5f2fd9d2)
+
+- [target/i386: fix direction of "32-bit MMU" test](https://gitlab.com/qemu-project/qemu/-/commit/64e5fffe523daee23b06f3fd0f31721b137901b5)
+
+- [target/i386: Revert monitor_puts() in do_inject_x86_mce()](https://gitlab.com/qemu-project/qemu/-/commit/1d024cdc49a9ebc4d51142d2c33668bba1d31c89)
+
+in particular is the fix:
+
+- [target/i386: fix direction of "32-bit MMU" test](https://gitlab.com/qemu-project/qemu/-/commit/64e5fffe523daee23b06f3fd0f31721b137901b5)
+
+that causes the tests failing (removing such fix, tests passes). The failing tests are:
+
+```
+Summary of Failures:
+
+ 92/689 qemu:qtest+qtest-i386 / qtest-i386/boot-serial-test                       ERROR           0.10s   killed by signal 6 SIGABRT
+127/689 qemu:qtest+qtest-x86_64 / qtest-x86_64/boot-serial-test                   ERROR           0.12s   killed by signal 6 SIGABRT
+ 48/689 qemu:qtest+qtest-i386 / qtest-i386/bios-tables-test                       ERROR          40.95s   killed by signal 6 SIGABRT
+ 71/689 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test                   ERROR          40.45s   killed by signal 6 SIGABRT
+```
+
+In particular we have:
+
+```
+ 92/689 qemu:qtest+qtest-i386 / qtest-i386/boot-serial-test                       ERROR           0.10s   killed by signal 6 SIGABRT
+――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
+stderr:
+Broken pipe
+../tests/qtest/libqtest.c:188: kill_qemu() detected QEMU death from signal 11 (Segmentation fault) (core dumped)
+
+(test program exited with status code -6)
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+```
+
+and
+
+
+```
+127/689 qemu:qtest+qtest-x86_64 / qtest-x86_64/boot-serial-test                   ERROR           0.12s   killed by signal 6 SIGABRT
+――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
+stderr:
+Broken pipe
+../tests/qtest/libqtest.c:188: kill_qemu() detected QEMU death from signal 11 (Segmentation fault) (core dumped)
+
+(test program exited with status code -6)
+
+TAP parsing error: Too few tests run (expected 2, got 0)
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+```
+
+and so on.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2265 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2265
new file mode 100644
index 00000000..c70544c1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2265
@@ -0,0 +1,48 @@
+qemu-system-x86_64 crash creating snapshot
+Description of problem:
+I'm facing a crash in qemu-system-x86_64.\
+I crash because bs->children.lh_first is null and QLIST_NEXT try dereference the pointer. It triggers a SIGSEGV\
+The manner to reproduce is too complex to give on gitlab and the version is not recent. (I reproduce also with 7.1)\
+
+here is the stack:
+
+(gdb) p bs->children\
+$1 = {lh_first = 0x0}\
+(gdb)\
+(gdb) p child\
+$2 = (BdrvChild *) 0x0\
+(gdb)\
+    if (bs->implicit) {\
+        /* For implicit nodes, just copy everything from the single child */\
+        child = QLIST_FIRST(&bs->children);\
+----->> assert(QLIST_NEXT(child, next) == NULL);\
+        pstrcpy(bs->exact_filename, sizeof(bs->exact_filename),\
+
+
+#0  bdrv_refresh_filename (bs=0x562927927000) at ../qemu-6.2.0/block.c:7525\
+#1  0x000056292527dd97 in bdrv_block_device_info (blk=blk@entry=0x0, bs=bs@entry=0x562927927000, flat=flat@entry=true, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/block/qapi.c:58\
+#2  0x00005629252470c0 in bdrv_named_nodes_list (flat=true, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/block.c:5863\
+#3  0x000056292523da7e in qmp_query_named_block_nodes (has_flat=<optimized out>, flat=<optimized out>, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/blockdev.c:2935\
+#4  0x0000562925301ebd in qmp_marshal_query_named_block_nodes (args=<optimized out>, ret=0x7fc833c83e88, errp=0x7fc833c83e80) at qapi/qapi-commands-block-core.c:423\
+#5  0x0000562925344129 in do_qmp_dispatch_bh (opaque=0x7fc833c83e90) at ../qemu-6.2.0/qapi/qmp-dispatch.c:129
+#6  0x000056292535ecf5 in aio_bh_call (bh=0x5629295ab560) at ../qemu-6.2.0/util/async.c:141\
+#7  aio_bh_poll (ctx=ctx@entry=0x5629276c93e0) at ../qemu-6.2.0/util/async.c:169\
+#8  0x000056292534cf9e in aio_dispatch (ctx=0x5629276c93e0) at ../qemu-6.2.0/util/aio-posix.c:381\
+#9  0x000056292535eb9e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../qemu-6.2.0/util/async.c:311\
+#10 0x00007fc8351cafee in g_match_info_fetch_pos () from /lib/x86_64-linux-gnu/libglib-2.0.so.0\
+#11 0x00007fc800000000 in ?? ()\
+#12 0x000003a05cb8b408 in ?? ()\
+#13 0x0000000000000000 in ?? ()\
+
+The case lh_first = 0x0 seems to be common, but never when bs->implicit is true. bs->implicit seems to be switch to true by another thread.\
+Because the qemu version and the system are too old, I'm not expecting a patch, I'm just requesting an opinion.\
+
+I fixed the problem by just doing:\
+child = QLIST_FIRST(&bs->children);\
+if (bs->implicit && (child != NULL)) {\
+   assert(QLIST_NEXT(child, next) == NULL);\
+   ....\
+}\
+I don't have the qemu knowledge to evaluate it and consequences.\
+Is there anyone who have any idea ?\
+Thank you very much.\
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2267 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2267
new file mode 100644
index 00000000..cb552273
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2267
@@ -0,0 +1,552 @@
+Out of bounds access in tx_fifo_push()
+Description of problem:
+I detected an out-of-bounds access in tx_fifo_push with my fuzzer.
+
+Stack trace (part):\
+`hw/net/lan9118.c:798:17: runtime error: index 2048 out of bounds for`\
+`type 'uint8_t[2048]' (aka 'unsigned char[2048]')`\
+    `#0 0x563ec9a057b1 in tx_fifo_push hw/net/lan9118.c:798:43`\
+    `#1 0x563ec99fbb28 in lan9118_writel hw/net/lan9118.c:1042:9`\
+    `#2 0x563ec99f2de2 in lan9118_16bit_mode_write hw/net/lan9118.c:1205:9`\
+    `#3 0x563ecbf78013 in memory_region_write_accessor system/memory.c:497:5`\
+    `#4 0x563ecbf776f5 in access_with_adjusted_size system/memory.c:573:18`\
+    `#5 0x563ecbf75643 in memory_region_dispatch_write system/memory.c:1521:16`\
+    `#6 0x563ecc01bade in flatview_write_continue_step system/physmem.c:2713:18`\
+    `#7 0x563ecc01b374 in flatview_write_continue system/physmem.c:2743:19`\
+    `#8 0x563ecbff1c9b in flatview_write system/physmem.c:2774:12`\
+    `#9 0x563ecbff1768 in address_space_write system/physmem.c:2894:18`\
+`...`
+Steps to reproduce:
+Reproducer:\
+export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine smdkc210"\
+cat \<\< EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio\
+outl 0xcf8 0x80000010\
+outl 0xcfc 0x5000000\
+outl 0xcf8 0x80000004\
+outl 0xcfc 0x07\
+writew 0x5000030 0x4918237b\
+writew 0x5000030 0x4918237b\
+writel 0x500003c 0x223bd37f\
+writel 0x500003c 0x223bd37f\
+writel 0x500003c 0x223bd37f\
+writew 0x500003c 0x223bd37f\
+writel 0x500003c 0x223bd37f\
+writew 0x500003c 0x223bd37f\
+writel 0x500003c 0x223bd37f\
+writel 0x500003c 0x223bd37f\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0xcb06897\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x17954990\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x17954990\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0xcb06897\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x17954990\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0xcb06897\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000024 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x17954990\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0xcb06897\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000024 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x17954990\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000024 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0xcb06897\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0xcb06897\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x17954990\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0xcb06897\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x17954990\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x17954990\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0xcb06897\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x17954990\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0xcb06897\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0xcb06897\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x17954990\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0xcb06897\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x17954990\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0xcb06897\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x17954990\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0xcb06897\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x17954990\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0xcb06897\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x17954990\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x17954990\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0xcb06897\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+writel 0x5000020 0x6a035c1b\
+EOF
+Additional information:
+Ack: Chuhong Yuan (hslester96@gmail.com)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2268 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2268
new file mode 100644
index 00000000..55e66a0d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2268
@@ -0,0 +1,43 @@
+Out of bounds access in smc91c111_readb()
+Description of problem:
+I detected an out-of-bounds access in smc91c111_readb with my fuzzer.
+
+Stack trace (part):\
+`hw/net/smc91c111.c:607:24: runtime error: index 175 out of bounds for`\
+`type 'uint8_t[4][2048]' (aka 'unsigned char[4][2048]')`\
+`SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior`\
+`hw/net/smc91c111.c:607:24 in`\
+`AddressSanitizer:DEADLYSIGNAL`\
+`==============================`<wbr>`==============================`<wbr>`=====`\
+`==397944==ERROR: AddressSanitizer: SEGV on unknown address`\
+`0x629000077db4 (pc 0x56272aed3b8d bp 0x7ffd1471f290 sp 0x7ffd1471ea20`\
+`T0)`\
+`==397944==The signal is caused by a READ memory access.`\
+    `#0 0x56272aed3b8d in smc91c111_readb hw/net/smc91c111.c:607:24`\
+    `#1 0x56272aecfd61 in smc91c111_readfn hw/net/smc91c111.c:650:16`\
+    `#2 0x56272d4b228b in memory_region_read_accessor system/memory.c:445:11`\
+    `#3 0x56272d46fb85 in access_with_adjusted_size system/memory.c:573:18`\
+    `#4 0x56272d46c58e in memory_region_dispatch_read1 system/memory.c:1426:16`\
+    `#5 0x56272d46bcd7 in memory_region_dispatch_read system/memory.c:1459:9`\
+    `#6 0x56272d4e8e03 in flatview_read_continue_step system/physmem.c:2794:18`\
+    `#7 0x56272d4e871e in flatview_read_continue system/physmem.c:2835:19`\
+    `#8 0x56272d4e98b8 in flatview_read system/physmem.c:2865:12`\
+    `#9 0x56272d4e9388 in address_space_read_full system/physmem.c:2878:18`\
+    `#10 0x56272d6e7840 in address_space_read include/exec/memory.h:3026:18`\
+`...`\
+Bug analysis: I found s-\>packet_num = 175 at line 599.
+Steps to reproduce:
+Reproducer:\
+export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine\
+mainstone"\
+cat \<\< EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio\
+outl 0xcf8 0x80000010\
+outl 0xcfc 0x10000300\
+outl 0xcf8 0x80000004\
+outl 0xcfc 0x07\
+writel 0x1000030c 0x66027cd6\
+writel 0x10000300 0x64af8eda\
+readw 0x10000308\
+EOF
+Additional information:
+Ack: Chuhong Yuan (hslester96@gmail.com)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/227 b/gitlab/issues_text/target_missing/host_missing/accel_missing/227
new file mode 100644
index 00000000..aa5975a9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/227
@@ -0,0 +1 @@
+meson: incomplete 'make help'
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2272 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2272
new file mode 100644
index 00000000..1a36f787
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2272
@@ -0,0 +1,21 @@
+Memory leak in the virtual device applesmc
+Description of problem:
+In the function _qdev_applesmc_isa_reset_, the device mallocs the _AppleSMCData_ but does not free them, causing a memory leak.
+
+The following log reveals it:
+
+```
+==1029295==ERROR: LeakSanitizer: detected memory leaksDirect leak of 80 byte(s) in 2 object(s) allocated from:
+#0 0x5574dc600a82 in __interceptor_calloc compiler-rt/lib/asan/asan_malloc_linux.cpp:138:3 
+#1 0x7f4919b22c50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50)
+#2 0x5574dcdb0dfe in qdev_applesmc_isa_reset qemu/hw/misc/applesmc.c:285:5 
+#3 0x5574de30e099 in resettable_phase_hold qemu/hw/core/resettable.c 
+#4 0x5574de2ef753 in bus_reset_child_foreach qemu/hw/core/bus.c:97:13 
+#5 0x5574de30dcfe in resettable_child_foreach qemu/hw/core/resettable.c:96:9 
+#6 0x5574de30dcfe in resettable_phase_hold qemu/hw/core/resettable.c:173:5 
+#7 0x5574de3059b3 in device_reset_child_foreach qemu/hw/core/qdev.c:276:9
+```
+Steps to reproduce:
+1. Build qemu with the sanitizer
+2. Boot the Linux kernel with the above command line.
+3. Stop the qemu process
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2273 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2273
new file mode 100644
index 00000000..f20eb093
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2273
@@ -0,0 +1,45 @@
+Abort in net_tx_pkt_update_sctp_checksum()
+Description of problem:
+In the function _net_tx_pkt_update_sctp_checksum(),_ an abort happened:
+
+```
+qemu-fuzz-x86_64: ../../../third_party/qemu/util/iov.c:39: size_t iov_from_buf_full(const struct iovec *, unsigned int, size_t, const void *, size_t): Assertion `offset == 0' failed.
+==1052929== ERROR: libFuzzer: deadly signal
+    #0 0x5575e5cccbe1 in __sanitizer_print_stack_trace llvm/compiler-rt/lib/asan/asan_stack.cpp:87:3
+    #1 0x5575e5c479b8 in fuzzer::PrintStackTrace() llvm/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5
+    #2 0x5575e5c2bbb3 in fuzzer::Fuzzer::CrashCallback() llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3
+    #3 0x7f691f24251f  (/lib/x86_64-linux-gnu/libc.so.6+0x4251f)
+    #4 0x7f691f2969fb in __pthread_kill_implementation nptl/./nptl/pthread_kill.c:43:17
+    #5 0x7f691f2969fb in __pthread_kill_internal nptl/./nptl/pthread_kill.c:78:10
+    #6 0x7f691f2969fb in pthread_kill nptl/./nptl/pthread_kill.c:89:10
+    #7 0x7f691f242475 in gsignal signal/../sysdeps/posix/raise.c:26:13
+    #8 0x7f691f2287f2 in abort stdlib/./stdlib/abort.c:79:7
+    #9 0x7f691f22871a in __assert_fail_base assert/./assert/assert.c:92:3
+    #10 0x7f691f239e95 in __assert_fail assert/./assert/assert.c:101:3
+    #11 0x5575e81e952a in iov_from_buf_full qemu/util/iov.c:39:5
+    #12 0x5575e6500768 in net_tx_pkt_update_sctp_checksum qemu/hw/net/net_tx_pkt.c:144:9
+    #13 0x5575e659f3e1 in igb_setup_tx_offloads qemu/hw/net/igb_core.c:478:11
+    #14 0x5575e659f3e1 in igb_tx_pkt_send qemu/hw/net/igb_core.c:552:10
+    #15 0x5575e659f3e1 in igb_process_tx_desc qemu/hw/net/igb_core.c:671:17
+    #16 0x5575e659f3e1 in igb_start_xmit qemu/hw/net/igb_core.c:903:9
+    #17 0x5575e659f3e1 in igb_set_tdt qemu/hw/net/igb_core.c:2812:5
+    #18 0x5575e657d6a4 in igb_core_write qemu/hw/net/igb_core.c:4248:9
+```
+Steps to reproduce:
+Here's a simple PoC:
+
+```
+cat << EOF | \
+qemu-system-x86_64 \
+-display none -machine accel=qtest -m 512M -M q35 -nodefaults -device \
+igb,netdev=net0 -netdev user,id=net0 -qtest stdio
+outl 0xcf8 0x80000810
+outl 0xcfc 0xe0000000
+outl 0xcf8 0x80000804
+outw 0xcfc 0x06
+write 0xe0000403 0x1 0x02
+writel 0xe0003808 0xffffffff
+write 0xe000381a 0x1 0x5b
+write 0xe000381b 0x1 0x00
+EOF
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2274 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2274
new file mode 100644
index 00000000..a80c587d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2274
@@ -0,0 +1,43 @@
+Assertion failuer in cryptodev_builtin_close_session()
+Description of problem:
+In the function _cryptodev_builtin_close_session(),_ an assertation happened:
+
+```
+qemu-fuzz-x86_64: qemu/backends/cryptodev-builtin.c:430: int cryptodev_builtin_close_session(CryptoDevBackend *, uint64_t, uint32_t, CryptoDevCompletionFunc, void *): Assertion `session_id < MAX_NUM_SESSIONS && builtin->sessions[session_id]' failed.
+==1256139== ERROR: libFuzzer: deadly signal
+    #9 0x71acb8c2871a in __assert_fail_base assert/./assert/assert.c:92:3
+    #10 0x71acb8c39e95 in __assert_fail assert/./assert/assert.c:101:3
+    #11 0x5af7f624b12b in cryptodev_builtin_close_session qemu/backends/cryptodev-builtin.c:430:5
+    #12 0x5af7f60b2860 in virtio_crypto_handle_close_session qemu/hw/virtio/virtio-crypto.c:262:12
+    #13 0x5af7f60b2860 in virtio_crypto_handle_ctrl qemu/hw/virtio/virtio-crypto.c:423:19
+```
+
+The user could send an invalid session_id to trigger this assertion.
+Steps to reproduce:
+Here's a simple PoC:
+
+```
+cat << EOF | qemu-system-x86_64 -display none\
+ -machine accel=qtest -m 512M -machine q35 -nodefaults -object \
+cryptodev-backend-builtin,id=cryptodev0 -device \
+virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -qtest stdio
+outl 0xcf8 0x80000804
+outw 0xcfc 0x06
+outl 0xcf8 0x80000820
+outl 0xcfc 0xe0008000
+write 0x10800e 0x1 0x01
+write 0xe0008016 0x1 0x01
+write 0xe0008020 0x4 0x00801000
+write 0xe0008028 0x4 0x00c01000
+write 0xe000801c 0x1 0x01
+write 0x110000 0x1 0x05
+write 0x110001 0x1 0x04
+write 0x108002 0x1 0x11
+write 0x108008 0x1 0x48
+write 0x10800c 0x1 0x01
+write 0x108018 0x1 0x10
+write 0x10801c 0x1 0x02
+write 0x10c002 0x1 0x01
+write 0xe000b005 0x1 0x00
+EOF
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2275 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2275
new file mode 100644
index 00000000..183fcbf2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2275
@@ -0,0 +1,9 @@
+qemu crash
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2276 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2276
new file mode 100644
index 00000000..ee5e9373
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2276
@@ -0,0 +1,42 @@
+qemu crash for  suspend and resume vm while backup disk of vm
+Description of problem:
+![image](/uploads/40e41df2dab7e0d3dacb6c07c1bf42b1/image.png)
+Steps to reproduce:
+1. virsh create vm2.xml
+2. virsh backup-begin domid
+3. virsh suspend domid
+4. sleep 1 && virsh resume domid
+
+qemu crash
+Additional information:
+static int blk_do_set_aio_context(BlockBackend *blk, AioContext *new_context,
+                                  bool update_root_node, Error **errp)
+{
+    BlockDriverState *bs = blk_bs(blk);
+    ThrottleGroupMember *tgm = &blk->public.throttle_group_member;
+    int ret;
+
+    if (bs) {
+        bdrv_ref(bs);
+
+        if (update_root_node) {
+            ret = bdrv_child_try_set_aio_context(bs, new_context, blk->root,
+                                                 errp);
+            if (ret < 0) {
+                bdrv_unref(bs);
+                return ret;
+            }
+        }
+        if (tgm->throttle_state) {
+         _   ****bdrv_drained_begin(bs);----- bs->aio_context->lock lock count is 0,so unlock failed**_
+            throttle_group_detach_aio_context(tgm);
+            throttle_group_attach_aio_context(tgm, new_context);
+            bdrv_drained_end(bs);
+        }
+
+        bdrv_unref(bs);
+    }
+
+    blk->ctx = new_context;
+    return 0;
+}
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2277 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2277
new file mode 100644
index 00000000..faa78f8a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2277
@@ -0,0 +1 @@
+COarse-grained LOck-stepping Virtual Machines for Non-stop Service Encountered Assertion Error
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2278 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2278
new file mode 100644
index 00000000..92b2132d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2278
@@ -0,0 +1 @@
+Build issue on OpenBSD with Clang 16
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/228 b/gitlab/issues_text/target_missing/host_missing/accel_missing/228
new file mode 100644
index 00000000..a3f4cfb5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/228
@@ -0,0 +1 @@
+TCG test targets missing from 'make check-help'
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2280 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2280
new file mode 100644
index 00000000..f221798d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2280
@@ -0,0 +1 @@
+Not Installing Properly
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2282 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2282
new file mode 100644
index 00000000..dc8cebad
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2282
@@ -0,0 +1 @@
+Corrupted output when using Intel Arc GPU with qemu+spice+virgl in headed mode
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2283 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2283
new file mode 100644
index 00000000..553a227d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2283
@@ -0,0 +1,33 @@
+memory leak in virtio-crypto
+Description of problem:
+The following log reveals it:
+
+```
+==1878896==ERROR: LeakSanitizer: detected memory leaks
+
+Direct leak of 48 byte(s) in 1 object(s) allocated from:
+    #0 0x5646565ec262 in __interceptor_calloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:138:3
+    #1 0x7f591ec3bc50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50)
+    #2 0x564659227db7 in error_setg_internal qemu/util/error.c:105:5
+    #3 0x56465794ad35 in cryptodev_builtin_operation qemu/backends/cryptodev-builtin.c:557:9
+    #4 0x5646579550b5 in cryptodev_backend_operation qemu/backends/cryptodev.c:180:16
+    #5 0x564657953640 in cryptodev_backend_crypto_operation qemu/backends/cryptodev.c:289:12
+    #6 0x56465773a647 in virtio_crypto_handle_request qemu/hw/virtio/virtio-crypto.c:911:19
+    #7 0x5646577386a0 in virtio_crypto_handle_dataq qemu/hw/virtio/virtio-crypto.c:938:13
+    #8 0x564657734f87 in virtio_crypto_dataq_bh qemu/hw/virtio/virtio-crypto.c:963:9
+    #9 0x56465928a6b1 in aio_bh_call qemu/util/async.c:171:5
+    #10 0x56465928b58c in aio_bh_poll qemu/util/async.c:218:13
+    #11 0x5646591eb398 in aio_dispatch qemu/util/aio-posix.c:423:5
+    #12 0x5646592919ce in aio_ctx_dispatch qemu/util/async.c:360:5
+    #13 0x7f591ec32d3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55d3a)
+
+Indirect leak of 36 byte(s) in 1 object(s) allocated from:
+    #0 0x5646565ec0cd in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
+    #1 0x7f591e488157 in __vasprintf_internal libio/./libio/vasprintf.c:71:30
+```
+Steps to reproduce:
+```
+qemu-system-x86_64 -display none -machine accel=qtest -m 512M -machine q35 -nodefaults -object cryptodev-backend-builtin,id=cryptodev0 -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -qtest stdio < /tmp/reproducer
+```
+
+[reproducer](/uploads/e0161b0d482bc5dac08929d51e70e7fc/reproducer)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2284 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2284
new file mode 100644
index 00000000..7a95df31
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2284
@@ -0,0 +1 @@
+sunxi avocado tests: kernel no longer available on armbian
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2288 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2288
new file mode 100644
index 00000000..961e0177
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2288
@@ -0,0 +1,29 @@
+ERROR: Unrecognized host OS (uname -s reports 'Linux')
+Description of problem:
+Hit "Unrecognized host OS (uname -s reports 'Linux')" ERROR when run configure file on upstream qemu.
+Steps to reproduce:
+1.Clone repo and compile it
+
+  1.1 git clone https://gitlab.com/qemu-project/qemu.git
+
+  1.2 cd qemu
+
+  1.3 mkdir build
+
+  1.4 cd build
+
+  1.5 ../configure --target-list=x86_64-softmmu --enable-debug
+
+2.The following ERROR message:
+
+ERROR: Unrecognized host OS (uname -s reports 'Linux')
+Additional information:
+Cpu information:
+
+Vendor ID:               AuthenticAMD
+
+  BIOS Vendor ID:        Advanced Micro Devices, Inc.
+
+  Model name:            AMD EPYC 9754 128-Core Processor
+
+  BIOS Model name:     AMD EPYC 9754 128-Core Processor
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2289 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2289
new file mode 100644
index 00000000..1a2f6200
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2289
@@ -0,0 +1 @@
+virtio-blk not work in freebsd guest with qemu>=7.0.0
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/229 b/gitlab/issues_text/target_missing/host_missing/accel_missing/229
new file mode 100644
index 00000000..7e9bee66
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/229
@@ -0,0 +1 @@
+build-tools-and-docs-debian job waste cycles building pointless things
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2291 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2291
new file mode 100644
index 00000000..cc6b0d72
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2291
@@ -0,0 +1,182 @@
+building qemu with msys2 mingw64 in github actions, sed error unterminated address regex
+Description of problem:
+in Github Actions (Windows)
+```
+$ make --trace -j $(nproc)
+ninja: no work to do.
+/d/a/qemu_app/qemu_app/qemu/BUILD/pyvenv/bin/meson introspect --targets --tests --benchmarks | D:/a/qemu_app/qemu_app/qemu/BUILD/pyvenv/bin/python3.exe -B scripts/mtest2make.py > Makefile.mtest
+D:\a\_temp\msys64\mingw64\bin\sed.exe: -e expression #1, char 41: unterminated address regex
+D:\a\_temp\msys64\mingw64\bin\sed.exe: -e expression #1, char 41: unterminated address regex
+```
+Steps to reproduce:
+```sh
+# enable symlinks in msys2 MINGW64 shell
+
+export MSYS=winsymlinks:native
+
+# download and extract qemu
+
+curl -L https://download.qemu.org/qemu-9.0.0-rc4.tar.xz -O
+tar xvJf qemu-9.0.0-rc4.tar.xz
+mv qemu-9.0.0-rc4 qemu
+
+# remove symlinks known to cause `git add` to fail, we will recreate these later in the yaml file
+
+/usr/bin/rm -f qemu/roms/edk2/EmulatorPkg/Unix/Host/X11IncludeHack
+/usr/bin/rm -f qemu/roms/skiboot/opal-ci/build-debian-unstable.sh
+/usr/bin/rm -f qemu/roms/skiboot/opal-ci/build-fedora-rawhide.sh
+/usr/bin/rm -f qemu/roms/u-boot/board/xilinx/zynq/zynq-cse-nand
+/usr/bin/rm -f qemu/roms/u-boot/board/xilinx/zynqmp/avnet-ultra96-rev1
+/usr/bin/rm -f qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-g-a2197-00-revA
+/usr/bin/rm -f qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-m-a2197-01-revA
+/usr/bin/rm -f qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-m-a2197-03-revA
+/usr/bin/rm -f qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-mini
+/usr/bin/rm -f qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-mini-emmc0
+/usr/bin/rm -f qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-mini-emmc1
+/usr/bin/rm -f qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-mini-qspi
+/usr/bin/rm -f qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-p-a2197-00-revA
+/usr/bin/rm -f qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-zcu104-revC
+/usr/bin/rm -f qemu/roms/u-boot/include/ctype.h
+/usr/bin/rm -f qemu/roms/u-boot/tools/binman/binman
+/usr/bin/rm -f qemu/roms/u-boot/tools/dtoc/dtoc
+/usr/bin/rm -f qemu/roms/u-boot/tools/microcode-tool
+/usr/bin/rm -f qemu/roms/u-boot/tools/patman/patman
+/usr/bin/rm -f qemu/tests/lcitool/libvirt-ci/ci/gitlab/all_mappings_prep_env/almalinux-8-prep.sh
+/usr/bin/rm -f qemu/tests/lcitool/libvirt-ci/ci/gitlab/all_mappings_prep_env/alpine-317-prep.sh
+/usr/bin/rm -f qemu/tests/lcitool/libvirt-ci/ci/gitlab/all_mappings_prep_env/alpine-edge-prep.sh
+/usr/bin/rm -f qemu/tests/lcitool/libvirt-ci/ci/gitlab/all_mappings_prep_env/fedora-37-prep.sh
+/usr/bin/rm -f qemu/tests/lcitool/libvirt-ci/ci/gitlab/all_mappings_prep_env/fedora-38-prep.sh
+/usr/bin/rm -f qemu/tests/lcitool/libvirt-ci/ci/gitlab/all_mappings_prep_env/fedora-rawhide-prep.sh
+
+# push qemu to github to test
+
+git init
+git add -Av
+git commit -m "qemu fail"
+git branch -M main
+
+git remote add origin < a url to a newly created git repo to test the qemu build which currently fails with sed error >
+
+git push origin
+```
+```yaml
+
+# save this in the following file: .github/workflows/windows.yaml
+
+# Job execution time - Each job in a workflow can run for up to 6 hours of execution time.
+# Workflow run time - Each workflow run is limited to 35 days
+
+name: windows
+
+on:
+  push:
+    branches: [ "main" ]
+  workflow_dispatch:
+
+defaults:
+  run:
+    shell: msys2 {0}
+
+# each job runs under a NEW image
+jobs:
+  build_qemu:
+    strategy:
+      matrix:
+        include:
+          - os: windows-latest
+            name: windows
+            sys: MINGW64
+
+    runs-on: ${{ matrix.os }}
+
+    name: build qemu - ${{ matrix.name }}
+
+    steps:
+      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
+      - uses: actions/checkout@v4
+        with:
+          ref: ${{needs.should_run.outputs.output1}}
+          submodules: recursive
+
+      - name: '${{ matrix.icon }} Setup MSYS2'
+        uses: msys2/setup-msys2@v2
+        with:
+          msystem: ${{matrix.sys}}
+          update: true
+          path-type: strict
+
+      - name: update packages
+        run: |
+          pacman -Sy
+
+      - name: install qemu deps
+        run: |
+          # https://github.com/qemu/qemu/blob/master/.gitlab-ci.d/windows.yml#L84
+          pacman -S --noconfirm --needed pactoys
+          pacman -S --noconfirm --needed bison flex git
+          pacboy -S --noconfirm --needed make:p cmake:p gcc:p meson:p autotools:p ninja:p python:p python-sphinx:p python-sphinx_rtd_theme:p tools-git:p angleproject:p capstone:p curl:p cyrus-sasl:p dtc:p expat:p fontconfig:p freetype:p fribidi:p gcc-libs:p gdk-pixbuf2:p gettext:p glib2:p gmp:p gnutls:p graphite2:p gst-plugins-base:p gstreamer:p gtk3:p harfbuzz:p jbigkit:p lerc:p libc++:p libdatrie:p libdeflate:p libepoxy:p libffi:p libiconv:p libidn2:p libjpeg-turbo:p libnfs:p libpng:p libpsl:p libslirp:p libssh:p libssh2:p libtasn1:p libthai:p libtiff:p libunistring:p libunwind:p libusb:p libwebp:p libwinpthread-git:p lz4:p lzo2:p nettle:p openssl:p opus:p orc:p p11-kit:p pango:p pixman:p SDL2:p SDL2_image:p snappy:p spice:p usbredir:p xz:p zlib:p zstd:p brotli:p bzip2:p nghttp2 diffutils grep make sed:p binutils:p capstone:p curl:p cyrus-sasl:p dtc:p gcc:p glib2:p gnutls:p gtk3:p libgcrypt:p libjpeg-turbo:p libnfs:p libpng:p libssh:p libtasn1:p libusb:p lzo2:p nettle:p ninja:p pixman:p pkgconf:p python:p SDL2:p SDL2_image:p snappy:p spice:p usbredir:p zstd:p
+
+      - name: restore symlinks
+        run: |
+          export MSYS=winsymlinks:native
+          ln -s /opt/X11/include qemu/roms/edk2/EmulatorPkg/Unix/Host/X11IncludeHack
+          ln -s build-ubuntu-latest.sh qemu/roms/skiboot/opal-ci/build-debian-unstable.sh
+          ln -s build-fedora33.sh qemu/roms/skiboot/opal-ci/build-fedora-rawhide.sh
+          ln -s zynq-zc770-xm011 qemu/roms/u-boot/board/xilinx/zynq/zynq-cse-nand
+          ln -s zynqmp-zcu100-revC qemu/roms/u-boot/board/xilinx/zynqmp/avnet-ultra96-rev1
+          ln -s zynqmp-a2197-revA qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-g-a2197-00-revA
+          ln -s zynqmp-a2197-revA qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-m-a2197-01-revA
+          ln -s zynqmp-a2197-revA qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-m-a2197-03-revA
+          ln -s zynqmp-zcu102-rev1.0 qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-mini
+          ln -s zynqmp-zcu100-revC qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-mini-emmc0
+          ln -s zynqmp-zcu102-rev1.0 qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-mini-emmc1
+          ln -s zynqmp-zcu102-rev1.0 qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-mini-qspi
+          ln -s zynqmp-a2197-revA qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-p-a2197-00-revA
+          ln -s zynqmp-zcu104-revA qemu/roms/u-boot/board/xilinx/zynqmp/zynqmp-zcu104-revC
+          ln -s linux/ctype.h qemu/roms/u-boot/include/ctype.h
+          ln -s main.py qemu/roms/u-boot/tools/binman/binman
+          ln -s main.py qemu/roms/u-boot/tools/dtoc/dtoc
+          ln -s microcode-tool.py qemu/roms/u-boot/tools/microcode-tool
+          ln -s main.py qemu/roms/u-boot/tools/patman/patman
+          ln -s centos-stream-8-prep.sh qemu/tests/lcitool/libvirt-ci/ci/gitlab/all_mappings_prep_env/almalinux-8-prep.sh
+          ln -s alpine-prep.sh qemu/tests/lcitool/libvirt-ci/ci/gitlab/all_mappings_prep_env/alpine-317-prep.sh
+          ln -s alpine-prep.sh qemu/tests/lcitool/libvirt-ci/ci/gitlab/all_mappings_prep_env/alpine-edge-prep.sh
+          ln -s fedora-prep.sh qemu/tests/lcitool/libvirt-ci/ci/gitlab/all_mappings_prep_env/fedora-37-prep.sh
+          ln -s fedora-prep.sh qemu/tests/lcitool/libvirt-ci/ci/gitlab/all_mappings_prep_env/fedora-38-prep.sh
+          ln -s fedora-prep.sh qemu/tests/lcitool/libvirt-ci/ci/gitlab/all_mappings_prep_env/fedora-rawhide-prep.sh
+
+      # we dont use split.exe since we need only fails the build and need not upload the results
+
+      # there is no use in caching the build directory since ../configure will cause a full rebuild
+      # and we are lazy to detect an existing Makefile
+
+      - name: cmake configure qemu - Release
+        run: |
+          export MSYS=winsymlinks:native
+          cd qemu
+          mkdir BUILD || true
+          mkdir BUILD/BUILD_ROOT || true
+          cd BUILD
+          ls -l
+
+          # this should succeed
+          ../configure --prefix=$(pwd)/BUILD_ROOT --enable-sdl --enable-gtk --disable-user --target-list=x86_64-softmmu --enable-whpx
+
+      - name: cmake build qemu - Release
+        run: |
+          export MSYS=winsymlinks:native
+          cd qemu/BUILD
+          ls -l
+          cat -n Makefile
+
+          # this should fail with sed.exe: -e expression #1, char 41: unterminated address regex
+          make --trace -j $(nproc)
+```
+Additional information:
+https://github.com/mgood7123/qemu_app/actions/runs/8732163169/job/23958798258
+
+note `make` `succeeds` (returns 0) but does not build anything due to sed error
+
+qemu folder is https://download.qemu.org/qemu-9.0.0-rc4.tar.xz
+
+symlinks incompatible with `git add` have been removed and then recreated in GHA
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2292 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2292
new file mode 100644
index 00000000..20c03a5b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2292
@@ -0,0 +1,19 @@
+UNIX socket path is too long
+Description of problem:
+At [Unikraft](https://unikraft.org) we facilitate the construction and also runtime lifecycle management of ultra-lightweight virtual machine unikernels.  We have developed [`kraft`](https://github.com/unikraft/kraftkit), an open-source tool which facilitates this across a number of different virtual machine monitors, [including QEMU](https://github.com/unikraft/kraftkit/tree/staging/machine/qemu).
+
+We are receiving increased reports of the following error from our users:
+
+```
+could not start and wait for QEMU process: qemu-system-x86_64: -qmp unix:/Users/__USERNAME__/.local/share/kraftkit/runtime/37a7691a-d402-4760-b493-692bb8d0460a/qemu_control.sock,server,nowait: UNIX socket path '/Users/__USERNAME__/.local/share/kraftkit/runtime/37a7691a-d402-4760-b493-692bb8d0460a/qemu_control.sock' is too long
+```
+
+We systematically build the relevant QEMU process command line and arguments with flags [via our Go SDK](https://github.com/unikraft/kraftkit/blob/staging/machine/qemu/v1alpha1.go#L180-L229) and include what has become an erroneously long UNIX path for the QAPI control socket which we use to manage instantiated VM instances.
+
+This issue tracks the increasing of maximum path length for the `-qmp` (and maybe other) flags which accept paths.
+Steps to reproduce:
+1. Install [`kraft`](https://github.com/unikraft/kraftkit), [Unikraft](https://unikraft.org)'s companion command-line client;
+2. Update KraftKit's config file to include an arbitrarily long path for `runtime_dir` by editing `~/.config/kraftkit/config.yaml`;
+3. Start a QEMU unikernel instance with `kraft run --arch x86_64 --plat qemu unikraft.org/helloworld:latest`
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2293 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2293
new file mode 100644
index 00000000..fef8dbe0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2293
@@ -0,0 +1,35 @@
+[u2f-passthru]: pamu2fcfg command will stuck forever in Guest OS of Qemu
+Description of problem:
+To use FIDO2 user verification we need to run `pamu2fcfg` command which will stuck forever in Guest OS of Qemu 
+
+Passing `-usb -device u2f-passthru,hidraw=/dev/hidraw2` for U2F-Passthrough
+Steps to reproduce:
+1. Make you have have plugged Yubikey.
+2. In Guest shell install package using following command `sudo apt-get install pamu2fcfg`
+3. Run $`pamu2fcfg` command will stuck forever.
+
+**Note:** If I run `pamu2fcfg` in my Ubuntu Host environment it works fine.
+Additional information:
+**lsusb output:**
+
+**$lusb**
+
+Bus 001 Device 002: ID 46f4:0005 **QEMU U2F USB key**
+
+Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
+
+**Debug Details:**
+
+When pamu2fcfg was launched following will be the call flow.
+
+[u2f_key_recv_from_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L251 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L251") → [recv_from_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L204 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L204") → [u2f_passthru_recv_from_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L332 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L332") → [u2f_passthru_read](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L305 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L305") → [u2f_passthru_recv_from_host](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L329 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L329") →[ u2f_transaction_get_from_nonce](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L272 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L272") → [u2f_send_to_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L302 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L302") →[ u2f_pending_in_add](https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L207 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L207") → [main_loop_wait](https://github.com/qemu/qemu/blob/master/system/runstate.c#L783 "https://github.com/qemu/qemu/blob/master/system/runstate.c#L783") (stuck here)
+
+From above call flow looks like guest is waiting for key.
+
+Even I have tried enabling U2F support flag in Qemu while building but that one was not helping either.
+
+**References:**
+
+https://github.com/Yubico/pam-u2f/tree/main
+
+https://www.qemu.org/docs/master/system/devices/usb-u2f.html
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2296 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2296
new file mode 100644
index 00000000..752d1a63
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2296
@@ -0,0 +1,97 @@
+heap-buffer-overflow in virtio-sound
+Description of problem:
+The following log reveals it:
+
+```
+==3191578==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000068620 at pc 0x55dadcde4ec5 bp 0x7ffe7f18aef0 sp 0x7ffe7f18aee0
+READ of size 8 at 0x602000068620 thread T0
+    #0 0x55dadcde4ec4 in virtio_snd_handle_rx_xfer ../hw/audio/virtio-snd.c:988
+    #1 0x55daddffbf5e in virtio_queue_notify ../hw/virtio/virtio.c:2296
+    #2 0x55dadd6cff4a in virtio_pci_notify_write ../hw/virtio/virtio-pci.c:1721
+    #3 0x55dade0ab336 in memory_region_write_accessor ../system/memory.c:497
+    #4 0x55dade0af3d0 in access_with_adjusted_size ../system/memory.c:573
+    #5 0x55dade0b5032 in memory_region_dispatch_write ../system/memory.c:1528
+    #6 0x55dade0ebb62 in flatview_write_continue_step ../system/physmem.c:2713
+    #7 0x55dade0ebfb2 in flatview_write_continue ../system/physmem.c:2743
+    #8 0x55dade0ebfb2 in flatview_write ../system/physmem.c:2774
+    #9 0x55dade0edd58 in address_space_write ../system/physmem.c:2894
+    #10 0x55dadd809972 in qtest_process_command ../system/qtest.c:679
+    #11 0x55dadd80c3e2 in qtest_process_inbuf ../system/qtest.c:811
+    #12 0x55dade6e79a4 in fd_chr_read ../chardev/char-fd.c:72
+    #13 0x7f79b0d29c43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43)
+    #14 0x55dade998bcf in glib_pollfds_poll ../util/main-loop.c:287
+    #15 0x55dade998bcf in os_host_main_loop_wait ../util/main-loop.c:310
+    #16 0x55dade998bcf in main_loop_wait ../util/main-loop.c:589
+    #17 0x55dadd810e00 in qemu_main_loop ../system/runstate.c:783
+    #18 0x55dade2b703a in qemu_default_main ../system/main.c:37
+    #19 0x7f79afe29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
+    #20 0x7f79afe29e3f in __libc_start_main_impl ../csu/libc-start.c:392
+    #21 0x55dadcb5a284 in _start (/home/joey/repo/qemu/build/qemu-system-x86_64+0x2ef6284)
+
+0x602000068620 is located 0 bytes to the right of 16-byte region [0x602000068610,0x602000068620)
+allocated by thread T0 here:
+    #0 0x7f79b18b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
+    #1 0x7f79b0d32c50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50)
+    #2 0x55dadebf5847  (/home/joey/repo/qemu/build/qemu-system-x86_64+0x4f91847)
+
+SUMMARY: AddressSanitizer: heap-buffer-overflow ../hw/audio/virtio-snd.c:988 in virtio_snd_handle_rx_xfer
+Shadow bytes around the buggy address:
+  0x0c0480005070: fa fa 05 fa fa fa 07 fa fa fa 00 01 fa fa 07 fa
+  0x0c0480005080: fa fa 05 fa fa fa 07 fa fa fa 00 03 fa fa fd fd
+  0x0c0480005090: fa fa fd fd fa fa fd fd fa fa fd fd fa fa 00 06
+  0x0c04800050a0: fa fa 00 00 fa fa 00 00 fa fa 00 01 fa fa 05 fa
+  0x0c04800050b0: fa fa 00 03 fa fa 00 03 fa fa 00 01 fa fa 00 05
+=>0x0c04800050c0: fa fa 00 00[fa]fa 00 00 fa fa 00 04 fa fa 00 00
+  0x0c04800050d0: fa fa fd fd fa fa fd fd fa fa fd fa fa fa fd fa
+  0x0c04800050e0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
+  0x0c04800050f0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
+  0x0c0480005100: fa fa fd fd fa fa fd fa fa fa fd fa fa fa fd fa
+  0x0c0480005110: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
+Shadow byte legend (one shadow byte represents 8 application bytes):
+  Addressable:           00
+  Partially addressable: 01 02 03 04 05 06 07
+  Heap left redzone:       fa
+  Freed heap region:       fd
+  Stack left redzone:      f1
+  Stack mid redzone:       f2
+  Stack right redzone:     f3
+  Stack after return:      f5
+  Stack use after scope:   f8
+  Global redzone:          f9
+  Global init order:       f6
+  Poisoned by user:        f7
+  Container overflow:      fc
+  Array cookie:            ac
+  Intra object redzone:    bb
+  ASan internal:           fe
+  Left alloca redzone:     ca
+  Right alloca redzone:    cb
+  Shadow gap:              cc
+```
+Steps to reproduce:
+```
+cat << EOF | qemu-system-x86_64 -display none \
+-machine accel=qtest -m 512M -machine q35 -device \
+virtio-sound,audiodev=my_audiodev,streams=2 -audiodev \
+alsa,id=my_audiodev -qtest stdio
+outl 0xcf8 0x80001804
+outw 0xcfc 0x06
+outl 0xcf8 0x80001820
+outl 0xcfc 0xe0008000
+write 0xe0008016 0x1 0x03
+write 0xe0008020 0x4 0x00901000
+write 0xe0008028 0x4 0x00a01000
+write 0xe000801c 0x1 0x01
+write 0xe000a004 0x1 0x40
+write 0x10c000 0x1 0x02
+write 0x109001 0x1 0xc0
+write 0x109002 0x1 0x10
+write 0x109008 0x1 0x04
+write 0x10a002 0x1 0x01
+write 0xe000b00d 0x1 0x00
+EOF
+```
+
+# Possible Fix
+
+check the user-assigned value in virtio_snd_set_config()
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2298 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2298
new file mode 100644
index 00000000..4d49f718
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2298
@@ -0,0 +1,12 @@
+Invariant result in opts-visitor.c
+Description of problem:
+Expressions:
+1) val2 <= INT64_MAX
+2) INT64_MIN <= val2
+in line [431](https://github.com/qemu/qemu/blob/62dbe54c24dbf77051bafe1039c31ddc8f37602d/qapi/opts-visitor.c#L431) are always true.
+
+Seems like this checks are redundant.
+
+Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
+
+Author A. Burke.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2299 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2299
new file mode 100644
index 00000000..ae432c68
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2299
@@ -0,0 +1,203 @@
+UFS Device sanitizers error
+Description of problem:
+Sanitizers error reported by Zheyu Ma zheyuma97@gmail.com
+
+The following log can reveal it:
+
+==3619819==ERROR: AddressSanitizer: heap-buffer-overflow on address
+
+0x62a000011200 at pc 0x7f9f9903a2c3 bp 0x7ffd44e1ee60 sp 0x7ffd44e1e608
+
+WRITE of size 20512 at 0x62a000011200 thread T0
+
+```
+#0 0x7f9f9903a2c2 in __interceptor_memcpy
+```
+
+../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
+
+```
+#1 0x5f23331ea4fc in memcpy
+```
+
+/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29
+
+```
+#2 0x5f23331ea4fc in flatview_read_continue_step
+```
+
+../system/physmem.c:2818
+
+```
+#3 0x5f23331eab72 in flatview_read_continue ../system/physmem.c:2835
+
+#4 0x5f23331eadc4 in flatview_read ../system/physmem.c:2865
+
+#5 0x5f23331ec2a5 in address_space_read_full ../system/physmem.c:2878
+
+#6 0x5f23331ec2a5 in address_space_rw ../system/physmem.c:2906
+
+#7 0x5f23326b7ad0 in ufs_dma_read_req_upiu ../hw/ufs/ufs.c:129
+
+#8 0x5f23326b7ad0 in ufs_dma_read_upiu ../hw/ufs/ufs.c:185
+
+#9 0x5f23326b7ad0 in ufs_exec_req ../hw/ufs/ufs.c:1021
+
+#10 0x5f23326b7ad0 in ufs_process_req ../hw/ufs/ufs.c:1066
+
+#11 0x5f2333a9160d in aio_bh_call ../util/async.c:171
+
+#12 0x5f2333a91f45 in aio_bh_poll ../util/async.c:218
+
+#13 0x5f2333a217a9 in aio_dispatch ../util/aio-posix.c:423
+
+#14 0x5f2333a90d01 in aio_ctx_dispatch ../util/async.c:360
+
+#15 0x7f9f985c4d3a in g_main_context_dispatch
+```
+
+(/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55d3a)
+
+```
+#16 0x5f2333a9690f in glib_pollfds_poll ../util/main-loop.c:287
+
+#17 0x5f2333a9690f in os_host_main_loop_wait ../util/main-loop.c:310
+
+#18 0x5f2333a9690f in main_loop_wait ../util/main-loop.c:589
+
+#19 0x5f23329370e0 in qemu_main_loop ../system/runstate.c:783
+
+#20 0x5f23333b4d7a in qemu_default_main ../system/main.c:37
+
+#21 0x7f9f97629d8f in __libc_start_call_main
+```
+
+../sysdeps/nptl/libc_start_call_main.h:58
+
+```
+#22 0x7f9f97629e3f in __libc_start_main_impl ../csu/libc-start.c:392
+
+#23 0x5f2331c8df64 in _start
+```
+
+(/home/joey/repo/qemu/build/qemu-system-x86_64+0x2ea8f64)
+
+0x62a000011200 is located 0 bytes to the right of 20480-byte region
+
+\[0x62a00000c200,0x62a000011200)
+
+allocated by thread T0 here:
+
+```
+#0 0x7f9f990b4a57 in __interceptor_calloc
+```
+
+../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
+
+```
+#1 0x7f9f985cdc50 in g_malloc0
+```
+
+(/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50)
+
+```
+#2 0xf0e808deae299ff  (<unknown module>)
+```
+
+SUMMARY: AddressSanitizer: heap-buffer-overflow
+
+../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
+
+in \__interceptor_memcpy
+
+Shadow bytes around the buggy address:
+
+0x0c547fffa1f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+0x0c547fffa200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+0x0c547fffa210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+0x0c547fffa220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+0x0c547fffa230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+=\>0x0c547fffa240:\[fa\]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+
+0x0c547fffa250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+
+0x0c547fffa260: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+
+0x0c547fffa270: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+
+0x0c547fffa280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+
+0x0c547fffa290: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+
+Shadow byte legend (one shadow byte represents 8 application bytes):
+
+Addressable: 00
+
+Partially addressable: 01 02 03 04 05 06 07
+
+Heap left redzone: fa
+
+Freed heap region: fd
+
+Stack left redzone: f1
+
+Stack mid redzone: f2
+
+Stack right redzone: f3
+
+Stack after return: f5
+
+Stack use after scope: f8
+
+Global redzone: f9
+
+Global init order: f6
+
+Poisoned by user: f7
+
+Container overflow: fc
+
+Array cookie: ac
+
+Intra object redzone: bb
+
+ASan internal: fe
+
+Left alloca redzone: ca
+
+Right alloca redzone: cb
+
+Shadow gap: cc
+
+==3619819==ABORTING
+
+And Here is a simple PoC:
+
+cat \<\< EOF \\
+
+qemu-system-x86_64 \\
+
+\-display none -machine accel=qtest -m 512M -M q35 -nodefaults -drive \\
+
+file=[null-co://,if=none,id=disk0](null-co://,if=none,id=disk0) -device ufs,id=ufs_bus -device \\
+
+ufs-lu,drive=disk0,bus=ufs_bus -qtest stdio
+
+outl 0xcf8 0x80000810
+
+outl 0xcfc 0xe0000000
+
+outl 0xcf8 0x80000804
+
+outw 0xcfc 0x06
+
+write 0xe0000058 0x1 0xa7
+
+write 0xa 0x1 0x50
+
+EOF
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/230 b/gitlab/issues_text/target_missing/host_missing/accel_missing/230
new file mode 100644
index 00000000..baca53a8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/230
@@ -0,0 +1 @@
+Confuse error message in virtio_init_region_cache()
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2301 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2301
new file mode 100644
index 00000000..01a7020a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2301
@@ -0,0 +1 @@
+GitLab Windows Server 2019 runner is deprecated
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2303 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2303
new file mode 100644
index 00000000..91beda75
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2303
@@ -0,0 +1,71 @@
+Multiple displays configuration supports
+Additional information:
+The following patch is a quick "hack" to make it work
+
+```patch
+
+From 18ad5058a18fa9f6db2c0c3058e25989908d95bb Mon Sep 17 00:00:00 2001
+From: Sergio Lopez <slp@redhat.com>
+Date: Fri, 23 Jun 2023 13:15:15 +0200
+Subject: [PATCH 6/8] HACK: Set static resolutions for the VM
+
+---
+ hw/display/virtio-gpu-base.c | 10 +++++++++-
+ ui/gtk.c                     |  6 ++++--
+ 2 files changed, 13 insertions(+), 3 deletions(-)
+
+diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
+index a29f191aa8..b1ccfa17b7 100644
+--- a/hw/display/virtio-gpu-base.c
++++ b/hw/display/virtio-gpu-base.c
+@@ -47,6 +47,7 @@ virtio_gpu_base_fill_display_info(VirtIOGPUBase *g,
+             dpy_info->pmodes[i].enabled = 1;
+             dpy_info->pmodes[i].r.width = cpu_to_le32(g->req_state[i].width);
+             dpy_info->pmodes[i].r.height = cpu_to_le32(g->req_state[i].height);
++            fprintf(stderr, "display %d: %dx%d\n", i, dpy_info->pmodes[i].r.width, dpy_info->pmodes[i].r.height);
+         }
+     }
+ }
+@@ -63,14 +64,17 @@ static void virtio_gpu_text_update(void *opaque, console_ch_t *chardata)
+ {
+ }
+ 
++#if 0
+ static void virtio_gpu_notify_event(VirtIOGPUBase *g, uint32_t event_type)
+ {
+     g->virtio_config.events_read |= event_type;
+     virtio_notify_config(&g->parent_obj);
+ }
++#endif
+ 
+ static void virtio_gpu_ui_info(void *opaque, uint32_t idx, QemuUIInfo *info)
+ {
++#if 0
+     VirtIOGPUBase *g = opaque;
+ 
+     if (idx >= g->conf.max_outputs) {
+@@ -94,6 +98,7 @@ static void virtio_gpu_ui_info(void *opaque, uint32_t idx, QemuUIInfo *info)
+     /* send event to guest */
+     virtio_gpu_notify_event(g, VIRTIO_GPU_EVENT_DISPLAY);
+     return;
++#endif
+ }
+ 
+ static void
+@@ -186,11 +191,14 @@ virtio_gpu_base_device_realize(DeviceState *qdev,
+         virtio_add_queue(vdev, 16, cursor_cb);
+     }
+ 
+-    g->enabled_output_bitmask = 1;
++    g->enabled_output_bitmask = 3;
+ 
+     g->req_state[0].width = g->conf.xres;
+     g->req_state[0].height = g->conf.yres;
+ 
++    g->req_state[1].width = 800;
++    g->req_state[1].height = 600;
++
+     g->hw_ops = &virtio_gpu_ops;
+     for (i = 0; i < g->conf.max_outputs; i++) {
+         g->scanout[i].con =
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2306 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2306
new file mode 100644
index 00000000..962d22a4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2306
@@ -0,0 +1 @@
+A bug of ptimer that the freq can't set more than 1000M
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2307 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2307
new file mode 100644
index 00000000..6c52d7fe
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2307
@@ -0,0 +1,39 @@
+QEMU Windows COM port filenames not recognized i.e. \\.\COM19 or \\.\CNCA0
+Steps to reproduce:
+1. Run qemu-system-arm with the comand line above.
+2. QEMU fails with `qemu-system-arm.exe: -gdb \\.\CNCA8: '\\.\CNCA8' is not a valid char driver`
+3. ```qemu-system-arm.exe -machine mps2-an500 -gdb \\.\COM19
+qemu-system-arm.exe: -gdb \\.\COM19: '\\.\COM19' is not a valid char driver
+```
+Additional information:
+Windows allows COM ports numbered 10 and higher to be prefixed with a `\\.\` escape as in `\\.\COM17`. Such COM port assignments are not uncommon when a plurality of USB serial adapters.
+Equally problematic are virtual COM port designations such as `\\.\CNCA8` created by the Windows 10x64 driver package known as `com0com`: https://pete.akeo.ie/2011/07/com0com-signed-drivers.html
+
+Upon checking the source pulled from the Github mirror an initial fix was to simply modify /chardev/char.c, but this appears insufficient. Sadly.
+
+Please ask if more information is required. I am actively working on extending an existing QEMU machine emulation. A patch to fix this problem is below. Please comment if applicable.
+
+Jerry.
+
+```
+diff --git a/chardev/char.c b/chardev/char.c
+index 3c43fb1278..7a3f342c72 100644
+--- a/chardev/char.c
++++ b/chardev/char.c
+@@ -418,6 +418,13 @@ QemuOpts *qemu_chr_parse_compat(const char *label, const char *filename,
+         qemu_opt_set(opts, "path", filename, &error_abort);
+         return opts;
+     }
++       // JME
++    if (strstart(filename, "\\\\.\\", NULL)) {
++        qemu_opt_set(opts, "backend", "serial", &error_abort);
++        qemu_opt_set(opts, "path", filename, &error_abort);
++        return opts;
++    }
++
+     if (strstart(filename, "file:", &p)) {
+         qemu_opt_set(opts, "backend", "file", &error_abort);
+         qemu_opt_set(opts, "path", p, &error_abort);
+
+```
+/label ~"kind::Bug"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2308 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2308
new file mode 100644
index 00000000..7a276f84
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2308
@@ -0,0 +1,79 @@
+QEMU Windows COM port setup dialog always invoked and fails if none is available (USB or virtual serial port hardware)
+Description of problem:
+The Windows backend serial port in `chardev/char-win.c` always calls `CommConfigDialog()`. This should display a COM port configuration dialog which does (and can) not persist the COM port settings. If the COM port does not support this action (see https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-commconfigdialoga) then the function fails.
+Steps to reproduce:
+1. Currently not possible with QEMU releases as QEMU does not recognize extended COM port specifications like `\\.\COM19` or `\\.\CNCA0`
+Additional information:
+See https://support.microsoft.com/en-gb/topic/howto-specify-serial-ports-larger-than-com9-db9078a5-b7b6-bf00-240f-f749ebfd913e for details on COM port filenames.
+
+I have a patch which 'fixes' this problem by setting the nominated COM port to defaults of `115200,8,N,0` which seems perfectly sensible in 2024. Please contact me for more details. A git diff shown below (with extensive error reporting)
+
+N.B. Markodown will destroy formatting!
+
+```
+diff --git a/chardev/char-win.c b/chardev/char-win.c
+index d4fb44c4dc..a05896ffe9 100644
+--- a/chardev/char-win.c
++++ b/chardev/char-win.c
+@@ -96,12 +96,24 @@ int win_chr_serial_init(Chardev *chr, const char *filename, Error **errp)
+     s->file = CreateFile(filename, GENERIC_READ | GENERIC_WRITE, 0, NULL,
+                       OPEN_EXISTING, FILE_FLAG_OVERLAPPED, 0);
+     if (s->file == INVALID_HANDLE_VALUE) {
++        {
++            char buffer[1024] = { 0 };
++            DWORD dw = GetLastError();
++            sprintf_s(buffer, 1024, "%s(%d) Error: %d 0x%x %s\r\n", __FILE__, __LINE__, dw, dw, filename);
++            OutputDebugString(buffer);
++        }
+         error_setg_win32(errp, GetLastError(), "Failed CreateFile");
+         s->file = NULL;
+         goto fail;
+     }
+
+     if (!SetupComm(s->file, NRECVBUF, NSENDBUF)) {
++        {
++            char buffer[1024] = { 0 };
++            DWORD dw = GetLastError();
++            sprintf_s(buffer, 1024, "%s(%d) Error: %d 0x%x %s\r\n", __FILE__, __LINE__, dw, dw, filename);
++            OutputDebugString(buffer);
++        }
+         error_setg(errp, "Failed SetupComm");
+         goto fail;
+     }
+@@ -110,9 +122,31 @@ int win_chr_serial_init(Chardev *chr, const char *filename, Error **errp)
+     size = sizeof(COMMCONFIG);
+     GetDefaultCommConfig(filename, &comcfg, &size);
+     comcfg.dcb.DCBlength = sizeof(DCB);
+-    CommConfigDialog(filename, NULL, &comcfg);
+-
++#if 1
++    // JME hardwire. There seems to be no mechanism to simply specify serial port options
++    comcfg.dcb.BaudRate = 115200;
++    comcfg.dcb.Parity = NOPARITY;
++    comcfg.dcb.StopBits = ONESTOPBIT;
++    comcfg.dcb.ByteSize = 8;
++#else
++    {
++        BOOL ret = CommConfigDialog(filename, NULL, &comcfg);
++        if (!ret)
++        {
++            char buffer[1024] = { 0 };
++            DWORD dw = GetLastError();
++            sprintf_s(buffer, 1024, "%s(%d) Error: %d 0x%x %s\r\n", __FILE__, __LINE__, dw, dw, filename);
++            OutputDebugString(buffer);
++        }
++    }
++#endif
+     if (!SetCommState(s->file, &comcfg.dcb)) {
++        {
++            char buffer[1024]={0};
++            DWORD dw = GetLastError();
++            sprintf_s(buffer,1024,"%s(%d) Error: %d 0x%x %s\r\n",__FILE__,__LINE__,dw,dw, filename);
++            OutputDebugString(buffer);
++        }
+         error_setg(errp, "Failed SetCommState");
+         goto fail;
+     }
+```
+
+/label ~"kind::Bug"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/231 b/gitlab/issues_text/target_missing/host_missing/accel_missing/231
new file mode 100644
index 00000000..5e877124
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/231
@@ -0,0 +1 @@
+Many leaks from qemu_spice_create_update
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2310 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2310
new file mode 100644
index 00000000..c939fa5b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2310
@@ -0,0 +1 @@
+Virtio devices not working
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2311 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2311
new file mode 100644
index 00000000..5f7512b7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2311
@@ -0,0 +1,15 @@
+Possible dereference of NULL
+Description of problem:
+There is possible dereference of NULL using macro QEMU_LOCK_GUARD(&q->lock) in:
+1) /block/nvme.c line [326](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/block/nvme.c#L326)
+2) /include/qemu/ratelimit.h line [45](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/ratelimit.h#L45)
+3) /include/qemu/ratelimit.h line [88](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/ratelimit.h#L88)
+
+
+The QEMU_MAKE_LOCKABLE(x) macro provides a special case (line [71](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/lockable.h#L71) of the lockable.h) if NULL gets into it. Then the macro will return NULL, which will get to the input of the qemu_lockable_auto_lock() function, then to the qemu_lockable_lock() function, where NULL dereference will occur (line [95](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/lockable.h#L95)).
+
+It turns out that the NULL case is provided, but not handled properly. I think a NULL check should be added.
+
+Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
+
+Author A. Burke.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2313 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2313
new file mode 100644
index 00000000..6e327d83
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2313
@@ -0,0 +1,17 @@
+RISC-V KVM strerrorname_np regression breaks build on Alpine Linux
+Description of problem:
+Build from source fails on Alpine Linux due to the use of the non-portable `strerrorname_np`:
+```
+/usr/lib/gcc/riscv64-alpine-linux-musl/13.2.1/../../../../riscv64-alpine-linux-musl/bin/ld: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o: in function `kvm_cpu_realize':
+kvm-cpu.c:(.text+0x538): undefined reference to `strerrorname_np'
+/usr/lib/gcc/riscv64-alpine-linux-musl/13.2.1/../../../../riscv64-alpine-linux-musl/bin/ld: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o: in function `kvm_cpu_instance_init':
+kvm-cpu.c:(.text+0x1244): undefined reference to `strerrorname_np'
+```
+Steps to reproduce:
+1. install alpine linux on a riscv64 machine
+2. build qemu-9.0.0 from source.
+3.
+Additional information:
+Same problem as https://gitlab.com/qemu-project/qemu/-/issues/2041
+
+Re-introduced with d4ff3da8f45c52670941c6e1b94e771d69d887e9 and 0d71f0a34938a6ac11953ae3dbec40113d2838a1
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2314 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2314
new file mode 100644
index 00000000..b7b02deb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2314
@@ -0,0 +1,16 @@
+Building QEMU 9.0.0 fails on MacOS 10.15.7 (error: initializing 'NSEdgeInsets' (aka 'struct NSEdgeInsets') with an expression of incompatible type 'id')
+Description of problem:
+QEMU fails to compile using Homebrew on OS X 10.15.7:
+```
+../ui/cocoa.m:542:18: error: initializing 'NSEdgeInsets' (aka 'struct NSEdgeInsets') with an expression of incompatible type 'id'
+    NSEdgeInsets insets = [[[self window] screen] safeAreaInsets];
+                 ^        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+1 error generated.
+```
+Steps to reproduce:
+1. Compile QEMU on OS X 10.15.7 using Homebrew
+2.
+3.
+Additional information:
+Build log
+[02.make.zip](/uploads/dfb618b86984ed6cf699d94bf9d6c9e1/02.make.zip)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2315 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2315
new file mode 100644
index 00000000..8592170c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2315
@@ -0,0 +1,12 @@
+Mouse cursor is flipped / inverted / upside-down with virtio-gpu in some Wayland compositors
+Description of problem:
+The mouse cursor is flipped:
+Steps to reproduce:
+1. Install a Linux system with a 6.8.x kernel inside the virtual machine
+2. Install sway / wayfire / hyprland, or kwin 6.0.4.1
+3. See the mouse cursor
+Additional information:
+The [kwin fix](https://invent.kde.org/plasma/kwin/-/commit/a31561c392adf5abcda0284e8049fafcb3701585) just makes use of dumb buffers instead of dmabuf.
+
+The mouse cursor should be pointing to the maximizing button at the top-right corner:
+![Screenshot](/uploads/f1c3db2129955159e9ce765dd29ae9eb/a.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2316 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2316
new file mode 100644
index 00000000..0fcbee47
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2316
@@ -0,0 +1,36 @@
+aarch64 virt cortex-a53 libc printf (with argument) hello world strange behavior
+Description of problem:
+My hello world get lost after
+
+`0x0000000040000370 <+48>:    str     q0, [sp, #80]`
+
+in 
+
+```
+   0x1f8:       udf     #0
+   0x1fc:       udf     #0
+=> 0x200:       udf     #0
+   0x204:       udf     #0
+   0x208:       udf     #0
+   0x20c:       udf     #0
+   0x210:       udf     #0
+   0x214:       udf     #0
+```
+
+By bisecting, I got the last commit OK : v8.2.0-2033-g49fa457ca5
+
+```
+$ qemu-system-aarch64 -M virt,secure=on,gic-version=3 -cpu cortex-a53 -kernel aarch64-none-elf-a.elf -serial stdio -display none
+printf with an integer : 42
+```
+
+But after v8.2.0-2034-g59754f85ed https://gitlab.com/qemu-project/qemu/-/commit/59754f85ed35cbd5f4bf2663ca2136c78d5b2413 (for example with latest v9.0.0-265-gfd87be1dad), it doesn't work anymore.
+Steps to reproduce:
+1. Build qemu-system-aarch64 with ``./configure --prefix=$PREFIX --target-list=aarch64-softmmu --disable-user --disable-linux-user --disable-bsd-user --enable-kvm --enable-tcg --disable-gnutls --disable-nettle --disable-gtk --disable-iconv --disable-curses --disable-curl --disable-vnc --disable-vnc-jpeg --disable-attr --disable-libusb --disable-opengl --disable-tpm --disable-bzip2 && make -j$(nproc) && make install``
+
+2. Run my hello world : ``qemu-system-aarch64 -M virt,secure=on,gic-version=3 -cpu cortex-a53 -kernel aarch64-none-elf-a.elf -serial stdio -display none``
+Additional information:
+I provide here the hello world (elf + map). Of course the problem might be that it (qemu and/or hello world) was not built correctly and that everything was working by chance before v8.2.0-2033-g49fa457ca5
+[aarch64-none-elf-a.elf](/uploads/daf7f37aec260c56d4be5fd90554dce3/aarch64-none-elf-a.elf)
+[aarch64-none-elf-a.map](/uploads/5564cee13a214e7eb8d6d4bf79f09682/aarch64-none-elf-a.map)
+Depending on the investigation, I can provide what's needed to rebuild it.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/232 b/gitlab/issues_text/target_missing/host_missing/accel_missing/232
new file mode 100644
index 00000000..48506d62
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/232
@@ -0,0 +1 @@
+I/O write make QXL abort in qxl_set_mode()
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2322 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2322
new file mode 100644
index 00000000..9f7594ea
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2322
@@ -0,0 +1 @@
+Qemu 9 make install failed on Ubuntu 23.10 ARM64
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2323 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2323
new file mode 100644
index 00000000..2000bca2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2323
@@ -0,0 +1,26 @@
+Win/Super key not working correctly under Windows hosts
+Description of problem:
+I accidentally noticed `Win` key (VK_LWIN) not working correctly on Windows hosts, more specifically:
+
+1. It is impossible to "hold" `Win`. If one presses and holds `Win`, the guest is spammed with `Win` keypresses, instead of receiving a single `Win` keypress at the point of releasing the button (VK_LWIN button up).
+2. It is impossible to make key combinations (shortcuts, hotkeys etc.) that involve the `Win/Super` key. Maybe implicitly solved by fixing #1.
+
+This behavior is present starting from bc8e883065f36581e4f2352c31a1dfa5f65a82f2 (ui/sdl2: disable SDL_HINT_GRAB_KEYBOARD on Windows). Before it, on the SDL2 keyboard hook `Win/Super` key worked correctly. I demonstrate the problem on Fedora/WinXP, but it affects all guests.
+Steps to reproduce:
+1. (see additional information)
+2.
+3.
+Additional information:
+Short video demonstration on a WinXP guest and a Fedora 39 guest. The qemus used are (qemu-8.0.2 e0968d21e27ef9c406f709180a39a076e786efbe; working correctly) and (qemu-9.0.0 from the release tarball qemu-9.0.0.tar.xz; buggy)
+
+1. In the WinXP video, I'm pressing and holding the `Win` key for about 3 seconds. In the correct version, the start menu is opened only at the point of release. In the buggy version, the start menu is opened repeatedly tens of times (flickering). You can see the point of release in Nirsoft's KeyboardStateView, when VK_LWIN loses the "pressed" asterisk.
+
+   At the end of the video I'm trying to use the `Win+e` shortcut for WinExplorer. In the buggy version, Outlook is opened instead. This is because the keypresses are processed individually, first `Win` opens the start menu and then `e` opens email application (in this case outlook). In the correct version WinExplorer is opened.
+
+   ![winxp-ok](/uploads/a8b621552c0a395766a42345654a2e01/winxp-ok.mp4)
+   ![winxp-buggy](/uploads/14b73486b6d58f643baf3370d8d19eaf/winxp-buggy.mp4)
+
+2. In the Fedora video, I'm trying to set up a simple shortcut, I'm pressing on my keyboard `LCTRL+LALT+Super+E`. In the buggy version, the `Super` key is not picked up. All the shortcut combinations involving `Super` are therefore not working.
+
+   ![fedora39-ok](/uploads/0704293eeecfce9fb2061b8d5a5ee36f/fedora39-ok.mp4)
+   ![fedora39-buggy](/uploads/fb623fa226dcb908ea6fa685d4f792e3/fedora39-buggy.mp4)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2327 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2327
new file mode 100644
index 00000000..ea172bdb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2327
@@ -0,0 +1,61 @@
+negative shift exponent in cirrus_colorexpand_pattern_transp_0_24()
+Description of problem:
+My fuzzer detected a runtime error in cirrus_colorexpand_pattern_transp_0_24()
+
+The stack trace is:
+
+```
+../hw/display/cirrus_vga_rop2.h:216:23: runtime error: shift exponent -2 is negative
+    #0 0x5589a028c89a in cirrus_colorexpand_pattern_transp_0_24 hw/display/cirrus_vga_rop2.h:216:23
+    #1 0x5589a031e239 in cirrus_bitblt_common_patterncopy hw/display/cirrus_vga.c:689:5
+    #2 0x5589a032735d in cirrus_bitblt_cputovideo_next hw/display/cirrus_vga.c:820:13
+    #3 0x5589a032cde9 in cirrus_linear_write hw/display/cirrus_vga.c:2365:13
+    #4 0x5589a2982823 in memory_region_write_accessor system/memory.c:497:5
+    #5 0x5589a2981f05 in access_with_adjusted_size system/memory.c:573:18
+    #6 0x5589a297fe69 in memory_region_dispatch_write system/memory.c:1521:16
+    #7 0x5589a2a2193e in flatview_write_continue_step system/physmem.c:2749:18
+    #8 0x5589a2a211d4 in flatview_write_continue system/physmem.c:2779:19
+    #9 0x5589a29f9cfb in flatview_write system/physmem.c:2810:12
+    #10 0x5589a29f97c8 in address_space_write system/physmem.c:2930:18
+...
+```
+Steps to reproduce:
+Arguments:\
+export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine\
+q35 -nodefaults -device cirrus-vga -display vnc=localhost:99 -L ../pc-bios/"\
+The base addresses of memory regions:
+
+* cirrus-io, 0x3b0
+* cirrus-low-memory, 0xa0000
+* cirrus-linear-io, 0xe0000000
+* cirrus-bitblt-mmio, 0xe1000000
+* cirrus-mmio, 0xe2000000
+
+Reproducer:
+
+```
+writeb 0xe2000108 0x642a8d58
+writeb 0xe2000117 0x335af91c
+writeb 0xe2000118 0x765861ed
+writeb 0xe200010d 0x7c3af934
+writeb 0xe2000140 0x33f13baf
+clock_step
+writeb 0xe01f0e68 0x6ea3696c
+writeb 0xe13bc720 0x11bb09ba
+readb 0xe2000133
+writeb 0xe033629b 0x80f19dd
+writeb 0xe134bba7 0x1eb198f9
+readb 0xe2000680
+writeb 0xe2000b84 0x3f0591fc
+clock_step
+writeb 0xe003469e 0xdbd627e
+writeb 0xe114f2bc 0x41adfe48
+readb 0xe2000cde
+readb 0xb269d
+writeb 0xe1368066 0x3c9ab77
+readb 0xe12a7fe1
+writeb 0xe0191988 0x7e18b0d1
+EOF
+```
+Additional information:
+Ack: Chuhong Yuan (hslester96@gmail.com)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2329 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2329
new file mode 100644
index 00000000..355a1017
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2329
@@ -0,0 +1 @@
+Windows 64-bit, qemu-monitor, change
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2331 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2331
new file mode 100644
index 00000000..c368b587
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2331
@@ -0,0 +1 @@
+(Question) There's a CLI option for the GUI option "Grab On Hover" ?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2335 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2335
new file mode 100644
index 00000000..7873ce8b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2335
@@ -0,0 +1,208 @@
+SPICE Worker segfault
+Description of problem:
+Hello. Sometimes we have an error. kvm randomly crashes.
+May 07 16:55:50 vdi1 kernel: SPICE Worker[249326]: segfault at 7f1c8c03af40 ip 00007f1fbbbb2579 sp 00007f1dabbf9d20 error 4 in libc.so.6[7f1fbbb41000+155000] likely on CPU 89 (core 20, socket 1)
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+`# coredumpctl info
+           PID: 249293 (kvm)
+           UID: 0 (root)
+           GID: 0 (root)
+        Signal: 11 (SEGV)
+     Timestamp: Tue 2024-05-07 16:55:50 MSK (18h ago)
+  Command Line: /usr/bin/kvm -id 141 -name VDI,debug-threads=on -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/141.qmp,server=on,wait=off -mon chardev=qmp,mode=control -chard>
+    Executable: /usr/bin/qemu-system-x86_64
+ Control Group: /qemu.slice/141.scope
+          Unit: 141.scope
+         Slice: qemu.slice
+       Boot ID: 5cfcd2d515a6425fa3880a61d8cd6bfc
+    Machine ID: 6e4c2fe391324304a856baa8e6c88002
+      Hostname: vdi1
+       Storage: /var/lib/systemd/coredump/core.kvm.0.5cfcd2d515a6425fa3880a61d8cd6bfc.249293.1715090150000000.zst (present)
+  Size on Disk: 2.3G
+       Message: Process 249293 (kvm) of user 0 dumped core.
+
+                Module libsystemd.so.0 from deb systemd-252.22-1~deb12u1.amd64
+                Module libudev.so.1 from deb systemd-252.22-1~deb12u1.amd64
+                Stack trace of thread 249326:
+                #0  0x00007f1fbbbb2579 _int_malloc (libc.so.6 + 0x97579)
+                #1  0x00007f1fbbbb46e2 __libc_calloc (libc.so.6 + 0x996e2)
+                #2  0x00007f1fbd3f76d1 g_malloc0 (libglib-2.0.so.0 + 0x5a6d1)
+                #3  0x00007f1fbdadd7a3 red_get_data_chunks_ptr (libspice-server.so.1 + 0x3e7a3)
+                #4  0x00007f1fbdaddf6b red_get_data_chunks (libspice-server.so.1 + 0x3ef6b)
+                #5  0x00007f1fbdadedd9 red_get_copy_ptr (libspice-server.so.1 + 0x3fdd9)
+                #6  0x00007f1fbdadf1e5 red_get_native_drawable (libspice-server.so.1 + 0x401e5)
+                #7  0x00007f1fbdaf1a2c red_process_display (libspice-server.so.1 + 0x52a2c)
+                #8  0x00007f1fbdaf1cb7 worker_source_dispatch (libspice-server.so.1 + 0x52cb7)
+                #9  0x00007f1fbd3f17a9 g_main_context_dispatch (libglib-2.0.so.0 + 0x547a9)
+                #10 0x00007f1fbd3f1a38 n/a (libglib-2.0.so.0 + 0x54a38)
+                #11 0x00007f1fbd3f1cef g_main_loop_run (libglib-2.0.so.0 + 0x54cef)
+                #12 0x00007f1fbdaf0fa9 red_worker_main (libspice-server.so.1 + 0x51fa9)
+                #13 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #14 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+
+                Stack trace of thread 249321:
+                #0  0x00007f1fbbc18c5b __GI___ioctl (libc.so.6 + 0xfdc5b)
+                #1  0x000055b3bae626cf kvm_vcpu_ioctl (qemu-system-x86_64 + 0x72b6cf)
+                #2  0x000055b3bae62ba5 kvm_cpu_exec (qemu-system-x86_64 + 0x72bba5)
+                #3  0x000055b3bae6408d kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x72d08d)
+                #4  0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78)
+                #5  0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #6  0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+
+                Stack trace of thread 249327:
+                #0  0x00007f1fbdac9b48 glz_rgb_alpha_compress_seg (libspice-server.so.1 + 0x2ab48)
+                #1  0x00007f1fbdacc1cb glz_rgb_alpha_compress (libspice-server.so.1 + 0x2d1cb)
+                #2  0x00007f1fbdad08ed image_encoders_compress_glz (libspice-server.so.1 + 0x318ed)
+                #3  0x00007f1fbdaba608 _Z18dcc_compress_imageP20DisplayChannelClientP10SpiceImageP11SpiceBitmapP8DrawableiP20compress_send_data_t (libspice-server.so.1 + 0x1b608)
+                #4  0x00007f1fbdabb7f5 fill_bits (libspice-server.so.1 + 0x1c7f5)
+                #5  0x00007f1fbdabca2f red_marshall_qxl_draw_copy (libspice-server.so.1 + 0x1da2f)
+                #6  0x00007f1fbdabe82b marshall_lossless_qxl_drawable (libspice-server.so.1 + 0x1f82b)
+                #7  0x00007f1fbdadb5d3 _ZN16RedChannelClient4pushEv (libspice-server.so.1 + 0x3c5d3)
+                #8  0x00007f1fbdadb700 red_channel_client_event (libspice-server.so.1 + 0x3c700)
+                #9  0x00007f1fbdac579d spice_watch_dispatch (libspice-server.so.1 + 0x2679d)
+                #10 0x00007f1fbd3f167f g_main_context_dispatch (libglib-2.0.so.0 + 0x5467f)
+                #11 0x00007f1fbd3f1a38 n/a (libglib-2.0.so.0 + 0x54a38)
+                #12 0x00007f1fbd3f1cef g_main_loop_run (libglib-2.0.so.0 + 0x54cef)
+                #13 0x00007f1fbdaf0fa9 red_worker_main (libspice-server.so.1 + 0x51fa9)
+                #14 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #15 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+
+                Stack trace of thread 249324:
+                #0  0x00007f1fbbc18c5b __GI___ioctl (libc.so.6 + 0xfdc5b)
+                #1  0x000055b3bae626cf kvm_vcpu_ioctl (qemu-system-x86_64 + 0x72b6cf)
+                #2  0x000055b3bae62ba5 kvm_cpu_exec (qemu-system-x86_64 + 0x72bba5)
+                #3  0x000055b3bae6408d kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x72d08d)
+                #4  0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78)
+                #5  0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #6  0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+
+                Stack trace of thread 249293:
+                #0  0x00007f1fbbc17256 __ppoll (libc.so.6 + 0xfc256)
+                #1  0x000055b3bb011dfe ppoll (qemu-system-x86_64 + 0x8dadfe)
+                #2  0x000055b3bb00f6ee os_host_main_loop_wait (qemu-system-x86_64 + 0x8d86ee)
+                #3  0x000055b3bac6caa7 qemu_main_loop (qemu-system-x86_64 + 0x535aa7)
+                #4  0x000055b3bae6cf46 qemu_default_main (qemu-system-x86_64 + 0x735f46)
+                #5  0x00007f1fbbb4224a __libc_start_call_main (libc.so.6 + 0x2724a)
+                #6  0x00007f1fbbb42305 __libc_start_main_impl (libc.so.6 + 0x27305)
+                #7  0x000055b3baa5f0a1 _start (qemu-system-x86_64 + 0x3280a1)
+
+                Stack trace of thread 249322:
+                #0  0x00007f1fbbc18c5b __GI___ioctl (libc.so.6 + 0xfdc5b)
+                #1  0x000055b3bae626cf kvm_vcpu_ioctl (qemu-system-x86_64 + 0x72b6cf)
+                #2  0x000055b3bae62ba5 kvm_cpu_exec (qemu-system-x86_64 + 0x72bba5)
+                #3  0x000055b3bae6408d kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x72d08d)
+                #4  0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78)
+                #5  0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #6  0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+
+                Stack trace of thread 249323:
+                #0  0x00007f1fbbc18c5b __GI___ioctl (libc.so.6 + 0xfdc5b)
+                #1  0x000055b3bae626cf kvm_vcpu_ioctl (qemu-system-x86_64 + 0x72b6cf)
+                #2  0x000055b3bae62ba5 kvm_cpu_exec (qemu-system-x86_64 + 0x72bba5)
+                #3  0x000055b3bae6408d kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x72d08d)
+                #4  0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78)
+                #5  0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #6  0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+
+                Stack trace of thread 249294:
+                #0  0x00007f1fbbc1c719 syscall (libc.so.6 + 0x101719)
+                #1  0x000055b3baffccfa qemu_futex_wait (qemu-system-x86_64 + 0x8c5cfa)
+                #2  0x000055b3bb006602 call_rcu_thread (qemu-system-x86_64 + 0x8cf602)
+                #3  0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78)
+                #4  0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #5  0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+
+                Stack trace of thread 249329:
+                #0  0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96)
+                #1  0x00007f1fbbba3558 __pthread_cond_wait_common (libc.so.6 + 0x88558)
+                #2  0x000055b3baffc68b qemu_cond_wait_impl (qemu-system-x86_64 + 0x8c568b)
+                #3  0x000055b3baa88f2b vnc_worker_thread_loop (qemu-system-x86_64 + 0x351f2b)
+                #4  0x000055b3baa89bc8 vnc_worker_thread (qemu-system-x86_64 + 0x352bc8)
+                #5  0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78)
+                #6  0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #7  0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+
+                Stack trace of thread 3982758:
+                #0  0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96)
+                #1  0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c)
+                #2  0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01)
+                #3  0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0)
+                #4  0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4)
+                #5  0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78)
+                #6  0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #7  0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+
+                Stack trace of thread 969111:
+                #0  0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96)
+                #1  0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c)
+                #2  0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01)
+                #3  0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0)
+                #4  0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4)
+                #5  0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78)
+                #6  0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #7  0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+
+                Stack trace of thread 969113:
+                #0  0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96)
+                #1  0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c)
+                #2  0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01)
+                #3  0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0)
+                #4  0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4)
+                #5  0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78)
+                #6  0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #7  0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+
+                Stack trace of thread 969114:
+                #0  0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96)
+                #1  0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c)
+                #2  0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01)
+                #3  0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0)
+                #4  0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4)
+                #5  0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78)
+                #6  0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #7  0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+
+                Stack trace of thread 969112:
+                #0  0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96)
+                #1  0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c)
+                #2  0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01)
+                #3  0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0)
+                #4  0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4)
+                #5  0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78)
+                #6  0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #7  0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+
+                Stack trace of thread 4165267:
+                #0  0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96)
+                #1  0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c)
+                #2  0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01)
+                #3  0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0)
+                #4  0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4)
+                #5  0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78)
+                #6  0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #7  0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+
+                Stack trace of thread 969116:
+                #0  0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96)
+                #1  0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c)
+                #2  0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01)
+                #3  0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0)
+                #4  0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4)
+                #5  0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78)
+                #6  0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #7  0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+
+                Stack trace of thread 969115:
+                #0  0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96)
+                #1  0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c)
+                #2  0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01)
+                #3  0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0)
+                #4  0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4)
+                #5  0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78)
+                #6  0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134)
+                #7  0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc)
+                ELF object binary architecture: AMD x86-64`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2337 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2337
new file mode 100644
index 00000000..f43e5ab7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2337
@@ -0,0 +1,62 @@
+Os boot issues on 9p filesystem due to unix domain sockets open failure
+Description of problem:
+Unix filesystem API is broken, unix domain socket special files return an error at open()
+Steps to reproduce:
+Simple script. Tries to use netcat to get data through a local unix domain socket file   
+```
+#!/bin/bash
+
+# Cleanup target dir
+[ -d ./target ] && rm -rf target
+mkdir target
+
+# Add configuration updates
+mkdir -p ./target/etc/initramfs-tools/
+echo 9p >> ./target/etc/initramfs-tools/modules
+echo 9pnet_virtio >> ./target/etc/initramfs-tools/modules
+
+# Add the test script
+cat > ./target/test_init << EOF
+#!/bin/bash
+
+echo "Test for unix domain sockets"
+
+nc -Ul /socket &
+sleep 1
+echo "Sockets work" | nc -UN /socket || echo "Sockets fail"
+
+echo o > /proc/sysrq-trigger
+sleep 999
+EOF
+chmod 700 ./target/test_init
+
+# Create an Ubuntu 23.10 around it
+echo "Creating Ubuntu target OS"
+debootstrap --variant=minbase\
+            --include=udev,kmod,initramfs-tools,systemd,netcat-openbsd,linux-image-generic \
+            --exclude=man,bash-completion \
+            mantic ./target > /dev/null || exit 1
+
+# Run the test in 9p forwarded filesystem
+echo "Running OS in qemu"
+qemu-system-s390x \
+  -m 8192 \
+  -smp 4 \
+  -nodefaults -nographic -no-reboot -no-user-config \
+  -kernel ./target/boot/vmlinuz \
+  -initrd ./target/boot/initrd.img \
+  -append 'root=fsRoot rw rootfstype=9p rootflags=trans=virtio,version=9p2000.L,msize=512000,cache=mmap,posixacl console=ttysclp0 init=/test_init quiet' \
+  -fsdev local,security_model=passthrough,multidevs=remap,id=fsdev-fsRoot,path=./target \
+  -device virtio-9p-pci,id=fsRoot,fsdev=fsdev-fsRoot,mount_tag=fsRoot \
+  -device virtio-serial-ccw -device sclpconsole,chardev=console \
+  -chardev stdio,id=console,signal=off 
+```
+Additional information:
+Test output:
+```
+Test for unix domain sockets
+qemu-system-s390x: 9p: broken or compromised client detected; attempt to open special file (i.e. neither regular file, nor directory)
+nc: No such device or address
+nc: /socket: No such file or directory
+Sockets fail
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2338 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2338
new file mode 100644
index 00000000..3185f319
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2338
@@ -0,0 +1 @@
+(Feature request) Implement the "grab-on-hover=on" CLI option on the SDL frontend
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2339 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2339
new file mode 100644
index 00000000..3a7eec32
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2339
@@ -0,0 +1 @@
+VM Crash is observed while deploying an ubuntu VM with OS version 18.04 on host with ubuntu version 24.04
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/234 b/gitlab/issues_text/target_missing/host_missing/accel_missing/234
new file mode 100644
index 00000000..f726cfd2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/234
@@ -0,0 +1 @@
+Failure building with clang-10 and libssh
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2341 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2341
new file mode 100644
index 00000000..f1678c06
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2341
@@ -0,0 +1,32 @@
+IVSHMEM device doesn't work for sharing memory with virtiofsd
+Description of problem:
+Trying to share a folder on the host to the guest with `virtiofsd` using the `ivshmem-plain` device doesn't work (for memory sharing), while using a NUMA node (with `-numa node,memdev=mem`) works just fine.
+Steps to reproduce:
+1. Install `virtiofsd`
+2. Run `/usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu --shared-dir=$HOME --cache always` as a regular user (or with another shared directory, it doesn't matter)
+3. Run QEMU with the aforementioned command line as a regular user
+4. Wait a bit for the OS to load and `virtiofsd` should error out
+Additional information:
+`virtiofsd` logs:
+```
+[2024-05-09T19:49:15Z WARN  virtiofsd::sandbox] Couldn't set the process uid as root: -1
+[2024-05-09T19:49:15Z WARN  virtiofsd::sandbox] Couldn't set the process gid as root: -1
+[2024-05-09T19:49:15Z INFO  virtiofsd] Waiting for vhost-user socket connection...
+[2024-05-09T19:49:16Z INFO  virtiofsd] Client connected, servicing requests
+[2024-05-09T19:49:22Z ERROR virtiofsd] Waiting for daemon failed: HandleRequest(ReqHandlerError(Custom { kind: Other, error: MissingMemoryMapping }))
+```
+
+QEMU logs (after virtiofsd errors out and exits):
+```
+qemu: Failed to read msg header. Read -1 instead of 12. Original request 0.
+qemu: Failed to write msg. Wrote -1 instead of 20.
+qemu: vhost VQ 1 ring restore failed: -22: Invalid argument (22)
+qemu: Failed to set msg fds.
+qemu: vhost VQ 0 ring restore failed: -22: Invalid argument (22)
+qemu: Error starting vhost: 5
+qemu: Failed to set msg fds.
+qemu: vhost_set_vring_call failed 22
+qemu: Failed to set msg fds.
+qemu: vhost_set_vring_call failed 22
+qemu: Unexpected end-of-file before all data were read
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2342 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2342
new file mode 100644
index 00000000..d0a85753
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2342
@@ -0,0 +1 @@
+DEREF_OF_NULL.RET in qdev-clock.c
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2343 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2343
new file mode 100644
index 00000000..f3e2b97d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2343
@@ -0,0 +1,31 @@
+pflash write timeout u-boot@qemu-system-aarch64
+Description of problem:
+Emulating the write into flash of environment variables within U-boot is not possible anymore. This works natively in Fedora 39 which has the 8.1.3 qemu version. Stopped working after transitioning to Fedora 40 which currently comes with 8.2.2, also doesn't work with Debian 12 which has 7.2.9.
+
+The write fails with the following message:
+
+```
+=> saveenv
+Saving Environment to Flash... Un-Protected 2 sectors
+Erasing Flash...
+.. done
+Erased 2 sectors
+Writing to Flash... pflash_write: Write to buffer emulation is flawed
+pflash_write: Write to buffer emulation is flawed
+pflash_write: Write to buffer emulation is flawed
+Flash buffer write timeout at address 4000000 data ffffffffb64f6361
+Timeout writing to Flash
+Protected 2 sectors
+Failed (1)
+```
+Steps to reproduce:
+1. Download or build u-boot for aarch64 qemu. You can extract from u-boot-qemu debian package https://packages.debian.org/unstable/u-boot-qemu .
+2. `truncate -s 64m varstore.img`
+3. `qemu-system-aarch64 -machine virt -cpu cortex-a35 -nographic  -smp 2 -m 1G -bios u-boot.bin -drive if=pflash,format=raw,file=varstore.img,readonly=off,index=1 -d guest_errors,unimp`
+Additional information:
+After building versions 8.1.3 and 8.1.4 I found both were working fine regartheless the host OS, the issue was introduced in 8.1.5. 
+After inspecting commits history I drop the following commit [hw/pflash: implement update buffer for block writes (hash:fcc79f2e09550b0461792491965fe202ed2219ae)](https://gitlab.com/qemu-project/qemu/-/commit/fcc79f2e09550b0461792491965fe202ed2219ae) rebuilt and the issue was gone.
+I then recheck all non working versions and both versions 8.2.2 and 7.2.9 also have this commit, this explains why it also doesn't work.
+I attached a trace running with v8.1.5 and v8.1.5 with drop commit.
+[v8.1.5.log](/uploads/04aa0e24e1e16f6bdf29a6e6be587ba1/v8.1.5.log)
+[v8.1.5-drop-fcc79f2e.log](/uploads/206fe958ab78c12542fda3764df978da/v8.1.5-drop-fcc79f2e.log)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2344 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2344
new file mode 100644
index 00000000..b1b07abf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2344
@@ -0,0 +1,45 @@
+Plugin scoreboard deadlock (plugin.lock vs start_exclusive)
+Description of problem:
+Deadlock
+
+In frame 9 the thread grabs the plugin.lock, and starts to wait for other cpus to enter exclusive idle.
+```
+#7  0x00005555555a1295 in start_exclusive () at ../hw/core/cpu-common.c:199
+#8  plugin_grow_scoreboards__locked (cpu=0x7fff0c2b4720) at ../plugins/core.c:238
+#9  qemu_plugin_vcpu_init_hook (cpu=0x7fff0c2b4720) at ../plugins/core.c:258
+```
+
+The other thread just finished a TB and do the callback to the plugin, so it will not become exclusive idle until it finishes.
+That callback tries to create a new 'scoreboard', but plugin.lock is already taken.
+```
+#7  qemu_plugin_scoreboard_new (element_size=element_size@entry=8) at ../plugins/api.c:464
+#8  0x00007ffff7fb973d in vcpu_tb_trans (id=<optimized out>, tb=0x555555858d60) at /home/rehn/source/qemu/contrib/plugins/hotblocks.c:125
+#9  0x00005555557394f1 in qemu_plugin_tb_trans_cb (cpu=<optimized out>, tb=0x555555858d60) at ../plugins/core.c:418
+```
+
+Locally I'm using this fix, reverse order so we enter exclusive idle before grabbing the plugin.lock:
+```
+diff --git a/plugins/core.c b/plugins/core.c
+index 1e58a57bf1..0e41c4ef22 100644
+--- a/plugins/core.c
++++ b/plugins/core.c
+@@ -236,4 +236,2 @@ static void plugin_grow_scoreboards__locked(CPUState *cpu)
+ 
+-    /* cpus must be stopped, as tb might still use an existing scoreboard. */
+-    start_exclusive();
+     struct qemu_plugin_scoreboard *score;
+@@ -244,3 +242,2 @@ static void plugin_grow_scoreboards__locked(CPUState *cpu)
+     tb_flush(cpu);
+-    end_exclusive();
+ }
+@@ -250,2 +247,4 @@ void qemu_plugin_vcpu_init_hook(CPUState *cpu)
+     bool success;
++    /* cpus must be stopped, as tb might still use an existing scoreboard. */
++    start_exclusive();
+ 
+@@ -259,2 +258,3 @@ void qemu_plugin_vcpu_init_hook(CPUState *cpu)
+     qemu_rec_mutex_unlock(&plugin.lock);
++    end_exclusive();
+```
+Steps to reproduce:
+Run command a few times and get 'unlucky'
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2345 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2345
new file mode 100644
index 00000000..fea5802e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2345
@@ -0,0 +1,48 @@
+Undefined behavior error: call to function qemu_mutex_lock through pointer to incorrect function type
+Description of problem:
+When compiling QEMU with:
+
+```
+./configure --cc=clang --extra-cflags=-fsanitize=undefined --extra-cflags=-fno-sanitize-recover=undefined --target-list=x86_64-softmmu
+```
+
+on a system that has Clang v17 or newer (e.g. on Fedora 39 or Fedora 40), the QEMU binary abort with an undefined behavior error:
+
+```
+$ ./qemu-system-x86_64
+include/qemu/lockable.h:95:5: runtime error: call to function qemu_mutex_lock through pointer to incorrect function type 'void (*)(void *)'
+include/qemu/thread.h:122:5: note: qemu_mutex_lock defined here
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior include/qemu/lockable.h:95:5 
+```
+
+Or for example when running ``make check-unit`` :
+
+```
+ 97/103 qemu:unit / test-yank                            ERROR            0.13s   killed by signal 6 SIGABRT
+>>> G_TEST_BUILDDIR=/tmp/qemu-ubsan/tests/unit ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MALLOC_PERTURB_=201 G_TEST_SRCDIR=~/qemu/tests/unit /tmp/qemu-ubsan/tests/unit/test-yank --tap -k
+――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――――――
+stderr:
+include/qemu/lockable.h:95:5: runtime error: call to function qemu_mutex_lock through pointer to incorrect function type 'void (*)(void *)'
+include/qemu/thread.h:122:5: note: qemu_mutex_lock defined here
+    #0 0x55753123f8b9 in qemu_lockable_lock include/qemu/lockable.h:95:5
+    #1 0x55753123f8b9 in qemu_lockable_auto_lock include/qemu/lockable.h:105:5
+    #2 0x55753123f8b9 in qmp_query_yank util/yank.c:184:5
+    #3 0x5575311a35fe in is_yank_instance_registered tests/unit/test-yank.c:43:12
+    #4 0x5575311a35fe in char_change_test tests/unit/test-yank.c:128:5
+    #5 0x7f7f0a8cfbbf  (/lib64/libglib-2.0.so.0+0x8bbbf) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #6 0x7f7f0a8cfb2f  (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #7 0x7f7f0a8cfb2f  (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #8 0x7f7f0a8cfb2f  (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #9 0x7f7f0a8d00c9 in g_test_run_suite (/lib64/libglib-2.0.so.0+0x8c0c9) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #10 0x7f7f0a8d015f in g_test_run (/lib64/libglib-2.0.so.0+0x8c15f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #11 0x5575311a336f in main tests/unit/test-yank.c:248:12
+    #12 0x7f7f0a32d087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06)
+    #13 0x7f7f0a32d14a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06)
+    #14 0x557531178d64 in _start (/tmp/qemu-ubsan/tests/unit/test-yank+0x77d64) (BuildId: 0bb470b7accec26b684d1c7e941239d31396604e)
+
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior include/qemu/lockable.h:95:5 
+
+(test program exited with status code -6)
+```
+
+The way we abuse the (void *) parameter of QemuLockUnlockFunc seems to be undefined behavior, which could likely also trigger issues with CFI or certain compilers/architectures like emscripten, so we should try to avoid this. See also https://github.com/systemd/systemd/issues/29972 or https://github.com/python/cpython/issues/111178 for discussions in other projects.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2346 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2346
new file mode 100644
index 00000000..ab236b57
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2346
@@ -0,0 +1,72 @@
+Undefined behavior error: call to function visit_type_InetSocketAddress_members through pointer to incorrect function type
+Description of problem:
+When compiling QEMU with --extra-cflags=-fsanitize=undefined and --extra-cflags=-fno-sanitize-recover=undefined on a system that has Clang v17 or newer (e.g. on Fedora 39 or Fedora 40), the unit tests abort with an undefined behavior error.
+Steps to reproduce:
+1. ``./configure --cc=clang --extra-cflags=-fsanitize=undefined --extra-cflags=-fno-sanitize-recover=undefined --target-list=x86_64-softmmu``
+2. ``make -j$(nproc)``
+3. ``make check-unit``
+Additional information:
+test-io-channel-socket aborts with:
+
+```
+ 74/103 qemu:unit / test-io-channel-socket               ERROR            0.15s   killed by signal 6 SIGABRT
+>>> G_TEST_BUILDDIR=/tmp/qemu-ubsan/tests/unit ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MALLOC_PERTURB_=163 G_TEST_SRCDIR=tests/unit /tmp/qemu-ubsan/tests/unit/test-io-channel-socket --tap -k
+―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀  ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+stderr:
+qapi/qapi-clone-visitor.c:188:5: runtime error: call to function visit_type_SocketAddress through pointer to incorrect function type 'bool (*)(struct Visitor *, const char *, void **, struct Error **)'
+/tmp/qemu-ubsan/qapi/qapi-visit-sockets.c:487: note: visit_type_SocketAddress defined here
+    #0 0x5642aa2f7f3b in qapi_clone qapi/qapi-clone-visitor.c:188:5
+    #1 0x5642aa2c8ce5 in qio_channel_socket_listen_async io/channel-socket.c:285:18
+    #2 0x5642aa2b8903 in test_io_channel_setup_async tests/unit/test-io-channel-socket.c:116:5
+    #3 0x5642aa2b8204 in test_io_channel tests/unit/test-io-channel-socket.c:179:9
+    #4 0x5642aa2b8129 in test_io_channel_ipv4 tests/unit/test-io-channel-socket.c:323:5
+    #5 0x7f01212c0bbf  (/lib64/libglib-2.0.so.0+0x8bbbf) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #6 0x7f01212c0b2f  (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #7 0x7f01212c0b2f  (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #8 0x7f01212c0b2f  (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #9 0x7f01212c10c9 in g_test_run_suite (/lib64/libglib-2.0.so.0+0x8c0c9) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #10 0x7f01212c115f in g_test_run (/lib64/libglib-2.0.so.0+0x8c15f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #11 0x5642aa2b72ec in main tests/unit/test-io-channel-socket.c:613:12
+    #12 0x7f0120d2d087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06)
+    #13 0x7f0120d2d14a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06)
+    #14 0x5642aa28cd04 in _start (tests/unit/test-io-channel-socket+0x69d04) (BuildId: eeaee2b8d62ce3aa77ab8b447916a40defd78dc6)
+
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior qapi/qapi-clone-visitor.c:188:5 
+
+(test program exited with status code -6)
+```
+
+And ``test-char`` aborts with:
+
+```
+ 99/103 qemu:unit / test-char                            ERROR            0.12s   killed by signal 6 SIGABRT
+>>> G_TEST_BUILDDIR=/tmp/qemu-ubsan/tests/unit ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MALLOC_PERTURB_=197 G_TEST_SRCDIR=tests/unit /tmp/qemu-ubsan/tests/unit/test-char --tap -k
+―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀  ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+stderr:
+qapi/qapi-clone-visitor.c:202:5: runtime error: call to function visit_type_InetSocketAddress_members through pointer to incorrect function type 'bool (*)(struct Visitor *, void *, struct Error **)'
+/tmp/qemu-ubsan/qapi/qapi-visit-sockets.c:65: note: visit_type_InetSocketAddress_members defined here
+    #0 0x55ee1d20ad60 in qapi_clone_members qapi/qapi-clone-visitor.c:202:5
+    #1 0x55ee1d24a993 in socket_address_flattenutil/qemu-sockets.c
+    #2 0x55ee1d1f26f6 in qmp_chardev_open_udp chardev/char-udp.c:199:34
+    #3 0x55ee1d1f5254 in qemu_char_open chardev/char.c:271:9
+    #4 0x55ee1d1f5254 in chardev_new chardev/char.c:968:5
+    #5 0x55ee1d1f45fd in qemu_chardev_new chardev/char.c:998:11
+    #6 0x55ee1d1f45fd in qemu_chr_new_from_opts chardev/char.c:657:11
+    #7 0x55ee1d1f49ac in qemu_chr_new_noreplay chardev/char.c:703:11
+    #8 0x55ee1d1f4aed in qemu_chr_new_permit_mux_mon chardev/char.c:731:11
+    #9 0x55ee1d1b45b8 in char_udp_test_internal tests/unit/test-char.c:590:15
+    #10 0x7f3dd421abbf  (/lib64/libglib-2.0.so.0+0x8bbbf) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #11 0x7f3dd421ab2f  (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #12 0x7f3dd421b0c9 in g_test_run_suite (/lib64/libglib-2.0.so.0+0x8c0c9) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #13 0x7f3dd421b15f in g_test_run (/lib64/libglib-2.0.so.0+0x8c15f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #14 0x55ee1d1af6bd in main tests/unit/test-char.c:1579:12
+    #15 0x7f3dd3c3d087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06)
+    #16 0x7f3dd3c3d14a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06)
+    #17 0x55ee1d184e34 in _start (/tmp/qemu-ubsan/tests/unit/test-char+0x78e34) (BuildId: afdf2ec9875e3011d3ff99174ec137dc79fff74e)
+
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior .qapi/qapi-clone-visitor.c:202:5 
+
+(test program exited with status code -6)
+```
+
+This undefined behavior could likely also trigger issues with CFI or certain compilers/architectures like emscripten, so we should try to avoid this. See also https://github.com/systemd/systemd/issues/29972 or https://github.com/python/cpython/issues/111178 for discussions in other projects, and https://gitlab.com/qemu-project/qemu/-/issues/2345 for a similar problem in the QEMU lockable code.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2347 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2347
new file mode 100644
index 00000000..3692cae9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2347
@@ -0,0 +1,9 @@
+Grab Input not working only for Windows key
+Description of problem:
+When Input Grabbing is enabled (as seen in the menu and the Qemu window title itself), a press on the Windows key will also send that press to the host system (Arch / KDE).
+
+I expected all inputs to be grabbed and stay within the VM.
+Steps to reproduce:
+1. Open a QEMU instance in a Arch / KDE host (not fullscreen)
+2. Focus the instance and enable Input Grabbing (Ctrl + Alt + G)
+3. Press the Windows key
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2348 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2348
new file mode 100644
index 00000000..d1710324
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2348
@@ -0,0 +1,7 @@
+Grabbing is not possible with menu-mode disabled
+Description of problem:
+When starting a Qemu and bringing it into Focus, I expected Ctrl + Alt + g to enable Input Grab mode. This does not occur when the menu-bar is hidden. It does occur when the menu-bar is visible.
+Steps to reproduce:
+1. Open a QEMU instance in a Arch / KDE host (not fullscreen)
+2. Focus the instance and attempt to enable Input Grabbing (Ctrl + Alt + G)
+3. Observe that Input Grab Mode is not toggled
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2349 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2349
new file mode 100644
index 00000000..844e3346
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2349
@@ -0,0 +1,12 @@
+keyboard (and mouse) not working in macOS guest
+Description of problem:
+keyboard not working after exiting EFI environment. it works in the OpenCore boot picker, but not in the recovery system. The mouse can work by forcing the PS2 controller and pause/resume the VM. See here for more details:
+https://github.com/utmapp/UTM/issues/5240#issuecomment-2112477131
+Tried adding ps2 kexts, but qemu USB keyboard, mouse and tablet do not attach to the AppleUSBEHCI bus. It works fine in Snow Leopard only as evident in the picture on the Github issue.
+Steps to reproduce:
+1.Install macOS guest Mavericks through Sierra using https://github.com/royalgraphx/LegacyOSXKVM/blob/main/info/CONVERSIONS.md
+2.https://github.com/kholia/OSX-KVM/blob/master/OpenCore-Boot-macOS.sh
+3.
+Additional information:
+[command.txt](/uploads/3af8e5476833a1f869debc4fbfe97e84/command.txt)
+[EFI.zip](/uploads/3f49054b496b19244ebb111cf07ed05a/EFI.zip)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/235 b/gitlab/issues_text/target_missing/host_missing/accel_missing/235
new file mode 100644
index 00000000..07a2b044
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/235
@@ -0,0 +1 @@
+atomic failure linking with --enable-sanitizers on 32-bit Linux hosts
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2350 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2350
new file mode 100644
index 00000000..538515f5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2350
@@ -0,0 +1,14 @@
+Incorrect RNG_CTRL and RNG_DATA_OUTPUT register offets for Aspeed AST2600 A3
+Description of problem:
+hw/misc/aspeed_scu.c has the following lines:
+
+#define AST2600_RNG_CTRL          TO_REG(0x524)
+#define AST2600_RNG_DATA          TO_REG(0x540)
+
+The Datasheet for the AST2600 A3 lists the offsets as 0x520 for RNG_CTRL and 0x524 for RNG_DATA.  I can confirm that these addresses are correct on the hardware.  I don't know if the offsets changed from a previous revision, but since qemu fills the SILICON_REV register with the AST2600_A3_SILICON_REV value for the AST2600, it makes sense to me that it would use the A3 register offsets.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2353 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2353
new file mode 100644
index 00000000..bc271aa4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2353
@@ -0,0 +1,56 @@
+linux-user: may map interpreter at address 0 with nonzero guest_base
+Description of problem:
+QEMU's user-mode emulation will, under certain conditions, map the ELF interpreter at guest address 0. This is not only a violation of Linux's policy never to map anything at the first page of any virtual address space, but also a cause of confusion (and segfaults) within certain libcs; though I only tested with musl. Musl [interprets a NULL base address](https://elixir.bootlin.com/musl/v1.2.4/source/ldso/dlstart.c#L105) as the dynamic linker being invoked directly, causing it to compute its base address incorrectly.
+
+The problem arises in `load_elf_image()`, which chooses a `load_addr` of 0 for the ELF interpreter (i.e. the musl dynamic loader). This is passed to `target_mmap()`. I do not know whether `target_mmap()` is meant to follow the POSIX rule that (in absence of `MAP_FIXED`) "All implementations interpret an *addr* value of 0 as granting the implementation complete freedom in selecting *pa*" or if 0 is requesting 0.
+
+QEMU's usermode mmap() implementation translates the guest address to a host address (this is effectively a no-op with `guest_base == 0`) and passes it along to the host Linux. This means that, when `guest_base == 0`, a NULL input address means "put it anywhere," but when `guest_base != 0`, NULL means "put it at (guest address) 0."
+Steps to reproduce:
+1. Download a rootfs of Alpine Linux AArch64.
+2. Install `gcc` (with `apk add gcc`) in the rootfs. `gcc` is not compiled as PIC, making QEMU use a nonzero `guest_base`.
+3. Attempt to run `gcc` within the rootfs via QEMU.
+Additional information:
+I am interested in submitting a MR that fixes this issue, but I do not know which of 4 possible solutions is preferred:
+
+1. Modify `load_elf_image()` to ensure that `load_addr` is never NULL.
+2. Modify `target_mmap()` so that NULLs are passed to the kernel as NULLs.
+3. Modify the guest<->host translation facilities (`g2h_untagged` et al) to translate NULL as NULL. Overwhelmingly, a NULL pointer semantically means "there is no pointer here" and not "a pointer to the zeroth address," so treating these as valid addresses in the translation functions is arguably going against the grain.
+4. When a nonzero `guest_base` is selected, reserve the first page of the guest VA space, so that the host kernel cannot accidentally put anything there.
+
+Here is my local patch that implements item 2 above, which indeed stops the segfaults for me:
+<details><summary>Patch</summary>
+
+```diff
+diff --git a/linux-user/mmap.c b/linux-user/mmap.c
+index be3b9a6..dad29ef 100644
+--- a/linux-user/mmap.c
++++ b/linux-user/mmap.c
+@@ -559,7 +559,7 @@ static abi_long mmap_h_eq_g(abi_ulong start, abi_ulong len,
+                             int host_prot, int flags, int page_flags,
+                             int fd, off_t offset)
+ {
+-    void *p, *want_p = g2h_untagged(start);
++    void *p, *want_p = start ? g2h_untagged(start) : 0;
+     abi_ulong last;
+ 
+     p = mmap(want_p, len, host_prot, flags, fd, offset);
+@@ -609,7 +609,7 @@ static abi_long mmap_h_lt_g(abi_ulong start, abi_ulong len, int host_prot,
+                             int mmap_flags, int page_flags, int fd,
+                             off_t offset, int host_page_size)
+ {
+-    void *p, *want_p = g2h_untagged(start);
++    void *p, *want_p = start ? g2h_untagged(start) : 0;
+     off_t fileend_adj = 0;
+     int flags = mmap_flags;
+     abi_ulong last, pass_last;
+@@ -739,7 +739,7 @@ static abi_long mmap_h_gt_g(abi_ulong start, abi_ulong len,
+                             int flags, int page_flags, int fd,
+                             off_t offset, int host_page_size)
+ {
+-    void *p, *want_p = g2h_untagged(start);
++    void *p, *want_p = start ? g2h_untagged(start) : 0;
+     off_t host_offset = offset & -host_page_size;
+     abi_ulong last, real_start, real_last;
+     bool misaligned_offset = false;
+```
+</details>
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2354 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2354
new file mode 100644
index 00000000..e932389c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2354
@@ -0,0 +1,7 @@
+Compile error with In function ‘vhost_scsi_set_workers’:
+Steps to reproduce:
+1. ./configure
+2. ./make
+Additional information:
+I suspect something is misconfigured on my system, but I followed the straighforward directions
+for building and I am running stock Debian 12.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2357 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2357
new file mode 100644
index 00000000..2ba37462
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2357
@@ -0,0 +1,18 @@
+assert in dwc2
+Description of problem:
+The following log reveals it:
+
+```
+ERROR:../hw/usb/hcd-dwc2.c:1131:dwc2_hsotg_read: code should not be reached
+Bail out! ERROR:../hw/usb/hcd-dwc2.c:1131:dwc2_hsotg_read: code should not be reached
+Aborted
+```
+Steps to reproduce:
+```
+cat << EOF | qemu-system-aarch64 -display \
+none -machine accel=qtest, -m 512M -machine raspi2b -m 1G -nodefaults \
+-usb -drive file=null-co://,if=none,format=raw,id=disk0 -device \
+usb-storage,port=1,drive=disk0 -qtest stdio
+readl 0x3f980dfb
+EOF
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2359 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2359
new file mode 100644
index 00000000..631d65f5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2359
@@ -0,0 +1,32 @@
+assert in virtio-iommu
+Description of problem:
+The following log reveals it:
+
+```
+qemu-system-x86_64: qemu/hw/virtio/virtio-iommu.c:821: void virtio_iommu_handle_command(VirtIODevice *, VirtQueue *): Assertion `sz == output_size' failed.
+Aborted
+```
+Steps to reproduce:
+```
+cat << EOF | \qemu-system-x86_64 \
+-display none -machine accel=qtest -m 512M -machine q35 -nodefaults \
+-device virtio-iommu -qtest stdio
+outl 0xcf8 0x80000804
+outw 0xcfc 0x06
+outl 0xcf8 0x80000820
+outl 0xcfc 0xe0004000
+write 0x10000e 0x1 0x01
+write 0xe0004020 0x4 0x00001000
+write 0xe0004028 0x4 0x00101000
+write 0xe000401c 0x1 0x01
+write 0x106000 0x1 0x05
+write 0x100001 0x1 0x60
+write 0x100002 0x1 0x10
+write 0x100009 0x1 0x04
+write 0x10000c 0x1 0x01
+write 0x100018 0x1 0x04
+write 0x10001c 0x1 0x02
+write 0x101003 0x1 0x01
+write 0xe0007001 0x1 0x00
+EOF
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2362 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2362
new file mode 100644
index 00000000..5c2d9f3d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2362
@@ -0,0 +1,63 @@
+short packets dropped by some network cards when using certain network backends
+Description of problem:
+Effectively a duplicate of https://gitlab.com/qemu-project/qemu/-/issues/2058 -- short ethernet packets (such as ARP packets) are discarded by various networking devices now.
+
+QEMU previously padded ethernet frames to 64 bytes when some network cards received them, but this was removed in various commits (140eae9c8f760e9260356fe9b56b802a02f0a9d2, c445f200ad241b443aa7a61a5381b26f56a18f0e, c58da33f2f8410b6f22cd1d33377dadf3a4d8867, 05db4476c5d25e437d807175de9f862bf5bf732c, 6d0d261dbfa6122e9b3bdcab7d934ca49f069c21, 63b901bfd30a0975bc326ba8527880fabac2e66, aee87b43fe2206acb8f5e334b42790df33a1cbad).
+
+969e50b61a285b0cc8dea6d4d2ade3f758d5ecc7 fixed SLIRP and TAP support, however the other various network backends (socket, dgram, vde, others) all have the same issue that some network cards will reject short packets.
+
+This does not fail on older versions of QEMU.
+Steps to reproduce:
+I have a python script that shows connecting two VMs of your choice using a socketpair connected to one of the affected NIC types (pcnet). If you start your OS (I used alpine linux as my test), and give each VM a unique IP address (eg, `ip addr add 192.168.0.1/24 dev eth0`), ping will fail to work. When you run tcpdump, you can see that the OS is sending out short ARP packets, but the other VM cannot see them.
+
+Using an older version of QEMU allows the ping to succeed.
+
+```python
+#!/usr/bin/env python3
+
+import argparse
+import shlex
+import socket
+import subprocess
+
+
+QEMU_PATH = "bin/qemu-system-x86_64"
+NIC = "pcnet"
+vnc = True
+
+if __name__ == "__main__":
+    parser = argparse.ArgumentParser()
+    parser.add_argument("qcow")
+    args = parser.parse_args()
+
+    p1, p2 = socket.socketpair()
+
+    qargs1 = [
+        QEMU_PATH, "-snapshot",
+        "-m", "2G",
+        "-drive", f"file={args.qcow}",
+        "-device", f"{NIC},netdev=n,mac=52:54:00:00:00:01",
+        "-netdev", f"socket,id=n,fd={p1.fileno()}"
+    ]
+    if vnc:
+        qargs1 += ["-display", "vnc=:2"]
+
+    print("+", shlex.join(qargs1))
+    proc1 = subprocess.Popen(qargs1, pass_fds=[p1.fileno()])
+
+    qargs2 = [
+        QEMU_PATH, "-snapshot",
+        "-m", "2G",
+        "-drive", f"file={args.qcow}",
+        "-device", f"{NIC},netdev=n,mac=52:54:00:00:00:02",
+        "-netdev", f"socket,id=n,fd={p2.fileno()}"
+    ]
+    if vnc:
+        qargs2 += ["-display", "vnc=:3"]
+
+    print("+", shlex.join(qargs2))
+    proc2 = subprocess.Popen(qargs2, pass_fds=[p2.fileno()])
+
+    proc1.wait()
+    proc2.wait()
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2363 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2363
new file mode 100644
index 00000000..2c9110df
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2363
@@ -0,0 +1 @@
+How can I enable MBI support in QEMU when running in KVM mode?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2364 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2364
new file mode 100644
index 00000000..89643774
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2364
@@ -0,0 +1 @@
+how to create two qemu instances on Windows11 so that they can access to each other in the same network?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2365 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2365
new file mode 100644
index 00000000..5ffcc640
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2365
@@ -0,0 +1,8 @@
+[Regression v8.2/v9.0+] stuck at SeaBIOS for >30s with 100% CPU (1T)
+Description of problem:
+starting our Linux direct-kernel-boot VMs with same args on different hosts/hardware will get stuck at SeaBIOS for 30-60s with 100% 1T CPU load starting with v8.2 and also in v9.0. v9.0.0 and v8.2.3 - v8.1.5 is OK. To be clear, everything seems to be fine after that, though I did not do any benchmarks to compare performance. It just delays (re)booting by almost 1 minute, which is a shame, because before that update/regression it was instant and our VMs only take 4s to boot, which is now more like 60s.
+Downgrading to v8.1 instantly fixes it, upgrading to v8.2/v9.0 instantly breaks it.
+Steps to reproduce:
+1. start VM with same args on different versions
+
+somehow if I save this bug with `/label ~"kind::Bug"` it disappears, so I'm unable to add/keep the label
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2366 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2366
new file mode 100644
index 00000000..7b692803
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2366
@@ -0,0 +1 @@
+qemu8.2  check test failed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2367 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2367
new file mode 100644
index 00000000..823bb9c4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2367
@@ -0,0 +1 @@
+qemu8.2 check test failed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2368 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2368
new file mode 100644
index 00000000..3b32fadd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2368
@@ -0,0 +1 @@
+Get get_maintainer.pl working with cover letter files
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2369 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2369
new file mode 100644
index 00000000..36571175
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2369
@@ -0,0 +1 @@
+qemu-img measure is incorrect when using discard-no-unref
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2370 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2370
new file mode 100644
index 00000000..970dafd2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2370
@@ -0,0 +1,11 @@
+[RFE] vde support on Windows
+Additional information:
+A vdeswitch approach can be yet another solution for #2364 .   
+On Windows, other methods to simultaneously bridge local qemu-VMs and allow bridge members to connect to the internet are troublesome. 
+Compared to MAC/Linux wherein who use kernel provided bridging. Windows users don't have it easy.  
+
+**Ref**: 
+1. qemu manual for ```netdev vde```  
+   https://qemu.readthedocs.io/_/downloads/en/v8.2.1/pdf/#page=75 
+2. virtualsquare/VDE-2 github bug Can't understand how to get it running on Windows10 64 bit ```#28```  
+   https://github.com/virtualsquare/vde-2/issues/28
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2378 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2378
new file mode 100644
index 00000000..47cb66ba
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2378
@@ -0,0 +1,28 @@
+make install (meson?) removes needed RPATH for libslirp, making build on CentOS 9 difficult
+Description of problem:
+make install appears to remove need RPATH attributes from the binary, making it difficult if not impossible to install Qemu 9.0.0 on a CentOS 9 machine.
+
+I'm trying to build Qemu 9.0.0 on a CentOS 9 Stream machine where I do not have root.
+The system ships with libslirp-4.4.0-7.el9.src.rpm which is libslirp 4.4.0, which is too old for Qemu.
+
+I checked out https://gitlab.freedesktop.org/slirp/libslirp.git which is 2 commits more recent than
+libslirp 4.8.0.  I installed this version in a separate directory.
+
+When I configure Qemu using PKG_CONFIG_PATH, it builds the correct executable with the correct RPATH.
+readelf -d shows:
+
+ 0x000000000000000f (RPATH)              Library rpath: [/web/courses/cs4284/pintostools/lib64]
+
+which is the correct directory where the proper version of libslirp is located.
+
+However, when I run "make install" the RPATH attribute is removed. Thus, Qemu resorts to the system version, which is version 4.4 (with which Qemu won't run.)
+
+Meson's propensity to strip necessary RPATHs appears to be well-known, see, for instance,
+
+https://github.com/mesonbuild/meson/issues/4027
+
+(There is a fix for at least some of the problems in 0.55.0 of Meson
+https://mesonbuild.com/Release-notes-for-0-55-0.html
+Qemu 9.0.0 appears to use Meson 1.2.3., but yet it still fails.)
+
+Work-around: don't use make install, copy it directly from the build directory to the destination directory.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2379 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2379
new file mode 100644
index 00000000..29707310
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2379
@@ -0,0 +1,126 @@
+virHashRemoveAll  remove all  jobs in priv->blockjobs but not set disk->priv->blockjob  is null for qemuDomainObjPrivateDataClear and qemuProcessStop
+Description of problem:
+it call virHashRemoveAll to remove all jobs in priv->blockjobs but the disk privateData blockjob is not null for qemuDomainObjPrivateDataClear and qemuProcessStop. when virHashRemoveAll is caled, accessing priv->blockjob cause segfault in others.
+Steps to reproduce:
+1. virsh blockcopy testvm vda /root/disk/centos7-copy.qcow2  --wait --verbose --pivot 
+ migrate disk of vm 
+2.  poweoff in guest vm
+3. libvirt core dump
+Additional information:
+--Type <RET> for more, q to quit, c to continue without paging--
+	Program terminated with signal SIGSEGV, Segmentation fault.
+	#0  qemuBlockJobUnregister (vm=0x7f823c045050, job=0x7f827c03ca90) at ../src/qemu/qemu_blockjob.c:211
+	211             if (job == diskPriv->blockjob) {
+	[Current thread is 1 (Thread 0x7f8283640640 (LWP 152))]
+	(gdb) bt
+	#0  qemuBlockJobUnregister (vm=0x7f823c045050, job=0x7f827c03ca90) at ../src/qemu/qemu_blockjob.c:211
+	#1  qemuBlockJobEventProcessConcluded (asyncJob=VIR_ASYNC_JOB_MIGRATION_OUT, vm=<optimized out>, driver=<optimized out>,
+		job=0x7f827c03ca90) at ../src/qemu/qemu_blockjob.c:1678
+	#2  qemuBlockJobEventProcess (asyncJob=VIR_ASYNC_JOB_MIGRATION_OUT, job=0x7f827c03ca90, vm=<optimized out>,
+		driver=<optimized out>) at ../src/qemu/qemu_blockjob.c:1703
+	#3  qemuBlockJobUpdate (vm=<optimized out>, job=0x7f827c03ca90, asyncJob=1) at ../src/qemu/qemu_blockjob.c:1756
+	#4  0x00007f828050c95f in qemuMigrationSrcNBDStorageCopyReady (vm=0x7f823c045050, asyncJob=VIR_ASYNC_JOB_MIGRATION_OUT)
+		at ../src/qemu/qemu_migration.c:605
+	#5  0x00007f8280518ca5 in qemuMigrationSrcNBDStorageCopy (flags=587, nbdURI=<optimized out>, tlsHostname=0x7f823c2b51d0 "",
+		tlsAlias=<optimized out>, dconn=0x7f823c014790, migrate_disks=0x7f827c006660, nmigrate_disks=2, speed=<optimized out>,
+		host=0x7f827c0156a0 "10.253.160.196", mig=0x7f827c027a30, vm=0x7f823c045050, driver=0x7f823c01ac40)
+		at ../src/qemu/qemu_migration.c:1202
+	#6  qemuMigrationSrcRun (driver=0x7f823c01ac40, vm=0x7f823c045050, persist_xml=<optimized out>, cookiein=<optimized out>,
+		cookieinlen=<optimized out>, cookieout=0x7f828363f500, cookieoutlen=0x7f828363f4d4, flags=587, resource=1024,
+		spec=0x7f828363f330, dconn=0x7f823c014790, graphicsuri=0x0, nmigrate_disks=2, migrate_disks=0x7f827c006660,
+		migParams=0x7f827c00d890, nbdURI=0x0) at ../src/qemu/qemu_migration.c:4167
+	#7  0x00007f828051a5dd in qemuMigrationSrcPerformNative (driver=0x7f823c01ac40, vm=0x7f823c045050,
+		persist_xml=0x7f827c020660 "<domain type=\"kvm\">\n  <name>default_vm-8altm</name>\n  <uuid>4a40fa64-fd9b-5078-8574-3ce5d0041d31</uuid>\n  <metadata>\n    <nodeagent xmlns=\"http://kubevirt.io/node-agent.io\">\n      <vmid>13fb0e90-2930-"...,
+		uri=<optimized out>,
+		cookiein=0x7f827c0519e0 "<qemu-migration>\n  <name>default_vm-8altm</name>\n  <uuid>4a40fa64-fd9b-5078-8574-3ce5d0041d31</uuid>\n  <hostname>ceasphere-node-1</hostname>\n  <hostuuid>5b0a0842-6535-27c1-b2e7-89c4ac4fd785</hostuuid>"...,
+		cookieinlen=876, cookieout=0x7f828363f500, cookieoutlen=0x7f828363f4d4, flags=587, resource=1024, dconn=0x7f823c014790,
+		graphicsuri=0x0, nmigrate_disks=2, migrate_disks=0x7f827c006660, migParams=0x7f827c00d890, nbdURI=0x0)
+		at ../src/qemu/qemu_migration.c:4506
+	#8  0x00007f828051c3e3 in qemuMigrationSrcPerformPeer2Peer3 (flags=<optimized out>, useParams=true, bandwidth=<optimized out>,
+		migParams=0x7f827c00d890, nbdURI=0x0, nbdPort=0, migrate_disks=0x7f827c006660, nmigrate_disks=<optimized out>,
+		listenAddress=<optimized out>, graphicsuri=0x0, uri=<optimized out>, dname=0x0,
+		persist_xml=0x7f827c020660 "<domain type=\"kvm\">\n  <name>default_vm-8altm</name>\n  <uuid>4a40fa64-fd9b-5078-8574-3ce5d0041d31</uuid>\n  <metadata>\n    <nodeagent xmlns=\"http://kubevirt.io/node-agent.io\">\n      <vmid>13fb0e90-2930-"...,
+		xmlin=<optimized out>, vm=0x7f823c045050,
+		dconnuri=0x7f827c00c2b0 "qemu+unix:///system?socket=/var/run/kubevirt/migrationproxy/13fb0e90-2930-4f0b-959a-cc40346e7d64-source.sock", dconn=0x7f823c014790, sconn=0x7f826c00e890, driver=0x7f823c01ac40) at ../src/qemu/qemu_migration.c:4925
+	#9  qemuMigrationSrcPerformPeer2Peer (v3proto=<synthetic pointer>, resource=<optimized out>, dname=0x0, flags=587,
+		migParams=0x7f827c00d890, nbdURI=0x0, nbdPort=0, migrate_disks=0x7f827c006660, nmigrate_disks=<optimized out>,
+		listenAddress=<optimized out>, graphicsuri=0x0, uri=<optimized out>,
+		dconnuri=0x7f827c00c2b0 "qemu+unix:///system?socket=/var/run/kubevirt/migrationproxy/13fb0e90-2930-4f0b-959a-cc40346e7d64-source.sock",
+	--Type <RET> for more, q to quit, c to continue without paging--
+		persist_xml=0x7f827c020660 "<domain type=\"kvm\">\n  <name>default_vm-8altm</name>\n  <uuid>4a40fa64-fd9b-5078-8574-3ce5d0041d31</uuid>\n  <metadata>\n    <nodeagent xmlns=\"http://kubevirt.io/node-agent.io\">\n      <vmid>13fb0e90-2930-"...,
+		xmlin=<optimized out>, vm=0x7f823c045050, sconn=0x7f826c00e890, driver=0x7f823c01ac40) at ../src/qemu/qemu_migration.c:5230
+	#10 qemuMigrationSrcPerformJob (driver=0x7f823c01ac40, conn=0x7f826c00e890, vm=0x7f823c045050, xmlin=<optimized out>,
+		persist_xml=0x7f827c020660 "<domain type=\"kvm\">\n  <name>default_vm-8altm</name>\n  <uuid>4a40fa64-fd9b-5078-8574-3ce5d0041d31</uuid>\n  <metadata>\n    <nodeagent xmlns=\"http://kubevirt.io/node-agent.io\">\n      <vmid>13fb0e90-2930-"...,
+		dconnuri=0x7f827c00c2b0 "qemu+unix:///system?socket=/var/run/kubevirt/migrationproxy/13fb0e90-2930-4f0b-959a-cc40346e7d64-source.sock", uri=<optimized out>, graphicsuri=<optimized out>, listenAddress=<optimized out>, nmigrate_disks=<optimized out>,
+		migrate_disks=<optimized out>, nbdPort=0, nbdURI=<optimized out>, migParams=<optimized out>, cookiein=<optimized out>,
+		cookieinlen=0, cookieout=<optimized out>, cookieoutlen=<optimized out>, flags=<optimized out>, dname=<optimized out>,
+		resource=<optimized out>, v3proto=<optimized out>) at ../src/qemu/qemu_migration.c:5307
+	#11 0x00007f828051cce7 in qemuMigrationSrcPerform (driver=0x7f823c01ac40, conn=0x7f826c00e890, vm=0x7f823c045050,
+		xmlin=0x7f827c01e630 "<domain type=\"kvm\">\n  <name>default_vm-8altm</name>\n  <uuid>4a40fa64-fd9b-5078-8574-3ce5d0041d31</uuid>\n  <metadata>\n    <nodeagent xmlns=\"http://kubevirt.io/node-agent.io\">\n      <vmid>13fb0e90-2930-"...,
+		persist_xml=0x7f827c020660 "<domain type=\"kvm\">\n  <name>default_vm-8altm</name>\n  <uuid>4a40fa64-fd9b-5078-8574-3ce5d0041d31</uuid>\n  <metadata>\n    <nodeagent xmlns=\"http://kubevirt.io/node-agent.io\">\n      <vmid>13fb0e90-2930-"...,
+		dconnuri=0x7f827c00c2b0 "qemu+unix:///system?socket=/var/run/kubevirt/migrationproxy/13fb0e90-2930-4f0b-959a-cc40346e7d64-source.sock", uri=0x556a1f856b20 "tcp://10.253.160.196:27939", graphicsuri=0x0, listenAddress=0x0, nmigrate_disks=2,
+		migrate_disks=0x7f827c006660, nbdPort=0, nbdURI=0x0, migParams=0x7f827c00d890, cookiein=0x0, cookieinlen=0,
+		cookieout=0x7f828363f8a8, cookieoutlen=0x7f828363f89c, flags=587, dname=0x0, resource=1024, v3proto=true)
+		at ../src/qemu/qemu_migration.c:5513
+	#12 0x00007f82804e34d0 in qemuDomainMigratePerform3Params (dom=0x7f8268002ee0,
+		dconnuri=0x7f827c00c2b0 "qemu+unix:///system?socket=/var/run/kubevirt/migrationproxy/13fb0e90-2930-4f0b-959a-cc40346e7d64-source.sock", params=0x7f827c01e380, nparams=7, cookiein=0x0, cookieinlen=0, cookieout=0x7f828363f8a8,
+		cookieoutlen=0x7f828363f89c, flags=587) at ../src/qemu/qemu_driver.c:11796
+	#13 0x00007f82853256d6 in virDomainMigratePerform3Params (domain=domain@entry=0x7f8268002ee0,
+		dconnuri=0x7f827c00c2b0 "qemu+unix:///system?socket=/var/run/kubevirt/migrationproxy/13fb0e90-2930-4f0b-959a-cc40346e7d64-source.sock", params=<optimized out>, nparams=7, cookiein=0x0, cookieinlen=0, cookieout=0x7f828363f8a8,
+		cookieoutlen=0x7f828363f89c, flags=587) at ../src/libvirt-domain.c:5165
+	#14 0x0000556a1f200f17 in remoteDispatchDomainMigratePerform3Params (server=<optimized out>, msg=0x556a1f86ba40,
+		ret=0x7f827c0197f0, args=0x7f827c019520, rerr=0x7f828363f9a0, client=<optimized out>)
+		at ../src/remote/remote_daemon_dispatch.c:5710
+	#15 remoteDispatchDomainMigratePerform3ParamsHelper (server=<optimized out>, client=<optimized out>, msg=0x556a1f86ba40,
+		rerr=0x7f828363f9a0, args=0x7f827c019520, ret=0x7f827c0197f0) at src/remote/remote_daemon_dispatch_stubs.h:8761
+	#16 0x00007f828522c676 in virNetServerProgramDispatchCall (msg=0x556a1f86ba40, client=0x556a1f85b510, server=0x556a1f84c080,
+		prog=0x556a1f850410) at ../src/rpc/virnetserverprogram.c:428
+	#17 virNetServerProgramDispatch (prog=0x556a1f850410, server=0x556a1f84c080, client=0x556a1f85b510, msg=0x556a1f86ba40)
+		at ../src/rpc/virnetserverprogram.c:302
+	--Type <RET> for more, q to quit, c to continue without paging--
+	#18 0x00007f82852331d8 in virNetServerProcessMsg (msg=<optimized out>, prog=<optimized out>, client=<optimized out>,
+		srv=0x556a1f84c080) at ../src/rpc/virnetserver.c:140
+	#19 virNetServerHandleJob (jobOpaque=0x556a1f861f90, opaque=0x556a1f84c080) at ../src/rpc/virnetserver.c:160
+	#20 0x00007f8285170653 in virThreadPoolWorker (opaque=<optimized out>) at ../src/util/virthreadpool.c:164
+	#21 0x00007f828516fc09 in virThreadHelper (data=<optimized out>) at ../src/util/virthread.c:256
+	#22 0x00007f8284b10802 in start_thread () from /lib64/libc.so.6
+	#23 0x00007f8284ab0450 in clone3 () from /lib64/libc.so.6
+
+
+	(gdb) p job
+	$1 = (qemuBlockJobData *) 0x7f827c03ca90
+	(gdb) p *job
+	$2 = {parent = {parent_instance = {g_type_instance = {g_class = 0x7f827c00dc90}, ref_count = 1, qdata = 0x0}},
+	  name = 0x7f827c038cd0 "drive-ua-vol-vm-8altm", disk = 0x7f823c0475c0, chain = 0x556a1f8548f0, mirrorChain = 0x0,
+	  jobflags = 0, jobflagsmissing = false, data = {pull = {base = 0x0}, commit = {topparent = 0x0, top = 0x0, base = 0x0,
+		  deleteCommittedImages = false}, create = {storage = false, src = 0x0}, copy = {shallownew = false}, backup = {
+		  store = 0x0, bitmap = 0x0}}, type = 2, state = 5, errmsg = 0x0, synchronous = true, newstate = 6, brokentype = 0,
+	  invalidData = false, reconnected = false}
+	(gdb) p *job->disk
+	$3 = {src = 0x7f823c047, privateData = 0xffe8eec3390edb93, device = VIR_DOMAIN_DISK_DEVICE_DISK,
+	  bus = VIR_DOMAIN_DISK_BUS_VIRTIO, dst = 0x7f823c047300 "\327_'ą\177", tray_status = VIR_DOMAIN_DISK_TRAY_CLOSED,
+	  removable = VIR_TRISTATE_SWITCH_ABSENT, rotation_rate = 0, mirror = 0x0, mirrorState = 0, mirrorJob = 0, geometry = {
+		cylinders = 0, heads = 0, sectors = 0, trans = VIR_DOMAIN_DISK_TRANS_DEFAULT}, blockio = {logical_block_size = 0,
+		physical_block_size = 0}, blkdeviotune = {total_bytes_sec = 0, read_bytes_sec = 0, write_bytes_sec = 0,
+		total_iops_sec = 0, read_iops_sec = 0, write_iops_sec = 0, total_bytes_sec_max = 0, read_bytes_sec_max = 0,
+		write_bytes_sec_max = 0, total_iops_sec_max = 0, read_iops_sec_max = 0, write_iops_sec_max = 0, size_iops_sec = 0,
+		group_name = 0x0, total_bytes_sec_max_length = 0, read_bytes_sec_max_length = 0, write_bytes_sec_max_length = 0,
+		total_iops_sec_max_length = 0, read_iops_sec_max_length = 0, write_iops_sec_max_length = 0},
+	  driverName = 0x7f823c047270 "\267\262'ą\177", serial = 0x0, wwn = 0x0, vendor = 0x0, product = 0x0,
+	  cachemode = VIR_DOMAIN_DISK_CACHE_DISABLE, error_policy = VIR_DOMAIN_DISK_ERROR_POLICY_RETRY,
+	  rerror_policy = VIR_DOMAIN_DISK_ERROR_POLICY_DEFAULT, retry_interval = 1000, retry_timeout = 0,
+	  iomode = VIR_DOMAIN_DISK_IO_NATIVE, ioeventfd = VIR_TRISTATE_SWITCH_ABSENT, event_idx = VIR_TRISTATE_SWITCH_ABSENT,
+	  copy_on_read = VIR_TRISTATE_SWITCH_ABSENT, snapshot = VIR_DOMAIN_SNAPSHOT_LOCATION_DEFAULT,
+	  startupPolicy = VIR_DOMAIN_STARTUP_POLICY_DEFAULT, transient = false, transientShareBacking = VIR_TRISTATE_BOOL_ABSENT,
+	  info = {alias = 0x0, type = 0, addr = {pci = {domain = 0, bus = 0, slot = 0, function = 0,
+			multi = VIR_TRISTATE_SWITCH_ABSENT, extFlags = 0, zpci = {uid = {value = 0, isSet = false}, fid = {value = 0,
+				isSet = false}}}, drive = {controller = 0, bus = 0, target = 0, unit = 0, diskbus = 0}, vioserial = {
+			controller = 0, bus = 0, port = 0}, ccid = {controller = 0, slot = 0}, usb = {bus = 0, port = {0, 0, 0, 0}},
+		  spaprvio = {reg = 0, has_reg = false}, ccw = {cssid = 0, ssid = 0, devno = 0, assigned = false}, isa = {iobase = 0,
+			irq = 0}, dimm = {slot = 0, base = 0}}, mastertype = 0, master = {usb = {startport = 0}},
+		romenabled = VIR_TRISTATE_BOOL_ABSENT, rombar = VIR_TRISTATE_SWITCH_ABSENT, romfile = 0x0, bootIndex = 1,
+		effectiveBootIndex = 1, acpiIndex = 0, pciConnectFlags = 9, pciAddrExtFlags = 0, loadparm = 0x0, isolationGroup = 0,
+		isolationGroupLocked = false}, rawio = VIR_TRISTATE_BOOL_ABSENT, sgio = VIR_DOMAIN_DEVICE_SGIO_DEFAULT,
+	  discard = VIR_DOMAIN_DISK_DISCARD_DEFAULT, iothread = 1, detect_zeroes = VIR_DOMAIN_DISK_DETECT_ZEROES_DEFAULT,
+	  domain_name = 0x0, queues = 0, queue_size = 0, model = VIR_DOMAIN_DISK_MODEL_DEFAULT, virtio = 0x7f823c047170,
+		  diskElementAuth = false, diskElementEnc = false}
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/238 b/gitlab/issues_text/target_missing/host_missing/accel_missing/238
new file mode 100644
index 00000000..f7877552
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/238
@@ -0,0 +1 @@
+capstone link failure building linux-user static
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2384 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2384
new file mode 100644
index 00000000..b013dd45
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2384
@@ -0,0 +1,26 @@
+Crash on QEMU 7.2.11 with imx6ul arm cpu cortex-a7 when trying to mount rootfs
+Description of problem:
+trying to run qemu 7.2.11 for NXP mcimx6ul-evk machine, We get a kernel panic trying to mount the rootfs.
+...
+[    7.401206]   No soundcards found.
+[    7.500010] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
+[    7.504607] VFS: Mounted root (vfat filesystem) on device 179:1.
+[    7.511987] devtmpfs: error mounting -2
+[    7.612562] Freeing unused kernel image (initmem) memory: 1024K
+[    7.638370] Run /sbin/init as init process
+[    7.638829]   with arguments:
+[    7.639016]     /sbin/init
+[    7.639247]     earlyprintk
+[    7.639429]     noresume
+...
+[    7.657347] Kernel panic - not syncing: No working init found.
+
+The full log is attached.[qemu_imx6ul_kernel_panic_info.txt](/uploads/c4075a3de7894c18050bf53c32bb18a7/qemu_imx6ul_kernel_panic_info.txt)
+Steps to reproduce:
+1. download and build qemu 7.2.11
+2. download LF_v6.1.55-2.2.1_images_IMX6UL7D.zip from NXP containing kernel, dtb, rootfs, ...etc binaries 
+3. To use diskimage as ‘sd’ card , we need to shrink .wic image we got from NXP to fit in 4GB : 
+./qemu-img resize --shrink imx-image-full.wic 4G
+4. invoke the command to run qemu described above.
+Additional information:
+Any help would be appreciated, if it's not the right forum please advise, thank you.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2386 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2386
new file mode 100644
index 00000000..562ade4a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2386
@@ -0,0 +1,43 @@
+RISCV - Incorrect behaviour of the SLL instruction
+Description of problem:
+`SLL` (and probably other similar instructions) produce incorrect results. To quote the [RISCV ISA manual](https://drive.google.com/file/d/1uviu1nH-tScFfgrovvFCrj7Omv8tFtkp/view):
+
+> SLL, SRL, and SRA perform logical left, logical right, and arithmetic right shifts on the value in register
+rs1 by the shift amount held in the lower 5 bits of register rs2.
+
+This instruction should perform a logical shift left by the shift amount from the lower 5 bits held in the third operand, however, it doesn't seem to be the case. As can be seen from the result of the snippet below: `55c3585000000000`, it seems that it calculates the correct value, but then shifts it by another 32 bits to the left:
+
+```python
+correct_shift_res = (0xDB4D6868655C3585 << (0x69C99AB9B9401024 & 0b11111)) & (2 ** 64 - 1)
+incorrect_qemu_produced = (correct_shift_res << 32) & (2 ** 64 - 1)
+```
+Steps to reproduce:
+1. Compile the attached source file: `riscv64-linux-gnu-gcc -static repro.c -o ./repro.elf`
+
+```c
+#include <stdint.h>
+#include <stdio.h>
+
+int main() {
+  uint64_t a = 0x69C99AB9B9401024;
+  uint64_t b = 0xDB4D6868655C3585;
+  uint64_t c;
+
+  asm volatile("sll %0, %1, %2" : "=r"(c) : "r"(b), "r"(a));
+
+  printf("s8      : %lx\n", c);
+  printf("expected: %lx\n", 0xb4d6868655c35850);
+
+  return 0;
+}
+```
+
+2. Run qemu: `./qemu-riscv64 ./repro.elf`
+3. You will see the output and what the result of the computation should really be:
+
+```
+s8      : 55c3585000000000
+expected: b4d6868655c35850
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2387 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2387
new file mode 100644
index 00000000..76e6c0b0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2387
@@ -0,0 +1,11 @@
+Segmentation fault on booting from ISO when using GTK display with OpenGL enabled
+Description of problem:
+When trying to boot from the ISO mounted in the `-cdrom` argument, using a GTK display with OpenGL enabled gives a segmentation fault error. If using SDL instead, the whole application kinda freezes most of the times. I managed to get it working once, but I don't know how or why, seemed completely random. After installing it, I can boot from the disk normally with no errors.
+Steps to reproduce:
+1. Install QEMU for MSYS2 / UCRT64 as described [here](https://www.qemu.org/download/#windows)
+2. Download ISO from EndeavourOS website
+3. Run `qemu-img create -f qcow2 EndeavourOS.qcow2 64G` to create a disk file
+4. Run the script as described above in a `.sh` file
+5. See error
+Additional information:
+I have multiple VMs, included but not limited to Manjaro, Pop!\_OS and Debian, none of them gives this specific error. I also usually avoid SDL because I had multiple issues with the application window completely freezing in the past with "Not responding", and that does not happen with GTK.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2388 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2388
new file mode 100644
index 00000000..acc7675c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2388
@@ -0,0 +1,17 @@
+NVMe SQ processing gets stuck when IO queue size is small (for example 4)
+Steps to reproduce:
+1. Get OSv repo with the NVMe driver and build OSv with the 'Hello World' example:
+```
+git clone https://github.com/wkozaczuk/osv.git
+cd osv
+git checkout nvme_refined
+git submodule update --init --recursive 
+./scripts/setup.py
+./scripts/build image=native-example fs=zfs -j$(nproc)
+```
+2. Run OSv with NVme on and point to your version of QEMU built with tracing enabled:
+```
+./scripts/run.py --qemu-path /home/wkozaczuk/projects/qemu/build/qemu-system-x86_64 --nics=0 --nvme -c 1  --pass-arg "--trace pci_nvme_*"
+```
+Additional information:
+I am adding both full QEMU logs with NVMe tracing enabled and diff of my changes to QEMU code to add extra logging.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2389 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2389
new file mode 100644
index 00000000..d7427f6a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2389
@@ -0,0 +1,34 @@
+Mutex initialization assertion failure due to incompatibility with macOS setrlimit() syscall
+Description of problem:
+Running the command with with any set of arguments instantly crashes with the following error message:
+
+```
+Assertion failed: (mutex->initialized), function qemu_mutex_lock_impl, file ../util/qemu-thread-posix.c, line 92.
+zsh: abort      ./qemu-system-x86_64
+```
+Steps to reproduce:
+As per instructions for building from scratch:
+
+1. `mkdir build && cd build`
+2. `../configure --prefix=$PWD/.. --audio-drv-list=sdl --disable-cocoa --enable-sdl --enable-sdl-image`
+3. `make && make install`
+4. `cd ../bin`
+5. `./qemu-system-x86_64`
+Additional information:
+The issue is coming from the `os_setup_limits()` function in `os-posix.c`. As it turns out, the `setrlimit()` syscall behaves subtly different on macOS than on Linux systems, and the macOS man pages explicitly forbade the code on line 273.
+
+Line 273 from `os-posix.c`:
+
+```
+nofile.rlim_cur = nofile.rlim_max;
+```
+
+macOS `setrlimit()` man page:
+
+```
+COMPATIBILITY
+     setrlimit() now returns with errno set to EINVAL in places that historically succeeded.  It no longer accepts "rlim_cur = RLIM_INFINITY" for
+     RLIM_NOFILE.  Use "rlim_cur = min(OPEN_MAX, rlim_max)".
+```
+
+The man page thankfully gives us the [patch](/uploads/e7c8c6e3b5620c3b1ee34e89661097f3/qemu.patch)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2390 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2390
new file mode 100644
index 00000000..ebd1c6ea
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2390
@@ -0,0 +1,63 @@
+linux-user: Qemu handles `getsockopt` with NULL `optval` incorrectly
+Description of problem:
+In short call to `getsockopt(_, SOL_TCP, TCP_KEEPIDLE, NULL, _)` behaves differently on RISC-V Qemu than on x64 Linux. 
+On Linux syscall returns 0, but on Qemu it fails with `"Bad address"`.
+Apparently Qemu `getsockopt` implementation is more conservative about NULL `optval` argument than kernel implementation. However man permits passing NULL [link](https://man7.org/linux/man-pages/man2/setsockopt.2.html):
+
+>  For getsockopt(), optlen is a value-result argument, initially
+       containing the size of the buffer pointed to by optval, and
+       modified on return to indicate the actual size of the value
+       returned.  **If no option value is to be supplied** or returned,
+       **optval may be NULL.**"
+
+For me it sounds like accepting NULL without error (and x64 confirms that interpretation).
+Steps to reproduce:
+1. Use below toy program `getsockopt.c` and compile it without optimizations like:
+```
+    gcc -Wall -W -std=gnu11 -pedantic  getsockopt.c -o getsockopt
+```
+
+```
+#include <stdlib.h>
+#include <unistd.h>
+#include <errno.h>
+#include <stdio.h>
+#include <netinet/in.h>
+#include <sys/socket.h>
+#include <netinet/tcp.h>
+
+static void fail_on_error(int error, const char *msg) {
+    if (error < 0) {
+        perror(msg);
+        exit(errno);
+    }
+}
+
+int main(int argc, char **argv) {
+     int socketfd = socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP);
+     fail_on_error(socketfd, "socket error");
+     uint8_t *option_value = NULL;
+     int32_t len = 0;
+     int32_t *option_len = &len;
+     socklen_t opt_len = (socklen_t)*option_len;
+     int status = getsockopt(socketfd, SOL_TCP, TCP_KEEPIDLE, option_value, &opt_len);
+     fail_on_error(status, "getsockopt error");
+     return 0;
+}
+```
+
+
+2. Run program on Qemu and compare output with output from x64 build. In my case it looks like:
+```
+root@57646f544f3a:/runtime/programs# ./getsockopt-x64
+root@57646f544f3a:/runtime/programs# ./getsockopt-riscv
+getsockopt error: Bad address
+```
+Additional information:
+I don't think issue is platform specific assuming Qemu `getsockopt` implementation that is actually running is here:
+[link](https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2522)
+
+Looking at sources, I'm not sure why Qemu can't simply forward everything to kernel space 
+instead doing extra sanity checks together with `optval` dereference attempt that eventually fails in one of `put_user*_` function: [link](https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2753) 
+
+Anyway, I think that interpretation of man quote is rather straightforward and Qemu `getsockopt` implementation should follow it.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2391 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2391
new file mode 100644
index 00000000..8881126f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2391
@@ -0,0 +1,16 @@
+virglrenderer related -device help failure
+Description of problem:
+When QEMU is compiled against a recent `virglrenderer` version, running the above command fails like this:
+```
+$ qemu-system-x86_64 -device virtio-vga-gl,help
+qemu-system-x86_64: -device virtio-vga-gl,help: failed to open module: /usr/bin/../lib/qemu/hw-display-virtio-gpu-gl.so: undefined symbol: qemu_egl_display
+```
+Steps to reproduce:
+1. build QEMU against latest `virglrenderer` (1.0.1)
+2. run the above command
+Additional information:
+The cause appears to be related to e8a2db94 cc @marcandre.lureau-rh
+
+Arch only recently updated to latest `virglrenderer` which has exposed the issue.
+
+Note that the device seems to function correctly in normal usage when combined with -display e.g. `-device virtio-vga-gl -display gtk,gl=on`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2392 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2392
new file mode 100644
index 00000000..32d31fb9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2392
@@ -0,0 +1 @@
+Ability to use KVM on Windows
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2395 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2395
new file mode 100644
index 00000000..14a73a3d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2395
@@ -0,0 +1,60 @@
+qemu-system-x86_64: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed when paused vm migrating (with shared storage) from dest  to src host
+Description of problem:
+We are doing migration tests with share storage (nfs) as follows:
+First, we pause the virtual machine using the 'virsh suspend'command, then migrate the virtual machine to the destination host by 'virsh migrate' command, and there is no problem. After the migration is complete, the virtual machine remains paused on the destination host. However, when we migrate the virtual machine back to the original host, an assertion error is triggered on the current host（dest host）:
+
+```
+705 qemu-system-x86_64: ../block.c:6748: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed.
+706 2024-06-17 11:15:59.972+0000: shutting down, reason=crashed
+```
+
+and virsh migrate commant return error:
+```
+**virsh migrate test qemu+tcp://host_ip/system tcp://host_ip --live --verbose --unsafe
+Migration: [ 98 %]error: operation failed: domain is not running**
+```
+Steps to reproduce:
+1. We create an vm with shareable storage and then paused vm in source host:
+  ```
+   virsh create test.xml    running 
+   virsh suspend test       paused
+  ```
+2. Migrate vm to the destination host:
+   ``virsh migrate test qemu+tcp://dest_ip/system tcp://dest_ip --live --verbose --unsafe``
+3. In destination host，vm is paused.
+4. Migrate vm back to the source host，and then migration failed and assert error in qemu log in destination host:
+   ```
+   virsh migrate test qemu+tcp://host_ip/system tcp://host_ip --live --verbose --unsafe
+   Migration: [ 98 %]error: operation failed: domain is not running
+   ```
+   ```
+    705 qemu-system-x86_64: ../block.c:6748: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & 
+        BDRV_O_INACTIVE)' failed.
+    706 2024-06-17 11:15:59.972+0000: shutting down, reason=crashed
+   ```
+Additional information:
+1) src -----> dest
+ ```
+migration_thread() 
+    migration_completion
+      global_state_store()
+      vm_stop_force_state(RUN_STATE_FINISH_MIGRATE)
+      qemu_savevm_state_complete_precopy_nop_iterable() 
+          bdrv_inactivate_all () 
+            bdrv_inactivate_recurse() 
+             bs->open_flags |= BDRV_O_INACTIVE; (BDRV_O_INACTIVE=0x0800)
+```
+
+2) dest -----> src
+```
+migration_thread() 
+  qemu_savevm_state_complete_precopy_non_iterable() 
+    bdrv_inactivate_all () 
+      bdrv_inactivate_recurse() 
+        assert(!(bs->open_flags & BDRV_O_INACTIVE));  Assert and Crash
+```
+
+
+I'm not sure how to address this issue. If QEMU does not support such a migration, a gentler way would be to directly report an error and exit, just like what did in migrate_prepare function， instead of crash qemu. 
+
+If you have any ideas, please let me know, thanks.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2396 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2396
new file mode 100644
index 00000000..869b6862
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2396
@@ -0,0 +1 @@
+Exception in interrupt handling after upgrading from 8.0 to 9.0
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2397 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2397
new file mode 100644
index 00000000..e9e2364f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2397
@@ -0,0 +1 @@
+Restrict qemu_file_set_error_obj() to migration/
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2398 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2398
new file mode 100644
index 00000000..845e8c5c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2398
@@ -0,0 +1,62 @@
+qemu stalls when taking LUKS encrypted snapshot
+Description of problem:
+We have been dealing with an issue recently, where qemu occasionally stalls when taking LUKS encrypted snapshots. We were able to take several core dumps (one example below) when the issue was happening and, upon analyzing those, we found out that the issue is that the function [qcrypto_pbkdf2_count_iters](https://github.com/qemu/qemu/blob/master/crypto/pbkdf.c#L88) reaches an iteration number high enough that the algorithm takes a long time to finish.
+
+Upon investigation, we were able to see that this is happening because [start_ms and end_ms](https://github.com/qemu/qemu/blob/master/crypto/pbkdf.c#L115) have the same value, giving a delta of zero, causing the number of iterations to always increase.
+
+Here are the important parts of the coredump:
+
+```
+(gdb) bt
+#0  0x00007fb00aba5489 in _gcry_sha256_transform_amd64_avx2 () at ../../cipher/sha256-avx2-bmi2-amd64.S:346
+#1  0x00007fb00aba3000 in sha256_final (context=0x55ab875d5028) at ../../cipher/sha256.c:591
+#2  0x00007fb00ab19dea in md_final (a=0x55ab82e1bf50) at ../../cipher/md.c:800
+#3  0x00007fb00ab19f89 in md_final (a=a@entry=0x55ab82e1bf50) at ../../cipher/md.c:1003
+#4  _gcry_md_ctl (hd=hd@entry=0x55ab82e1bf50, buflen=0, buffer=0x0, cmd=5) at ../../cipher/md.c:1012
+#5  0x00007fb00ab1a4d0 in _gcry_md_ctl (buflen=0, buffer=0x0, cmd=5, hd=0x55ab82e1bf50) at ../../cipher/md.c:1106
+#6  _gcry_md_read (hd=0x55ab82e1bf50, algo=algo@entry=0) at ../../cipher/md.c:1110
+#7  0x00007fb00ab1d9ef in _gcry_kdf_pkdf2 (passphrase=passphrase@entry=0x55ab8177f040, passphraselen=passphraselen@entry=64, hashalgo=hashalgo@entry=8, salt=salt@entry=0x55ab8397a1d4, saltlen=saltlen@entry=32, 
+    iterations=iterations@entry=32768000000, keysize=20, keybuffer=0x55ab817693c0) at ../../cipher/kdf.c:213
+#8  0x00007fb00ab1de3c in _gcry_kdf_pkdf2 (keybuffer=0x55ab817693c0, keysize=20, iterations=32768000000, saltlen=32, salt=0x55ab8397a1d4, hashalgo=8, passphraselen=64, passphrase=0x55ab8177f040) at ../../cipher/kdf.c:144
+#9  _gcry_kdf_derive (passphrase=0x55ab8177f040, passphraselen=64, algo=34, subalgo=8, salt=0x55ab8397a1d4, saltlen=32, iterations=32768000000, keysize=20, keybuffer=0x55ab817693c0) at ../../cipher/kdf.c:286
+#10 0x00007fb00ab02299 in gcry_kdf_derive (passphrase=passphrase@entry=0x55ab8177f040, passphraselen=passphraselen@entry=64, algo=algo@entry=34, hashalgo=hashalgo@entry=8, salt=salt@entry=0x55ab8397a1d4, saltlen=saltlen@entry=32, 
+    iterations=32768000000, keysize=20, keybuffer=0x55ab817693c0) at ../../src/visibility.c:1337
+#11 0x000055ab7f80ff83 in qcrypto_pbkdf2 (hash=hash@entry=QCRYPTO_HASH_ALG_SHA256, key=key@entry=0x55ab8177f040 "\b@\327\061\177F\f\345\200Bw#", nkey=nkey@entry=64, 
+    salt=salt@entry=0x55ab8397a1d4 "\"ͧ\322+\201!\375\177\020\037\252Hg$\271\021\340\343T\021OKָ\234m\304\066g\024\276", nsalt=nsalt@entry=32, iterations=iterations@entry=32768000000, 
+    out=0x55ab817693c0 "C[\210\003\332\017b\350\f\257\377UP\257\262\275\033\v\034(", nout=20, errp=0x7fa7565e5df8) at ./crypto/pbkdf-gcrypt.c:75
+#12 0x000055ab7f80fe66 in qcrypto_pbkdf2_count_iters (hash=hash@entry=QCRYPTO_HASH_ALG_SHA256, key=key@entry=0x55ab8177f040 "\b@\327\061\177F\f\345\200Bw#", nkey=64, 
+    salt=salt@entry=0x55ab8397a1d4 "\"ͧ\322+\201!\375\177\020\037\252Hg$\271\021\340\343T\021OKָ\234m\304\066g\024\276", nsalt=nsalt@entry=32, nout=nout@entry=20, errp=0x7fa7565e5df8) at ./crypto/pbkdf.c:80
+#13 0x000055ab7f812930 in qcrypto_block_luks_create (block=0x55ab82944540, options=<optimized out>, optprefix=<optimized out>, initfunc=0x55ab7f7abad0 <qcow2_crypto_hdr_init_func>, writefunc=0x55ab7f7ac040 <qcow2_crypto_hdr_write_func>, 
+    opaque=0x55ab83a32290, errp=0x55ab823873d0) at ./crypto/block-luks.c:1362
+#14 0x000055ab7f810d80 in qcrypto_block_create (options=options@entry=0x55ab818e1f40, optprefix=optprefix@entry=0x55ab7f99912b "encrypt.", initfunc=initfunc@entry=0x55ab7f7abad0 <qcow2_crypto_hdr_init_func>, 
+    writefunc=writefunc@entry=0x55ab7f7ac040 <qcow2_crypto_hdr_write_func>, opaque=opaque@entry=0x55ab83a32290, errp=errp@entry=0x55ab823873d0) at ./crypto/block.c:106
+#15 0x000055ab7f7b0f79 in qcow2_set_up_encryption (errp=0x55ab823873d0, cryptoopts=0x55ab818e1f40, bs=0x55ab83a32290) at ./block/qcow2.c:2996
+#16 qcow2_co_create (create_options=<optimized out>, errp=0x55ab823873d0) at ./block/qcow2.c:3529
+#17 0x000055ab7f7e2fca in blockdev_create_run (job=0x55ab82387350, errp=0x55ab823873d0) at ./block/create.c:46
+#18 0x000055ab7f79cf6f in job_co_entry (opaque=0x55ab82387350) at ./job.c:878
+#19 0x000055ab7f87e09c in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at ./util/coroutine-ucontext.c:115
+#20 0x00007fb009a14680 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
+#21 0x00007ffd40716530 in ?? ()
+#22 0x0000000000000000 in ?? ()
+(gdb) frame 12
+#12 0x000055ab7f80fe66 in qcrypto_pbkdf2_count_iters (hash=hash@entry=QCRYPTO_HASH_ALG_SHA256, key=key@entry=0x55ab8177f040 "\b@\327\061\177F\f\345\200Bw#", nkey=64, 
+    salt=salt@entry=0x55ab8397a1d4 "\"ͧ\322+\201!\375\177\020\037\252Hg$\271\021\340\343T\021OKָ\234m\304\066g\024\276", nsalt=nsalt@entry=32, nout=nout@entry=20, errp=0x7fa7565e5df8) at ./crypto/pbkdf.c:80
+80	        if (qcrypto_pbkdf2(hash,
+(gdb) info locals
+ret = 18446744073709551615
+out = 0x55ab817693c0 "C[\210\003\332\017b\350\f\257\377UP\257\262\275\033\v\034("
+iterations = 32768000000
+delta_ms = <optimized out>
+start_ms = 35357141
+end_ms = 35357141
+```
+
+We did some investigation on the getrusage system call, which is [used to calculate start_ms and end_ms](https://github.com/qemu/qemu/blob/master/crypto/pbkdf.c#L72) and found some patches which indicate that it might not be that accurate:
+
+https://github.com/torvalds/linux/commit/3dc167ba5729ddd2d8e3fa1841653792c295d3f1
+
+https://lore.kernel.org/lkml/20221226031010.4079885-1-maxing.lan@bytedance.com/t/#m1c7f2fdc0ea742776a70fd1aa2a2e414c437f534
+
+So far we have only seen this with Windows guests, but it might be a red herring. It happens maybe once a month and we were unable to get a reproducer.
+
+I'm open to proposing a fix for this, but how could we measure this without relying on getrusage which is causing us trouble? Any other suggestions or tips on this?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2399 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2399
new file mode 100644
index 00000000..24014b80
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2399
@@ -0,0 +1,27 @@
+division by zero in ide
+Description of problem:
+The following log reveals it:
+
+```
+../hw/ide/core.c:659:26: runtime error: division by zero
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/ide/core.c:659:26 in AddressSanitizer:DEADLYSIGNAL ================================================================= 
+==4104568==ERROR：AddressSanitizer：FPE on unknown address 0x559d996a7ec3 (pc 0x559d996a7ec3 bp 0x7ffdcf109da0 sp 0x7ffdcf109a40 T0) 
+#0 0x559d996a7ec3 in ide_set_sector qemu/hw/ide/core.c:659:26 
+#1 0x559d996c8dee in ide_sector_read_cb qemu/hw/ide/core.c:786:5 
+#2 0x559d996aa50a in ide_buffered_readv_cb qemu/hw/ide/core.c:684:9 
+#3 0x559d9b499289 in blk_aio_complete qemu/block/block-backend.c:1555:9 
+#4 0x559d9b4891af in blk_aio_complete_bh qemu/block/block-backend.c:1565:5 
+#5 0x559d9bbef6b1 in aio_bh_call qemu/util/async.c:171:5 
+#6 0x559d9bbf058c in aio_bh_poll qemu/util/async.c:218:13 
+#7 0x559d9bb58a28 in aio_dispatch qemu/util/aio-posix.c:423:5 
+#8 0x559d9bbf69ce in aio_ctx_dispatch qemu/util/async.c:360:5 
+#9 0x7f51fbc77d3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0) +0x55d3a.+0x55d3a) 
+#10 0x559d9bbfa229 in glib_pollfds_poll qemu/util/main-loop.c:287:9 
+#11 0x559d9bbf8b63 in os_host_main_loop_wait qemu/util/main-loop.c:310:5 
+#12 0x559d9bbf872c in main_loop_wait qemu/util/main-loop.c:589:11 
+#13 0x559d9a2640e7 in qemu_main_loop qemu/system/runstate.c:796:9 
+#14 0x559d9b1dcaec in qemu_default_main qemu/system/main.c:37:14 
+#15 0x559d9b1dcb37 in main qemu/system/main.c:48:12 
+#16 0x7f51fb229d8f in __libc_start_call_main csu/.../sysdeps/nptl/libc_start_call_main.h:58:16 
+#17 0x7f51fb229e3f in __libc_start_main csu/../csu/libc-start.c:392:3 #18 0x559d98f20ed4 in _start (/home/joey/repo/qemu/build/qemu-system-x86_64+0x1f93ed4)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2400 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2400
new file mode 100644
index 00000000..f81072f7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2400
@@ -0,0 +1,43 @@
+Qemu fails to boot snapshot image if its header is qcow2 but its payload and backing image extension are luks
+Description of problem:
+Qemu fails to recognize snapshot image E:\\test_snapshot.qcow2 saying Volume is not in LUKS format
+
+You need three commands to reproduce:
+
+`qemu-img create -f luks --object secret,id=sec0,data=123 -o key-secret=sec0 E:\test.luks 1G`
+
+`qemu-img create --object secret,id=sec0,data=123 -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 -b E:\test.luks -F luks E:\test_snapshot.qcow2`
+
+`qemu-system-x86_64 -drive file=E:\test_snapshot.qcow2,format=luks,key-secret=sec0 -object secret,id=sec0,data=123`
+
+This error is printed:
+
+`qemu-system-x86_64: -drive file=E:\test_snapshot.qcow2,format=luks,key-secret=sec0: Volume is not in LUKS format`
+
+But fourth command shows that payload of `E:\test_snapshot.qcow2` has LUKS format:
+
+`qemu-img info E:\test_snapshot.qcow2`
+
+\[output\]
+
+```bash
+virtual size: 1 GiB (1073741824 bytes)
+disk size: 2.25 MiB
+encrypted: yes
+cluster_size: 65536
+backing file: E:\test.luks
+backing file format: luks
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: false
+    refcount bits: 16
+    encrypt:
+        ivgen alg: plain64
+        detached header: false
+        hash alg: sha256
+        cipher alg: aes-256
+        uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
+        format: luks
+        cipher mode: xts ...
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2401 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2401
new file mode 100644
index 00000000..f57631c7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2401
@@ -0,0 +1 @@
+"-nic none" option has no equivalent in config file
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2406 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2406
new file mode 100644
index 00000000..35e4c818
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2406
@@ -0,0 +1,7 @@
+SDL UI on KMSDRM Frontend flips qemu-consoles
+Description of problem:
+If I launch qemu on the kms/drm console (without X11 or Wayland), the screen flips automatically between all qemu-consoles. The first (500?) milliseconds, there is the maschine output (boot messages), than the next (200?) milliseconds there is the monitor0 console, the next milliseconds, the serial0 console, and than the parallel0 console. And again from beginning (maschine, monitor0, serial0, parallel0, ... maschine, monitor0, serial0, parallel0, ...) - I dont press any key.
+
+If I disable monitor0, serial0, parallel0, all is fine, except one thing: I cannot issue a command on monitor0, because its disabled ;).
+Steps to reproduce:
+1. Start qemu without X11 and without wayland on the KMSDRM console.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2407 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2407
new file mode 100644
index 00000000..b918926d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2407
@@ -0,0 +1,53 @@
+"code should not be reached" in ati_2d_blt()
+Description of problem:
+My fuzzer detected a "code should not be reached" bug in ati_2d_blt()
+
+The stack trace is:
+
+```
+ERROR:include/qemu/bswap.h:418:stn_he_p: code should not be reached
+Bail out! ERROR:include/qemu/bswap.h:418:stn_he_p: code should not be reached
+==69534== ERROR: libFuzzer: deadly signal
+    #0 0x559e65667f5e in __sanitizer_print_stack_trace llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_stack.cpp:87:3
+    #1 0x559e655a73bc in fuzzer::PrintStackTrace() llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x559e65585a66 in fuzzer::Fuzzer::CrashCallback() (.part.0) llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18
+    #3 0x559e65585b2b in fuzzer::Fuzzer::CrashCallback() llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1
+    #4 0x559e65585b2b in fuzzer::Fuzzer::StaticCrashSignalCallback() llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19
+    #5 0x7fa8835e351f  (/lib/x86_64-linux-gnu/libc.so.6+0x4251f) (BuildId: c289da5071a3399de893d2af81d6a30c62646e1e)
+    #6 0x7fa8836379fb in __pthread_kill_implementation nptl/pthread_kill.c:43:17
+    #7 0x7fa8836379fb in __pthread_kill_internal nptl/pthread_kill.c:78:10
+    #8 0x7fa8836379fb in pthread_kill nptl/pthread_kill.c:89:10
+    #9 0x7fa8835e3475 in gsignal signal/../sysdeps/posix/raise.c:26:13
+    #10 0x7fa8835c97f2 in abort stdlib/abort.c:79:7
+    #11 0x7fa8848e5b56  (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x1eb56) (BuildId: c74e800dfd5f72649d673b44292f4a817e45150b)
+    #12 0x7fa88493f70e in g_assertion_message_expr (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7870e) (BuildId: c74e800dfd5f72649d673b44292f4a817e45150b)
+    #13 0x559e65fc7d70 in stn_he_p include/qemu/bswap.h:418:1
+    #14 0x559e65fc55dc in ati_2d_blt hw/display/ati_2d.c:224:21
+    #15 0x559e65faccff in ati_mm_write hw/display/ati.c:857:9
+    #16 0x559e685b8363 in memory_region_write_accessor system/memory.c:497:5
+    #17 0x559e685b7a45 in access_with_adjusted_size system/memory.c:573:18
+    #18 0x559e685b59a9 in memory_region_dispatch_write system/memory.c:1521:16
+    #19 0x559e6865938e in flatview_write_continue_step system/physmem.c:2757:18
+    #20 0x559e68658c24 in flatview_write_continue system/physmem.c:2787:19
+    #21 0x559e6863024b in flatview_write system/physmem.c:2818:12
+    #22 0x559e6862fd18 in address_space_write system/physmem.c:2938:18
+...
+```
+Steps to reproduce:
+Arguments: `export QEMU_ARGS="-machine q35 -nodefaults -device ati-vga,romfile=\"\" -display vnc=localhost:99 -L ../pc-bios/"`
+
+The base addresses of memory regions:
+
+ati.mmregs: 0xe1000000
+
+Reproducer:
+
+```
+writew 0xe100146c 0x44e4c5c1
+writeb 0xe10016c0 0x773b93cf
+writeb 0xe10016e4 0x2beb6e13
+writel 0xe100143c 0x118b71f6
+EOF
+```
+Additional information:
+Ack: Chuhong Yuan (hslester96@gmail.com)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2408 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2408
new file mode 100644
index 00000000..9c63adb8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2408
@@ -0,0 +1,237 @@
+QEMU crashes during guest OS boot if virtserialport is present
+Description of problem:
+QEMU will load the firmware (`OVMF_CODE.fd`) and run the boot manager (`BootDisk.qcow2`) just fine, then shortly after control is passed to the OS installer (`InstallDisk.raw`) it will crash.
+
+This only happens if a `virtioserialport` is present: dropping that single device from the configuration will allow the installer to run, even if the `virtio-serial-pci` device is still present. The exact value of the `name` attribute doesn't seem to make a difference either, I'm just using the standard one for qemu-ga here.
+
+Note that `InstallDisk.raw` is attached using `virtio-blk-pci`, so it's this specific virtio device triggering the crash, not the use of virtio devices in general.
+Additional information:
+The crash happens 100% of the time.
+
+Running a bisect between 8.2 (known to work) and 9.0 (known to crash) has identified the commit 2ce6cff94df2650c460f809e5ad263f1d22507c0 as the culpit:
+
+```
+commit 2ce6cff94df2650c460f809e5ad263f1d22507c0
+Author: Cindy Lu <lulu@redhat.com>
+Date:   Fri Apr 12 14:26:55 2024 +0800
+
+    virtio-pci: fix use of a released vector
+
+    During the booting process of the non-standard image, the behavior of the
+    called function in qemu is as follows:
+
+    1. vhost_net_stop() was triggered by guest image. This will call the function
+    virtio_pci_set_guest_notifiers() with assgin= false,
+    virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0
+
+    2. virtio_reset() was triggered, this will set configure vector to VIRTIO_NO_VECTOR
+
+    3.vhost_net_start() was called (at this time, the configure vector is
+    still VIRTIO_NO_VECTOR) and then call virtio_pci_set_guest_notifiers() with
+    assgin=true, so the irqfd for vector 0 is still not "init" during this process
+
+    4. The system continues to boot and sets the vector back to 0. After that
+    msix_fire_vector_notifier() was triggered to unmask the vector 0 and  meet the crash
+
+    To fix the issue, we need to support changing the vector after VIRTIO_CONFIG_S_DRIVER_OK is set.
+
+    (gdb) bt
+    0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0)
+        at pthread_kill.c:44
+    1  0x00007fc87148ec53 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
+    2  0x00007fc87143e956 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
+    3  0x00007fc8714287f4 in __GI_abort () at abort.c:79
+    4  0x00007fc87142871b in __assert_fail_base
+        (fmt=0x7fc8715bbde0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d "../accel/kvm/kvm-all.c", line=1837, function=<optimized out>) at assert.c:92
+    5  0x00007fc871437536 in __GI___assert_fail
+        (assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d "../accel/kvm/kvm-all.c", line=1837, function=0x5606413f06f0 <__PRETTY_FUNCTION__.19> "kvm_irqchip_commit_routes") at assert.c:101
+    6  0x0000560640f884b5 in kvm_irqchip_commit_routes (s=0x560642cae1f0) at ../accel/kvm/kvm-all.c:1837
+    7  0x0000560640c98f8e in virtio_pci_one_vector_unmask
+        (proxy=0x560643c65f00, queue_no=4294967295, vector=0, msg=..., n=0x560643c6e4c8)
+        at ../hw/virtio/virtio-pci.c:1005
+    8  0x0000560640c99201 in virtio_pci_vector_unmask (dev=0x560643c65f00, vector=0, msg=...)
+        at ../hw/virtio/virtio-pci.c:1070
+    9  0x0000560640bc402e in msix_fire_vector_notifier (dev=0x560643c65f00, vector=0, is_masked=false)
+        at ../hw/pci/msix.c:120
+    10 0x0000560640bc40f1 in msix_handle_mask_update (dev=0x560643c65f00, vector=0, was_masked=true)
+        at ../hw/pci/msix.c:140
+    11 0x0000560640bc4503 in msix_table_mmio_write (opaque=0x560643c65f00, addr=12, val=0, size=4)
+        at ../hw/pci/msix.c:231
+    12 0x0000560640f26d83 in memory_region_write_accessor
+        (mr=0x560643c66540, addr=12, value=0x7fc86b7bc628, size=4, shift=0, mask=4294967295, attrs=...)
+        at ../system/memory.c:497
+    13 0x0000560640f270a6 in access_with_adjusted_size
+
+         (addr=12, value=0x7fc86b7bc628, size=4, access_size_min=1, access_size_max=4, access_fn=0x560640f26c8d <memory_region_write_accessor>, mr=0x560643c66540, attrs=...) at ../system/memory.c:573
+    14 0x0000560640f2a2b5 in memory_region_dispatch_write (mr=0x560643c66540, addr=12, data=0, op=MO_32, attrs=...)
+        at ../system/memory.c:1521
+    15 0x0000560640f37bac in flatview_write_continue
+        (fv=0x7fc65805e0b0, addr=4273803276, attrs=..., ptr=0x7fc871e9c028, len=4, addr1=12, l=4, mr=0x560643c66540)
+        at ../system/physmem.c:2714
+    16 0x0000560640f37d0f in flatview_write
+        (fv=0x7fc65805e0b0, addr=4273803276, attrs=..., buf=0x7fc871e9c028, len=4) at ../system/physmem.c:2756
+    17 0x0000560640f380bf in address_space_write
+        (as=0x560642161ae0 <address_space_memory>, addr=4273803276, attrs=..., buf=0x7fc871e9c028, len=4)
+        at ../system/physmem.c:2863
+    18 0x0000560640f3812c in address_space_rw
+        (as=0x560642161ae0 <address_space_memory>, addr=4273803276, attrs=..., buf=0x7fc871e9c028, len=4, is_write=true) at ../system/physmem.c:2873
+    --Type <RET> for more, q to quit, c to continue without paging--
+    19 0x0000560640f8aa55 in kvm_cpu_exec (cpu=0x560642f205e0) at ../accel/kvm/kvm-all.c:2915
+    20 0x0000560640f8d731 in kvm_vcpu_thread_fn (arg=0x560642f205e0) at ../accel/kvm/kvm-accel-ops.c:51
+    21 0x00005606411949f4 in qemu_thread_start (args=0x560642f292b0) at ../util/qemu-thread-posix.c:541
+    22 0x00007fc87148cdcd in start_thread (arg=<optimized out>) at pthread_create.c:442
+    23 0x00007fc871512630 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+    (gdb)
+
+    MST: coding style and typo fixups
+
+    Fixes: f9a09ca3ea ("vhost: add support for configure interrupt")
+    Cc: qemu-stable@nongnu.org
+    Signed-off-by: Cindy Lu <lulu@redhat.com>
+    Message-ID: <2321ade5f601367efe7380c04e3f61379c59b48f.1713173550.git.mst@redhat.com>
+    Cc: Lei Yang <leiyang@redhat.com>
+    Cc: Jason Wang <jasowang@redhat.com>
+    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+    Tested-by: Cindy Lu <lulu@redhat.com>
+```
+
+Considering that it touches virtio-pci, the results seem plausible.
+
+This commit was also backported to stable as part of the 8.2.3 release, and indeed I have verified that that version suffers from the crash while 8.2.2 didn't.
+
+Reverting the commit makes the crash go away, but obviously the change was made for a reason so we probably need a follow-up fix rather than a plain revert.
+
+Crash and stack trace:
+
+```
+Thread 10 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
+[Switching to Thread 0x7fffe56006c0 (LWP 323938)]
+kvm_virtio_pci_vq_vector_use (vector=0, proxy=0x555558e04690) at ../hw/virtio/virtio-pci.c:817
+817	    if (irqfd->users == 0) {
+(gdb) t a a bt
+
+Thread 33 (Thread 0x7fffe6a006c0 (LWP 323987) "qemu-system-x86"):
+#0  0x00007ffff4ae1169 in __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x7fffe69fb010, op=393, expected=0, futex_word=0x555557ad4370) at futex-internal.c:57
+#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x555557ad4370, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fffe69fb010, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
+#2  0x00007ffff4ae11ef in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x555557ad4370, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fffe69fb010, private=private@entry=0) at futex-internal.c:139
+#3  0x00007ffff4ae3e72 in __pthread_cond_wait_common (abstime=0x7fffe69fb010, clockid=0, mutex=0x7fffe69faf90, cond=0x555557ad4348) at pthread_cond_wait.c:503
+#4  ___pthread_cond_timedwait64 (cond=cond@entry=0x555557ad4348, mutex=mutex@entry=0x555557ad42e0, abstime=abstime@entry=0x7fffe69fb010) at pthread_cond_wait.c:643
+#5  0x0000555555efc651 in qemu_cond_timedwait_ts (cond=cond@entry=0x555557ad4348, mutex=mutex@entry=0x555557ad42e0, ts=ts@entry=0x7fffe69fb010, file=file@entry=0x55555616c035 "../util/thread-pool.c", line=line@entry=91) at ../util/qemu-thread-posix.c:239
+#6  0x0000555555efd2f8 in qemu_cond_timedwait_impl (cond=0x555557ad4348, mutex=0x555557ad42e0, ms=<optimized out>, file=0x55555616c035 "../util/thread-pool.c", line=91) at ../util/qemu-thread-posix.c:253
+#7  0x0000555555f129bc in worker_thread (opaque=opaque@entry=0x555557ad42d0) at ../util/thread-pool.c:91
+#8  0x0000555555efc4c8 in qemu_thread_start (args=0x555557aef190) at ../util/qemu-thread-posix.c:541
+#9  0x00007ffff4ae4897 in start_thread (arg=<optimized out>) at pthread_create.c:444
+#10 0x00007ffff4b6ba5c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
+
+Thread 32 (Thread 0x7fffece006c0 (LWP 323986) "qemu-system-x86"):
+#0  0x00007ffff4ae1169 in __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x7fffecdfb010, op=393, expected=0, futex_word=0x555557ad4374) at futex-internal.c:57
+#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x555557ad4374, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fffecdfb010, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
+#2  0x00007ffff4ae11ef in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x555557ad4374, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fffecdfb010, private=private@entry=0) at futex-internal.c:139
+#3  0x00007ffff4ae3e72 in __pthread_cond_wait_common (abstime=0x7fffecdfb010, clockid=0, mutex=0x7fffecdfaf90, cond=0x555557ad4348) at pthread_cond_wait.c:503
+#4  ___pthread_cond_timedwait64 (cond=cond@entry=0x555557ad4348, mutex=mutex@entry=0x555557ad42e0, abstime=abstime@entry=0x7fffecdfb010) at pthread_cond_wait.c:643
+#5  0x0000555555efc651 in qemu_cond_timedwait_ts (cond=cond@entry=0x555557ad4348, mutex=mutex@entry=0x555557ad42e0, ts=ts@entry=0x7fffecdfb010, file=file@entry=0x55555616c035 "../util/thread-pool.c", line=line@entry=91) at ../util/qemu-thread-posix.c:239
+#6  0x0000555555efd2f8 in qemu_cond_timedwait_impl (cond=0x555557ad4348, mutex=0x555557ad42e0, ms=<optimized out>, file=0x55555616c035 "../util/thread-pool.c", line=91) at ../util/qemu-thread-posix.c:253
+#7  0x0000555555f129bc in worker_thread (opaque=opaque@entry=0x555557ad42d0) at ../util/thread-pool.c:91
+#8  0x0000555555efc4c8 in qemu_thread_start (args=0x555557aee7b0) at ../util/qemu-thread-posix.c:541
+#9  0x00007ffff4ae4897 in start_thread (arg=<optimized out>) at pthread_create.c:444
+#10 0x00007ffff4b6ba5c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
+
+Thread 10 (Thread 0x7fffe56006c0 (LWP 323938) "qemu-system-x86"):
+#0  kvm_virtio_pci_vq_vector_use (vector=0, proxy=0x555558e04690) at ../hw/virtio/virtio-pci.c:817
+#1  kvm_virtio_pci_vector_use_one (proxy=0x555558e04690, queue_no=5) at ../hw/virtio/virtio-pci.c:893
+#2  0x0000555555cde680 in memory_region_write_accessor (mr=0x555558e05230, addr=26, value=<optimized out>, size=2, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../system/memory.c:497
+#3  0x0000555555cddf26 in access_with_adjusted_size (addr=addr@entry=26, value=value@entry=0x7fffe55fae78, size=size@entry=2, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x555555cde600 <memory_region_write_accessor>, mr=<optimized out>, attrs=...) at ../system/memory.c:573
+#4  0x0000555555cde271 in memory_region_dispatch_write (mr=mr@entry=0x555558e05230, addr=addr@entry=26, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../system/memory.c:1528
+#5  0x0000555555ce623f in flatview_write_continue_step (attrs=attrs@entry=..., buf=buf@entry=0x7fffeef80028 "", mr_addr=26, l=l@entry=0x7fffe55faf90, mr=0x555558e05230, len=2) at ../system/physmem.c:2757
+#6  0x0000555555ce6918 in flatview_write_continue (mr=<optimized out>, l=<optimized out>, mr_addr=<optimized out>, len=2, ptr=0x8100401a, attrs=..., addr=2164277274, fv=0x7fff343ec810) at ../system/physmem.c:2787
+#7  flatview_write (fv=0x7fff343ec810, addr=addr@entry=2164277274, attrs=attrs@entry=..., buf=buf@entry=0x7fffeef80028, len=len@entry=2) at ../system/physmem.c:2818
+#8  0x0000555555ce9e61 in address_space_write (len=2, buf=0x7fffeef80028, attrs=..., addr=2164277274, as=0x555556e03d40 <address_space_memory>) at ../system/physmem.c:2938
+#9  address_space_rw (as=0x555556e03d40 <address_space_memory>, addr=2164277274, attrs=attrs@entry=..., buf=buf@entry=0x7fffeef80028, len=2, is_write=<optimized out>) at ../system/physmem.c:2948
+#10 0x0000555555d45118 in kvm_cpu_exec (cpu=cpu@entry=0x555557cde8b0) at ../accel/kvm/kvm-all.c:3031
+#11 0x0000555555d46845 in kvm_vcpu_thread_fn (arg=arg@entry=0x555557cde8b0) at ../accel/kvm/kvm-accel-ops.c:50
+#12 0x0000555555efc4c8 in qemu_thread_start (args=0x555557c5a370) at ../util/qemu-thread-posix.c:541
+#13 0x00007ffff4ae4897 in start_thread (arg=<optimized out>) at pthread_create.c:444
+#14 0x00007ffff4b6ba5c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
+
+Thread 9 (Thread 0x7fffe60006c0 (LWP 323937) "qemu-system-x86"):
+#0  futex_wait (private=0, expected=2, futex_word=0x555556deffe0 <bql>) at ../sysdeps/nptl/futex-internal.h:146
+#1  __GI___lll_lock_wait (futex=futex@entry=0x555556deffe0 <bql>, private=0) at lowlevellock.c:49
+#2  0x00007ffff4ae7e41 in lll_mutex_lock_optimized (mutex=0x555556deffe0 <bql>) at pthread_mutex_lock.c:48
+#3  ___pthread_mutex_lock (mutex=mutex@entry=0x555556deffe0 <bql>) at pthread_mutex_lock.c:93
+#4  0x0000555555efc8c3 in qemu_mutex_lock_impl (mutex=0x555556deffe0 <bql>, file=0x5555560e97ca "../system/physmem.c", line=2689) at ../util/qemu-thread-posix.c:94
+#5  0x0000555555ad6082 in bql_lock_impl (file=file@entry=0x5555560e97ca "../system/physmem.c", line=line@entry=2689) at ../system/cpus.c:536
+#6  0x0000555555ce632f in prepare_mmio_access (mr=0x55555874c4b0) at ../system/physmem.c:2689
+#7  flatview_write_continue_step (attrs=..., attrs@entry=..., buf=buf@entry=0x7fffeef83028 "", mr_addr=536, l=l@entry=0x7fffe5ffaf90, mr=0x55555874c4b0, len=4) at ../system/physmem.c:2738
+#8  0x0000555555ce6918 in flatview_write_continue (mr=<optimized out>, l=<optimized out>, mr_addr=<optimized out>, len=4, ptr=0x81084218, attrs=..., addr=2164802072, fv=0x7fff343ec810) at ../system/physmem.c:2787
+#9  flatview_write (fv=0x7fff343ec810, addr=addr@entry=2164802072, attrs=attrs@entry=..., buf=buf@entry=0x7fffeef83028, len=len@entry=4) at ../system/physmem.c:2818
+#10 0x0000555555ce9e61 in address_space_write (len=4, buf=0x7fffeef83028, attrs=..., addr=2164802072, as=0x555556e03d40 <address_space_memory>) at ../system/physmem.c:2938
+#11 address_space_rw (as=0x555556e03d40 <address_space_memory>, addr=2164802072, attrs=attrs@entry=..., buf=buf@entry=0x7fffeef83028, len=4, is_write=<optimized out>) at ../system/physmem.c:2948
+#12 0x0000555555d45118 in kvm_cpu_exec (cpu=cpu@entry=0x555557dbdcd0) at ../accel/kvm/kvm-all.c:3031
+#13 0x0000555555d46845 in kvm_vcpu_thread_fn (arg=arg@entry=0x555557dbdcd0) at ../accel/kvm/kvm-accel-ops.c:50
+#14 0x0000555555efc4c8 in qemu_thread_start (args=0x555557c0b4a0) at ../util/qemu-thread-posix.c:541
+#15 0x00007ffff4ae4897 in start_thread (arg=<optimized out>) at pthread_create.c:444
+#16 0x00007ffff4b6ba5c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
+
+Thread 7 (Thread 0x7fffe74006c0 (LWP 323934) "dconf worker"):
+#0  0x00007ffff4b5de3d in __GI___poll (fds=0x7fffc8000b90, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
+#1  0x00007ffff6e38f04 in g_main_context_poll_unlocked (priority=2147483647, n_fds=1, fds=0x7fffc8000b90, timeout=<optimized out>, context=0x555557adfef0) at ../glib/gmain.c:4653
+#2  g_main_context_iterate_unlocked.isra.0 (context=context@entry=0x555557adfef0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4344
+#3  0x00007ffff6ddbad3 in g_main_context_iteration (context=context@entry=0x555557adfef0, may_block=may_block@entry=1) at ../glib/gmain.c:4414
+#4  0x00007ffff7fb16b5 in dconf_gdbus_worker_thread (user_data=0x555557adfef0) at ../gdbus/dconf-gdbus-thread.c:82
+#5  0x00007ffff6e0e573 in g_thread_proxy (data=0x555557ae00d0) at ../glib/gthread.c:831
+#6  0x00007ffff4ae4897 in start_thread (arg=<optimized out>) at pthread_create.c:444
+#7  0x00007ffff4b6ba5c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
+
+Thread 6 (Thread 0x7fffe7e006c0 (LWP 323933) "gdbus"):
+#0  0x00007ffff4b5de3d in __GI___poll (fds=0x7fffd0000b90, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
+#1  0x00007ffff6e38f04 in g_main_context_poll_unlocked (priority=2147483647, n_fds=3, fds=0x7fffd0000b90, timeout=<optimized out>, context=0x7fffd4005a90) at ../glib/gmain.c:4653
+#2  g_main_context_iterate_unlocked.isra.0 (context=0x7fffd4005a90, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4344
+#3  0x00007ffff6ddf447 in g_main_loop_run (loop=0x7fffd4005b80) at ../glib/gmain.c:4551
+#4  0x00007ffff7048bc2 in gdbus_shared_thread_func (user_data=0x7fffd4005a60) at ../gio/gdbusprivate.c:284
+#5  0x00007ffff6e0e573 in g_thread_proxy (data=0x7fffd4005bc0) at ../glib/gthread.c:831
+#6  0x00007ffff4ae4897 in start_thread (arg=<optimized out>) at pthread_create.c:444
+#7  0x00007ffff4b6ba5c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
+
+Thread 4 (Thread 0x7fffed8006c0 (LWP 323931) "gmain"):
+#0  0x00007ffff4b5de3d in __GI___poll (fds=0x555557acd200, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
+#1  0x00007ffff6e38f04 in g_main_context_poll_unlocked (priority=2147483647, n_fds=1, fds=0x555557acd200, timeout=<optimized out>, context=0x555557accfd0) at ../glib/gmain.c:4653
+#2  g_main_context_iterate_unlocked.isra.0 (context=context@entry=0x555557accfd0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4344
+#3  0x00007ffff6ddbad3 in g_main_context_iteration (context=0x555557accfd0, may_block=may_block@entry=1) at ../glib/gmain.c:4414
+#4  0x00007ffff6ddbb29 in glib_worker_main (data=<optimized out>) at ../glib/gmain.c:6574
+#5  0x00007ffff6e0e573 in g_thread_proxy (data=0x555557ac1140) at ../glib/gthread.c:831
+#6  0x00007ffff4ae4897 in start_thread (arg=<optimized out>) at pthread_create.c:444
+#7  0x00007ffff4b6ba5c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
+
+Thread 3 (Thread 0x7fffee2006c0 (LWP 323930) "pool-spawner"):
+#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
+#1  0x00007ffff6e35b7d in g_cond_wait (cond=0x555557ac5f28, mutex=0x555557ac5f20) at ../glib/gthread-posix.c:1552
+#2  0x00007ffff6da922b in g_async_queue_pop_intern_unlocked (queue=0x555557ac5f20, wait=1, end_time=-1) at ../glib/gasyncqueue.c:425
+#3  0x00007ffff6e123e3 in g_thread_pool_spawn_thread (data=<optimized out>) at ../glib/gthreadpool.c:311
+#4  0x00007ffff6e0e573 in g_thread_proxy (data=0x555557ac7800) at ../glib/gthread.c:831
+#5  0x00007ffff4ae4897 in start_thread (arg=<optimized out>) at pthread_create.c:444
+#6  0x00007ffff4b6ba5c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
+
+Thread 2 (Thread 0x7fffeec006c0 (LWP 323929) "qemu-system-x86"):
+#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
+#1  0x0000555555efd7ca in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /home/abologna/src/upstream/qemu/include/qemu/futex.h:29
+#2  qemu_event_wait (ev=ev@entry=0x555556e182e8 <rcu_call_ready_event>) at ../util/qemu-thread-posix.c:464
+#3  0x0000555555f07216 in call_rcu_thread (opaque=opaque@entry=0x0) at ../util/rcu.c:278
+#4  0x0000555555efc4c8 in qemu_thread_start (args=0x555556ea0ed0) at ../util/qemu-thread-posix.c:541
+#5  0x00007ffff4ae4897 in start_thread (arg=<optimized out>) at pthread_create.c:444
+#6  0x00007ffff4b6ba5c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
+
+Thread 1 (Thread 0x7fffef0864c0 (LWP 323692) "qemu-system-x86"):
+#0  futex_wait (private=0, expected=2, futex_word=0x555556deffe0 <bql>) at ../sysdeps/nptl/futex-internal.h:146
+#1  __GI___lll_lock_wait (futex=futex@entry=0x555556deffe0 <bql>, private=0) at lowlevellock.c:49
+#2  0x00007ffff4ae7e41 in lll_mutex_lock_optimized (mutex=0x555556deffe0 <bql>) at pthread_mutex_lock.c:48
+#3  ___pthread_mutex_lock (mutex=mutex@entry=0x555556deffe0 <bql>) at pthread_mutex_lock.c:93
+#4  0x0000555555efc8c3 in qemu_mutex_lock_impl (mutex=0x555556deffe0 <bql>, file=0x55555616b7ef "../util/main-loop.c", line=308) at ../util/qemu-thread-posix.c:94
+#5  0x0000555555ad6082 in bql_lock_impl (file=file@entry=0x55555616b7ef "../util/main-loop.c", line=line@entry=308) at ../system/cpus.c:536
+#6  0x0000555555f109a6 in os_host_main_loop_wait (timeout=6299288) at ../util/main-loop.c:308
+#7  main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:589
+#8  0x0000555555ae0ce9 in qemu_main_loop () at ../system/runstate.c:795
+#9  0x0000555555d50f66 in qemu_default_main () at ../system/main.c:37
+#10 0x00007ffff4a7e14a in __libc_start_call_main (main=main@entry=0x555555897b80 <main>, argc=argc@entry=29, argv=argv@entry=0x7fffffffe0e8) at ../sysdeps/nptl/libc_start_call_main.h:58
+#11 0x00007ffff4a7e20b in __libc_start_main_impl (main=0x555555897b80 <main>, argc=29, argv=0x7fffffffe0e8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe0d8) at ../csu/libc-start.c:360
+#12 0x00005555558998a5 in _start ()
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2409 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2409
new file mode 100644
index 00000000..dccdee11
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2409
@@ -0,0 +1 @@
+High CPU usage on network traffic on Apple laptops
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2410 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2410
new file mode 100644
index 00000000..66405d9a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2410
@@ -0,0 +1,92 @@
+linux-user: `Setsockopt` with IP_OPTIONS returns "Protocol not available" error
+Description of problem:
+It seems that call to `setsockopt(sd, SOL_IP, IP_OPTIONS,_)` behaves differently on RISC-V Qemu than on x64 Linux. 
+On Linux syscall returns 0, but on Qemu it fails with `Protocol not available`.
+According [man](https://man7.org/linux/man-pages/man7/ip.7.html) `IP_OPTIONS` on `SOCK_STREAM` socket "should work".
+Steps to reproduce:
+1. Use below toy program `setsockopt.c` and compile it without optimizations like:
+```
+    gcc -Wall -W -Wextra -std=gnu17 -pedantic setsockopt.c -o setsockopt
+```
+
+```
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <arpa/inet.h>
+#include <netinet/in.h>
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+int main() {
+    {
+        int sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
+        if(sd < 0) {
+            perror("Opening stream socket error");
+            exit(1);
+        }
+        else
+            printf("Opening stream socket....OK.\n");
+
+        struct sockaddr_in local_address = {AF_INET, htons(1234), {inet_addr("255.255.255.255")}, {0}};
+        int err = connect(sd, (struct sockaddr*)&local_address, (socklen_t)16);
+
+        if (err < 0) {
+            perror("Connect error");
+            close(sd);
+        }
+        else
+            printf("Connect...OK.\n");
+    }
+    {
+        int sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
+        if(sd < 0) {
+            perror("Opening stream socket error");
+            exit(1);
+        }
+        else
+            printf("Opening stream socket....OK.\n");
+
+        char option[4] = {0};
+        if(setsockopt(sd, SOL_IP, IP_OPTIONS, (char *)option, sizeof(option)) < 0) {
+            perror("setsockopt error");
+            close(sd);
+            exit(1);
+        }
+        else
+            printf("setsockopt...OK.\n");
+
+        struct sockaddr_in local_address = {AF_INET, htons(1234), {inet_addr("255.255.255.255")}, {0}};
+        int err = connect(sd, (struct sockaddr*)&local_address, (socklen_t)16);
+
+        if (err < 0) {
+            perror("Connect error");
+            close(sd);
+        }
+        else
+            printf("Connect...OK.\n");
+    }
+    return 0;
+}
+```
+
+
+2. Run program on Qemu and compare output with output from x64 build. In my case it looks like:
+```
+root@AMDC4705:~/runtime/connect$ ./setsockopt-x64
+Opening stream socket....OK.
+Connect error: Network is unreachable
+Opening stream socket....OK.
+setsockopt...OK.
+Connect error: Network is unreachable
+
+root@AMDC4705:/runtime/connect# ./setsockopt-riscv
+Opening stream socket....OK.
+Connect error: Network is unreachable
+Opening stream socket....OK.
+setsockopt error: Protocol not available
+```
+Additional information:
+In above demo option `value` is quite artificial. However I tried passing many different `option` arguments (with same `SOL_IP` + `IP_OPTIONS` combination) but always ended up with `setsockopt` failure. 
+From the other hand on x64 it worked fine. Then I realized that appropriate path in Qemu was unimplemented: https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2141
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2411 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2411
new file mode 100644
index 00000000..29d7e08d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2411
@@ -0,0 +1,11 @@
+[SPICE] How to make SPICE work with GVT-g + DMA-BUF + egl-headless ?
+Description of problem:
+I try to use GVT-g + DMA-BUF in PVE , vGPU display output can be displayed normally on noVNC, 
+
+but when I try use SPICE, VM would not boot, come up with error: kvm: **The console requires display DMABUF support**.
+Steps to reproduce:
+1. Create a windows virtual machine
+2. Manually add args to the conf file, add the mdev device of GVT-g.
+3. Starting the Virtual Machine
+
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2412 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2412
new file mode 100644
index 00000000..95e909d2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2412
@@ -0,0 +1,100 @@
+Race condition in megasas device
+Description of problem:
+Race condition DoS in megasas device was found during **fuzzing**. I'm not sure about **worst case impact**, but for now I can make a suggestion: worst case might be leading to **DoS**, but probably it's a rabbit hole. So if we dig deeper we might find something like CWE-200 or CWE-202 (Exposure of Sensitive Information to an Unauthorized Actor and so on). Also, I think that we should analyse thread usage in this case and make all operations thread-safe, but it's not my business of course. As a consequence, I do not suggest any patch (at least for now).
+Steps to reproduce:
+This command:
+
+`cat << EOF | ./build/qemu-system-x86_64 \`\
+`-display none -machine accel=qtest, -m 512M -machine q35 -nodefaults \`\
+`-device megasas -device scsi-cd,drive=null0 -blockdev \`\
+`driver=null-co,read-zeroes=on,node-name=null0 -qtest stdio`\
+`outl 0xcf8 0x80000818`\
+`outl 0xcfc 0xc000`\
+`outl 0xcf8 0x80000804`\
+`outw 0xcfc 0x05`\
+`write 0x20 0x1 0x03`\
+`write 0x26 0x1 0x08`\
+`write 0x27 0x1 0x01`\
+`write 0x30 0x1 0x02`\
+`write 0x40 0x1 0x08`\
+`write 0x57 0x1 0x01`\
+`write 0x5a 0x1 0x08`\
+`outl 0xc03d 0x20000000`\
+`outl 0xc03d 0x00`\
+`EOF`\
+\
+Results in:\
+\
+`[R +0.081916] outl 0xcf8 0x80000818`\
+`[S +0.081986] OK`\
+`OK`\
+`[R +0.082033] outl 0xcfc 0xc000`\
+`[S +0.082083] OK`\
+`OK`\
+`[R +0.082102] outl 0xcf8 0x80000804`\
+`[S +0.082117] OK`\
+`OK`\
+`[R +0.082133] outw 0xcfc 0x05`\
+`[S +0.082926] OK`\
+`OK`\
+`[R +0.082961] write 0x20 0x1 0x03`\
+`[S +0.083688] OK`\
+`OK`\
+`[R +0.083731] write 0x26 0x1 0x08`\
+`[S +0.083754] OK`\
+`OK`\
+`[R +0.083780] write 0x27 0x1 0x01`\
+`[S +0.083799] OK`\
+`OK`\
+`[R +0.083817] write 0x30 0x1 0x02`\
+`[S +0.083850] OK`\
+`OK`\
+`[R +0.083872] write 0x40 0x1 0x08`\
+`[S +0.083903] OK`\
+`OK`\
+`[R +0.083925] write 0x57 0x1 0x01`\
+`[S +0.083947] OK`\
+`OK`\
+`[R +0.083962] write 0x5a 0x1 0x08`\
+`[S +0.083985] OK`\
+`OK`\
+`[R +0.084000] outl 0xc03d 0x20000000`\
+`[S +0.085531] OK`\
+`OK`\
+`[R +0.085570] outl 0xc03d 0x00`\
+`[S +0.085673] OK`\
+`OK`\
+`qemu/include/exec/memory.h:1152:12: runtime error: member access within null pointer of type 'AddressSpace' (aka 'struct AddressSpace')`\
+`SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior qemu/include/exec/memory.h:1152:12 in` \
+`AddressSanitizer:DEADLYSIGNAL`\
+`=================================================================`\
+`==168244==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000020 (pc 0x56259b9829ac bp 0x000000000001 sp 0x7ffe62140220 T0)`\
+`==168244==The signal is caused by a READ memory access.`\
+`==168244==Hint: address points to the zero page.`\
+    `#0 0x56259b9829ac in address_space_to_flatview qemu/include/exec/memory.h:1152:12`\
+    `#1 0x56259b9829ac in address_space_write qemu/build/../system/physmem.c:2929:14`\
+    `#2 0x56259b98665e in address_space_unmap qemu/build/../system/physmem.c:3272:9`\
+    `#3 0x56259af31dce in dma_memory_unmap qemu/include/sysemu/dma.h:236:5`\
+    `#4 0x56259af31dce in dma_blk_unmap qemu/build/../system/dma-helpers.c:93:9`\
+    `#5 0x56259af2f220 in dma_complete qemu/build/../system/dma-helpers.c:105:5`\
+    `#6 0x56259af2f220 in dma_blk_cb qemu/build/../system/dma-helpers.c:129:9`\
+    `#7 0x56259bce7041 in blk_aio_complete qemu/build/../block/block-backend.c:1555:9`\
+    `#8 0x56259c224495 in aio_bh_call qemu/build/../util/async.c:171:5`\
+    `#9 0x56259c224ca6 in aio_bh_poll qemu/build/../util/async.c:218:13`\
+    `#10 0x56259c1b9b89 in aio_dispatch qemu/build/../util/aio-posix.c:423:5`\
+    `#11 0x56259c228f40 in aio_ctx_dispatch qemu/build/../util/async.c:360:5`\
+    `#12 0x7f2b8c0a07a8 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x547a8) (BuildId: 9f90bd7bbfcf84a1f1c5a6102f70e6264837b9d4)`\
+    `#13 0x56259c22a1ed in glib_pollfds_poll qemu/build/../util/main-loop.c:287:9`\
+    `#14 0x56259c22a1ed in os_host_main_loop_wait qemu/build/../util/main-loop.c:310:5`\
+    `#15 0x56259c22a1ed in main_loop_wait qemu/build/../util/main-loop.c:589:11`\
+    `#16 0x56259af5159e in qemu_main_loop qemu/build/../system/runstate.c:796:9`\
+    `#17 0x56259baefdb4 in qemu_default_main qemu/build/../system/main.c:37:14`\
+    `#18 0x7f2b8aff7249  (/lib/x86_64-linux-gnu/libc.so.6+0x27249) (BuildId: 82ce4e6e4ef08fa58a3535f7437bd3e592db5ac0)`\
+    `#19 0x7f2b8aff7304 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x27304) (BuildId: 82ce4e6e4ef08fa58a3535f7437bd3e592db5ac0)`\
+    `#20 0x562599f60b70 in _start (qemu/build/qemu-system-x86_64+0x20feb70) (BuildId: 48f1333e9a9d60383d8c9e0db5f690e7c26e1bb2)`\
+`AddressSanitizer can not provide additional info.`\
+`SUMMARY: AddressSanitizer: SEGV qemu/include/exec/memory.h:1152:12 in address_space_to_flatview`\
+`==168244==ABORTING`
+
+\
+But, if we manually put all of those qtest commands and wait for each command to complete, QEMU doesn't fail. It's because of possible race condition - while QEMU still mapping memory, we already starting to unmap it. It results in this crash.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2415 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2415
new file mode 100644
index 00000000..d586a734
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2415
@@ -0,0 +1,53 @@
+Assertion `r->req.aiocb == NULL' in am53c974 device
+Description of problem:
+The following log reveals it:
+
+```
+qemu-truman-x86_64-4467afcc: qemu/hw/scsi/scsi-disk.c:558: void scsi_write_data(SCSIRequest *): Assertion `r->req.aiocb == NULL' failed.
+==2957464== ERROR: libFuzzer: deadly signal
+    #0 0x55e76f00e911 in __sanitizer_print_stack_trace llvm/compiler-rt/lib/asan/asan_stack.cpp:87:3
+    #1 0x55e76ef88fb8 in fuzzer::PrintStackTrace() llvm/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5
+    #2 0x55e76ef6d1b3 in fuzzer::Fuzzer::CrashCallback() llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3
+    #3 0x7f83d604251f  (/lib/x86_64-linux-gnu/libc.so.6+0x4251f)
+    #4 0x7f83d60969fb in __pthread_kill_implementation nptl/./nptl/pthread_kill.c:43:17
+    #5 0x7f83d60969fb in __pthread_kill_internal nptl/./nptl/pthread_kill.c:78:10
+    #6 0x7f83d60969fb in pthread_kill nptl/./nptl/pthread_kill.c:89:10
+    #7 0x7f83d6042475 in gsignal signal/../sysdeps/posix/raise.c:26:13
+    #8 0x7f83d60287f2 in abort stdlib/./stdlib/abort.c:79:7
+    #9 0x7f83d602871a in __assert_fail_base assert/./assert/assert.c:92:3
+    #10 0x7f83d6039e95 in __assert_fail assert/./assert/assert.c:101:3
+    #11 0x55e76fbb55a5 in scsi_write_data qemu/hw/scsi/scsi-disk.c:558:5
+    #12 0x55e76fb95a1f in scsi_req_continue qemu/hw/scsi/scsi-bus.c
+    #13 0x55e76fbfe0cc in esp_do_dma qemu/hw/scsi/esp.c
+    #14 0x55e76fc0be39 in handle_ti qemu/hw/scsi/esp.c:1104:9
+    #15 0x55e76fc042f6 in esp_run_cmd qemu/hw/scsi/esp.c:1186:9
+    #16 0x55e76fc042f6 in esp_reg_write qemu/hw/scsi/esp.c:1304:9
+    #17 0x55e76fc1329b in esp_pci_io_write qemu/hw/scsi/esp-pci.c:248:9
+```
+Steps to reproduce:
+```
+cat << EOF | qemu-system-x86_64 -display none\
+-machine accel=qtest, -m 512M -device am53c974,id=scsi -device \
+scsi-hd,drive=disk0 -drive id=disk0,if=none,file=null-co://,format=raw \
+-nodefaults -qtest stdio
+outl 0xcf8 0x80001010
+outl 0xcfc 0xc000
+outl 0xcf8 0x80001004
+outw 0xcfc 0x05
+outl 0xc03e 0x030000
+outl 0xc009 0xc1000000
+outl 0xc008 0x8a
+outl 0xc00d 0x0
+outl 0xc009 0x00
+outl 0xc00c 0x11
+outl 0xc00d 0x0
+outl 0xc00d 0x00
+outl 0xc00d 0x0
+outw 0xc00f 0x00
+outb 0xc00d 0x0
+outl 0xc00d 0x0
+outl 0xc009 0x41000000
+outb 0xc00c 0x90
+outl 0xc00d 0x0
+EOF
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2416 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2416
new file mode 100644
index 00000000..c2df3b7c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2416
@@ -0,0 +1,39 @@
+Assertion failure in virtio_snd_get_qemu_format()
+Description of problem:
+The following log reveals it:
+
+```
+ERROR:hw/audio/virtio-snd.c:356:virtio_snd_get_qemu_format: code should not be reached
+Bail out! ERROR:hw/audio/virtio-snd.c:356:virtio_snd_get_qemu_format: code should not be reached
+Aborted
+```
+Steps to reproduce:
+```
+cat << EOF | qemu-system-x86_64 -display none \
+-machine accel=qtest, -m 512M -machine q35 -device \
+virtio-sound,audiodev=my_audiodev,streams=2 -audiodev \
+alsa,id=my_audiodev -qtest stdio
+outl 0xcf8 0x80001804
+outw 0xcfc 0x06
+outl 0xcf8 0x80001820
+outl 0xcfc 0xe0008000
+write 0xe0008020 0x4 0x00001000
+write 0xe0008028 0x4 0x00101000
+write 0xe000801c 0x1 0x01
+write 0x10c000 0x1 0x01
+write 0x10c001 0x1 0x01
+write 0x10c014 0x1 0x01
+write 0x10c015 0x1 0x51
+write 0x100001 0x1 0xc0
+write 0x100002 0x1 0x10
+write 0x100008 0x1 0x18
+write 0x10f000 0x1 0x02
+write 0x10f001 0x1 0x01
+write 0x100021 0x1 0xf0
+write 0x100022 0x1 0x10
+write 0x100028 0x1 0x08
+write 0x101006 0x1 0x02
+write 0x101002 0x1 0x02
+write 0xe000b001 0x1 0x00
+EOF
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2417 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2417
new file mode 100644
index 00000000..a9a95f11
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2417
@@ -0,0 +1,5 @@
+qemu-img allocates full size on exFAT when metadata preallocation is requested
+Description of problem:
+`qemu-img` seems to preallocate the full size of a qcow2 image on exFAT rather than just the metadata when that is requested. This was initially seen via libvirt/libvirt#649. exFAT does not support sparse files.
+Steps to reproduce:
+1. Run command
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2418 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2418
new file mode 100644
index 00000000..f390918c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2418
@@ -0,0 +1,12 @@
+[Gfxstream BUG]
+Description of problem:
+I tried to test gfxstream with qemu,I build qemu-9.0.1 with --enable-rutabaga-gfx flag,but after I have compiled and try to boot my Virtual Devices,it crashed and told me with "invalid rutabaga build parameters: gfxstream feature not enabled"
+
+![图片](/uploads/8a979b0808aee2dc173e648d67a46a05/图片.png){width=1276 height=99}
+Steps to reproduce:
+1.Compile the qemu with kvm,vhost,rutabaga_gfxstream,virgl support
+2.run the virtual machine with my command
+
+But I found an interesting thing:If I build and install AEMU&Gfxstream at /usr in place of /usr/local,I could boot Virtual Machine normally😂 
+
+Could developers solve the problems?Thanks!
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/242 b/gitlab/issues_text/target_missing/host_missing/accel_missing/242
new file mode 100644
index 00000000..71a019b4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/242
@@ -0,0 +1 @@
+Implementation of Virtual Battery for Battery Status
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2421 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2421
new file mode 100644
index 00000000..441fe6ed
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2421
@@ -0,0 +1,18 @@
+Cannot boot ArcaOS 5.1.0 (a distro of OS/2 Warp 4.52) in UEFI mode
+Description of problem:
+ArcaOS has added the UEFI support since 5.1.0, it has been tested on my physical machine(Ryzen 3300X + RTX2060 Super), and VirtualBox with an `Other x64` machine(the new OS/2 bootloader used in UEFI mode is x64 only).
+
+Fixes applied to #2198 are perfectly worked in legacy BIOS mode, but if I tried to boot it in UEFI mode, it will stuck on logo screen, and if I enable verbose mode in boot menu, nothing will be shown on the screen and serial ports.
+
+It happens in both `i440fx` machine type and `q35` machine type.
+Steps to reproduce:
+1. Install latest qemu HEAD version via `brew install qemu --HEAD`
+2. Create new virtual disk via `qemu-img create -f qcow2 hdd.img 20G`
+3. Copy EFI bios file and var file
+   ```
+   cp /opt/homebrew/Cellar/qemu/HEAD-1a2d52c/share/qemu/edk2-x86_64-code.fd bios.fd
+   cp /opt/homebrew/Cellar/qemu/HEAD-1a2d52c/share/qemu/edk2-i386-vars.fd vars.fd
+   ```
+4. Launch it
+Additional information:
+![截屏2024-07-03_17.33.19](/uploads/74723c79ae46a72d2fbf9d89194cbb3a/截屏2024-07-03_17.33.19.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2423 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2423
new file mode 100644
index 00000000..b84022df
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2423
@@ -0,0 +1,34 @@
+`qemu -serial stdio` leaves stdout in non-blocking mode
+Description of problem:
+When `-serial stdio` is used, qemu exits leaving stdout in non-blocking mode. Although it [attempts](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L52) to restore stdin to blocking mode, it misses that stdout also gets O_NONBLOCK by [qemu_chr_open_fd](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L116) ([here](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-fd.c#L215)). It causes the next applications in the script misbehave because they get unexpected EAGAIN on write to stdout.
+Steps to reproduce:
+Run the following script:
+
+```
+#!/usr/bin/env bash
+
+qemu-system-x86_64 -nodefaults -display none -no-reboot -serial stdio &
+PID="$!"
+sleep 5
+kill "$PID"
+wait "$PID"
+echo "EXITING $?"
+
+sleep 5
+seq 1 400000
+```
+
+The seq command will be interrupted prematurely:
+
+```
+...
+5143
+5144
+5145⏎                                                                                                                                                                                                                wResource temporarily unavailable
+write: Resource temporarily unavailable
+write: Resource temporarily unavailable
+```
+
+When run from fish shell, it will also start misbehaving when running next commands (fish bug report: https://github.com/fish-shell/fish-shell/issues/10600).
+Additional information:
+Expect a patch from me soon.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2424 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2424
new file mode 100644
index 00000000..de417ad7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2424
@@ -0,0 +1,318 @@
+Fatal error: futex robust_list not initialized by pthreads (Unknown syscall 386)
+Description of problem:
+Seems like steamcmd modified their binary with a function unimplemented by QEMU just recently. This was working perfectly until then. I did some strace debugging and came up with this error: `set_robust_list(0x40b7be2c,12) = -1 errno=38 (Function not implemented)`. I even tried doing `qemu-arm` over `box86` just to see if it'll work but still got that same error. However, using `box86` alone worked.
+
+I have my reasons of wanting to use `qemu-i386` over `box86` mainly due to it being compilable into an ARM64 binary unlike `box86` which is only an ARM binary. Performance doesn't really matter as it's only being used to download server files. Running QEMU was the only option working for people on M-series Macs to run steamcmd in a container reliably over Docker Desktop as those CPUs don't have 32-bit support. Even if I force them to use only `box86`, Mac's Docker Desktop runs QEMU over the image to emulate 32-bit support which causes the same error.
+Steps to reproduce:
+1. Install Docker
+2. Run `docker run -it --pull=always sonroyaalmerol/steamcmd-arm64:root`
+3. Inside the container shell, run `LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/steam/steamcmd/linux32 qemu-i386-static /home/steam/steamcmd/linux32/steamcmd +@sSteamCmdForcePlatformType linux +@sSteamCmdForcePlatformBitness 64 +force_install_dir "/palworld" +login anonymous +app_update 2394010 validate +quit`
+Additional information:
+I'm running all these inside a Docker container. I maintain a Docker image that is meant to be a base image for steamcmd-based dedicated servers (https://github.com/sonroyaalmerol/steamcmd-arm64).
+
+I tried both the `qemu-user-static` package from Debian repos (which I believe is v7.2) and building straight from the source (stable-9.0 tag) with no luck.
+
+strace from the command:
+```
+25 brk(NULL) = 0x00a89000
+25 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x40839000
+25 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/i686/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/i686/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"i686/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"i686/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/i686/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/i686/sse2",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/i686/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/i686",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/sse2",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/tls",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/i686/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/i686/sse2",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/i686/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/i686",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/sse2",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = 0
+25 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
+25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffe38) = 0
+25 mmap2(NULL,11734,PROT_READ,MAP_PRIVATE,3,0) = 0x4083b000
+25 close(3) = 0
+25 openat(AT_FDCWD,"/lib/i386-linux-gnu/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
+25 read(3,0x408000a0,512) = 512
+25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdd8) = 0
+25 mmap2(NULL,16392,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x4083e000
+25 mmap2(0x4083f000,4096,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1) = 0x4083f000
+25 mmap2(0x40840000,4096,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x40840000
+25 mmap2(0x40841000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x40841000
+25 close(3) = 0
+25 openat(AT_FDCWD,"tls/i686/sse2/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/i686/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/sse2/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"i686/sse2/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"i686/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"sse2/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/lib/i386-linux-gnu/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
+25 read(3,0x40800080,512) = 512
+25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = 0
+25 mmap2(NULL,16400,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x40843000
+25 mmap2(0x40844000,4096,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1) = 0x40844000
+25 mmap2(0x40845000,4096,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x40845000
+25 mmap2(0x40846000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x40846000
+25 close(3) = 0
+25 openat(AT_FDCWD,"tls/i686/sse2/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/i686/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/sse2/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"i686/sse2/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"i686/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"sse2/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/lib/i386-linux-gnu/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
+25 read(3,0x40800060,512) = 512
+25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffd98) = 0
+25 mmap2(NULL,1065052,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x40848000
+25 mmap2(0x40855000,786432,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xd) = 0x40855000
+25 mmap2(0x40915000,221184,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xcd) = 0x40915000
+25 mmap2(0x4094b000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x103) = 0x4094b000
+25 close(3) = 0
+25 openat(AT_FDCWD,"tls/i686/sse2/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/i686/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/sse2/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"i686/sse2/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"i686/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"sse2/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/lib/i386-linux-gnu/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
+25 read(3,0x40800040,512) = 512
+25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffd78) = 0
+25 mmap2(NULL,16392,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x4094d000
+25 mmap2(0x4094e000,4096,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1) = 0x4094e000
+25 mmap2(0x4094f000,4096,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x4094f000
+25 mmap2(0x40950000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x40950000
+25 close(3) = 0
+25 openat(AT_FDCWD,"tls/i686/sse2/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/i686/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/sse2/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"tls/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"i686/sse2/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"i686/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"sse2/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/lib/i386-linux-gnu/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
+25 read(3,0x40800020,512) = 512
+25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffd58) = 0
+25 mmap2(NULL,2259228,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x40952000
+25 mmap2(0x40974000,1544192,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x22) = 0x40974000
+25 mmap2(0x40aed000,524288,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x19b) = 0x40aed000
+25 mmap2(0x40b6d000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x21b) = 0x40b6d000
+25 mmap2(0x40b70000,39196,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x40b70000
+25 close(3) = 0
+25 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x40b7a000
+25 mmap2(NULL,16384,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x40b7c000
+25 set_thread_area(0x408008b0) = 0
+25 set_tid_address(0x40b7be28) = 25
+25 set_robust_list(0x40b7be2c,12) = -1 errno=38 (Function not implemented)
+25 Unknown syscall 386
+25 mprotect(0x40b6d000,8192,PROT_READ) = 0
+25 mprotect(0x40950000,4096,PROT_READ) = 0
+25 mprotect(0x4094b000,4096,PROT_READ) = 0
+25 mprotect(0x40846000,4096,PROT_READ) = 0
+25 mprotect(0x40841000,4096,PROT_READ) = 0
+25 mprotect(0x00a18000,143360,PROT_READ) = 0
+25 mprotect(0x40833000,8192,PROT_READ) = 0
+25 ugetrlimit(3,1082132628,1085730804,1,2097152,1082133208) = 0
+25 munmap(0x4083b000,11734) = 0
+25 getrandom(0x40b72b50,4,1) = 4
+25 brk(NULL) = 0x00a89000
+25 brk(0x00aaa000) = 0x00aaa000
+25 brk(0x00aab000) = 0x00aab000
+25 brk(0x00acc000) = 0x00acc000
+25 futex(0x00a867f0,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,2147483647,NULL,0x40b6eff4,1085730804) = 0
+25 futex(0x00a867f8,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,2147483647,NULL,0x40b6eff4,1085730804) = 0
+25 clock_gettime64(CLOCK_BOOTTIME,0x40800b6c) = 0 ({tv_sec=4668200,tv_nsec=47711961})
+25 gettid() = 25
+25 clock_gettime64(CLOCK_BOOTTIME,0x40800b5c) = 0 ({tv_sec=4668200,tv_nsec=48585844})
+25 getpid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 rt_sigprocmask(SIG_BLOCK,0x407fe9f0,NULL,8) = 0
+25 rt_sigaction(SIGPIPE,0x407fe804,0x407fe890) = 0
+25 ugetrlimit(7,1082125036,1085730804,10725408,13,1082133352) = 0
+25 prlimit64(0,RLIMIT_NOFILE,{rlim_cur=1048576,rlim_max=1048576},NULL) = 0
+25 openat(AT_FDCWD,"/usr/lib/locale/locale-archive",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
+25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fe5bc) = 0
+25 mmap2(NULL,2097152,PROT_READ,MAP_PRIVATE,3,0) = 0x40b80000
+25 mmap2(NULL,2596864,PROT_READ,MAP_PRIVATE,3,0x6f) = 0x40d80000
+25 close(3) = 0
+25 readlink("/proc/self/exe",0x00a8c450,4095) = 37
+25 readlink("/proc/self/exe",0x00a45060,4095) = 37
+25 chdir("/home/steam/steamcmd") = 0
+25 gettid() = 25
+25 clock_gettime64(CLOCK_BOOTTIME,0x407fe92c) = 0 ({tv_sec=4668200,tv_nsec=87889751})
+25 clock_gettime64(CLOCK_BOOTTIME,0x407fe92c) = 0 ({tv_sec=4668200,tv_nsec=89062235})
+25 clock_gettime64(CLOCK_REALTIME_COARSE,0x407fea1c) = 0 ({tv_sec=1720063413,tv_nsec=948892664})
+25 openat(AT_FDCWD,"/home/steam/steamcmd/steam.cfg",O_RDONLY|O_LARGEFILE) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/home/steam/steamcmd/Steam.cfg",O_RDONLY|O_LARGEFILE) = -1 errno=2 (No such file or directory)
+25 readlink("/root",0x407fb530,1023) = -1 errno=22 (Invalid argument)
+25 readlink("/root/.steam",0x407fb530,1023) = -1 errno=2 (No such file or directory)
+25 stat64("/root/.steam/steam",0x407fb8f0) = -1 errno=2 (No such file or directory)
+25 mkdir("/root/Steam/logs",0777) = -1 errno=17 (File exists)
+25 stat64("/root/Steam/logs/bootstrap_log.txt",0x407fd8f0) = 0
+25 lstat64("/root/Steam/logs",0x407fd850) = 0
+25 openat(AT_FDCWD,"/root/Steam/logs/bootstrap_log.txt",O_RDWR|O_LARGEFILE) = 3
+25 flock(3,5,10725408,2,10725408,1082120376) = 0
+25 fcntl64(3,F_SETFD,1) = 0
+25 _llseek(3,0,0,0x407fd8a0,SEEK_END) = 0
+25 write(3,0x9022f3,4) = 4
+25 clock_gettime64(CLOCK_REALTIME_COARSE,0x407fd90c) = 0 ({tv_sec=1720063413,tv_nsec=960892708})
+25 openat(AT_FDCWD,"/etc/localtime",O_RDONLY|O_CLOEXEC) = 4
+25 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fd65c) = 0
+25 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fd52c) = 0
+25 read(4,0xaa28b0,4096) = 114
+25 _llseek(4,4294967295,4294967236,0x407fd630,SEEK_CUR) = 0
+25 read(4,0xaa28b0,4096) = 60
+25 close(4) = 0
+25 write(3,0xa90d60,68) = 68
+25 clock_gettime64(CLOCK_REALTIME_COARSE,0x407fd90c) = 0 ({tv_sec=1720063413,tv_nsec=976892768})
+25 write(3,0xa922e0,276) = 276
+25 getcwd(0xaa28b0,4096) = 21
+25 stat64("/home/steam/steamcmd/package/beta",0x407fb8e0) = -1 errno=2 (No such file or directory)
+25 openat(AT_FDCWD,"/home/steam/steamcmd/package/steam_cmd_linux.manifest",O_RDONLY|O_LARGEFILE) = 4
+25 flock(4,5,10725408,0,10725408,1082116024) = 0
+25 fcntl64(4,F_SETFD,1) = 0
+25 fstat64(4,0x407fc890) = 0
+25 read(4,0xab1e20,1838) = 1838
+25 close(4) = 0
+25 mmap2(NULL,266240,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x40ffa000
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 gettid() = 25
+25 munmap(0x40ffa000,266240) = 0
+25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/crashhandler.so",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4
+25 read(4,0x407fc180,512) = 512
+25 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fbeb8) = 0
+25 mmap2(NULL,661476,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,4,0) = 0x40ffa000
+25 mmap2(0x41002000,442368,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,4,0x8) = 0x41002000
+25 mmap2(0x4106e000,147456,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,4,0x74) = 0x4106e000
+25 mmap2(0x41092000,16384,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,4,0x97) = 0x41092000
+25 mmap2(0x41096000,22500,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x41096000
+25 close(4) = 0
+25 mprotect(0x41092000,12288,PROT_READ) = 0
+25 clock_gettime64(CLOCK_REALTIME,0x407fc2ec) = 0 ({tv_sec=1720063414,tv_nsec=1788981})
+25 clock_gettime64(CLOCK_BOOTTIME,0x407fc31c) = 0 ({tv_sec=4668200,tv_nsec=139217662})
+25 gettid() = 25
+25 futex(0x41099f4c,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,2147483647,NULL,0x40b6eff4,1085730804) = 0
+25 futex(0x41099f54,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,2147483647,NULL,0x40b6eff4,1085730804) = 0
+25 clock_gettime64(CLOCK_BOOTTIME,0x407fc2ec) = 0 ({tv_sec=4668200,tv_nsec=147181452})
+25 getpid() = 25
+25 openat(AT_FDCWD,"/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq",O_RDONLY) = -1 errno=2 (No such file or directory)
+25 clock_gettime64(CLOCK_REALTIME,0x407fc05c) = 0 ({tv_sec=1720063414,tv_nsec=15478752})
+25 clock_nanosleep(CLOCK_REALTIME,0,{tv_sec = 0,tv_nsec = 5000000},{tv_sec = 7,tv_nsec = 1593058279}) = 0
+25 clock_gettime64(CLOCK_REALTIME,0x407fc05c) = 0 ({tv_sec=1720063414,tv_nsec=21040173})
+25 clock_gettime64(CLOCK_REALTIME,0x407fc05c) = 0 ({tv_sec=1720063414,tv_nsec=21460575})
+25 clock_nanosleep(CLOCK_REALTIME,0,{tv_sec = 0,tv_nsec = 5000000},{tv_sec = 7,tv_nsec = 1593058279}) = 0
+25 clock_gettime64(CLOCK_REALTIME,0x407fc05c) = 0 ({tv_sec=1720063414,tv_nsec=26631394})
+25 openat(AT_FDCWD,"/proc/cpuinfo",O_RDONLY) = 4
+25 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fb8fc) = 0
+25 read(4,0xaa2ff0,1024) = 968
+25 read(4,0xaa2ff0,1024) = 0
+25 close(4) = 0
+25 gettid() = 25
+25 write(2,0x407fb120,57)Unable to determine CPU Frequency. Try defining CPU_MHZ.
+ = 57
+25 write(2,0x40b6fd47,1)
+ = 1
+25 statx(1,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fa8fc) = 0
+25 write(1,0xaa2ff0,57)Unable to determine CPU Frequency. Try defining CPU_MHZ.
+ = 57
+25 openat(AT_FDCWD,"/proc/cpuinfo",O_RDONLY) = 4
+25 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fc1cc) = 0
+25 read(4,0xaa3400,1024) = 968
+25 read(4,0xaa3400,1024) = 0
+25 close(4) = 0
+25 write(1,0xaa2ff0,52)Redirecting stderr to '/root/Steam/logs/stderr.txt'
+ = 52
+25 openat(AT_FDCWD,"/root/Steam/logs/stderr.txt",O_WRONLY|O_CREAT|O_LARGEFILE|O_TRUNC,0666) = 4
+25 dup3(4,2,0)Logging directory: '/root/Steam/logs'
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2425 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2425
new file mode 100644
index 00000000..71580940
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2425
@@ -0,0 +1,7 @@
+Add support for the 1366x768  resolution to the -vga std output
+Additional information:
+There is a Debian [issue](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700055) about it back from 2013. The is also a 2024 thread [thread](https://lists.nongnu.org/archive/html/qemu-discuss/2024-07/msg00003.html) about it on the `qemu-user` mailing list.
+
+I failed to make it a feature reqeust by keeping the template text  
+`/label ~"kind::Feature Request"`  
+at the end of the message: *Gitlab* removes it automatically.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2427 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2427
new file mode 100644
index 00000000..4e467c62
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2427
@@ -0,0 +1,141 @@
+Heap-buffer-overflow in virtio-sound
+Description of problem:
+The following log reveals it:
+
+```
+==852995==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x50400002f2f9 at pc 0x5b291f531ba9 bp 0x7ffd8e80c0a0 sp 0x7ffd8e80c098
+WRITE of size 2 at 0x50400002f2f9 thread T0
+    #0 0x5b291f531ba8 in clip_natural_int16_t_from_stereo audio/mixeng_template.h:133:16
+    #1 0x5b291f4ea707 in audio_pcm_sw_read audio/audio.c:604:5
+    #2 0x5b291f4e9502 in AUD_read audio/audio.c:900:16
+    #3 0x5b291e6db7c7 in virtio_snd_pcm_in_cb hw/audio/virtio-snd.c:1279:24
+    #4 0x5b291f4f3017 in audio_run_in audio/audio.c:1331:21
+    #5 0x5b291f4eda89 in audio_run audio/audio.c:1389:5
+    #6 0x5b291fa34311 in alsa_poll_handler audio/alsaaudio.c:205:9
+    #7 0x5b2921054bb3 in aio_dispatch_handler util/aio-posix.c:372:9
+    #8 0x5b292104b9d5 in aio_dispatch_handlers util/aio-posix.c:414:20
+    #9 0x5b292104b4b9 in aio_dispatch util/aio-posix.c:424:5
+    #10 0x5b29210ede0e in aio_ctx_dispatch util/async.c:360:5
+    #11 0x79b4f927fd3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55d3a) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241)
+    #12 0x5b29210f1851 in glib_pollfds_poll util/main-loop.c:287:9
+    #13 0x5b29210f007a in os_host_main_loop_wait util/main-loop.c:310:5
+    #14 0x5b29210efc24 in main_loop_wait util/main-loop.c:589:11
+    #15 0x5b291f5e5475 in qemu_main_loop system/runstate.c:795:9
+    #16 0x5b292067eefb in qemu_default_main system/main.c:37:14
+    #17 0x5b292067ef7d in main system/main.c:48:12
+    #18 0x79b4f8829d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
+    #19 0x79b4f8829e3f in __libc_start_main csu/../csu/libc-start.c:392:3
+    #20 0x5b291e29bef4 in _start (/usr/local/bin/qemu-system-x86_64+0x1c8fef4)
+
+0x50400002f2f9 is located 1 bytes after 40-byte region [0x50400002f2d0,0x50400002f2f8)
+allocated by thread T0 here:
+    #0 0x5b291e339758 in calloc /home/runner/work/llvm-project/llvm-project/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:77:3
+    #1 0x79b4f9288c50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241)
+    #2 0x5b29202d0efd in virtio_queue_notify hw/virtio/virtio.c:2297:9
+    #3 0x5b291f3d242e in virtio_pci_notify_write hw/virtio/virtio-pci.c:1721:9
+    #4 0x5b29203c82a4 in memory_region_write_accessor system/memory.c:497:5
+    #5 0x5b29203c7951 in access_with_adjusted_size system/memory.c:573:18
+    #6 0x5b29203c57eb in memory_region_dispatch_write system/memory.c:1521:16
+    #7 0x5b292046cb42 in flatview_write_continue_step system/physmem.c:2757:18
+    #8 0x5b292046c3c1 in flatview_write_continue system/physmem.c:2787:19
+    #9 0x5b29204424c9 in flatview_write system/physmem.c:2818:12
+    #10 0x5b2920441f1e in address_space_write system/physmem.c:2938:18
+    #11 0x5b291f5d8eac in qtest_process_command system/qtest.c:643:9
+    #12 0x5b291f5cfec5 in qtest_process_inbuf system/qtest.c:776:9
+    #13 0x5b291f5de05e in qtest_read system/qtest.c:788:5
+    #14 0x5b2920d2aef0 in qemu_chr_be_write_impl chardev/char.c:214:9
+    #15 0x5b2920d2afb1 in qemu_chr_be_write chardev/char.c:226:9
+    #16 0x5b2920d37388 in fd_chr_read chardev/char-fd.c:72:9
+    #17 0x5b2920719767 in qio_channel_fd_source_dispatch io/channel-watch.c:84:12
+    #18 0x79b4f927fc43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241)
+
+SUMMARY: AddressSanitizer: heap-buffer-overflow audio/mixeng_template.h:133:16 in clip_natural_int16_t_from_stereo
+Shadow bytes around the buggy address:
+  0x50400002f000: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
+  0x50400002f080: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
+  0x50400002f100: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
+  0x50400002f180: fa fa 00 00 00 00 00 fa fa fa fd fd fd fd fd fd
+  0x50400002f200: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
+=>0x50400002f280: fa fa fd fd fd fd fd fd fa fa 00 00 00 00 00[fa]
+  0x50400002f300: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
+  0x50400002f380: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
+  0x50400002f400: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
+  0x50400002f480: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
+  0x50400002f500: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
+Shadow byte legend (one shadow byte represents 8 application bytes):
+  Addressable:           00
+  Partially addressable: 01 02 03 04 05 06 07
+  Heap left redzone:       fa
+  Freed heap region:       fd
+  Stack left redzone:      f1
+  Stack mid redzone:       f2
+  Stack right redzone:     f3
+  Stack after return:      f5
+  Stack use after scope:   f8
+  Global redzone:          f9
+  Global init order:       f6
+  Poisoned by user:        f7
+  Container overflow:      fc
+  Array cookie:            ac
+  Intra object redzone:    bb
+  ASan internal:           fe
+  Left alloca redzone:     ca
+  Right alloca redzone:    cb
+```
+Steps to reproduce:
+```
+cat << EOF | qemu-system-x86_64 -display none \
+-machine accel=qtest, -m 512M -machine q35 -device \
+virtio-sound,audiodev=my_audiodev,streams=2 -audiodev \
+alsa,id=my_audiodev -qtest stdio
+outl 0xcf8 0x80001804
+outw 0xcfc 0x7
+outl 0xcf8 0x80001820
+outl 0xcfc 0xe0008000
+write 0xe0008020 0x4 0x00001000
+write 0xe0008028 0x4 0x00101000
+write 0xe0008016 0x1 0x03
+write 0xe0008020 0x4 0x00901000
+write 0xe0008028 0x4 0x00a01000
+write 0xe0008016 0x1 0x00
+write 0xe000801c 0x1 0x01
+write 0xe0008016 0x1 0x03
+write 0xe000801c 0x1 0x01
+write 0x100008 0x1 0x08
+write 0x109008 0x1 0x04
+write 0x11e000 0x1 0x04
+write 0x11e001 0x1 0x01
+write 0x11e004 0x1 0x01
+write 0x100081 0x1 0xe0
+write 0x100082 0x1 0x11
+write 0x100088 0x1 0x08
+write 0x10100a 0x1 0x08
+write 0x151000 0x1 0x01
+write 0x1090c1 0x1 0x10
+write 0x1090c2 0x1 0x15
+write 0x1090c8 0x1 0x04
+write 0x10a00c 0x1 0x0c
+write 0x10a002 0x1 0x05
+write 0xe000b00c 0x1 0x03
+write 0x101002 0x1 0x1d
+write 0xe000b001 0x1 0x00
+outl 0xcfc 0xe0008000
+outl 0xcf8 0x80001885
+outl 0xcf8 0x80001870
+outl 0xcf8 0x80001878
+inl 0xcfc
+outl 0xcf8 0x80001870
+outl 0xcf8 0x80001863
+outl 0xcf8 0x80001853
+inb 0xcfc
+outl 0xcf8 0x80001854
+inb 0xcfc
+inb 0xcfc
+outl 0xcf8 0x80001898
+inb 0xcfc
+outl 0xcf8 0x80001899
+outl 0xcf8 0x80001870
+inb 0xcfc
+inb 0xcfc
+EOF
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2428 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2428
new file mode 100644
index 00000000..badee2b9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2428
@@ -0,0 +1,29 @@
+Null-pointer-dereference in ufs
+Description of problem:
+The following log reveals it:
+
+```
+../hw/ufs/ufs.c:740:13: runtime error: member access within null pointer of type 'UfsSq' (aka 'struct UfsSq')
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/ufs/ufs.c:740:13 in
+AddressSanitizer:DEADLYSIGNAL
+=================================================================
+==848760==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000020 (pc 0x6220e29edfce bp 0x7fffea0c6cf0 sp 0x7fffea0c6c40 T0)
+==848760==The signal is caused by a READ memory access.
+==848760==Hint: address points to the zero page.
+    #0 0x6220e29edfce in ufs_mcq_process_db hw/ufs/ufs.c:740:9
+    #1 0x6220e29dc10f in ufs_write_mcq_op_reg hw/ufs/ufs.c:758:13
+    #2 0x6220e29d85c6 in ufs_mmio_write hw/ufs/ufs.c:813:9
+```
+Steps to reproduce:
+```
+cat << EOF | qemu-system-x86_64  \
+-display none -machine accel=qtest, -m 512M -M q35 -nodefaults -drive \
+file=null-co://,if=none,id=disk0 -device ufs,id=ufs_bus -device \
+ufs-lu,drive=disk0,bus=ufs_bus -qtest stdio
+outl 0xcf8 0x80000810
+outl 0xcfc 0xe0000000
+outl 0xcf8 0x80000804
+outw 0xcfc 0x02
+write 0xe0001004 0x1 0x01
+EOF
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2430 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2430
new file mode 100644
index 00000000..14d4c1c9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2430
@@ -0,0 +1,7 @@
+allocate /  free need use glibs's function.
+Description of problem:
+https://gitlab.com/qemu-project/qemu/-/blob/master/hw/core/machine.c?ref_type=heads#L982
+
+use g_free to free config,because it is allocated by g_malloc0 
+
+on windows,if use crt's free && glib's(DLL) g_malloc0 ,will crash.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2431 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2431
new file mode 100644
index 00000000..a886e792
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2431
@@ -0,0 +1 @@
+we ship a single qemu.1 manpage supposedly applicable for all system emulators but it is full of qemu-system-x86_64 specific info/command lines
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2433 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2433
new file mode 100644
index 00000000..d41dc2ef
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2433
@@ -0,0 +1,224 @@
+[TestCase] -object filter-redirector completely ignores linked bidirectional chardev, so encryption for netdev is broken
+Description of problem:
+If I form a wittingly broken network topology using -object filter-redirector and an encrypting bi-directional chardev linked to redirected traffic, the topology continues to function when it must not. See Fig.2.
+
+By "continues to function", I mean the two guest Windows XP from Fig.2 topology are able to see each other, join the same "MSHOME" workgroup, make shared folders which are mutually seen from each other and even send files to each other's shared folder!
+
+\
+Why do I consider Fig.2 a broken topology? It includes only one encrypting chardev, whereas a normal encrypted network topology must contain one encrypting and one decrypting chardev.\
+To form Fig.2 topology, follow "Steps to reproduce" section.\
+\
+At the same time, -object filter-redirector works perfectly if only uni-directional chardevs are used, see Fig.1 with corresponding commands to launch guest#1 qemu and guest#2 qemu. All network activities from previous paragraphs seem to function correctly both in Fig.1 and in Fig.2
+
+If I put tls-creds=tls0, inside any "-chardev socket" switch in Fig.1 to make traffic encrypted without further decryption, local network between guests becomes broken (0 packets received), which is normal and expected behaviour.\
+\
+The end goal is to have netdev traffic encrypted. If anyone knows a workaround to encrypt netdev traffic on Windows hosts without installing crypto libs/drivers besides GnuTLS, please describe it in comments.
+
+*** Please note that some old broswers show Fig.1 and Fig.2 a little bit screwed. If so, please copy their source to Mousepad or Notepad - they must show topology correctly. And disable "Word Wrap" mode in your text editor, of course. ***
+
+```
+         *********************** Fig. 1. Perfectly working network topology with uni-directional chardevs *************************
+
+                                   NOTE: rx:receive packets sent to the netdev
+                                         tx:receive packets sent by the netdev
+   First qemu                                                                                            Second qemu
++--------------------------------------------------------------------------------------------------+  +----------------------------------------+
+|                                                                                                  |  |                                        |
+|   +----------------------------------------------------------------------------------------+     |  |     +------------------------------+   |
+|   |                                   Guest Windows XP #1:                                 |     |  |     |      Guest Windows XP #2:    |   |
+|   |                                                                                        |     |  |     |                              |   |
+|   | 169.254.144.98 IP,                                                                     |     |  |     | 169.254.144.99 IP,           |   |
+|   | 255.255.0.0 Net mask,                                                                  |     |  |     | 255.255.0.0 Net mask,        |   |
+|   | Gateway empty,                                                                         |     |  |     | Gateway empty,               |   |
+|   | DNS server empty,                                                                      |     |  |     | DNS server empty,            |   |
+|   | WINS server empty,                                                                     |     |  |     | WINS server empty,           |   |
+|   | DHCP off                                                                               |     |  |     | DHCP off                     |   |
+|   +----------------------------------------------------------------------------------------+     |  |     +------------------------------+   |
+|                                           ^       |                                              |  |                 ^        |             |
+|                                           |  all  |                                              |  |                 |        |             |
+|                                           |       V                                              |  |                 |        |             |
+|                                       +--------------+                                           |  |                 |        |             |
+|                                       |              |                                           |  |                 |        |             |
+|                              indev    |    filter    |     outdev                                |  |                 |        |             |
+|                                 +----->  redirector  >-------+                                   |  |                 |        |             |
+|                                 |     |              |       |                                   |  |                 |        |             |
+|                                 |     |   queue=all  |       |                                   |  |                 |        |             |
+|                                 |     +--------------+       |                                   |  |                 |        |             |
+|                                 |                            |                                   |  |                 |        |             |
+|                                 +------------+  +------------+                                   |  |                 |        |             |
+|                                              |  |                                                |  |                 |        |             |
+|   +------------------+  +------------------+ |  | +-------------------+  +------------------+    |  |                 |        |             |
+|   |      :9001       |  |      :9001       | |  | |      :9002        |  |      :9002       |    |  |                 |        |             |
+|   | uni-directional  |  | uni-directional  | |  | | uni-directional   |  | uni-directional  |    |  |                 |  all   |             |
+| +->     chardev      |->|     chardev      >-+  +->     chardev       |->|      chardev     >-+  |  |                 |        |             |
+| | |                  |  |                  |      |                   |  |                  | |  |  |                 |        |             |
+| | |     id=tx_in     |  |id=tx_out_to_guest|      |id=rx_in_from_guest|  |     id=rx_out    | |  |  |                 |        |             |
+| | |    server=on     |  |                  |      |                   |  |     server=on    | |  |  |                 |        |             |
+| | +------------------+  +------------------+      +-------------------+  +------------------+ |  |  |                 |        |             |
+| |                                                                                             |  |  |                 |        |             |
+| |                                                                                             |  |  |                 |        |             |
+| |                       +----------------+          +----------------+                        |  |  |                 |        |             |
+| |                       |                |          |                |                        |  |  |                 |        |             |
+| |                       |     filter     |          |     filter     |                        |  |  |                 |        |             |
+| +-----------------------<   redirector   |          |   redirector   <------------------------+  |  |                 |        |             |
+|                  outdev |                |          |                |  indev                    |  |                 |        |             |
+|                         |    queue=tx    |          |    queue=rx    |                           |  |                 |        |             |
+|                         +--------+-------+          +--------+-------+                           |  |                 |        |             |
+|                                  |                           |                                   |  |                 |        |             |
+|                                  |                           |                                   |  |                 |        V             |
+| +--------------------------------^---------------------------V-----------------------------+     |  |     +--------------------------------+ |
+| |==========================================================================================|------------->|================================| |
+| |                                     |                                                    |     |  |     |        |                       | |
+| |                             netdev  |  mac=52:54:00:12:34:56                             |7001::  ::7001| netdev | mac=52:54:00:12:34:57 | |
+| |                                     |                                                    |     |  |     |        |                       | |
+| |                                     |                                                    |<-------------|        |                       | |
+| +------------------------------------------------------------------------------------------+     |  |     +--------------------------------+ |
+|                                                                                                  |  |                                        |
++--------------------------------------------------------------------------------------------------+  +----------------------------------------+
+
+Command to run Guest Windows XP #1 from Fig.1:
+  qemu-system-i386.exe \
+    -accel tcg \
+    -m 256M \
+    -cpu Westmere \
+    -hda d:\xp1.qcow2 \
+    -usb -device usb-tablet \
+    -netdev socket,id=net0,listen=localhost:7001 \
+    -device rtl8139,netdev=net0,mac=52:54:00:12:34:56 \
+    -chardev socket,id=tx_in,host=127.0.0.1,port=9001,server=on,wait=off \
+    -chardev socket,id=tx_out_to_guest,host=127.0.0.1,port=9001 \
+    -chardev socket,id=rx_out,host=127.0.0.1,port=9002,server=on,wait=off \
+    -chardev socket,id=rx_in_from_guest,host=127.0.0.1,port=9002 \
+    -object filter-redirector,netdev=net0,queue=tx,outdev=tx_in,id=tx1 \
+    -object filter-redirector,netdev=net0,queue=rx,indev=rx_out,id=rx1 \
+    -object filter-redirector,netdev=net0,queue=all,outdev=rx_in_from_guest,indev=tx_out_to_guest,id=inner_redirector
+
+Command to run Guest Windows XP #2 from Fig.1:
+  qemu-system-i386.exe
+    -accel tcg \
+    -m 256M \
+    -cpu Westmere \
+    -hda d:\xp2.qcow2 \
+    -usb -device usb-tablet \
+    -netdev socket,id=net1,connect=localhost:7001 \
+    -device rtl8139,netdev=net1,mac=52:54:00:12:34:57
+
+
+     *********************** Fig. 2. Erroneously working network topology, despite encrypting bi-directional chardev *************************
+
+                                   NOTE: queue=rx:receive packets sent to the netdev
+                                         queue=tx:receive packets sent by the netdev
+                                         queue=all:receive packets sent by and to the netdev (both directions)
+
+   First qemu                                                                                            Second qemu
++--------------------------------------------------------------------------------------------------+  +----------------------------------------+
+|                                                                                                  |  |                                        |
+|   +----------------------------------------------------------------------------------------+     |  |     +------------------------------+   |
+|   |                                   Guest Windows XP #1:                                 |     |  |     |      Guest Windows XP #2:    |   |
+|   |                                                                                        |     |  |     |                              |   |
+|   | 169.254.144.98 IP,                                                                     |     |  |     | 169.254.144.99 IP,           |   |
+|   | 255.255.0.0 Net mask,                                                                  |     |  |     | 255.255.0.0 Net mask,        |   |
+|   | Gateway empty,                                                                         |     |  |     | Gateway empty,               |   |
+|   | DNS server empty,                                                                      |     |  |     | DNS server empty,            |   |
+|   | WINS server empty,                                                                     |     |  |     | WINS server empty,           |   |
+|   | DHCP off                                                                               |     |  |     | DHCP off                     |   |
+|   +----------------------------------------------------------------------------------------+     |  |     +------------------------------+   |
+|                                           ^       |                                              |  |                 ^        |             |
+|                                           |  all  |                                              |  |                 |        |             |
+|                                           |       V                                              |  |                 |        |             |
+|                                     +-------------------+                                        |  |                 |        |             |
+|                                     |                   |                                        |  |                 |        |             |
+|                             +------>|       filter      |                                        |  |                 |        |             |
+|                             |       |     redirector    |                                        |  |                 |        |             |
+|                             |   +--<|                   |                                        |  |                 |        |             |
+|                             |   |   |   queue=all       |                                        |  |                 |        |             |
+|                             |   |   |id=inner_redirector|                                        |  |                 |        |             |
+|                             |   |   +-----------V-------+                                        |  |                 |        |             |
+|                             |   |               | indev                                          |  |                 |        |             |
+|                             |   |               |                                                |  |                 |        |             |
+|                             |   |               |                                                |  |                 |        |             |
+|                             |   |    +----------V-------+     +-----------------------+          |  |                 |        |             |
+|                             |   |    |      :9001       |     |                       |          |  |                 |        |             |
+|                             |   |    |  bi-directional  |     | -object tls-creds-psk |          |  |                 |        |             |
+|                             |   |    |encrypting chardev|     |                       |          |  |                 |        |             |
+|                             |   |    |                  |---->|                       |          |  |                 |        |             |
+|                             |   |    |  tls-creds=tls0  |     |        id=tls0        |          |  |                 |        |             |
+|                             |   |    | id=inner_chardev |     |     endpoint=server   |          |  |                 |        |             |
+|                             |   |    |     server=on    |     |                       |          |  |                 |        |             |
+|                             |   |    +------------------+     +-----------------------+          |  |                 |        |             |
+|                             |   |                                                                |  |                 |        |             |
+|                             |   |                                                                |  |                 |        |             |
+|                             ^   V                                                                |  |                 |        V             |
+| +------------------------------------------------------------------------------------------+     |  |     +--------------------------------+ |
+| |==========================================================================================|------------->|================================| |
+| |                                     |                                                    |     |  |     |        |                       | |
+| |                             netdev  |  mac=52:54:00:12:34:56                             |7001::  ::7001| netdev | mac=52:54:00:12:34:57 | |
+| |                                     |                                                    |     |  |     |        |                       | |
+| |                                     |                                                    |<-------------|        |                       | |
+| +------------------------------------------------------------------------------------------+     |  |     +--------------------------------+ |
+|                                                                                                  |  |                                        |
++--------------------------------------------------------------------------------------------------+  +----------------------------------------+
+```
+Steps to reproduce:
+1. Download official GnuTLS .zip for windows from https://www.gnutls.org/download.html and extract it.
+2. Download and install official QEMU 9.0 from https://qemu.weilnetz.de/w64/qemu-w64-setup-20240423.exe
+3. Open command prompt, navigate to the folder with psktool.exe from Step 1.
+4. Run this command: "psktool -u qemu_user -p keys.psk"
+5. Run first guest Windows XP with the command described in "QEMU command line" section above, replacing "dir=C:\\Downloads" with path to keys.psk, like this: "dir=C:\\path_to_keys_dot_psk" (without filename itself)
+6. Run second guest Windows XP with the following command: `qemu-system-i386.exe -accel tcg -m 256M -cpu Westmere -hda d:\\xp2.qcow2 -usb -device usb-tablet -netdev socket,id=net1,connect=localhost:7001 -device rtl8139,netdev=net1,mac=52:54:00:12:34:57`
+Additional information:
+Yes, I know Qemu on Linux hosts is able to encrypt netdev traffic with the aid of `-netdev vhost-user,id=net0,chardev=chr0`\
+But `-netdev vhost-user,id=net0,chardev=chr0` is not officially supported by Qemu on Windows hosts.\
+\
+If I run this command in one command prompt instance:\
+`qemu-system-i386.exe -accel tcg -m 256M -object tls-creds-psk,id=tls0,endpoint=server,dir=C:\Downloads -chardev socket,id=chr0,port=7001,host=127.0.0.1,tls-creds=tls0,server=on -netdev vhost-user,id=net0,chardev=chr0 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:56`\
+\
+And this one in another instance\
+`gnutls-cli.exe --priority=NORMAL -p 7001 --pskusername=pskusername_from_keys_psk_file --pskkey=pskkeyhash_from_keys_psk_file 127.0.0.1`\
+\
+I see this:\
+`qemu-system-i386.exe: -netdev vhost-user,id=net0,chardev=chr0: network backend 'vhost-user' is not compiled into this binary`\
+\
+Testcase:
+
+<details>
+
+static void test_redirector_incomplete_bidirectional_topology_connectionError(void)\
+{\
+//prepare keys.psk\
+FILE \*fileAddress;\
+fileAddress = fopen("/home/keys.psk", "w");\
+char content\[50\] = "deadbeefname:deadbeefkey";\
+int i;\
+int len = strlen(content);\
+\
+if (fileAddress != NULL) {\
+for (i = 0; i \< len; i++) {\
+fputc (content\[i\], fileAddress);\
+}\
+fclose(fileAddress); \
+}\
+else {\
+return -1;\
+}\
+\
+\
+QTestState \*qts0;\
+char \*expect;\
+\
+qts0 = qtest_initf("-netdev socket,id=net0,listen=localhost:7001 "\
+"-device rtl8139,netdev=net0,mac=52:54:00:12:34:56 "\
+"-object filter-redirector,netdev=net0,queue=all,indev=inner_chardev,id=inner_redirector"\
+"-chardev socket,id=inner_chardev,host=127.0.0.1,port=9001,tls-creds=tls0,server=on,wait=off"\
+"-object tls-creds-psk,id=tls0,endpoint=server,dir=/home/");\
+\
+expect = g_strdup_printf("st0: index=0,type=socket,connection error\\r\\n");\
+\
+EXPECT_STATE(qts0, expect, 0);\
+\
+g_free(expect);\
+\
+qtest_quit(qts0);\
+}
+
+</details>
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2434 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2434
new file mode 100644
index 00000000..4d28dfb7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2434
@@ -0,0 +1,29 @@
+qemu fails to build tests/unit/test-nested-aio-poll with errors about writing <N> bytes into a region of size <M> overflows the destination
+Description of problem:
+Fails to compile from source with:
+```
+[2/2] Linking target tests/unit/test-nested-aio-poll
+FAILED: tests/unit/test-nested-aio-poll 
+cc -m64  -o tests/unit/test-nested-aio-poll libevent-loop-base.a.p/event-loop-base.c.o libqom.a.p/qom_container.c.o libqom.a.p/qom_object.c.o libqom.a.p/qom_object_interfaces.c.o libqom.a.p/qom_qom-qobject.c.o libblock.a.p/block.c.o libblock.a.p/blockjob.c.o libblock.a.p/job.c.o libblock.a.p/qemu-io-cmds.c.o libblock.a.p/replication.c.o libblock.a.p/nbd_client.c.o libblock.a.p/nbd_client-connection.c.o libblock.a.p/nbd_common.c.o libblock.a.p/scsi_utils.c.o libblock.a.p/scsi_pr-manager.c.o libblock.a.p/scsi_pr-manager-helper.c.o libblock.a.p/block_accounting.c.o libblock.a.p/block_aio_task.c.o libblock.a.p/block_amend.c.o libblock.a.p/block_backup.c.o libblock.a.p/block_blkdebug.c.o libblock.a.p/block_blklogwrites.c.o libblock.a.p/block_blkverify.c.o libblock.a.p/block_block-backend.c.o libblock.a.p/block_block-copy.c.o libblock.a.p/block_commit.c.o libblock.a.p/block_copy-before-write.c.o libblock.a.p/block_copy-on-read.c.o libblock.a.p/block_create.c.o libblock.a.p/block_crypto.c.o libblock.a.p/block_dirty-bitmap.c.o libblock.a.p/block_filter-compress.c.o libblock.a.p/block_graph-lock.c.o libblock.a.p/block_io.c.o libblock.a.p/block_mirror.c.o libblock.a.p/block_nbd.c.o libblock.a.p/block_null.c.o libblock.a.p/block_preallocate.c.o libblock.a.p/block_progress_meter.c.o libblock.a.p/block_qapi.c.o libblock.a.p/block_qcow2.c.o libblock.a.p/block_qcow2-bitmap.c.o libblock.a.p/block_qcow2-cache.c.o libblock.a.p/block_qcow2-cluster.c.o libblock.a.p/block_qcow2-refcount.c.o libblock.a.p/block_qcow2-snapshot.c.o libblock.a.p/block_qcow2-threads.c.o libblock.a.p/block_quorum.c.o libblock.a.p/block_raw-format.c.o libblock.a.p/block_reqlist.c.o libblock.a.p/block_snapshot.c.o libblock.a.p/block_snapshot-access.c.o libblock.a.p/block_throttle.c.o libblock.a.p/block_throttle-groups.c.o libblock.a.p/block_write-threshold.c.o libblock.a.p/block_qcow.c.o libblock.a.p/block_vdi.c.o libblock.a.p/block_vhdx-endian.c.o libblock.a.p/block_vhdx-log.c.o libblock.a.p/block_vhdx.c.o libblock.a.p/block_vmdk.c.o libblock.a.p/block_vpc.c.o libblock.a.p/block_cloop.c.o libblock.a.p/block_bochs.c.o libblock.a.p/block_vvfat.c.o libblock.a.p/block_dmg.c.o libblock.a.p/block_qed-check.c.o libblock.a.p/block_qed-cluster.c.o libblock.a.p/block_qed-l2-cache.c.o libblock.a.p/block_qed-table.c.o libblock.a.p/block_qed.c.o libblock.a.p/block_parallels.c.o libblock.a.p/block_parallels-ext.c.o libblock.a.p/block_file-posix.c.o libblock.a.p/block_iscsi-opts.c.o libblock.a.p/block_nvme.c.o libblock.a.p/block_replication.c.o libblock.a.p/block_linux-aio.c.o libblock.a.p/block_io_uring.c.o libblock.a.p/block_stream.c.o libblock.a.p/block_monitor_bitmap-qmp-cmds.c.o libblock.a.p/block_blkio.c.o libblock.a.p/block_curl.c.o libblock.a.p/block_gluster.c.o libblock.a.p/block_iscsi.c.o libblock.a.p/block_nfs.c.o libblock.a.p/block_ssh.c.o libblock.a.p/block_dmg-bz2.c.o libblock.a.p/meson-generated_.._block_block-gen.c.o libcrypto.a.p/crypto_afsplit.c.o libcrypto.a.p/crypto_akcipher.c.o libcrypto.a.p/crypto_block-luks.c.o libcrypto.a.p/crypto_block-qcow.c.o libcrypto.a.p/crypto_block.c.o libcrypto.a.p/crypto_cipher.c.o libcrypto.a.p/crypto_der.c.o libcrypto.a.p/crypto_hash.c.o libcrypto.a.p/crypto_hmac.c.o libcrypto.a.p/crypto_ivgen-essiv.c.o libcrypto.a.p/crypto_ivgen-plain.c.o libcrypto.a.p/crypto_ivgen-plain64.c.o libcrypto.a.p/crypto_ivgen.c.o libcrypto.a.p/crypto_pbkdf.c.o libcrypto.a.p/crypto_secret_common.c.o libcrypto.a.p/crypto_secret.c.o libcrypto.a.p/crypto_tlscreds.c.o libcrypto.a.p/crypto_tlscredsanon.c.o libcrypto.a.p/crypto_tlscredspsk.c.o libcrypto.a.p/crypto_tlscredsx509.c.o libcrypto.a.p/crypto_tlssession.c.o libcrypto.a.p/crypto_rsakey.c.o libcrypto.a.p/crypto_hash-gnutls.c.o libcrypto.a.p/crypto_hmac-gnutls.c.o libcrypto.a.p/crypto_pbkdf-gnutls.c.o libcrypto.a.p/crypto_secret_keyring.c.o libauthz.a.p/authz_base.c.o libauthz.a.p/authz_list.c.o libauthz.a.p/authz_listfile.c.o libauthz.a.p/authz_simple.c.o libauthz.a.p/authz_pamacct.c.o libio.a.p/io_channel-buffer.c.o libio.a.p/io_channel-command.c.o libio.a.p/io_channel-file.c.o libio.a.p/io_channel-null.c.o libio.a.p/io_channel-socket.c.o libio.a.p/io_channel-tls.c.o libio.a.p/io_channel-util.c.o libio.a.p/io_channel-watch.c.o libio.a.p/io_channel-websock.c.o libio.a.p/io_channel.c.o libio.a.p/io_dns-resolver.c.o libio.a.p/io_net-listener.c.o libio.a.p/io_task.c.o tests/unit/test-nested-aio-poll.p/test-nested-aio-poll.c.o tests/unit/test-nested-aio-poll.p/iothread.c.o -Werror -flto -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -pie -Wl,-z,relro -Wl,-z,now -march=native -fno-omit-frame-pointer -Wl,-rpath,/usr/lib64/iscsi -Wl,-rpath-link,/usr/lib64/iscsi -Wl,--start-group libqemuutil.a subprojects/libvhost-user/libvhost-user-glib.a subprojects/libvhost-user/libvhost-user.a /usr/lib64/libzstd.so /usr/lib64/libz.so /usr/lib64/iscsi/libiscsi.so -laio /usr/lib64/liburing.so -lblkio /usr/lib64/libcurl.so /usr/lib64/libacl.so /usr/lib64/libgfapi.so /usr/lib64/libglusterfs.so /usr/lib64/libgfrpc.so /usr/lib64/libgfxdr.so /usr/lib64/libuuid.so /usr/lib64/libnfs.so /usr/lib64/libssh.so /usr/lib64/libglib-2.0.so /usr/lib64/libgmodule-2.0.so -pthread -lbz2 /usr/lib64/libgnutls.so -lpam -lnuma /usr/lib64/libgio-2.0.so /usr/lib64/libgobject-2.0.so -lm -Wl,--end-group
+In function ‘aio_notify’,
+    inlined from ‘aio_bh_enqueue’ at ../util/async.c:96:5,
+    inlined from ‘aio_bh_schedule_oneshot_full’ at ../util/async.c:139:5,
+    inlined from ‘aio_wait_kick.part.0’ at ../util/aio-wait.c:54:9:
+../util/async.c:494:5: error: ‘__atomic_store_1’ writing 1 byte into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
+  494 |     qatomic_set(&ctx->notified, true);
+      |     ^
+In function ‘aio_wait_kick.part.0’:
+lto1: note: destination object is likely at address zero
+In function ‘aio_notify’,
+    inlined from ‘aio_bh_enqueue’ at ../util/async.c:96:5,
+    inlined from ‘aio_bh_schedule_oneshot_full’ at ../util/async.c:139:5,
+    inlined from ‘aio_wait_kick.part.0’ at ../util/aio-wait.c:54:9:
+../util/async.c:501:9: error: ‘__atomic_load_4’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
+  501 |     if (qatomic_read(&ctx->notify_me)) {
+      |         ^
+In function ‘aio_wait_kick.part.0’:
+lto1: note: destination object is likely at address zero
+lto1: all warnings being treated as errors
+```
+Steps to reproduce:
+1. Build qemu from source, probably with LTO enabled and recent GCC.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2435 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2435
new file mode 100644
index 00000000..21fbd0d6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2435
@@ -0,0 +1,20 @@
+CPU halted during fuzzing OHCI
+Description of problem:
+Is there a limit on the number of CPU cores that QEMU can use? I am running multiple sets of parallel fuzzing tests on a host machine. To prevent CPU contention, I have divided the running environments by using docker. The docker startup command is as follows:
+`docker run --cpuset-cpus=8-15 --privileged --name qemu-container-ohci -it qemu-container bash`
+
+I found that the CPU is in a halted state and encountered the following error:
+```
+#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=126899170563648) at ./nptl/pthread_kill.c:44                                                                                                                      
+#1  __pthread_kill_internal (signo=6, threadid=126899170563648) at ./nptl/pthread_kill.c:78                                                                                                                        
+#2  __GI___pthread_kill (threadid=126899170563648, signo=signo@entry=6) at ./nptl/pthread_kill.c:89                                                                                                                  
+#3  0x0000736a904a3476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26                                                                                         
+#4  0x0000736a904897f3 in __GI_abort () at ./stdlib/abort.c:79                                                                                                               
+#5  0x0000736a90dcbb57 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0                                                                                                             
+#6  0x0000736a90e2570f in g_assertion_message_expr () at /lib/x86_64-linux-gnu/libglib-2.0.so.0                                                                                                                        
+#7  0x00005eca4aff5bad in mttcg_cpu_thread_fn (arg=0x62b000000200) at ../accel/tcg/tcg-accel-ops-mttcg.c:110                                                                                                                                 
+#8  0x00005eca4b89d658 in qemu_thread_start (args=0x60300008b030) at ../util/qemu-thread-posix.c:541                                                                                                                      
+#9  0x0000736a904f5ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
+#10 0x0000736a90587850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+```
+Can someone help analyze the reason?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2437 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2437
new file mode 100644
index 00000000..8809e713
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2437
@@ -0,0 +1,37 @@
+qm terminal VMID return "Inappropriate ioctl for device" when spawned by an another process
+Description of problem:
+as i dont want to mess with vnc i want to use qm terminal to interact with my vms and it doesnt work im currently using nodejs as a test heres the code if anybody wanna try it 
+```js
+import { spawn } from "child_process";
+var child = spawn('qm', ["terminal", "100"]);
+
+child.stdout.setEncoding('utf8');
+child.stdin.setDefaultEncoding("utf8");
+child.stdout.on('data', function (data) {
+    console.log('stdout: ' + data.trim());
+});
+
+child.stderr.setEncoding('utf8');
+child.stderr.on('data', function (data) {
+    console.log('stderr: ' + data.trim());
+});
+
+child.on('close', function (code) {
+    console.log('closing code: ' + code);
+});
+
+setInterval(() => {
+    child.stdin.write("\n");
+}, 5000);
+```
+its just spawning qm terminal and sending return every 5 seconds
+
+it seems to start but crash
+
+"Inappropriate ioctl for device"
+
+![image](/uploads/dd1306f1b6437814cc90c9d1be0fcd3b/image.png){width=478 height=48}
+
+maybe its not the place to put that but i have no clue so here am i
+
+At least i tryed spawning something else my code is working
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2438 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2438
new file mode 100644
index 00000000..5888d269
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2438
@@ -0,0 +1 @@
+QEMU needs compat tweak to build against upstream capstone 6
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2439 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2439
new file mode 100644
index 00000000..58545ef8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2439
@@ -0,0 +1,9 @@
+qemu.org ssl certificate is expired
+Description of problem:
+
+Steps to reproduce:
+1. go to qemu.org
+2. look at it
+3. maybe screenshot
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2440 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2440
new file mode 100644
index 00000000..312af6b1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2440
@@ -0,0 +1,112 @@
+virtio-net: Use-After-Free during unrealization of virtio-net
+Description of problem:
+When hotplugging `virtio-net` device, mishandling of `failover` option may leads to use-after-free.
+More specifically, if we try to hotplug virtio-net device with `failover=on` and other invalid option (e.g. `rx_queue_size=0`), the device listner callback is registered but not unregistered before being freed, leading to UAF.
+Steps to reproduce:
+```sh
+cat <<EOF | qemu-system-i386 -M q35 -nodefaults -chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0
+device_add virtio-net,failover=on,rx_queue_size=0,bus=br1,id=dev0
+device_add virtio-net,failover=on,bus=br1,id=dev0
+quit
+EOF
+```
+
+If above command is not working, let me know so that I provide more information.
+Additional information:
+The following log leveals bug location:
+
+```sh
+$ cat <<EOF | qemu-system-i386 -M q35 -nodefaults -chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0
+device_add virtio-net,failover=on,rx_queue_size=0,bus=br1,id=dev0
+device_add virtio-net,failover=on,bus=br1,id=dev0
+quit
+EOF
+==836681==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+QEMU 8.1.93 monitor - type 'help' for more information
+VNC server running on 127.0.0.1:5900
+(qemu) device_add virtio-net,failover=on,rx_queue_size=0,bus=br1,id=dev0
+Error: Invalid rx_queue_size (= 0), must be a power of 2 between 256 and 1024.
+(qemu) device_add virtio-net,failover=on,bus=br1,id=dev0
+=================================================================
+==836681==ERROR: AddressSanitizer: heap-use-after-free on address 0x62e00000ab58 at pc 0x5577bbb8fe22 bp 0x7ffeb03fca50 sp 0x7ffeb03fca48
+READ of size 8 at 0x62e00000ab58 thread T0
+    #0 0x5577bbb8fe21 in qdev_should_hide_device /home/XXX/qemu/build/../hw/core/qdev.c:233:23
+    #1 0x5577bb14aac4 in qdev_device_add_from_qdict /home/XXX/qemu/build/../system/qdev-monitor.c:662:9
+    #2 0x5577bb14c364 in qdev_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:738:11
+    #3 0x5577bb14d6eb in qmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:860:11
+    #4 0x5577bb14e11d in hmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:968:5
+    #5 0x5577bb29aef4 in handle_hmp_command_exec /home/XXX/qemu/build/../monitor/hmp.c:1106:9
+    #6 0x5577bb298fa3 in handle_hmp_command /home/XXX/qemu/build/../monitor/hmp.c:1158:9
+    #7 0x5577bb2949ee in monitor_command_cb /home/XXX/qemu/build/../monitor/hmp.c:47:5
+    #8 0x5577bc2b0c3a in readline_handle_byte /home/XXX/qemu/build/../util/readline.c:419:13
+    #9 0x5577bb29d261 in monitor_read /home/XXX/qemu/build/../monitor/hmp.c:1390:13
+    #10 0x5577bbfda644 in fd_chr_read /home/XXX/qemu/build/../chardev/char-fd.c:72:9
+    #11 0x7f53d36e5c43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241)
+    #12 0x5577bc2536db in glib_pollfds_poll /home/XXX/qemu/build/../util/main-loop.c:290:9
+    #13 0x5577bc2536db in os_host_main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:313:5
+    #14 0x5577bc2536db in main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:592:11
+    #15 0x5577bb15dd06 in qemu_main_loop /home/XXX/qemu/build/../system/runstate.c:782:9
+    #16 0x5577bbb81115 in qemu_default_main /home/XXX/qemu/build/../system/main.c:37:14
+    #17 0x7f53d2c3fd8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
+    #18 0x7f53d2c3fe3f in __libc_start_main csu/../csu/libc-start.c:392:3
+    #19 0x5577ba4c3584 in _start (/usr/local/bin/qemu-system-i386+0x1ada584) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e)
+
+0x62e00000ab58 is located 42840 bytes inside of 43008-byte region [0x62e000000400,0x62e00000ac00)
+freed by thread T1 here:
+    #0 0x5577ba546122 in __interceptor_free (/usr/local/bin/qemu-system-i386+0x1b5d122) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e)
+    #1 0x5577bbba5135 in object_finalize /home/XXX/qemu/build/../qom/object.c:714:9
+    #2 0x5577bbba5135 in object_unref /home/XXX/qemu/build/../qom/object.c:1217:9
+    #3 0x5577bbb91ac3 in bus_free_bus_child /home/XXX/qemu/build/../hw/core/qdev.c:55:5
+
+previously allocated by thread T0 here:
+    #0 0x5577ba5463ce in malloc (/usr/local/bin/qemu-system-i386+0x1b5d3ce) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e)
+    #1 0x7f53d36ee738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241)
+    #2 0x5577bb14c364 in qdev_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:738:11
+    #3 0x5577bb29aef4 in handle_hmp_command_exec /home/XXX/qemu/build/../monitor/hmp.c:1106:9
+    #4 0x5577bb298fa3 in handle_hmp_command /home/XXX/qemu/build/../monitor/hmp.c:1158:9
+    #5 0x5577bb2949ee in monitor_command_cb /home/XXX/qemu/build/../monitor/hmp.c:47:5
+
+Thread T1 created by T0 here:
+    #0 0x5577ba52f84c in pthread_create (/usr/local/bin/qemu-system-i386+0x1b4684c) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e)
+    #1 0x5577bc1fcc24 in qemu_thread_create /home/XXX/qemu/build/../util/qemu-thread-posix.c:581:11
+    #2 0x5577bc229970 in rcu_init_complete /home/XXX/qemu/build/../util/rcu.c:415:5
+    #3 0x5577bc229970 in rcu_init /home/XXX/qemu/build/../util/rcu.c:471:5
+    #4 0x7f53d2c3feba in call_init csu/../csu/libc-start.c:145:3
+    #5 0x7f53d2c3feba in __libc_start_main csu/../csu/libc-start.c:379:5
+
+SUMMARY: AddressSanitizer: heap-use-after-free /home/XXX/qemu/build/../hw/core/qdev.c:233:23 in qdev_should_hide_device
+Shadow bytes around the buggy address:
+  0x0c5c7fff9510: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c5c7fff9520: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c5c7fff9530: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c5c7fff9540: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c5c7fff9550: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+=>0x0c5c7fff9560: fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd
+  0x0c5c7fff9570: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c5c7fff9580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c5c7fff9590: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c5c7fff95a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c5c7fff95b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+Shadow byte legend (one shadow byte represents 8 application bytes):
+  Addressable:           00
+  Partially addressable: 01 02 03 04 05 06 07
+  Heap left redzone:       fa
+  Freed heap region:       fd
+  Stack left redzone:      f1
+  Stack mid redzone:       f2
+  Stack right redzone:     f3
+  Stack after return:      f5
+  Stack use after scope:   f8
+  Global redzone:          f9
+  Global init order:       f6
+  Poisoned by user:        f7
+  Container overflow:      fc
+  Array cookie:            ac
+  Intra object redzone:    bb
+  ASan internal:           fe
+  Left alloca redzone:     ca
+  Right alloca redzone:    cb
+==836681==ABORTING
+```
+
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2441 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2441
new file mode 100644
index 00000000..a9b2af50
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2441
@@ -0,0 +1,100 @@
+virtio-net: memory leak when hotplugging virtio-net
+Description of problem:
+When invalid option for virtio-net device is provided during hotplug, allocated string is not freed, leading to memory leak.
+Steps to reproduce:
+```sh
+cat <<EOF | qemu-system-i386 -M q35 -nodefaults \
+-chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0
+device_add virtio-net,rx_queue_size=0,bus=br1,id=dev0
+quit
+EOF
+```
+
+If above command is not working, let me know so that I provide more information.
+Additional information:
+There is LeakSanitizer log:
+
+```sh
+$ cat <<EOF | LSAN_OPTIONS=fast_unwind_on_malloc=0 qemu-system-i386 -M q35 -nodefaults \
+-chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0
+device_add virtio-net,rx_queue_size=0,bus=br1,id=dev0
+quit
+EOF
+==831633==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+QEMU 8.1.93 monitor - type 'help' for more information
+VNC server running on 127.0.0.1:5900
+(qemu) device_add virtio-net,rx_queue_size=0,bus=br1,id=dev0
+Error: Invalid rx_queue_size (= 0), must be a power of 2 between 256 and 1024.
+(qemu) quit
+
+=================================================================
+==831633==ERROR: LeakSanitizer: detected memory leaks
+
+Direct leak of 15 byte(s) in 1 object(s) allocated from:
+    #0 0x55c1ac66b3ce in malloc (/usr/local/bin/qemu-system-i386+0x1b5d3ce) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e)
+    #1 0x7f45c1695738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241)
+    #2 0x7f45c16aa583 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x73583) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241)
+    #3 0x55c1ad943dd4 in virtio_net_set_netclient_name /home/XXX/qemu/build/../hw/net/virtio-net.c:3445:25
+    #4 0x55c1adace541 in virtio_net_pci_realize /home/XXX/qemu/build/../hw/virtio/virtio-net-pci.c:62:5
+    #5 0x55c1ad13ec00 in virtio_pci_realize /home/XXX/qemu/build/../hw/virtio/virtio-pci.c:2228:9
+    #6 0x55c1acdec557 in pci_qdev_realize /home/XXX/qemu/build/../hw/pci/pci.c:2117:9
+    #7 0x55c1adcb9484 in device_set_realized /home/XXX/qemu/build/../hw/core/qdev.c:510:13
+    #8 0x55c1adcd6278 in property_set_bool /home/XXX/qemu/build/../qom/object.c:2305:5
+    #9 0x55c1adcd1443 in object_property_set /home/XXX/qemu/build/../qom/object.c:1435:5
+    #10 0x55c1adcdd15c in object_property_set_qobject /home/XXX/qemu/build/../qom/qom-qobject.c:28:10
+    #11 0x55c1adcd1d11 in object_property_set_bool /home/XXX/qemu/build/../qom/object.c:1504:15
+    #12 0x55c1ad27021a in qdev_device_add_from_qdict /home/XXX/qemu/build/../system/qdev-monitor.c:719:10
+    #13 0x55c1ad271364 in qdev_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:738:11
+    #14 0x55c1ad2726eb in qmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:860:11
+    #15 0x55c1ad27311d in hmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:968:5
+    #16 0x55c1ad3bfef4 in handle_hmp_command_exec /home/XXX/qemu/build/../monitor/hmp.c:1106:9
+    #17 0x55c1ad3bdfa3 in handle_hmp_command /home/XXX/qemu/build/../monitor/hmp.c:1158:9
+    #18 0x55c1ad3b99ee in monitor_command_cb /home/XXX/qemu/build/../monitor/hmp.c:47:5
+    #19 0x55c1ae3d5c3a in readline_handle_byte /home/XXX/qemu/build/../util/readline.c:419:13
+    #20 0x55c1ad3c2261 in monitor_read /home/XXX/qemu/build/../monitor/hmp.c:1390:13
+    #21 0x55c1ae0ff644 in fd_chr_read /home/XXX/qemu/build/../chardev/char-fd.c:72:9
+    #22 0x7f45c168cc43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241)
+    #23 0x55c1ae3786db in glib_pollfds_poll /home/XXX/qemu/build/../util/main-loop.c:290:9
+    #24 0x55c1ae3786db in os_host_main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:313:5
+    #25 0x55c1ae3786db in main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:592:11
+    #26 0x55c1ad282d06 in qemu_main_loop /home/XXX/qemu/build/../system/runstate.c:782:9
+    #27 0x55c1adca6115 in qemu_default_main /home/XXX/qemu/build/../system/main.c:37:14
+    #28 0x7f45c0bd0d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
+    #29 0x7f45c0bd0e3f in __libc_start_main csu/../csu/libc-start.c:392:3
+
+Direct leak of 5 byte(s) in 1 object(s) allocated from:
+    #0 0x55c1ac66b3ce in malloc (/usr/local/bin/qemu-system-i386+0x1b5d3ce) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e)
+    #1 0x7f45c1695738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241)
+    #2 0x7f45c16aa583 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x73583) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241)
+    #3 0x55c1ad943da2 in virtio_net_set_netclient_name /home/XXX/qemu/build/../hw/net/virtio-net.c:3444:25
+    #4 0x55c1adace541 in virtio_net_pci_realize /home/XXX/qemu/build/../hw/virtio/virtio-net-pci.c:62:5
+    #5 0x55c1ad13ec00 in virtio_pci_realize /home/XXX/qemu/build/../hw/virtio/virtio-pci.c:2228:9
+    #6 0x55c1acdec557 in pci_qdev_realize /home/XXX/qemu/build/../hw/pci/pci.c:2117:9
+    #7 0x55c1adcb9484 in device_set_realized /home/XXX/qemu/build/../hw/core/qdev.c:510:13
+    #8 0x55c1adcd6278 in property_set_bool /home/XXX/qemu/build/../qom/object.c:2305:5
+    #9 0x55c1adcd1443 in object_property_set /home/XXX/qemu/build/../qom/object.c:1435:5
+    #10 0x55c1adcdd15c in object_property_set_qobject /home/XXX/qemu/build/../qom/qom-qobject.c:28:10
+    #11 0x55c1adcd1d11 in object_property_set_bool /home/XXX/qemu/build/../qom/object.c:1504:15
+    #12 0x55c1ad27021a in qdev_device_add_from_qdict /home/XXX/qemu/build/../system/qdev-monitor.c:719:10
+    #13 0x55c1ad271364 in qdev_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:738:11
+    #14 0x55c1ad2726eb in qmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:860:11
+    #15 0x55c1ad27311d in hmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:968:5
+    #16 0x55c1ad3bfef4 in handle_hmp_command_exec /home/XXX/qemu/build/../monitor/hmp.c:1106:9
+    #17 0x55c1ad3bdfa3 in handle_hmp_command /home/XXX/qemu/build/../monitor/hmp.c:1158:9
+    #18 0x55c1ad3b99ee in monitor_command_cb /home/XXX/qemu/build/../monitor/hmp.c:47:5
+    #19 0x55c1ae3d5c3a in readline_handle_byte /home/XXX/qemu/build/../util/readline.c:419:13
+    #20 0x55c1ad3c2261 in monitor_read /home/XXX/qemu/build/../monitor/hmp.c:1390:13
+    #21 0x55c1ae0ff644 in fd_chr_read /home/XXX/qemu/build/../chardev/char-fd.c:72:9
+    #22 0x7f45c168cc43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241)
+    #23 0x55c1ae3786db in glib_pollfds_poll /home/XXX/qemu/build/../util/main-loop.c:290:9
+    #24 0x55c1ae3786db in os_host_main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:313:5
+    #25 0x55c1ae3786db in main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:592:11
+    #26 0x55c1ad282d06 in qemu_main_loop /home/XXX/qemu/build/../system/runstate.c:782:9
+    #27 0x55c1adca6115 in qemu_default_main /home/XXX/qemu/build/../system/main.c:37:14
+    #28 0x7f45c0bd0d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
+    #29 0x7f45c0bd0e3f in __libc_start_main csu/../csu/libc-start.c:392:3
+
+SUMMARY: AddressSanitizer: 20 byte(s) leaked in 2 allocation(s).
+```
+
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2442 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2442
new file mode 100644
index 00000000..05c75831
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2442
@@ -0,0 +1,147 @@
+kvm-unit-tests ept failed
+Description of problem:
+On the Sierra Forest and Emerald Rapids platform, the ept test in kvm-unit-tests failed on the latest QEMU.
+
+QEMU first bad commit is 0b2757412cb1d1947d7e2c1fe14985f1e72bba32.
+
+This bad commit also caused other errors, such as:
+
+1.kvm-unit-tests vmx_pf_invvpid_test
+
+Test suite: vmx_pf_invvpid_test
+
+Host skipping test: INVVPID ADDR unsupported
+
+filter = vmx_pf_invvpid_test, test = vmx_pf_vpid_test
+
+filter = vmx_pf_invvpid_test, test = vmx_exception_test
+
+SUMMARY: 0 tests
+
+SKIP vmx_pf_invvpid_test (0 tests)
+
+2.kvm-unit-tests vmx_pf_no_vpid_test
+
+Test suite: vmx_pf_no_vpid_test
+
+run
+
+x86/vmx_tests.c:10568: assert failed: false: Unexpected exit to L1, exit_reason: VMX_CR (0x1c)
+        STACK: 40717c 4072a3 402039 403f11 4001bd
+
+FAIL vmx_pf_no_vpid_test
+
+3.kvm-unit-tests vmx:
+
+Test suite: vmx_controls_test
+
+FAIL: Clear primary processor-based controls bit 15: vmlaunch fails
+
+FAIL: Clear primary processor-based controls bit 16: vmlaunch fails
+
+Test suite: vmx_mtf_test
+
+FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual)
+        LHS: 0x0000000000000025 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0010'0101 - 37
+        RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28
+Expected VMX_MTF, got VMX_CR.
+        STACK: 406faa 407478 407911 402039 403f11 4001bd
+
+4.Failed to boot L2 guest on L1 windows guest, host does not support "Intel EPT" hardware assisted MMU virtualization.
+Steps to reproduce:
+1.git clone https://gitlab.com/kvm-unit-tests/kvm-unit-tests.git
+
+2.cd kvm-unit-tests; ./configure
+
+3.make standalone
+
+4.rmmod kvm_intel
+
+5.modprobe kvm_intel nested=Y allow_smaller_maxphyaddr=Y
+
+6.cd tests; ./ept
+Additional information:
+...
+Test suite: ept_access_test_paddr_not_present_ad_disabled
+FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual)
+        LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18
+        RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28
+Expected VMX_VMCALL, got VMX_CR.
+        STACK: 406faa 40730c 416905 416cf2 416f68 402039 403f11 4001bd
+filter = ept_access*, test = ept_access_test_paddr_not_present_ad_enabled
+
+Test suite: ept_access_test_paddr_not_present_ad_enabled
+FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual)
+        LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18
+        RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28
+Expected VMX_VMCALL, got VMX_CR.
+        STACK: 406faa 40730c 416905 416cf2 416f09 402039 403f11 4001bd
+filter = ept_access*, test = ept_access_test_paddr_read_only_ad_disabled
+
+Test suite: ept_access_test_paddr_read_only_ad_disabled
+FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual)
+        LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18
+        RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28
+Expected VMX_VMCALL, got VMX_CR.
+        STACK: 406faa 40730c 416905 416cf2 417150 402039 403f11 4001bd
+filter = ept_access*, test = ept_access_test_paddr_read_only_ad_enabled
+
+Test suite: ept_access_test_paddr_read_only_ad_enabled
+FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual)
+        LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18
+        RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28
+Expected VMX_VMCALL, got VMX_CR.
+        STACK: 406faa 40730c 416905 416cf2 416e14 402039 403f11 4001bd
+filter = ept_access*, test = ept_access_test_paddr_read_write
+
+Test suite: ept_access_test_paddr_read_write
+FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual)
+        LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18
+        RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28
+Expected VMX_VMCALL, got VMX_CR.
+        STACK: 406faa 40730c 416905 416fb1 4170fb 402039 403f11 4001bd
+filter = ept_access*, test = ept_access_test_paddr_read_write_execute
+
+Test suite: ept_access_test_paddr_read_write_execute
+FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual)
+        LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18
+        RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28
+Expected VMX_VMCALL, got VMX_CR.
+        STACK: 406faa 40730c 416905 416fb1 4170b0 402039 403f11 4001bd
+filter = ept_access*, test = ept_access_test_paddr_read_execute_ad_disabled
+
+Test suite: ept_access_test_paddr_read_execute_ad_disabled
+FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual)
+        LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18
+        RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28
+Expected VMX_VMCALL, got VMX_CR.
+        STACK: 406faa 40730c 416905 416cf2 416fde 402039 403f11 4001bd
+filter = ept_access*, test = ept_access_test_paddr_read_execute_ad_enabled
+
+Test suite: ept_access_test_paddr_read_execute_ad_enabled
+FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual)
+        LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18
+        RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28
+Expected VMX_VMCALL, got VMX_CR.
+        STACK: 406faa 40730c 416905 416cf2 416d1f 402039 403f11 4001bd
+filter = ept_access*, test = ept_access_test_paddr_not_present_page_fault
+
+Test suite: ept_access_test_paddr_not_present_page_fault
+filter = ept_access*, test = ept_access_test_force_2m_page
+
+Test suite: ept_access_test_force_2m_page
+filter = ept_access*, test = atomic_switch_max_msrs_test
+filter = ept_access*, test = atomic_switch_overflow_msrs_test
+filter = ept_access*, test = rdtsc_vmexit_diff_test
+filter = ept_access*, test = vmx_mtf_test
+filter = ept_access*, test = vmx_mtf_pdpte_test
+filter = ept_access*, test = vmx_pf_exception_test
+filter = ept_access*, test = vmx_pf_exception_forced_emulation_test
+filter = ept_access*, test = vmx_pf_no_vpid_test
+filter = ept_access*, test = vmx_pf_invvpid_test
+filter = ept_access*, test = vmx_pf_vpid_test
+filter = ept_access*, test = vmx_exception_test
+SUMMARY: 5824 tests, 8 unexpected failures
+FAIL ept (5824 tests, 8 unexpected failures)
+
+[error.log](/uploads/407a04df83bae220bca6fad3c9bba9ff/error.log)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2443 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2443
new file mode 100644
index 00000000..55df9732
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2443
@@ -0,0 +1,18 @@
+virtio-gpu-gl: "opengl is not available" message is too vague and doesn't suggest how to fix the problem
+Description of problem:
+I finally compiled qemu for Apple Silicon M2 Pro with opengl enabled and virtglrenderer enabled thanks to instruction from homebrew formula,
+but I did it without homebrew nor macports just manually compiling necessary libraries.
+Qemu was compiled succesfully with flags:
+````
+./configure --target-list=aarch64-softmmu,x86_64-softmmu --enable-cocoa  --enable-sdl --enable-virglrenderer --enable-vhost-net   --enable-spice-protocol --enable-tools --enable-opengl --enable-pixman --enable-vmnet
+````
+
+the device is clearly listed:
+````
+name "virtio-gpu-device", bus virtio-bus
+name "virtio-gpu-gl-device", bus virtio-bus
+name "virtio-gpu-gl-pci", bus PCI, alias "virtio-gpu-gl"
+name "virtio-gpu-pci", bus PCI, alias "virtio-gpu"
+````
+
+So why it not working and gives that info while opengl is clearly there and is enabled.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2444 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2444
new file mode 100644
index 00000000..e124800f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2444
@@ -0,0 +1 @@
+Use of vulnerable function 'strcpy' at can_socketcan.c:213. This function is unsafe.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2446 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2446
new file mode 100644
index 00000000..c3bc6409
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2446
@@ -0,0 +1,60 @@
+linux-user: Qemu doesn't support `set_robust_list` used by glibc robust mutex implementation
+Description of problem:
+It seems that syscall set_robust_list is not implemented on Qemu for any Linux platform: [link]( https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L12811)
+Steps to reproduce:
+1.  Use below toy program `set_robust_list.c` and compile it without optimizations like:
+```
+    gcc -Wall -W -Wextra -std=gnu17 -pedantic set_robust_list.c -o set_robust_list
+```
+
+```
+#include <stdio.h>
+#include <stdlib.h>
+#include <errno.h>
+#include <sys/syscall.h>
+#include <sys/types.h>
+#include <unistd.h>
+#include <linux/futex.h>
+#include <syscall.h>
+
+int main(void)
+{
+#ifdef __NR_set_robust_list
+    struct robust_list_head head;
+    size_t len = sizeof(struct robust_list_head);
+
+    // This call to set_robust_list function should fail
+    int err = syscall(__NR_set_robust_list, &head, -1);
+    if (err < 0)
+        perror("1st set_robust_list error");
+    else
+        puts("1st set_robust_list OK");
+
+    // This call to set_robust_list function should be sucessful
+    err = syscall(__NR_set_robust_list, &head, len);
+    if (err < 0)
+        perror("2nd set_robust_list error");
+    else
+        puts("2nd set_robust_list OK");
+#else
+    puts("No set_robust_list support");
+#endif
+    exit(0);
+}
+```
+
+2. Run program on Qemu and compare output with output from x64 build. In my case it looks like:
+```
+root@AMDC4705:/runtime/set_robust_list# ./set_robust_list
+1st set_robust_list error: Invalid argument
+2nd set_robust_list OK
+root@AMDC4705:/runtime/set_robust_list# ./set_robust_list-riscv
+1st set_robust_list error: Function not implemented
+2nd set_robust_list error: Function not implemented
+```
+Additional information:
+Working `set_robust_list` on Linux is quite important in context of named robust mutexes. In NPTL `set_robust_list` is used internally at ld.so initialization time to perform following check: [link](https://github.com/bminor/glibc/blob/master/sysdeps/nptl/dl-tls_init_tp.c#L96)
+
+When syscall fails, later `pthread_mutex_init` (with `PTHREAD_MUTEX_ROBUST` + `PTHREAD_PROCESS_SHARED` attributes) end up with `ENOTSUP` error [link](https://github.com/bminor/glibc/blob/master/nptl/pthread_mutex_init.c#L99).
+
+In dotnet we use robust mutexes for process synchronization purpose. Although there are other available techniques like named semaphores or file locks, robust mutexes are better locking option in case of unexpected process death.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2447 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2447
new file mode 100644
index 00000000..e9240066
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2447
@@ -0,0 +1,23 @@
+With -display sdl,gl=on and 3D acceleration, the position of mouse does not show correctly
+Description of problem:
+Real mouse position is nearly 100 px on the left of drawn cursor. The closer the cursor to the lower right corner of the VM window, the worse (divergence becomes way bigger than 100 px).
+
+Split off from https://gitlab.com/qemu-project/qemu/-/issues/761
+
+VM window is not necessary to be resized to reproduce this bug. If your VM desktop comes 1920x1080 originally, the bug can be reproduced from the very start.
+
+Smaller resolutions show this bug too, but it not so noticeable.
+Steps to reproduce:
+1. Download and install official QEMU 9.0 from https://qemu.weilnetz.de/w64/qemu-w64-setup-20240423.exe
+2. Go to https://www.kali.org/get-kali/#kali-virtual-machines and click big QEMU 64 icon, and wait till kali-linux-2024.2-qemu-amd64.7z has been downloaded
+3. Extract kali-linux-2024.2-qemu-amd64.qcow2 from kali-linux-2024.2-qemu-amd64.7z
+4. Run it: `qemu-system-x86_64.exe -accel tcg -device virtio-vga-gl -display sdl,gl=on -hda C:\kali-linux-2024.2-qemu-amd64.qcow2 -usb -device usb-tablet -m 4096 -machine q35 -smp 2 -cpu Westmere`
+5. Enter `kali` as user and `kali` as password when prompted
+6. When the desktop is shown up, click the leftmost, upmost blue "Applications" button. Then click Settings -\> Display
+7. Pick 1920x1080 as resolution and click Apply, then Keep this configuration.
+8. Click Firefox Browser icon on the top panel.
+9. When the browser starts working, experience how hard to use its interface, though it's fast. Real mouse position is nearly 100 px on the left of drawn cursor. The closer the cursor to the lower right corner of the VM window, the worse (divergence becomes way bigger than 100 px).
+Additional information:
+Run `qemu-system-x86_64.exe -accel tcg -device virtio-vga -display sdl -hda C:\kali-linux-2024.2-qemu-amd64.qcow2 -usb -device usb-tablet -m 4096 -machine q35 -smp 2 -cpu Westmere` and experience correct behavior.
+
+Mouse in Gtk mode works ok. OpenGL not available for Windows in GTK mode.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2448 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2448
new file mode 100644
index 00000000..3f791d0d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2448
@@ -0,0 +1,46 @@
+linux-user as binfmt_misc fails to recognize AT_EXECFD if it's 0 and leaves it open as stdin
+Description of problem:
+When a `*-linux-user` is used as binfmt_misc, and...
+
+- The `O` (i.e. open-binary) flag is set
+- File descriptor 0 is closed when running the executable
+
+FD 0 is opened to point at the executable and passed as `AT_EXECFD`, which QEMU fails to recognize and leaves open before handing control over to the executable, leading to the program to think stdin is opened for reading its own executable.
+
+Some use cases rely on closed stdin to behave correctly. For example, this problem causes the `tests/tail/follow-stdin.sh` and `tests/tac/tac-2-nonseekable.sh` tests in GNU coreutils to fail. In any case, having the executable itself be stdin is definitely incorrect and quite surprising behavior.
+Steps to reproduce:
+1. Set up qemu-riscv64 as binfmt_misc with `qemu-binfmt-conf.sh`, with the `--credential` flag (which enables open-binary)
+2. Get a coreutils built for riscv64 (Let's say it can be found in `riscv64-coreutils/bin`)
+3. Run it with something like `riscv64-coreutils/bin/cat <&- | xxd | head` (`xxd | head` to catch the binary output)
+
+The correct behavior is (You can see by running the native `cat <&-`):
+
+```
+cat: -: Bad file descriptor
+cat: closing standard input: Bad file descriptor
+```
+
+Instead, the executable `cat` itself is dumped to stdout.
+
+Perhaps slightly more clear is `riscv64-coreutils/bin/ls -l /proc/self/fd <&-` which shows fd 0 unexpectedly pointing to the coreutils executable.
+Additional information:
+I'm interested in writing a patch to fix this issue but I'm uncertain how to proceed. This is what I've found so far:
+
+In `linux-user/main.c` if (effectively) `getauxval(AT_EXECFD)` is 0 it's treated as nonexistent. (https://gitlab.com/qemu-project/qemu/-/blob/0d9f1016d43302108d33d1268304a06cc3fb2021/linux-user/main.c#L758-765)
+
+```c
+    execfd = qemu_getauxval(AT_EXECFD);
+    if (execfd == 0) {
+        execfd = open(exec_path, O_RDONLY);
+        if (execfd < 0) {
+            printf("Error while loading %s: %s\n", exec_path, strerror(errno));
+            _exit(EXIT_FAILURE);
+        }
+    }
+```
+
+However as we've seen `getauxval(AT_EXECFD)` can have 0 as a valid value.
+
+`qemu_getauxval` in `util/getauxval.c` implements several strategies to get the auxv, but doesn't currently give a way to distinguish not found and 0. FreeBSD `elf_aux_info` has `EINVAL` and `ENOENT` error codes but it's ignored here. On Linux, glibc sets `errno` to `ENOENT` to distinguish the two cases but only on glibc >= 2.19. Musl's `getauxval` has always had setting `errno` to `ENOENT`.
+
+Once we add a proper "`AT_EXECFD` doesn't exist" check this will no longer be a problem since (IIUC) `execfd` will eventually be closed after loading. How should we add "not found" support to `qemu_getauxval`? Is just simply relying on libc's `getauxval` setting `errno` okay?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2449 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2449
new file mode 100644
index 00000000..d2d0f46e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2449
@@ -0,0 +1 @@
+How to extract FIS (personal question)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2451 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2451
new file mode 100644
index 00000000..46eada49
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2451
@@ -0,0 +1 @@
+Italian language (po) not updated
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2454 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2454
new file mode 100644
index 00000000..13af8c3b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2454
@@ -0,0 +1,8 @@
+sd: assertion in sd_read_byte()
+Description of problem:
+The following log reveals it:
+
+```
+ERROR: qemu/hw/sd/sd.c:2541:sd_read_byte: code should not be reached
+Bail out! ERROR: qemu/hw/sd/sd.c:2541:sd_read_byte: code should not be reached Aborted (core dumped)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2455 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2455
new file mode 100644
index 00000000..f2c88aa5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2455
@@ -0,0 +1,8 @@
+sdhci: assertion in sdhci_read_dataport()
+Description of problem:
+The following log reveals it:
+
+```
+qemu-system-x86_64: qemu/hw/sd/sdhci.c:476: uint32_t sdhci_read_dataport(SDHCIState *, unsigned int): Assertion `s->data_count < s->buf_maxsz' failed.
+Aborted (core dumped)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2457 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2457
new file mode 100644
index 00000000..50fb869b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2457
@@ -0,0 +1 @@
+Building plugin sources doesn't produce any output to 'make'
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2458 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2458
new file mode 100644
index 00000000..93e31b9e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2458
@@ -0,0 +1 @@
+Documentation build fails with Sphinx 8
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2459 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2459
new file mode 100644
index 00000000..f1ebebf9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2459
@@ -0,0 +1 @@
+Qemu in termux network bug
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/246 b/gitlab/issues_text/target_missing/host_missing/accel_missing/246
new file mode 100644
index 00000000..7f89ebcc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/246
@@ -0,0 +1 @@
+Build fails with 64 bits time_t
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2465 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2465
new file mode 100644
index 00000000..8260b101
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2465
@@ -0,0 +1 @@
+QEMU does not stop other threads when hitting a breakpoint
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2466 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2466
new file mode 100644
index 00000000..75884d1d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2466
@@ -0,0 +1,24 @@
+I'm not sure. But I Think I could cause the err(include/qemu/queue.h).
+Description of problem:
+At file "include/qemu/queue.h", Maybe I Think QTAILQ_REMOVE could cause a Error.
+
+```
+#define QTAILQ_REMOVE(head, elm, field) do {                            \
+       if (((elm)->field.tqe_next) != NULL)                            \
+           (elm)->field.tqe_next->field.tqe_circ.tql_prev =            \
+               (elm)->field.tqe_circ.tql_prev;                         \
+       else                                                            \
+           (head)->tqh_circ.tql_prev = (elm)->field.tqe_circ.tql_prev; \
+       (elm)->field.tqe_circ.tql_prev->tql_next = (elm)->field.tqe_next; \
+       (elm)->field.tqe_circ.tql_prev = NULL;                          \
+       (elm)->field.tqe_circ.tql_next = NULL;                          \
+       (elm)->field.tqe_next = NULL;                                   \
+} while (/*CONSTCOND*/0)
+```
+If the length of the que is one, line 7 cause a segmentation fault.
+Steps to reproduce:
+1. Create a Que with QTAILQ_INIT
+2. Add one element to que.
+3. Remove the element with QTAILQ_REMOVE
+Additional information:
+queue.h file is located at "inclue/qemu/queue.h"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2471 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2471
new file mode 100644
index 00000000..f2a9849b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2471
@@ -0,0 +1 @@
+error handling in of_dpa_cmd_add_acl()
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2472 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2472
new file mode 100644
index 00000000..a56f72a9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2472
@@ -0,0 +1 @@
+optimize nvme_directive_receive() function
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2475 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2475
new file mode 100644
index 00000000..3dab86fd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2475
@@ -0,0 +1 @@
+Inconsistency between cpu_tb_exec() and qemu_plugin_register_vcpu_tb_exec_cb()?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2476 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2476
new file mode 100644
index 00000000..536d1674
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2476
@@ -0,0 +1,52 @@
+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/gitlab/issues_text/target_missing/host_missing/accel_missing/2477 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2477
new file mode 100644
index 00000000..ace7a0a3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2477
@@ -0,0 +1 @@
+GDB_HAS_MTE detection is incomplete
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2478 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2478
new file mode 100644
index 00000000..1b5690c2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2478
@@ -0,0 +1,18 @@
+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/gitlab/issues_text/target_missing/host_missing/accel_missing/248 b/gitlab/issues_text/target_missing/host_missing/accel_missing/248
new file mode 100644
index 00000000..f9e90fc1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/248
@@ -0,0 +1 @@
+Reconnect failed with loopback virtio1.1 server mode test
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2480 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2480
new file mode 100644
index 00000000..c562db4e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2480
@@ -0,0 +1,29 @@
+Two questions about VFIO device live migration
+Description of problem:
+For my own pcie device, i implement system memory && device memory dirty bitmap track and works well
+
+use pre-copy mode live migration by the way.
+
+first question:
+- for system memory dirty bitmap sync, notice that last sync will come early than i expected
+  read qemu code and found qemu will call every savevm_state.handlers->save_live_complete_precopy callback 
+  in "qemu_savevm_state_complete_precopy_iterable", and "vfio" handler will always behind "ram".
+  so here is question, my own vfio device will only be halted after "vfio" handler enter 
+  save_live_complete_precopy, and last system memory dirty bitmap sync will come with "ram"'s 
+  save_live_complete_precopy, there will be some system dirty between this period, should we add one more 
+  system dirty bitmap sync after "vfio"'s save_live_complete_precopy
+
+second question:
+- notice that qemu will clean up migration and call every savevm_state.handlers->save_cleanup call back, and   
+  in this function, qemu will only call vfio listener's log_global_stop call back when vm_is_running 
+  but for my vfio device, state will be paused(postmigrate) when enter here, so there is no chance for qemu 
+  to relese some resource create by my device kernel mode driver, where should i put the logic about "stop 
+  migration resource" anyway
+
+Thanks ^_^
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2481 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2481
new file mode 100644
index 00000000..34b61a72
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2481
@@ -0,0 +1 @@
+Possible dereference of NULL
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2482 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2482
new file mode 100644
index 00000000..ac1bb2cc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2482
@@ -0,0 +1,136 @@
+qemu-system-x86_64: Live Migration fails with BLOCK_JOB_ERROR
+Description of problem:
+After disk migration is completed and RAM migration is being performed, migration status switches to 'pre-switchover'.
+In the 'pre-switchover' migration state, block jobs status is still set to 'ready' instead of 'running'
+on queried for block job status when 'offset' and 'length' diverged. Thus, It results in BLOCK_JOB_ERROR.
+Steps to reproduce:
+On source host
+1. Add disk(s) that needed to be migrated by issuing 'blockdev-add' QMP command.
+2. start blockdev-mirror operations to perform disk(s) transfer by issuing QMP command
+3. start RAM migration. (send HMP commands - listed below
+4. Migration status changed to 'pre-switchover'. While in 'pre-switchover', check for disk activity
+
+While RAM migration is happening, Migration status is changed to 'pre-switchover'
+and observe that block jobs 'offset' and 'length' diverged. But, block job status is still set to 'ready' instead of 'running'.
+
+On destination host
+1. Launch the VM in listening mode (-incoming) for migrations
+2. start NBD server
+3. add disks to NBD server.
+4. set migration parameters by sending HMP commands
+Additional information:
+# On SOURCE Host, start all blockdev-add operations
+# Issue QMP commands (blockdev-add) for all block devices ("drive-scsi-disk-0" and "drive-scsi-disk-1") of VM
+
+```
+            {
+                "execute"   => "blockdev-add",
+                "arguments" => {
+                    "driver"         => "raw",
+                    "node-name"      => "node_drive-scsi-disk-0",
+                    "auto-read-only" => false,
+                    "read-only"      => false,
+                    "file"           => {
+                        "driver" => "nbd",
+                        "export" => "drive-scsi-disk-0",
+                        "server" => {
+                            "type" => "inet",
+                            "host" => "2600:3c0f:17:14::21",
+                            "port" => "37552",
+                        },
+                        "tls-creds" => "tlscreds0"
+                    }
+                }
+            }
+```
+
+            {
+                "execute"   => "blockdev-add",
+                "arguments" => {
+                    "driver"         => "raw",
+                    "node-name"      => "node_drive-scsi-disk-1",
+                    "auto-read-only" => false,
+                    "read-only"      => false,
+                    "file"           => {
+                        "driver" => "nbd",
+                        "export" => "drive-scsi-disk-1",
+                        "server" => {
+                            "type" => "inet",
+                            "host" => "2600:3c0f:17:14::21",
+                            "port" => "37552",
+                        },
+                        "tls-creds" => "tlscreds0"
+                    }
+                }
+            }
+
+# On SOURCE Host, start all blockdev-mirror operations to start disk transfer
+# i.e Issue QMP commands (blockdev-mirror) for each of those block devices ("drive-scsi-disk-0" and "drive-scsi-disk-1")
+
+```
+        {
+            "execute"   => "blockdev-mirror",
+            "arguments" => {
+                "device" => "drive-scsi-disk0",
+                "target" => "node_drive-scsi-disk-0",
+                "speed"  => 100000000,
+                "sync"   => "full",
+            }
+        }
+```
+
+```
+        {
+            "execute"   => "blockdev-mirror",
+            "arguments" => {
+                "device" => "drive-scsi-disk1",
+                "target" => "node_drive-scsi-disk-1",
+                "speed"  => 100000000,
+                "sync"   => "full",
+            }
+        }
+```
+
+# NBD server configuration on destination host by issuing QMP command
+# Start NBD server
+```
+        {
+            "execute"   => "nbd-server-start",
+            "arguments" => {
+                "addr" => {
+                    "type" => "inet",
+                    "data" => {
+                        "host" => "2600:3c0f:17:14::21",
+                        "port" => "37552"
+                    }
+                },
+                "tls-creds" => "tlscreds0"
+            }
+        }
+```
+
+# On DESTINATION Host
+# Register incoming disks(2) with NBD server by issuing QMP commands to VM on the destination host
+# Disk# 1
+```
+        {
+            "execute"   => "nbd-server-add",
+            "arguments" => {
+                "device"   => "drive-scsi-disk0",
+                "writable" => true
+            }
+        }
+```
+# Disk# 2
+```
+        {
+            "execute"   => "nbd-server-add",
+            "arguments" => {
+                "device"   => "drive-scsi-disk1",
+                "writable" => true
+            }
+        }
+```
+
+# Wait for disks to finish the bulk of the data migration.
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2485 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2485
new file mode 100644
index 00000000..3b80f94f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2485
@@ -0,0 +1,47 @@
+getifaddrs linked with musl libc hangs on big-endian targets
+Description of problem:
+When the following C program (borrowed from curl's `configure`) is compiled for { m68k, ppc, ppc64, s390x } (possibly others, like or1k and sparc) and linked against musl libc, it hangs inside musl when run. Copying the same binaries to real hardware results in success.
+
+```c
+#include <stdlib.h>
+#include <ifaddrs.h>
+
+int
+main (void)
+{
+
+    struct ifaddrs *ifa = 0;
+    int error;
+
+    error = getifaddrs(&ifa);
+    if (error || !ifa)
+        exit(1);
+    else
+        exit(0);
+
+    return 0;
+}
+```
+Steps to reproduce:
+1. Compile the above program and link it with musl libc (pre-built toolchains are available [here](https://musl.cc/))
+2. Run the appropriate `qemu-*` (e.g. `qemu-m68k ./test` or `qemu-ppc ./test`)
+3. Observe that the process hangs.
+Additional information:
+This has come up elsewhere:
+
+* https://bugs.gentoo.org/914256
+* https://www.openwall.com/lists/musl/2018/05/30/4
+* Likely affects or1k but I can't test that at the moment (need to debug an unrelated issue with that toolchain)
+* Likely affects sparc but that port/toolchain is also a WIP
+
+Here are some static sample binaries for the above program:
+
+* https://temp.zv.io/qemu-bug.tar.xz (no guarantees of continued existence months or years later)
+
+GitLab labels seem to be missing:
+
+* ~"kind::Bug"
+* ~"linux-user"
+* ~"target: ppc"
+* ~"target: m68k"
+* ~"target: s390x"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2490 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2490
new file mode 100644
index 00000000..fe28dc94
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2490
@@ -0,0 +1,51 @@
+Windows: virtio-vga-gl no longer works with current virglrenderer version
+Description of problem:
+Error occurs, when executing QEMU with virtio-vga-gl device using current virglrenderer:
+First the boot screen is shown as expected.
+After a short while the screen shows and keeps showing "virtio-vga-gl: Display output is not active."
+Console logs:
+```
+qemu: GtkGLArea console lacks DMABUF support.
+qemu: GtkGLArea console lacks DMABUF support.
+qemu: GtkGLArea console lacks DMABUF support.
+qemu: GtkGLArea console lacks DMABUF support.
+Realize gdk gl context failed: GL-Kontext kann nicht erstellt werden
+Realize gdk gl context failed: GL-Kontext kann nicht erstellt werden
+virtio_gpu_virgl_process_cmd: ctrl 0x103, error 0x1203
+virtio_gpu_virgl_process_cmd: ctrl 0x103, error 0x1203
+virtio_gpu_virgl_process_cmd: ctrl 0x103, error 0x1203
+```
+Steps to reproduce:
+1. Prepare current Msys2/Ucrt64 environment including virglrenderer 1.0.1 by installing QEMU as described in https://www.qemu.org/download/#windows
+2. `wget https://download.opensuse.org/distribution/leap/15.3/live/openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso`
+3. `qemu-system-x86_64.exe -m 1024 -display gtk,gl=on -device virtio-vga-gl -cdrom openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso`
+Additional information:
+virglrenderer may use certain D3D features starting with virglrenderer 1.0.0, see https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1103 for details
+
+Given virglrenderer >= 1.0.0, QEMU activates these D3D features since https://gitlab.com/qemu-project/qemu/-/commit/c1600f84ce011a056c9c432c8ad8d77f7f8b9e6f.
+
+But the current QEMU implementation is broken when using these D3D features. 
+
+git bisect finishes with:
+```
+574b64aa6754ba491f51024c5a823a674d48a658 is the first bad commit
+commit 574b64aa6754ba491f51024c5a823a674d48a658
+Author: Dmitry Osipenko <dmitry.osipenko@collabora.com>
+Date:   Mon Jan 29 10:39:21 2024 +0300
+
+    virtio-gpu: Correct virgl_renderer_resource_get_info() error check
+
+    virgl_renderer_resource_get_info() returns errno and not -1 on error.
+    Correct the return-value check.
+
+    Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
+    Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
+    Message-Id: <20240129073921.446869-1-dmitry.osipenko@collabora.com>
+    Cc: qemu-stable@nongnu.org
+    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
+    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+
+ contrib/vhost-user-gpu/virgl.c | 6 +++---
+ hw/display/virtio-gpu-virgl.c  | 2 +-
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2492 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2492
new file mode 100644
index 00000000..eb8c3945
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2492
@@ -0,0 +1,20 @@
+Unable to disable gvnc dependency during build
+Description of problem:
+The qtest tests will pick up a copy of gvnc if it happens to be installed and there does not appear
+to be any way of disabling the dependency to ensure a reproducible build. We tripped over this in
+bulk builds on OpenBSD.
+Steps to reproduce:
+1. Install gvnc
+2. Build QEMU
+Additional information:
+From tests/qtest/meson.build
+
+```
+if vnc.found()
+  gvnc = dependency('gvnc-1.0', method: 'pkg-config', required: false)
+  if gvnc.found()
+    qtests += {'vnc-display-test': [gvnc]}
+    qtests_generic += [ 'vnc-display-test' ]
+  endif
+endif
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2493 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2493
new file mode 100644
index 00000000..11521877
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2493
@@ -0,0 +1 @@
+qemu-img delete snapshot by id
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2494 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2494
new file mode 100644
index 00000000..7a40b89f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2494
@@ -0,0 +1 @@
+Isolated network between VMs not visible to the host
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2496 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2496
new file mode 100644
index 00000000..72f7c471
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2496
@@ -0,0 +1,33 @@
+Regression 9.1.0-rc1: Adventcalendar 2016, Day 14 crashes
+Description of problem:
+Crashes with 
+   ```
+	**** PANIC: ****
+ terminating with uncaught exception of type hw::Device_not_found: Device of type NIC not found at position #0
+   ```
+see [acorn.log](/uploads/daa06857763716183cec625ead619387/acorn.log) for details
+Steps to reproduce:
+1. Download https://www.qemu-advent-calendar.org/2016/download/day14.tar.xz
+2. Execute
+Additional information:
+git bisect determines:
+   ```
+64f75f57f9d2c8c12ac6d9355fa5d3a2af5879ca is the first bad commit
+commit 64f75f57f9d2c8c12ac6d9355fa5d3a2af5879ca
+Author: David Woodhouse <dwmw@amazon.co.uk>
+Date:   Tue Jul 9 13:34:44 2024 +0100
+
+    net: Reinstate '-net nic, model=help' output as documented in man page
+    
+    While refactoring the NIC initialization code, I broke '-net nic,model=help'
+    which no longer outputs a list of available NIC models.
+    
+    Fixes: 2cdeca04adab ("net: report list of available models according to platform")
+    Cc: qemu-stable@nongnu.org
+    Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
+    Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
+    Signed-off-by: Jason Wang <jasowang@redhat.com>
+
+ net/net.c | 25 ++++++++++++++++++++++---
+ 1 file changed, 22 insertions(+), 3 deletions(-)
+   ```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/250 b/gitlab/issues_text/target_missing/host_missing/accel_missing/250
new file mode 100644
index 00000000..a3ab92c5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/250
@@ -0,0 +1 @@
+windows qemu-img fails to convert vhdx, assertion failure
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2501 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2501
new file mode 100644
index 00000000..a4451aa3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2501
@@ -0,0 +1 @@
+compile qemu as a shared library
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2503 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2503
new file mode 100644
index 00000000..42a28bd0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2503
@@ -0,0 +1,9 @@
+how to install  cmake scipt in QEMU with riscv
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2505 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2505
new file mode 100644
index 00000000..15f79cbf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2505
@@ -0,0 +1 @@
+Interpreter ELF flags ignored when selecting CPU
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2506 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2506
new file mode 100644
index 00000000..d2c0733e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2506
@@ -0,0 +1,58 @@
+LC_RPATH stripped despite setting INSTALL_REMOVE_ENVIRONMENT_RPATH=FALSE
+Description of problem:
+When I try to run qemu, I get the following output:
+> dyld[93165]: Library not loaded: @rpath/libjpeg.62.dylib
+>   Referenced from: <85BC1FBA-CA2E-3CAC-9ABF-E5330AC86CAF> /Users/mj/local/bin/qemu-system-aarch64
+>   Reason: no LC_RPATH's found
+Steps to reproduce:
+If the qemu-9.0.2 folder is present, remove it:
+```
+$ rm -rf qemu-9.0.2
+```
+Create the source folder:
+```
+$ tar xzf qemu-9.0.2.tar.xz
+$ cd qemu-9.0.2
+```
+
+Make sure the following environment variables are set:
+```
+$ export CC=clang
+$ export LDFLAGS="-rpath $HOME/local/lib"
+$ export INSTALL_REMOVE_ENVIRONMENT_RPATH=FALSE
+```
+
+Configure as follows:
+```
+$ ./configure --prefix=$HOME/local --disable-sdl --enable-slirp --enable-fdt=internal --enable-spice
+```
+
+Build
+```
+$ make -j 10
+```
+
+Note there are a large number of linker warnings like this:
+> ld: warning: duplicate -rpath '/Users/mj/local/lib' ignored
+
+Execute this:
+```
+$ otool -l build/qemu-system-aarch64 | grep LC_RPATH -A2
+```
+
+See this output
+>          cmd LC_RPATH
+>      cmdsize 32
+>         path /Users/mj/local/lib (offset 12) 
+
+Change directory to $HOME/local/bin & execute:
+```
+$ otool -l qemu-system-aarch64 | grep LC_RPATH -A2
+```
+
+The output is now empty - the LC_RPATH has been stripped by the install.  This results in the failure to execute the resulting binary.  Note, I tried using install_name_tool to add the RPATH, but it warned me this changed the signature of the file, and it would not run.
+
+Executing qemu-system-aarch64 produces the following:
+>  dyld[93165]: Library not loaded: @rpath/libjpeg.62.dylib
+>    Referenced from: <85BC1FBA-CA2E-3CAC-9ABF-E5330AC86CAF> /Users/mj/local/bin/qemu-system-aarch64
+>    Reason: no LC_RPATH's found
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2508 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2508
new file mode 100644
index 00000000..fcf59e5d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2508
@@ -0,0 +1 @@
+test-aio unreliable on MSYS2
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/251 b/gitlab/issues_text/target_missing/host_missing/accel_missing/251
new file mode 100644
index 00000000..04253a5f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/251
@@ -0,0 +1 @@
+Qemu DOS Quake - 640x480 and above resolutions - Unable to load VESA palette in dos prompt and game crashing are not working
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2510 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2510
new file mode 100644
index 00000000..b70c807f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2510
@@ -0,0 +1,45 @@
+Cross compiling tools / qemu-img results in "ninja: no work to do"
+Description of problem:
+I have the following Dockerfile setting up a cross-compile environment for QEMU.
+I am trying to build qemu-img.exe only at the moment
+
+
+```
+FROM fedora as builder
+RUN --mount=type=cache,target=/var/cache \
+        dnf -v install --assumeyes strace gcc make mingw64-gcc mingw64-binutils python-setuptools meson mingw64-glib2-static mingw64-glib2 diffutils
+
+FROM builder as qemu-builder
+WORKDIR /src/qemu #assuming qemu source tree is already available at /src/qemu
+RUN
+RUN ./configure --cross-prefix=x86_64-w64-mingw32- --target-list='' --static
+RUN make V=1 tools
+```
+With either `make tools` or `make qemu-img.exe` I get
+
+```
+#10 0.265 changing dir to build for make "tools"...
+#10 0.267 make[1]: Entering directory '/src/qemu/build'
+#10 0.330 ninja: no work to do.
+#10 0.331 { \
+#10 0.331   echo 'ninja-targets = \'; \
+#10 0.331   /usr/bin/ninja -t targets all | sed 's/:.*//; $!s/$/ \\/'; \
+#10 0.331   echo 'build-files = \'; \
+#10 0.331   /usr/bin/ninja -t query build.ninja | sed -n '1,/^  input:/d; /^  outputs:/q; s/$/ \\/p'; \
+#10 0.331 } > Makefile.ninja.tmp && mv Makefile.ninja.tmp Makefile.ninja
+#10 0.363 /src/qemu/build/pyvenv/bin/meson introspect --targets --tests --benchmarks | /src/qemu/build/pyvenv/bin/python3 -B scripts/mtest2make.py > Makefile.mtest
+#10 0.634 make[1]: Nothing to be done for 'tools'.
+#10 0.634 make[1]: Leaving directory '/src/qemu/build'
+#10 DONE 0.6s
+```
+
+Following the info in `make help`, I tried `make qemu-img.o` which resulted in
+
+```
+cc    -c -o qemu-img.o qemu-img.c
+qemu-img.c:25:10: fatal error: qemu/osdep.h: No such file or directory
+   25 | #include "qemu/osdep.h"
+      |          ^~~~~~~~~~~~~~
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2512 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2512
new file mode 100644
index 00000000..c87e6366
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2512
@@ -0,0 +1,45 @@
+macOS builds of target arm-softmmu broken
+Description of problem:
+Attempting to build for target `arm-softmmu` on macOS fails with errors:
+
+```
+[919/2786] Compiling C object libblock.a.p/block_file-posix.c.o
+FAILED: libblock.a.p/block_file-posix.c.o 
+clang -Ilibblock.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -Iblock -I/nix/store/vb7baj6dq2mvynfh6zmwxz57w83h7w0q-zlib-1.3.1-dev/include -I/nix/store/k1yzx1ykpwmhqvyr0j5fxvs9px7k92m7-glib-2.80.4-dev/include/glib-2.0 -I/nix/store/fm2kb8jvvc9s9nhi2gpr3jp6xxjxcvkq-glib-2.80.4/lib/glib-2.0/include -I/nix/store/k1yzx1ykpwmhqvyr0j5fxvs9px7k92m7-glib-2.80.4-dev/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -fstack-protector-strong -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wformat-security -Wformat-y2k -Wignored-qualifiers -Winit-self -Wmissing-format-attribute -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wredundant-decls -Wstrict-prototypes -Wtype-limits -Wundef -Wvla -Wwrite-strings -Wno-gnu-variable-sized-type-not-at-end -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-psabi -Wno-shift-negative-value -Wno-string-plus-int -Wno-tautological-type-limit-compare -Wno-typedef-redefinition -iquote . -iquote /Users/josh/workspace/qemu -iquote /Users/josh/workspace/qemu/include -iquote /Users/josh/workspace/qemu/host/include/aarch64 -iquote /Users/josh/workspace/qemu/host/include/generic -iquote /Users/josh/workspace/qemu/tcg/aarch64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -fno-pie -ftrivial-auto-var-init=zero -fzero-call-used-regs=used-gpr -MD -MQ libblock.a.p/block_file-posix.c.o -MF libblock.a.p/block_file-posix.c.o.d -o libblock.a.p/block_file-posix.c.o -c ../block/file-posix.c
+../block/file-posix.c:1501:19: error: variable has incomplete type 'struct statfs'
+    struct statfs buf;
+                  ^
+../block/file-posix.c:1501:12: note: forward declaration of 'struct statfs'
+    struct statfs buf;
+           ^
+../block/file-posix.c:1503:10: error: call to undeclared function 'fstatfs'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
+    if (!fstatfs(s->fd, &buf)) {
+         ^
+2 errors generated.
+```
+Steps to reproduce:
+1. nix-shell -p python3 ninja pkg-config glib
+2. ./configure --target-list=arm-softmmu
+3. make
+Additional information:
+The following patch fixes the issue (although I'm not sure whether this is the most appropriate fix):
+
+```
+diff --git a/block/file-posix.c b/block/file-posix.c
+index ff928b5e85..6c78db3b0b 100644
+--- a/block/file-posix.c
++++ b/block/file-posix.c
+@@ -44,10 +44,10 @@
+ 
+ #if defined(__APPLE__) && (__MACH__)
+ #include <sys/ioctl.h>
+-#if defined(HAVE_HOST_BLOCK_DEVICE)
+-#include <paths.h>
+ #include <sys/param.h>
+ #include <sys/mount.h>
++#if defined(HAVE_HOST_BLOCK_DEVICE)
++#include <paths.h>
+ #include <IOKit/IOKitLib.h>
+ #include <IOKit/IOBSD.h>
+ #include <IOKit/storage/IOMediaBSDClient.h>
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2513 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2513
new file mode 100644
index 00000000..c0d2d768
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2513
@@ -0,0 +1,13 @@
+CXL Device Missing PCI_CAP_ID_PM (01h) in CAP List Implementation According to PCIe SPEC
+Description of problem:
+- The lack of **PCI_CAP_ID_PM (01h)** will not cause any crash or error when running QEMU, but it is violated to the PCIe SPEC.
+- When some vendors test the power management capability (e.g., Linux Runtime PM), they must manually implement this CAP list to support the D1/D2/D3_Hot d-states changes.
+- We don't see any PCI_CAP_ID_PM (01h) in the CXL rootport or endpoint
+
+    ![image](/uploads/ba5f2de689eb1059b2b82ab072f1bf7b/image.png){width=349 height=474}
+
+
+#
+Steps to reproduce:
+1. Run the qemu-system-x86 (See QEMU command line)
+2. sudo lspci -xxx
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2514 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2514
new file mode 100644
index 00000000..b820bd4f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2514
@@ -0,0 +1 @@
+network unreachable to esxi 8 guest
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2515 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2515
new file mode 100644
index 00000000..cbb87fbd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2515
@@ -0,0 +1,46 @@
+qemu -daemonize crashes on macOS with "NSPlaceholderDate initialize may have been in progress in another thread"
+Description of problem:
+Context: I build [an open source project](https://tsduck.io/) on several operating systems and architectures. For riscv64, s390x, ppc64, I build in emulated virtual machines. The three emulated OS work correctly when running qemu manually and the project is correctly built.
+
+Now, I want to automate the process in a script: for each target architecture, boot the VM (start qemu as a background process), connect to the VM using ssh, build the software, collect the binaries, shut down the VM.
+
+Starting the same qemu command as used interactively as a background process with `&` does not work and fails immediately, apparently because of the lack of stdin. So, I added option `-daemonize` (and removed `-nographic` because an error message says the two options are incompatible).
+
+Using `-daemonize` instead of `-nographic`, all qemu command immediately fail with the following error:
+
+```
+objc[1141]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called.
+objc[1141]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
+```
+Steps to reproduce:
+```
+$ qemu-system-riscv64 -machine virt -smp 8 -m 8192 -daemonize \
+      -bios fw_jump.bin -kernel u-boot.bin \
+      -device virtio-net-device,netdev=net \
+      -netdev user,id=net,hostfwd=tcp::2233-:22 \
+      -drive file=disk.qcow2,format=qcow2,if=virtio  -device virtio-rng-pci
+objc[1141]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called.
+objc[1141]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
+
+
+$ qemu-system-s390x -machine s390-ccw-virtio -cpu max,zpci=on -smp 8 -m 8192 -daemonize \
+      -drive file=disk.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none \
+      -device virtio-blk-ccw,devno=fe.0.0002,drive=drive-virtio-disk0,bootindex=1 \
+      -nic user,hostfwd=tcp::2288-:22 
+objc[1209]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called.
+objc[1209]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
+
+
+$ qemu-system-ppc64 -smp 8 -m 8192 -daemonize \
+      -drive file=disk.qcow2,format=qcow2 -nic user,hostfwd=tcp::2299-:22
+qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-cfpc=workaround
+qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-sbbc=workaround
+qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ibs=workaround
+qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ccf-assist=on
+objc[1166]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called.
+objc[1166]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
+```
+
+All the above commands work correctly when using  `-nographic` instead of `-daemonize`. The virtual disks are the same as in the interactive runs, with a fully configured Linux OS (Ubuntu or Debian).
+Additional information:
+From a [report from here](https://stackoverflow.com/questions/63041445/python-os-high-sierra-nsplaceholderdate-error), I tried to define the environment variable `OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES` before running qemu. The `[__NSPlaceholderDate initialize]` errors disappear but qemu still crashes immediately.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2516 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2516
new file mode 100644
index 00000000..c9b85e7d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2516
@@ -0,0 +1 @@
+Qemu 9.1 dropped support for Ubuntu 20.04
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2517 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2517
new file mode 100644
index 00000000..c800e7ef
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2517
@@ -0,0 +1 @@
+destroying a vCPU will leak its AddressSpaces
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2519 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2519
new file mode 100644
index 00000000..91038368
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2519
@@ -0,0 +1 @@
+make check TIMEOUT_MULTIPLIER variable is undocumented
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/252 b/gitlab/issues_text/target_missing/host_missing/accel_missing/252
new file mode 100644
index 00000000..db998ac5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/252
@@ -0,0 +1 @@
+KVM Old ATI(pre) AMD card passthrough is not working
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2521 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2521
new file mode 100644
index 00000000..f47ac5c0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2521
@@ -0,0 +1,16 @@
+USB Passthrough Improper Remote Wakeup
+Description of problem:
+I am doing research with Linux Power Management interactions with USB devices. Which is why I would like to be able to wake a qemu vm from suspend with a passed through USB device. The first issue is that remote wakeup from usb devices do not wake the vm at all when running in -nographic mode (issuing system_wakeup from a qemu monitor shell will wake it though). When running with a GUI it is possible to wake the vm from a usb device as well as the qemu monitor shell but both will result in the GUI screen being black afterwards. It is still possible to use the vm though. Finally, waking the vm with a usb device is only possible when a valid usb device is passed through in the qemu launch command line. But interestingly the usb device specified to be passed through will only wakeup the vm if it is unplugged and plugged back in during the suspend. All other usb devices can wakeup the vm normally even though they are not passed through. It is not clear to me what is going on here and why other devices not being passed through to qemu can wake the vm. Note I have also enabled the /sys/bus/usb/devices/usb#/power/wakeup file and have manually unsuppressed the remote_wakeup flag in the source code to enable the /sys/bus/usb/devices/#-#/power/wakeup files to be generated but it has not affected anything.
+Steps to reproduce:
+I have tested this issue with multiple kernel versions (6.10, 6.10-rc4, 6.6.43) as well as custom and generic kernel configs and different debian images so these do not seem to be the problem. But here is a detailed description of the exact setup I am currently using:
+
+1. Download linux-6.10-rc4 source and configure with syzkaller fuzzing config https://github.com/google/syzkaller/blob/master/dashboard/config/linux/upstream-usb.config 
+2. Set CONFIG_KCOV_INSTRUMENT_ALL to off (breaks suspend/resume in vm) and create bzImage
+2. Create a debian bookworm image with syzkaller script https://github.com/google/syzkaller/blob/master/tools/create-image.sh
+3. Download and build Qemu from source (see attached for detailed configuration and dependencies)
+4. Attach a usb keyboard and mouse
+5. Choose one device to pass through via command line
+6. Try waking the vm with nographic and graphic mode using the usb devices
+Additional information:
+[configuration_output.txt](/uploads/f7d3487dab65deef40bd0e110b64a573/configuration_output.txt)
+[gui_wakeup_log.txt](/uploads/72b192a88d587eced4bb4032307307e5/gui_wakeup_log.txt)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2524 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2524
new file mode 100644
index 00000000..caf9a4d6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2524
@@ -0,0 +1,3 @@
+Reverse debugging is broken on release and stable branches
+Description of problem:
+Master branch has commit 94962ff00d09674047aed896e87ba09736cd6941, which reverts incorrect commit and fix reverse debugging. But this commit is missing in 9.0.x 9.1.x releases branches and in stable branches too.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2525 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2525
new file mode 100644
index 00000000..feeb6473
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2525
@@ -0,0 +1 @@
+bFLT triggers accel/tcg/user-exec.c:505: page_set_flags: Assertion `have_mmap_lock()' failed.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2526 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2526
new file mode 100644
index 00000000..88afd4a5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2526
@@ -0,0 +1,39 @@
+qemu-system-aarch64: Build of system emulators with --static failed on aarch64 Ubuntu 22.04 for tests/unit/test-bitcnt
+Description of problem:
+Build Qemu got error:
+```
+[1107/2870] Compiling C object tcg/libtcg_system.fa.p/perf.c.o
+[1108/2870] Linking target tests/unit/test-bitcnt
+FAILED: tests/unit/test-bitcnt
+cc  -o tests/unit/test-bitcnt tests/unit/test-bitcnt.p/test-bitcnt.c.o -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libevent-loop-base.fa libqom.fa -Wl,--no-whole-archive -static-pie -fstack-protector-strong -Wl,-z,relro -Wl,-z,now -Wl,--start-group libqemuutil.a subprojects/libvhost-user/libvhost-user-glib.a subprojects/libvhost-user/libvhost-user.a libevent-loop-base.fa libqom.fa /usr/lib/aarch64-linux-gnu/libgio-2.0.a /usr/lib/aarch64-linux-gnu/libgmodule-2.0.a -pthread /usr/lib/aarch64-linux-gnu/libz.a -ldl /usr/lib/aarch64-linux-gnu/libblkid.a /usr/lib/aarch64-linux-gnu/libselinux.a /usr/lib/aarch64-linux-gnu/libsepol.a /usr/lib/aarch64-linux-gnu/libpcre2-8.a /usr/lib/aarch64-linux-gnu/libgobject-2.0.a /usr/lib/aarch64-linux-gnu/libffi.a /usr/lib/aarch64-linux-gnu/libglib-2.0.a -lm /usr/lib/aarch64-linux-gnu/libpcre.a -lmount -lmount -Wl,--end-group
+/usr/bin/ld: cannot find -lmount: No such file or directory
+/usr/bin/ld: cannot find -lmount: No such file or directory
+collect2: error: ld returned 1 exit status
+[1109/2870] Linking target tests/unit/test-qapi-util
+FAILED: tests/unit/test-qapi-util
+cc  -o tests/unit/test-qapi-util tests/unit/test-qapi-util.p/test-qapi-util.c.o -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libevent-loop-base.fa libqom.fa -Wl,--no-whole-archive -static-pie -fstack-protector-strong -Wl,-z,relro -Wl,-z,now -Wl,--start-group libqemuutil.a subprojects/libvhost-user/libvhost-user-glib.a subprojects/libvhost-user/libvhost-user.a libevent-loop-base.fa libqom.fa /usr/lib/aarch64-linux-gnu/libgio-2.0.a /usr/lib/aarch64-linux-gnu/libgmodule-2.0.a -pthread /usr/lib/aarch64-linux-gnu/libz.a -ldl /usr/lib/aarch64-linux-gnu/libblkid.a /usr/lib/aarch64-linux-gnu/libselinux.a /usr/lib/aarch64-linux-gnu/libsepol.a /usr/lib/aarch64-linux-gnu/libpcre2-8.a /usr/lib/aarch64-linux-gnu/libgobject-2.0.a /usr/lib/aarch64-linux-gnu/libffi.a /usr/lib/aarch64-linux-gnu/libglib-2.0.a -lm /usr/lib/aarch64-linux-gnu/libpcre.a -lmount -lmount -Wl,--end-group
+/usr/bin/ld: cannot find -lmount: No such file or directory
+/usr/bin/ld: cannot find -lmount: No such file or directory
+collect2: error: ld returned 1 exit status
+[1110/2870] Linking target tests/unit/check-qom-interface
+FAILED: tests/unit/check-qom-interface
+cc  -o tests/unit/check-qom-interface tests/unit/check-qom-interface.p/check-qom-interface.c.o -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libevent-loop-base.fa libqom.fa -Wl,--no-whole-archive -static-pie -fstack-protector-strong -Wl,-z,relro -Wl,-z,now -Wl,--start-group libqemuutil.a subprojects/libvhost-user/libvhost-user-glib.a subprojects/libvhost-user/libvhost-user.a libevent-loop-base.fa libqom.fa /usr/lib/aarch64-linux-gnu/libgio-2.0.a /usr/lib/aarch64-linux-gnu/libgmodule-2.0.a -pthread /usr/lib/aarch64-linux-gnu/libz.a -ldl /usr/lib/aarch64-linux-gnu/libblkid.a /usr/lib/aarch64-linux-gnu/libselinux.a /usr/lib/aarch64-linux-gnu/libsepol.a /usr/lib/aarch64-linux-gnu/libpcre2-8.a /usr/lib/aarch64-linux-gnu/libgobject-2.0.a /usr/lib/aarch64-linux-gnu/libffi.a /usr/lib/aarch64-linux-gnu/libglib-2.0.a -lm /usr/lib/aarch64-linux-gnu/libpcre.a -lmount -lmount -Wl,--end-group
+/usr/bin/ld: cannot find -lmount: No such file or directory
+/usr/bin/ld: cannot find -lmount: No such file or directory
+collect2: error: ld returned 1 exit status
+```
+After install libmount-dev, this error is still there.
+If we just run:
+```
+./configure --target-list=aarch64-softmmu --enable-kvm
+make -16
+```
+This works well.
+Steps to reproduce:
+```
+1. ./configure --target-list=aarch64-softmmu --enable-kvm --disable-brlapi --disable-docs --disable-curses --disable-gtk --disable-opengl --disable-sdl --disable-spice --disable-vte --disable-vnc --disable-vnc-jpeg --disable-png --disable-vnc-sasl --disable-auth-pam --disable-glusterfs --disable-libiscsi --disable-libnfs --disable-libssh --disable-bzip2 --disable-lzo --disable-snappy --disable-slirp --disable-libusb --disable-usb-redir --static --disable-qom-cast-debug --disable-libudev --disable-curl --disable-rdma --disable-tools --enable-virtfs --disable-bsd-user --disable-linux-user --disable-sparse --disable-vde --disable-nettle --disable-xen --disable-linux-aio --disable-capstone --disable-virglrenderer --disable-replication --disable-smartcard --disable-guest-agent --disable-guest-agent-msi --disable-vvfat --disable-vdi --disable-qed --disable-qcow1 --disable-bochs --disable-cloop --disable-dmg --disable-parallels --disable-colo-proxy --disable-debug-graph-lock --disable-hexagon-idef-parser --disable-libdw --disable-pipewire --disable-pixman --disable-relocatable --disable-rutabaga-gfx --disable-vmdk --disable-avx512bw --disable-vpc --disable-vhdx --disable-hv-balloon
+
+2.make -j16
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2527 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2527
new file mode 100644
index 00000000..0b49919c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2527
@@ -0,0 +1 @@
+bFLT parser doesn't select MMU-less CPU
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2528 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2528
new file mode 100644
index 00000000..a3295ce5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2528
@@ -0,0 +1,9 @@
+nbd: CVE-2024-7409 fix is incomplete
+Description of problem:
+Patch will hit list soon, but opening issue here since if this misses 9.1, we would need to allocate a second CVE for having an incomplete fix (a remaining use-after-free) in the code originally proposed for CVE-2024-7409.
+Steps to reproduce:
+1. stress test of attempting repeated 'qemu-nbd --list' in parallel with repeated 'nbd-server-start/nbd-server-stop' loops in a qemu process revealed a use-after-free SEGV of nbd_server->listener
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2529 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2529
new file mode 100644
index 00000000..971c6259
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2529
@@ -0,0 +1,32 @@
+`stack smashing detected` running arm64 image from amd64 machine
+Description of problem:
+When running a linux/arm64 `ubuntu:20.04` docker image on a linux/amd64 machine, an single command `apt-get update` will through below error
+```sh
+root@189bd36b9ae7:/# apt-get update
+0% [Working]*** stack smashing detected ***: terminated
+Reading package lists... Done
+E: Method http has died unexpectedly!
+E: Sub-process http received signal 6.
+
+```
+
+Tested this is happening for ubuntu:18.04, ubuntu:20.04, ubuntu:22.04 so far
+
+If running same image directly from an ARM64 host, issue is gone
+Steps to reproduce:
+1. install QEMU on an AMD64 host machine (Ubuntu20)
+   ```sh
+   docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
+   ```
+2. run linux/arm64 docker image of ubuntu:20.04
+   ```sh
+   docker run --platform linux/arm64 -it --entrypoint /bin/bash ubuntu:20.04
+   ``` 
+3. from within the container, run `apt-get update`, it will through below error
+   ```sh
+   root@189bd36b9ae7:/# apt-get update
+   0% [Working]*** stack smashing detected ***: terminated
+   Reading package lists... Done
+   E: Method http has died unexpectedly!
+   E: Sub-process http received signal 6.
+   ```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/253 b/gitlab/issues_text/target_missing/host_missing/accel_missing/253
new file mode 100644
index 00000000..50482b70
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/253
@@ -0,0 +1 @@
+Qemu Win98 VM with KVM videocard passthrough DOS mode video is not working for most of games..
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2532 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2532
new file mode 100644
index 00000000..b8d4e440
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2532
@@ -0,0 +1,40 @@
+empty vmdk disk created by qemu-img cann't import to vmware ESXi or Workstation
+Description of problem:
+qemu-img create empty vmdk file, and can't import to vmware workstation or ESXi. the ovftool
+ fail.  the log:
+
+> ```
+> 2024-08-23T11:19:32.335+08:00 verbose OVFTool[4088548] [Originator@6876 sub=Default] Opening disk target empty-disk2.vmdk
+> 2024-08-23T11:19:32.335+08:00 error OVFTool[4088548] [Originator@6876 sub=Default] Error on read, error: -1
+> 2024-08-23T11:19:32.336+08:00 verbose OVFTool[4088187] [Originator@6876 sub=Default] Exception thrown: N5boost16exception_detail10clone_implINS_17unknown_exceptionEEE(std::exception)
+> 2024-08-23T11:19:32.337+08:00 verbose OVFTool[4088187] [Originator@6876 sub=Default] Backtrace: 
+> --> [backtrace begin] product: VMware Workstation, version: e.x.p, build: build-15722219, tag: OVFTool, cpu: x86_64, os: linux, buildType: release
+> --> backtrace[00] libvmacore.so[0x003DD716]
+> --> backtrace[01] libvmacore.so[0x001CF8DF]: Vmacore::System::Stacktrace::CaptureWork(unsigned int)
+> --> backtrace[02] libvmacore.so[0x001B6EA9]: Vmacore::System::SystemFactory::CreateQuickBacktrace(Vmacore::Ref<Vmacore::System::Backtrace>&)
+> --> backtrace[03] libvmacore.so[0x0016CF2E]: Vmacore::Throwable::Throwable(std::string&&)
+> --> backtrace[04] ovftool.bin[0x001C1F38]
+> --> backtrace[05] ovftool.bin[0x002008D5]
+> --> backtrace[06] ovftool.bin[0x00129EF0]
+> --> backtrace[07] libc.so.6[0x00044E50]
+> --> backtrace[08] libc.so.6[0x00044EFC]
+> --> backtrace[09] ovftool.bin[0x00132D21]
+> --> [backtrace end]
+> ```
+
+the log file:
+[test.log](/uploads/174db2ace468bd9f0ec3ab14de524217/test.log)
+Steps to reproduce:
+1. create empty vmdk file
+
+./qemu-img create -f vmdk -o adapter_type=lsilogic,subformat=streamOptimized empty.vmdk 1G
+
+2. add empty file info  to  ovf file
+<File ovf:href="empty.vmdk" ovf:id="file2"/>
+
+3. import it to vmware workstation
+Additional information:
+If i write some data to empty vmdk file, it can import successfully.  The reson: qemu only write metadata for empty vmdk file, but the ovftool need read more data and it cann't read more.
+we can write one sector zero data after the metadata, ovftool work well. 
+I submitted the patch:
+https://patchew.org/QEMU/20240822105237.777-1-luzhipeng@cestc.cn/
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2535 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2535
new file mode 100644
index 00000000..07da8a04
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2535
@@ -0,0 +1 @@
+Security patch of CVE-2024-4693 backport request
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2537 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2537
new file mode 100644
index 00000000..d8be7c06
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2537
@@ -0,0 +1 @@
+Hang in Cocoa_SetWindowSize()
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2539 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2539
new file mode 100644
index 00000000..823ca558
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2539
@@ -0,0 +1 @@
+Crash in early_gtk_display_init() on macOS 14.6.1
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/254 b/gitlab/issues_text/target_missing/host_missing/accel_missing/254
new file mode 100644
index 00000000..f5f8661f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/254
@@ -0,0 +1 @@
+Windows 98 videocard passthrough - unable to load higher resolution -Desktop, after some games crashes, without whole physical machine reset..
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2541 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2541
new file mode 100644
index 00000000..dc2336b0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2541
@@ -0,0 +1 @@
+virtio-9p qos-test failure: v9fs_req_recv: assertion failed (hdr.id == id): (7 == 73) FAIL
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2544 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2544
new file mode 100644
index 00000000..c5e397a8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2544
@@ -0,0 +1 @@
+Bug: qemu not properly flushing error messages related to bad arguments
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2545 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2545
new file mode 100644
index 00000000..22fc087d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2545
@@ -0,0 +1,9 @@
+QEMU Version 9.0.0 - HAXM 7.8.0.0 - Error : qemu-system-x86_64.exe: -accel hax: invalid accelerator hax
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2548 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2548
new file mode 100644
index 00000000..e8f73544
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2548
@@ -0,0 +1,406 @@
+Assert failure in `usb_ep_get` : Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT` failed.
+Description of problem:
+Assert failure in `usb_ep_get` : Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT` failed.
+
+The TD PID needs to be either `USB_TOKEN_IN` or `USB_TOKEN_OUT` in `usb_ep_get`, but in the caller `uhci_handle_td` it may be `USB_TOKEN_SETUP`. 
+
+An unprivileged guest user may be able to reach the assertion, I think this bug is quite akin to CVE-2024-3567 (https://gitlab.com/qemu-project/qemu/-/issues/2273) :
+
+Users are not directly able to craft URBs, however as a user, one might be able to find a kernel path that would send a TD with PID `USB_TOKEN_SETUP` to QEMU (which is called `USB_PID_SETUP` in Linux).
+For instance in the Linux Kernel,  `uhci_submit_control` in `drivers/usb/host/uhci-q.c:789`  does link a `USB_PID_SETUP` TD to the URB.
+Steps to reproduce:
+Minimized reproducer:
+
+```
+cat << EOF | ./qemu/build2/qemu-system-x86_64 -machine q35 -nodefaults \
+-device \
+ich9-usb-ehci1,bus=pcie.0,addr=1d.7,multifunction=on,id=ich9-ehci-1 \
+-device ich9-usb-uhci1,bus=pcie.0,addr=1d.0,multifunction=on,masterbus=i\
+ch9-ehci-1.0,firstport=0 -device ich9-usb-uhci2,bus=pcie.0,addr=1d.1,mul\
+tifunction=on,masterbus=ich9-ehci-1.0,firstport=2 -device ich9-usb-uhci3\
+,bus=pcie.0,addr=1d.2,multifunction=on,masterbus=ich9-ehci-1.0,firstport\
+=4 -drive if=none,id=usbcdrom,media=cdrom -device \
+usb-tablet,bus=ich9-ehci-1.0,port=1,usb_version=1 -device \
+usb-storage,bus=ich9-ehci-1.0,port=2,drive=usbcdrom -qtest stdio
+outl 0xcf8 0x8000e900
+inw 0xcfc
+outl 0xcf8 0x8000e920
+outl 0xcfc 0xffffffff
+outl 0xcf8 0x8000e920
+inl 0xcfc
+outl 0xcf8 0x8000e920
+outl 0xcfc 0xc001
+outl 0xcf8 0x8000e904
+inw 0xcfc
+outl 0xcf8 0x8000e904
+outw 0xcfc 0x7
+outl 0xcf8 0x8000e904
+inw 0xcfc
+outl 0xcf8 0x8000ef00
+inw 0xcfc
+outl 0xcf8 0x8000ef10
+outl 0xcfc 0xffffffff
+outl 0xcf8 0x8000ef10
+inl 0xcfc
+outl 0xcf8 0x8000ef10
+outl 0xcfc 0xe0000000
+outl 0xcf8 0x8000ef04
+inw 0xcfc
+outl 0xcf8 0x8000ef04
+outw 0xcfc 0x7
+outl 0xcf8 0x8000ef04
+inw 0xcfc
+outl 0xcf8 0x8000ea00
+inw 0xcfc
+outl 0xcf8 0x8000ea20
+outl 0xcfc 0xffffffff
+outl 0xcf8 0x8000ea20
+inl 0xcfc
+outl 0xcf8 0x8000ea20
+outl 0xcfc 0xc021
+outl 0xcf8 0x8000ea04
+inw 0xcfc
+outl 0xcf8 0x8000ea04
+outw 0xcfc 0x7
+outl 0xcf8 0x8000ea04
+inw 0xcfc
+outl 0xcf8 0x8000e800
+inw 0xcfc
+outl 0xcf8 0x8000e820
+outl 0xcfc 0xffffffff
+outl 0xcf8 0x8000e820
+inl 0xcfc
+outl 0xcf8 0x8000e820
+outl 0xcfc 0xc041
+outl 0xcf8 0x8000e804
+inw 0xcfc
+outl 0xcf8 0x8000e804
+outw 0xcfc 0x7
+outl 0xcf8 0x8000e804
+inw 0xcfc
+outl 0xcf8 0x8000fa00
+inw 0xcfc
+outl 0xcf8 0x8000fa20
+outl 0xcfc 0xffffffff
+outl 0xcf8 0x8000fa20
+inl 0xcfc
+outl 0xcf8 0x8000fa20
+outl 0xcfc 0xc061
+outl 0xcf8 0x8000fa24
+outl 0xcfc 0xffffffff
+outl 0xcf8 0x8000fa24
+inl 0xcfc
+outl 0xcf8 0x8000fa24
+outl 0xcfc 0xe0001000
+outl 0xcf8 0x8000fa04
+inw 0xcfc
+outl 0xcf8 0x8000fa04
+outw 0xcfc 0x7
+outl 0xcf8 0x8000fa04
+inw 0xcfc
+outl 0xcf8 0x8000ea20
+outl 0xcfc 0x625f69a0
+outb 0xc040 0x46
+outb 0xc040 0x69
+inb 0xc000
+outb 0xc040 0x46
+clock_step
+outb 0xc040 0x69
+clock_step
+write 0x0 0x4 0x64657669
+write 0x69766560 0x8 0x000000ff6c46f228
+write 0x69766568 0x8 0x2d323334319c6c65
+write 0xff000000 0x8 0x000000ff6c6f6766
+write 0xff000008 0x8 0x8d6c65652d736400
+outb 0xc040 0x69
+outl 0xcf8 0x8000ef76
+outw 0xcfc 0x6563
+outb 0xc040 0x46
+clock_step
+outb 0xc040 0x69
+inb 0xc000
+clock_step
+write 0x4 0x4 0x64657669
+write 0x69766560 0x8 0x000000ff6c46f228
+write 0x69766568 0x8 0x2d323334319c6c65
+write 0xff000000 0x8 0x000000ff6c6f6766
+write 0xff000008 0x8 0x8d6c65652d736400
+outb 0xc040 0x69
+outw 0xc003 0x6769
+outb 0xc040 0x69
+readq 0xe0000074
+outb 0xc040 0x46
+clock_step
+outb 0xc040 0x69
+clock_step
+write 0x8 0x4 0x00000100
+write 0x10000 0x10 0x000000ff6c46f2282d00363939333336
+write 0xff000000 0x8 0x6465766963656d69
+write 0xff000008 0x8 0x740d00699b652d63
+write 0x69766560 0x8 0x000000ff6c46f228
+write 0x69766568 0x8 0x2d323334319c6c65
+clock_step
+write 0xc 0x4 0x000000ff
+write 0xff000000 0x8 0x0000010000000069
+write 0xff000008 0x8 0x636c395f61707269
+write 0x10000 0x10 0x000000ff6c46f2282d00363939333336
+outw 0xc003 0x6f00
+outb 0xc040 0x69
+outl 0xc053 0x6378616d
+clock_step
+write 0x10 0x4 0x000000ff
+write 0xff000000 0x8 0x6465766963656d69
+write 0xff000008 0x8 0x740d00699b652d63
+write 0x69766560 0x8 0x000000ff6c46f228
+write 0x69766568 0x8 0x2d323334319c6c65
+outb 0xc051 0x6d
+outb 0xc04f 0x61
+outb 0xc040 0x69
+clock_step
+write 0x14 0x4 0x000000ff
+write 0xff000000 0x8 0x0000010000000069
+write 0xff000008 0x8 0x636c395f61707269
+write 0x10000 0x10 0x000000ff6c46f2282d00363939333336
+EOF
+```
+
+# Additional information
+The crash report triggered by the reproducer is:
+
+```
+[R +0.033173] outl 0xcf8 0x8000e900
+[S +0.033189] [R +0.033195] inw 0xcfc
+[S +0.033205] [R +0.033212] outl 0xcf8 0x8000e920
+[S +0.033218] [R +0.033222] outl 0xcfc 0xffffffff
+[S +0.033231] [R +0.033235] outl 0xcf8 0x8000e920
+[S +0.033241] [R +0.033245] inl 0xcfc
+[S +0.033250] [R +0.033255] outl 0xcf8 0x8000e920
+[S +0.033261] [R +0.033265] outl 0xcfc 0xc001
+[S +0.033271] [R +0.033275] outl 0xcf8 0x8000e904
+[S +0.033281] [R +0.033285] inw 0xcfc
+[S +0.033290] [R +0.033295] outl 0xcf8 0x8000e904
+[S +0.033300] [R +0.033306] outw 0xcfc 0x7
+[S +0.033755] [R +0.033767] outl 0xcf8 0x8000e904
+[S +0.033774] [R +0.033779] inw 0xcfc
+[S +0.033785] [R +0.033792] outl 0xcf8 0x8000ef00
+[S +0.033798] [R +0.033802] inw 0xcfc
+[S +0.033808] [R +0.033813] outl 0xcf8 0x8000ef10
+[S +0.033818] [R +0.033840] outl 0xcfc 0xffffffff
+[S +0.033848] [R +0.033853] outl 0xcf8 0x8000ef10
+[S +0.033859] [R +0.033864] inl 0xcfc
+[S +0.033870] [R +0.033875] outl 0xcf8 0x8000ef10
+[S +0.033880] [R +0.033884] outl 0xcfc 0xe0000000
+[S +0.033891] [R +0.033895] outl 0xcf8 0x8000ef04
+[S +0.033901] [R +0.033904] inw 0xcfc
+[S +0.033909] [R +0.033916] outl 0xcf8 0x8000ef04
+[S +0.033922] [R +0.033926] outw 0xcfc 0x7
+[S +0.034381] [R +0.034389] outl 0xcf8 0x8000ef04
+[S +0.034395] [R +0.034399] inw 0xcfc
+[S +0.034405] [R +0.034412] outl 0xcf8 0x8000ea00
+[S +0.034417] [R +0.034421] inw 0xcfc
+[S +0.034427] [R +0.034431] outl 0xcf8 0x8000ea20
+[S +0.034437] [R +0.034441] outl 0xcfc 0xffffffff
+[S +0.034448] [R +0.034452] outl 0xcf8 0x8000ea20
+[S +0.034457] [R +0.034463] inl 0xcfc
+[S +0.034469] [R +0.034474] outl 0xcf8 0x8000ea20
+[S +0.034480] [R +0.034484] outl 0xcfc 0xc021
+[S +0.034490] [R +0.034494] outl 0xcf8 0x8000ea04
+[S +0.034500] [R +0.034504] inw 0xcfc
+[S +0.034509] [R +0.034515] outl 0xcf8 0x8000ea04
+[S +0.034521] [R +0.034525] outw 0xcfc 0x7
+[S +0.034948] [R +0.034955] outl 0xcf8 0x8000ea04
+[S +0.034961] [R +0.034965] inw 0xcfc
+[S +0.034971] [R +0.034989] outl 0xcf8 0x8000e800
+[S +0.034996] [R +0.035000] inw 0xcfc
+[S +0.035005] [R +0.035010] outl 0xcf8 0x8000e820
+[S +0.035016] [R +0.035020] outl 0xcfc 0xffffffff
+[S +0.035027] [R +0.035033] outl 0xcf8 0x8000e820
+[S +0.035039] [R +0.035043] inl 0xcfc
+[S +0.035048] [R +0.035053] outl 0xcf8 0x8000e820
+[S +0.035059] [R +0.035065] outl 0xcfc 0xc041
+[S +0.035071] [R +0.035075] outl 0xcf8 0x8000e804
+[S +0.035081] [R +0.035084] inw 0xcfc
+[S +0.035089] [R +0.035094] outl 0xcf8 0x8000e804
+[S +0.035100] [R +0.035103] outw 0xcfc 0x7
+[S +0.035525] [R +0.035532] outl 0xcf8 0x8000e804
+[S +0.035538] [R +0.035542] inw 0xcfc
+[S +0.035548] [R +0.035553] outl 0xcf8 0x8000fa00
+[S +0.035558] [R +0.035562] inw 0xcfc
+[S +0.035567] [R +0.035572] outl 0xcf8 0x8000fa20
+[S +0.035578] [R +0.035581] outl 0xcfc 0xffffffff
+[S +0.035589] [R +0.035594] outl 0xcf8 0x8000fa20
+[S +0.035600] [R +0.035604] inl 0xcfc
+[S +0.035609] [R +0.035613] outl 0xcf8 0x8000fa20
+[S +0.035618] [R +0.035623] outl 0xcfc 0xc061
+[S +0.035629] [R +0.035633] outl 0xcf8 0x8000fa24
+[S +0.035638] [R +0.035642] outl 0xcfc 0xffffffff
+[S +0.035648] [R +0.035652] outl 0xcf8 0x8000fa24
+[S +0.035658] [R +0.035664] inl 0xcfc
+[S +0.035669] [R +0.035673] outl 0xcf8 0x8000fa24
+[S +0.035679] [R +0.035683] outl 0xcfc 0xe0001000
+[S +0.035689] [R +0.035696] outl 0xcf8 0x8000fa04
+[S +0.035702] [R +0.035706] inw 0xcfc
+[S +0.035711] [R +0.035716] outl 0xcf8 0x8000fa04
+[S +0.035722] [R +0.035725] outw 0xcfc 0x7
+[S +0.036402] [R +0.036412] outl 0xcf8 0x8000fa04
+[S +0.036418] [R +0.036422] inw 0xcfc
+[S +0.036434] [R +0.036442] outl 0xcf8 0x8000ea20
+[S +0.036448] [R +0.036463] outl 0xcfc 0x625f69a0
+[S +0.036906] [I +0.036981] CLOSED
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outb 0xc040 0x46
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outb 0xc040 0x69
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] inb 0xc000
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outb 0xc040 0x46
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] clock_step
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outb 0xc040 0x69
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] clock_step
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x0 0x4 0x64657669
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0xff000000 0x8 0x000000ff6c6f6766
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0xff000008 0x8 0x8d6c65652d736400
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outb 0xc040 0x69
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outl 0xcf8 0x8000ef76
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outw 0xcfc 0x6563
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outb 0xc040 0x46
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] clock_step
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outb 0xc040 0x69
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] inb 0xc000
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] clock_step
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x4 0x4 0x64657669
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0xff000000 0x8 0x000000ff6c6f6766
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0xff000008 0x8 0x8d6c65652d736400
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outb 0xc040 0x69
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outw 0xc003 0x6769
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outb 0xc040 0x69
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] readq 0xe0000074
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outb 0xc040 0x46
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] clock_step
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outb 0xc040 0x69
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] clock_step
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x8 0x4 0x00000100
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x10000 0x10 0x000000ff6c46f2282d00363939333336
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0xff000000 0x8 0x6465766963656d69
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0xff000008 0x8 0x740d00699b652d63
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] clock_step
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0xc 0x4 0x000000ff
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0xff000000 0x8 0x0000010000000069
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0xff000008 0x8 0x636c395f61707269
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x10000 0x10 0x000000ff6c46f2282d00363939333336
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outw 0xc003 0x6f00
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outb 0xc040 0x69
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outl 0xc053 0x6378616d
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] clock_step
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x10 0x4 0x000000ff
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0xff000000 0x8 0x6465766963656d69
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0xff000008 0x8 0x740d00699b652d63
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outb 0xc051 0x6d
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outb 0xc04f 0x61
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] outb 0xc040 0x69
+x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] clock_step
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x14 0x4 0x000000ff
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0xff000000 0x8 0x0000010000000069
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0xff000008 0x8 0x636c395f61707269
+[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
+[R +0.000000] write 0x10000 0x10 0x000000ff6c46f2282d00363939333336
+qemu-fuzz-x86_64: ../hw/usb/core.c:744: struct USBEndpoint *usb_ep_get(USBDevice *, int, int): Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed.
+==892641== ERROR: libFuzzer: deadly signal
+    #0 0x557dd985fc41 in __sanitizer_print_stack_trace (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x20b2c41) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5)
+    #1 0x557dd97cfa58 in fuzzer::PrintStackTrace() (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2022a58) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5)
+    #2 0x557dd97b5ae3 in fuzzer::Fuzzer::CrashCallback() (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2008ae3) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5)
+    #3 0x7fd7e623c45f  (/lib/x86_64-linux-gnu/libc.so.6+0x3c45f) (BuildId: d320ce4e63925d698610ed423fc4b1f0e8ed51f1)
+    #4 0x7fd7e629152a in __pthread_kill_implementation nptl/pthread_kill.c:43:17
+    #5 0x7fd7e629152a in __pthread_kill_internal nptl/pthread_kill.c:78:10
+    #6 0x7fd7e629152a in pthread_kill nptl/pthread_kill.c:89:10
+    #7 0x7fd7e623c3b5 in raise signal/../sysdeps/posix/raise.c:26:13
+    #8 0x7fd7e622287b in abort stdlib/abort.c:79:7
+    #9 0x7fd7e622279a in __assert_fail_base assert/assert.c:92:3
+    #10 0x7fd7e6233b65 in __assert_fail assert/assert.c:101:3
+    #11 0x557dda3b67c6 in usb_ep_get /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/core.c:744:5
+    #12 0x557dda3d8820 in uhci_handle_td /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/hcd-uhci.c:819:14
+    #13 0x557dda3d41ed in uhci_process_frame /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/hcd-uhci.c:1022:15
+    #14 0x557dda3cbf7e in uhci_frame_timer /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/hcd-uhci.c:1121:9
+    #15 0x557ddb90c0ff in timerlist_run_timers /home/hypervisor/qemu_fuzz/qemu/build2/../util/qemu-timer.c:576:9
+    #16 0x557ddb90d3e8 in qemu_clock_run_timers /home/hypervisor/qemu_fuzz/qemu/build2/../util/qemu-timer.c:590:12
+    #17 0x557ddb90d3e8 in qemu_clock_advance_virtual_time /home/hypervisor/qemu_fuzz/qemu/build2/../util/qemu-timer.c:696:9
+    #18 0x557dda67fa2f in qtest_process_command /home/hypervisor/qemu_fuzz/qemu/build2/../system/qtest.c:722:9
+    #19 0x557dda67b3bb in qtest_process_inbuf /home/hypervisor/qemu_fuzz/qemu/build2/../system/qtest.c:776:9
+    #20 0x557dda67acf6 in qtest_server_inproc_recv /home/hypervisor/qemu_fuzz/qemu/build2/../system/qtest.c:907:9
+    #21 0x557ddb5fa3e2 in qtest_sendf /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/libqtest.c:640:5
+    #22 0x557ddb5fa4f4 in qtest_clock_step_next /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/libqtest.c:1009:5
+    #23 0x557ddb67c2ef in generic_fuzz /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/fuzz/generic_fuzz.c:667:13
+    #24 0x557ddb66e807 in LLVMFuzzerTestOneInput /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/fuzz/fuzz.c:158:5
+    #25 0x557dd97b6f52 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2009f52) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5)
+    #26 0x557dd97a1080 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x1ff4080) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5)
+    #27 0x557dd97a6d07 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x1ff9d07) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5)
+    #28 0x557dd97d0292 in main (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2023292) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5)
+    #29 0x7fd7e6223a8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
+    #30 0x7fd7e6223b48 in __libc_start_main csu/../csu/libc-start.c:360:3
+    #31 0x557dd979b884 in _start (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x1fee884) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2550 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2550
new file mode 100644
index 00000000..e0925fdc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2550
@@ -0,0 +1,25 @@
+GICv3 vGIC system registers not initialized on ARM Cortex-A15
+Description of problem:
+For Cortex-A15, the GICv3 vGIC registers are not initialized like for AArch64 CPUs, for example Cotex-A35, Cortex-A55, etc
+Steps to reproduce:
+The setup is not trivial. I can provide a boot image on request. But I hope the problem is straight-forward.
+Additional information:
+Suggested fix:
+```diff
+index 20c2737f17..136b513bda 100644
+--- a/target/arm/tcg/cpu32.c
++++ b/target/arm/tcg/cpu32.c
+@@ -569,6 +569,12 @@ static void cortex_a15_initfn(Object *obj)
+     cpu->ccsidr[1] = 0x201fe00a; /* 32K L1 icache */
+     cpu->ccsidr[2] = 0x711fe07a; /* 4096K L2 unified cache */
+     cpu->isar.reset_pmcr_el0 = 0x410F3000;
++
++    /* From B3.5 VGIC Type register */
++    cpu->gic_num_lrs = 4;
++    cpu->gic_vpribits = 5;
++    cpu->gic_vprebits = 5;
++
+     define_arm_cp_regs(cpu, cortexa15_cp_reginfo);
+ }
+
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2552 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2552
new file mode 100644
index 00000000..41319fbd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2552
@@ -0,0 +1,72 @@
+system libfdt said to be too old (1.5.1 min required) but 1.7.1 is installed.
+Description of problem:
+<--
+I am running an update build of the latest qemu version 9.0.2 to update it from 8.1.2 in the IPFire firewall distribution.
+The build command being run was
+
+`
+./configure \
+	--prefix=/usr \
+	--sysconfdir=/etc \
+	--localstatedir=/var \
+	--enable-kvm \
+	--disable-attr \
+	--target-list="$(TARGETS)" \
+	--extra-cflags="$(CFLAGS)" \
+	--enable-spice \
+	--enable-usb-redir \
+	--enable-seccomp \
+	--disable-docs \
+	--disable-sdl \
+	--enable-slirp 
+`
+
+and where $TARGETS is
+
+`	x86_64-linux-user \
+	aarch64-linux-user \
+	riscv64-linux-user \
+	x86_64-softmmu \
+	aarch64-softmmu \
+	riscv64-softmmu
+`
+
+and $CFLAGS is
+
+`	"-O2"
+	"-g0"
+	"-pipe"
+	"-Wall"
+	"-fexceptions"
+	"-fPIC"
+	"-Wp,-U_FORTIFY_SOURCE"
+	"-Wp,-D_FORTIFY_SOURCE=3"
+	"-Wp,-D_GLIBCXX_ASSERTIONS"
+	"-fstack-protector-strong"
+	"-fstack-clash-protection"
+` 
+
+This built qemu successfully with version 8.1.2 and earlier versions.
+
+From version 9.0.1 onwards the subproject dtc has been removed from the Source Tarball and the build came back with the error message
+
+Library fdt found: NO
+
+../meson.build:3190:18: ERROR: Git command failed: ['/usr/bin/git', 'fetch', '--depth', '1', 'origin', 'b6910bec11614980a21e46fbccc35934b671bd81']
+
+The git command failed as the distribution build is done with no network connection. All packages have to be available in the build and so the package cannot be downloaded during the build.
+
+Therefore I moved the dtc package in the IPFire build to before building qemu and added --disable-download to the ./configure options.
+
+The error message changed to
+
+Library fdt found: YES
+
+../meson.build:3182:7: ERROR: Problem encountered: system libfdt requested, but it is too old (1.5.1 or newer required)
+
+However the dtc libfdt version is 1.7.1 - definitely newer than 1.5.1
+
+Why is the version being seen as too old?
+How do I get this to detect the dtc libfdt version correctly (it has detected that libfdt is present in the IPFire build environment).
+
+-->
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2557 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2557
new file mode 100644
index 00000000..2ab9a20f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2557
@@ -0,0 +1 @@
+balloon size startup parameter needed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2559 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2559
new file mode 100644
index 00000000..fbd96a41
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2559
@@ -0,0 +1,11 @@
+macOS cocoa UI cursor position mismatch when running Windows XP under QEMU 9.1.0
+Description of problem:
+QEMU 9.1.0 got hardware cursor support on macOS with the cocoa UI. When running a Windows XP guest, the windows's own cursor got a 13 pixel offset both in X and Y direction. When the "show-cursor" is off, the problem still exists, so the click target is not under the pointer of the cursor. I was using the "Red Hat QXL GPU" driver v6.1.0.10024 which was built in 2015.
+
+I also checked it with Linux (i have an x86-64 Alma Linux 8 installation too), this working fine when using the "-display cocoa,show-cursoor=off,zoom-to-fit=off -device virtio-vga" parameters.
+Steps to reproduce:
+1. Load a Windows XP with QXL drivers installed
+Additional information:
+![Screenshot_2024-09-05_at_6.13.34_PM](/uploads/4edd814458f40d01a9a806a010068687/Screenshot_2024-09-05_at_6.13.34_PM.png)
+
+![xp](/uploads/1d74ed8a1d71fcaa9f4ef328368d073c/xp.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/256 b/gitlab/issues_text/target_missing/host_missing/accel_missing/256
new file mode 100644
index 00000000..f8d712b9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/256
@@ -0,0 +1 @@
+`make install` fails on documentation when using Sphinx 4
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2561 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2561
new file mode 100644
index 00000000..a351b5ca
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2561
@@ -0,0 +1,39 @@
+Sound doesnt work on debian guest + debian host using Pipewire
+Description of problem:
+There is no sound on Debian Stable VM. Im using SPICE for audio redirection.
+Steps to reproduce:
+1. Download debian stable ISO (12 atm)
+2. Install it on your KVM
+3. Make sure your host and your guest are using pipewire (check https://wiki.debian.org/PipeWire#Installation)
+4. No sound is transmitted to the host.
+Additional information:
+- I have tried switching SPICE to something else like ALSA, but it will result in hanging of the video page similar to this video: 
+
+https://github.com/QubesOS/qubes-issues/issues/1698#issuecomment-1031376517
+
+- Tried to use direct pipewire, but resulted into error:
+
+```
+Error starting domain: internal error: process exited while connecting to monitor: 2024-09-04T18:13:40.241754Z qemu-system-x86_64: Unknown audio driver pipewire'. Perhaps you want to install qemu-system-gui package?
+
+Traceback (most recent call last):
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper
+    callback(asyncjob, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, in tmpcb
+    callback(*args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
+    ret = fn(self, *args, **kwargs)
+          ^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1402, in startup
+    self._backend.create()
+  File "/usr/lib/python3/dist-packages/libvirt.py", line 1379, in create
+    raise libvirtError('virDomainCreate() failed')
+libvirt.libvirtError: internal error: process exited while connecting to monitor: 2024-09-04T18:13:40.241754Z qemu-system-x86_64: Unknown audio driver pipewire'. Perhaps you want to install qemu-system-gui package?
+```
+
+Yes i have installed "qemu-system-gui" but still got the same message.
+
+
+Debian XML with SPICE:
+
+[Debian-XML.txt](/uploads/66e09b37f672b49f8f0a0a01d3c6a6b2/Debian-XML.txt)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2563 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2563
new file mode 100644
index 00000000..dfcacf9e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2563
@@ -0,0 +1,210 @@
+W64 build referenced to by https://www.qemu.org/download/#windows fails to run with GTK and 3D but cross-build for W64 works ok with GTK and 3d
+Description of problem:
+Qemu W64 build referenced to by https://www.qemu.org/download/#windows (https://qemu.weilnetz.de/w64/qemu-w64-setup-20240903.exe) crashes with aforementioned command line, leaving 0xc0000005 exception in Windows event log. But a custom cross-compiled build at least boots into default qemu BIOS. See steps below to cross-compile qemu with GTK + OpenGL +VirGL support.
+Steps to reproduce:
+1. `wget https://qemu.weilnetz.de/w64/qemu-w64-setup-20240903.exe`, install it, run `qemu-system-x86_64.exe -display gtk,gl=on -device virtio-vga-gl` and watch immediate qemu crash.
+ 2. Prepare cross-compilation build of qemu 9.1.0 using following steps:
+ 3. Download official Fedora workstation 40 x86_64 ISO and install it to a virtual disk and boot that disk.
+ 4. `wget https://download.qemu.org/qemu-9.1.0.tar.xz`\
+    `tar xvJf qemu-9.1.0.tar.xz`\
+    `cd qemu-9.1.0`
+ 5. Run `sudo yum install git meson ninja-build python3-sphinx python3-sphinx_rtd_theme gcc mingw64-gcc mingw64-glib2 mingw64-pkg-config mingw64-pixman mingw64-gtk3 mingw64-SDL2 mingw64-libepoxy mingw64-librsvg2` in virtual Fedora. `mingw64-librsvg2` is optional, see step #14
+ 6. `git clone https://gitlab.freedesktop.org/slirp/libslirp.git` (e61dbd45 as of 04 August 2024) `git clone https://gitlab.freedesktop.org/virgl/virglrenderer.git` (3d82ed86 as of 03 September 2024)
+ 7. create file x86_64-w64-mingw32.txt in qemu-9.1.0 directory with the content as follows:\
+    `[binaries]`\
+    `c = '/usr/bin/x86_64-w64-mingw32-gcc'`\
+    `cpp = '/usr/bin/x86_64-w64-mingw32-g++'`\
+    `ar = '/usr/bin/x86_64-w64-mingw32-ar'`\
+    `strip = '/usr/bin/x86_64-w64-mingw32-strip'`\
+    `pkg-config = '/usr/bin/x86_64-w64-mingw32-pkg-config'`\
+    `exe_wrapper = 'wine'`\
+    \
+    `[host_machine]`\
+    `system = 'windows'`\
+    `cpu_family = 'x86_64'`\
+    `cpu = 'i686'`\
+    `endian = 'little'`
+ 8. Make a directory to which QEMU dependencies will be installed after compilation from git: `export CROSS_QEMU_DEPS="/home/cross-qemu-deps"`\
+    `sudo mkdir -p $CROSS_QEMU_DEPS`
+ 9. Install libslirp so that future qemu binaries can have internet access via -netdev user\
+    `    cd libslirp`\
+    \
+    `    meson setup --cross-file ../x86_64-w64-mingw32.txt --prefix "$CROSS_QEMU_DEPS" build-mingw/`\
+    `    meson compile -C build-mingw`\
+    `    cd build-mingw`\
+    `    ninja install`
+10. Install virgl to have 3D hardware acceleration\
+    `    cd ../../`\
+    `    cd virglrenderer`\
+    \
+    `    meson setup --cross-file ../x86_64-w64-mingw32.txt --prefix "$CROSS_QEMU_DEPS" build-mingw/`\
+    `    meson compile -C build-mingw`\
+    `    cd build-mingw`\
+    `    ninja install`
+11. Set three environment variables for cross-compilation:
+
+    `sudo find / -type f -name '*.pc'` and make sure all mingw \*.pc files live in `/usr/x86_64-w64-mingw32/sys-root/mingw/share/pkgconfig/` and `/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/`. Correct these paths in PKG_CONFIG_PATH if you see they were altered by mingw or package contributors.\
+    \
+    `export PKG_CONFIG_PATH="/usr/x86_64-w64-mingw32/sys-root/mingw/share/pkgconfig/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/:$PKG_CONFIG_PATH"`
+
+    \
+    `export PKG_CONFIG_LIBDIR="${CROSS_QEMU_DEPS}/lib/pkgconfig/:$PKG_CONFIG_LIBDIR"`
+
+    \
+    `export PKG_CONFIG_SYSROOT_DIR=""`
+12. <span dir="">Configure Qemu makefile:</span>
+
+    `cd ../../`
+
+    `./configure --cross-prefix=x86_64-w64-mingw32- --enable-gtk --enable-sdl --enable-opengl --enable-virglrenderer --enable-slirp --enable-debug`
+
+    and make sure you see this in the output of configure:
+
+    `Compilation`\
+    `host CPU : x86_64`\
+    `host endianness : little`\
+    `C compiler : x86_64-w64-mingw32-gcc -m64`\
+    `Host C compiler : cc`
+
+    and this one:
+
+    `Checking whether type "struct virgl_renderer_resource_info_ext" has member "d3d_tex2d" with dependency virglrenderer: YES`
+13. Cross-compile qemu: `` make -j`nproc` ``
+14. \[optional step to get rid of "**Gtk-WARNING \*\*: 19:22:02.461: Could not load a pixbuf**"\]
+
+    **Copy gdk-pixbuf-query-loaders.exe** from `/usr/x86_64-w64-mingw32/sys-root/mingw/bin/`\
+    to\
+    `./qemu-9.1.0/build/qemu-bundle/qemu`**\
+    \
+    `mkdir -p ./qemu-9.1.0/build/qemu-bundle/qemu/lib`\
+    \
+    copy recursively /usr/x86_64-w64-mingw32/sys-root/mingw/lib/gdk-pixbuf-2.0** to `./qemu-9.1.0/build/qemu-bundle/qemu/lib`
+
+    **`mkdir -p ./qemu-9.1.0/build/qemu-bundle/qemu/share`**\
+    \
+    **copy recursively /usr/x86_64-w64-mingw32/sys-root/mingw/share/icons** to `./qemu-9.1.0/build/qemu-bundle/qemu/share`
+
+    **copy recursively /usr/x86_64-w64-mingw32/sys-root/mingw/share/themes** to `./qemu-9.1.0/build/qemu-bundle/qemu/share`
+
+    Run `gdk-pixbuf-query-loaders.exe --update-cache` on host right before step 17.
+15. Copy all dll files from
+
+    `/usr/x86_64-w64-mingw32/sys-root/mingw/bin/`\
+    to\
+    `./qemu-9.1.0/build/qemu-bundle/`**`qemu`**
+
+    Copy libvirglrenderer-1.dll and libslirp-0.dll from `$CROSS_QEMU_DEPS` directory exported above to
+
+    `./qemu-9.1.0/build/qemu-bundle/`**`qemu`**
+16. Copy this **`qemu`** folder from the previous step to Windows machine using ssh or whatever else\
+    E.g. by doing\
+    `    sudo yum install openssh-server`\
+    `    sudo systemctl start sshd`\
+    `    sudo systemctl status sshd`\
+    on guest OS (provided you have launched guest Fedora qemu with `-nic user,hostfwd=tcp::8888-:22` command line parameter for ssh)
+
+    and then
+
+    `scp.exe -P 8888 -r virtual_machine_user@127.0.0.1:/home/virtual_machine_user/qemu-9.1.0/build/qemu-bundle/qemu C:\downloads\qemu`\
+    on host OS
+17. `cd` to that `qemu` folder and run `qemu-system-x86_64.exe -display gtk,gl=on -device virtio-vga-gl` and watch qemu booting into BIOS.
+
+<details>
+<summary>Previous version</summary>
+
+1\. \`wget https://qemu.weilnetz.de/w64/qemu-w64-setup-20240903.exe\\\\\\\\\\\\\\\`, install it, run \`qemu-system-x86_64.exe -display gtk,gl=on -device virtio-vga-gl\` and watch immediate qemu crash. 2. Prepare cross-compilation build of qemu 9.1.0 using following steps: 3. Download official Fedora workstation 40 x86_64 ISO and install it to a virtual disk and boot that disk. 4. Run \`sudo yum install meson ninja-build python3-sphinx python3-sphinx_rtd_theme gcc mingw64-gcc mingw64-glib2 mingw64-pkg-config mingw64-pixman mingw64-gtk3 mingw64-SDL2 mingw64-libepoxy\` in virtual Fedora. 5. \`wget https://download.qemu.org/qemu-9.1.0.tar.xz\\\\\\\\\\\\\\\\\\\\\\\`
+
+```
+`tar xvJf qemu-9.1.0.tar.xz`\
+`cd qemu-9.1.0`
+```
+
+ 6. `git clone https://gitlab.freedesktop.org/virgl/virglrenderer.git` (3d82ed86 as of 03 September 2024)\
+    `cd virglrenderer`
+ 7. create file x86_64-w64-mingw32.txt in virglrenderer directory with the content as follows:\
+    `[binaries]`\
+    `c = '/usr/bin/x86_64-w64-mingw32-gcc'`\
+    `cpp = '/usr/bin/x86_64-w64-mingw32-g++'`\
+    `ar = '/usr/bin/x86_64-w64-mingw32-ar'`\
+    `strip = '/usr/bin/x86_64-w64-mingw32-strip'`\
+    `pkg-config = '/usr/bin/x86_64-w64-mingw32-pkg-config'`\
+    `exe_wrapper = 'wine'`\
+    \
+    `[host_machine]`\
+    `system = 'windows'`\
+    `cpu_family = 'x86_64'`\
+    `cpu = 'i686'`\
+    `endian = 'little'`
+ 8. Run `meson setup --cross-file x86_64-w64-mingw32.txt build-mingw`\
+    `meson compile -C build-mingw`\
+    `cd build-mingw`\
+    `ninja install`
+ 9. Set pkgconfig for virglrenderer: `export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/home/your_user/virglrenderer/build-mingw/meson-private`\
+    (replace /home/your_user/virglrenderer/build-mingw/meson-private with path containing virglrenderer.pc file from output of `sudo find / -type f -name 'virglrenderer.pc'` command)
+10. Run confugure: \
+    `cd ../../`\
+    `./configure --cross-prefix=x86_64-w64-mingw32- --enable-gtk --enable-sdl --enable-opengl --enable-virglrenderer --enable-debug`\
+    \
+    and make sure you see this in the output of configure:\
+    `Compilation`\
+    `host CPU : x86_64`\
+    `host endianness : little`\
+    `C compiler : x86_64-w64-mingw32-gcc -m64`\
+    `Host C compiler : cc`\
+    \
+    run\
+    `export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig"`
+11. Run this command to see where x86_64-w64-mingw32-pkg-config will look for virglrenderer.h:
+
+    `/usr/bin/x86_64-w64-mingw32-pkg-config --cflags virglrenderer`\
+    \> -I/usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/virgl (possible result)
+12. Copy folder containing virglrenderer.h to that one to satisfy mingw expectations:
+
+    `sudo mkdir -p /usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/`\
+    `sudo cp -r /usr/local/include/virgl /usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/`
+13. Run search `sudo find / -type f -name 'libvirglrenderer.dll.a'` and satisfy mingw's expectation for libvirglrenderer.dll.a:\
+    `sudo mkdir -p /usr/x86_64-w64-mingw32/sys-root/usr/local/lib/`\
+    `sudo ln -s /usr/local/lib/libvirglrenderer.dll.a /usr/x86_64-w64-mingw32/sys-root/usr/local/lib/libvirglrenderer.dll.a`
+14. Cross-compile qemu: \
+    `make -j4`\
+    \* if you see "/usr/lib/gcc/x86_64-w64-mingw32/14.1.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lvirglrenderer: No such file or directory" then most likely Qemu's makefile was confused by libvirglrenderer.dll.a path; check `/usr/x86_64-w64-mingw32/bin/ld -lvirglrenderer --verbose` output to find out path of libvirglrenderer.dll.a file it cannot find
+15. copy all dll files from \
+    /usr/x86_64-w64-mingw32/sys-root/mingw/bin/\
+    to\
+    ./qemu-9.1.0-rc4/**build**
+16. copy libvirglrenderer-1.dll from /usr/local/bin to\
+    ./qemu-9.1.0-rc4/**build**
+17. copy this **build** folder to Windows machine using ssh or whatever else
+18. `cd` to that **build** folder and run `qemu-system-x86_64.exe -display gtk,gl=on -device virtio-vga-gl` and watch qemu booting into BIOS.
+
+</details>
+Additional information:
+P.S. Cross-compilation on Fedora build machine for Windows target usually requires installing pre-compiled binary packages along with libslirp and libvirglrenderer from git. Almost all of them include \*.pc files (pkg-config files) needed by mingw to find .h headers and .dll.a library files. Normally, it's not necessarry to add extra include paths using something like CFLAGS="-I/include_headers_path" or LDFLAGS="-L/path_to_dll_a_lib". The commands from above must produce a fully working windows build. But, just in case someone damages packages in Fedora repository or libslirp or virglrenderer in their git, here are some ideas how to fix broken links between files:
+
+- First, make sure you have enumerated all .pc folders from Fedora repository packages in PKG_CONFIG_PATH= and all .pc folders built from source in PKG_CONFIG_LIBDIR=, as it was shown at Step 11. If you see a message saying something like "virglrenderer.h not found", run this command to see where x86_64-w64-mingw32-pkg-config will look for virglrenderer.h: `/usr/bin/x86_64-w64-mingw32-pkg-config --cflags virglrenderer`
+
+> \-I/usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/virgl (possible result)
+
+- Then copy folder containing virglrenderer.h (for example, /usr/local/include/virgl) to that one to satisfy mingw expectations:
+
+  `sudo mkdir -p /usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/` `sudo cp -r /usr/local/include/virgl /usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/`
+- If you see "/usr/lib/gcc/x86_64-w64-mingw32/14.1.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lvirglrenderer: No such file or directory" then most likely Qemu's makefile was confused by libvirglrenderer.dll.a path; check `/usr/x86_64-w64-mingw32/bin/ld -lvirglrenderer --verbose` output to find out path of libvirglrenderer.dll.a file it cannot find
+- For example, `/usr/x86_64-w64-mingw32/bin/ld -lvirglrenderer --verbose` shows that build script tries to find .dll.a file under /usr/x86_64-w64-mingw32/sys-root/usr/local/lib/libvirglrenderer.dll.a and `find / -type f -name 'libvirglrenderer.dll.a'` shows that file is in /usr/local/lib/libvirglrenderer.dll.a
+- Then satisfy mingw's expectation for libvirglrenderer.dll.a: `sudo mkdir -p /usr/x86_64-w64-mingw32/sys-root/usr/local/lib/`\
+  `sudo ln -s /usr/local/lib/libvirglrenderer.dll.a /usr/x86_64-w64-mingw32/sys-root/usr/local/lib/libvirglrenderer.dll.a`
+
+Upd: I was able to refine instructions on how to cross-compile Qemu's dependencies thanks to these references:
+
+https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/52:
+
+> PKG_CONFIG_SYSROOT_DIR blindly prepend the sysroot to all paths. I made a MR that add PKG_CONFIG_SYSROOT_MAP to get smarter mapping from pcfiledir-\>sysroot. !7. I generally discontinued the use of PKG_CONFIG_SYSROOT_DIR and switched to merely using PKG_CONFIG_LIBDIR. That way I got absolute paths everyehere which at least was consistent and could be postprocessed if needed.
+
+https://forum.qt.io/topic/88946/qt5-10-1-cross-compile-configure-errors/9:
+
+> WARNING: Disabling pkg-config since PKG_CONFIG_LIBDIR is not set and the host's .pc files would be used (even if you set PKG_CONFIG_PATH). Set this variable to the directory that contains target .pc files for pkg-config to function correctly when cross-compiling or use -pkg-config to override this test.
+
+https://cmake.org/pipermail/cmake/2008-November/025050.html:
+
+> The situation is as follows: PKG_CONFIG_PATH is searched before PKG_CONFIG_LIBDIR for the desired \*.pc file. (The man page doesn't say which is searched first, but my tests reveal that is the order at least for the present version of pkg-config.) Cross-compiling users should avoid using native paths in PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR. Furthermore, cross-compiling users should always specify PKG_CONFIG_LIBDIR (with or without PKG_CONFIG_PATH) since use of PKG_CONFIG_LIBDIR supresses appending default native paths to whatever is specified in PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR.
+>
+> In sum, for cross-compilation purposes you should always use PKG_CONFIG_LIBDIR (with or without PKG_CONFIG_PATH) and make sure there are no native paths in it (or in PKG_CONFIG_PATH). If you follow those rules you should get a good cross-compilation result, otherwise not.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2564 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2564
new file mode 100644
index 00000000..4ce6bd27
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2564
@@ -0,0 +1 @@
+ubuntu-22.04-s390x-all-system CI job often times out
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2565 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2565
new file mode 100644
index 00000000..ee223209
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2565
@@ -0,0 +1,13 @@
+Bisected: 176e3783f2ab14 results in a heavy performance regression with the SDL interface
+Description of problem:
+With the patch  176e3783f2ab14 a significant 3D performance regression was introduced when using the SDL gui and VirGL. Before the patch glxgears runs at about 4000 FPS on my machine, with the patch this drops to about 150 FPS, and if one moves the mouse the reported frame rate drops even more.
+Steps to reproduce:
+1. Run the qemu like given above with a current Debian-SID guest
+2. Start glxgears from a terminal 
+3. Move the mouse continuously to see the extra drop in frame rate
+Additional information:
+* (Guest) OpenGL Renderer string: virgl (AMD Radeon RX 6700 XT (radeonsi, navi22, LLVM 18.1.8 ...)
+* Reverting the commit 176e3783f2ab14 fixes the problem on SDL 
+* I don't think the host kernel version is an issue here (namely the KVM patches that are required to run Venus on discrete graphics cards) 
+* I've seen a similar issue when using GTK, but other that with SDL it's already present in version 7.2.11 (the one I used as a "good" base when I was bisecting the regression) - so I was not able to bisect yet.
+* I've looked around in the code and I'm aware the that commit *shouldn't* have the impact it seems to have. I can only assume that there is some unexpected side effect when creating the otherwise unused renderer.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2566 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2566
new file mode 100644
index 00000000..d46bdc6a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2566
@@ -0,0 +1,119 @@
+Plugin deadlock with qemu_plugin_register_vcpu_mem_cb introduced prior to v8.1.0
+Description of problem:
+Between v8.0.5 and v8.1.0 a bug was introduced where a TCG plugin calling `qemu_plugin_register_vcpu_mem_cb` can cause a deadlock. This bug is still present in the current head of master (a66f28df650166ae8b50c992eea45e7b247f4143).
+
+I was able to reproduce this reliably (>95% of the time) testing with the minimal plugin shown below. In more limited testing, I found the logic in the (in-tree) hotpages plugin will also trigger this deadlock.
+
+I tested with the Ubuntu Bionic qcow from [here](https://panda.re/qcows/linux/ubuntu/1804/x86_64/bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2), but don't think there's anything particularly special about this qcow.
+
+
+A minimal plugin to trigger the deadlock is as follows. To build the plugin, you'll need to add a `NAMES += customtest` line into `contrib/plugins/Makefile.
+
+contrib/plugins/customtest.c:
+```
+#include <qemu-plugin.h>
+
+QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION;
+
+static void vcpu_mem(unsigned int cpu_index, qemu_plugin_meminfo_t info,
+                     uint64_t vaddr, void *udata)
+{}
+
+
+static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb)
+{
+    struct qemu_plugin_insn *insn;
+    size_t n = qemu_plugin_tb_n_insns(tb);
+
+    for (size_t i = 0; i < n; i++) {
+        insn = qemu_plugin_tb_get_insn(tb, i);
+
+        /* Register callback on memory read or write */
+        qemu_plugin_register_vcpu_mem_cb(insn, vcpu_mem,
+                                         QEMU_PLUGIN_CB_NO_REGS,
+                                         QEMU_PLUGIN_MEM_R, NULL);
+    }
+}
+
+QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id,
+                                           const qemu_info_t *info, int argc,
+                                           char **argv)
+{
+    qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans);
+
+    return 0;
+}
+```
+Steps to reproduce:
+1. From the current head of `master` (a66f28df650166ae8b50c992eea45e7b247f4143)
+2. Add the above plugin to the contrib/plugins directory and update the `contrib/plugins/Makefile` with `NAMES += customtest` so it will be built.
+3. `../configure --enable-plugins --target-list=x86_64-softmmu`
+4. `make && make plugins`
+5. `wget https://panda.re/qcows/linux/ubuntu/1804/x86_64/bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2`
+6. Launch the guest with `./qemu-system-x86_64 -m 1G -plugin contrib/plugins/libcustomtest.so bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2 -nographic -d plugin`, and wait a moment. There will be no output after the initial "Booting from Hard Disk" mesasge. Switch to the monitor with `ctrl+a c` type `quit` and press enter, qemu fails to exit because of the deadlock.
+Additional information:
+* I tested and saw the bug on the following commits/tags: current head of master (a66f28df650166ae8b50c992eea45e7b247f4143), v9.1.0, v9.0.0, and v8.2.6, v8.1.0.
+* I tested and saw no bug on the following tags: v8.0.5, v8.0.4, v8.0.0
+* If `qemu_plugin_register_vcpu_mem_cb` is called with a fourth argument of `0` instead of `QEMU_PLUGIN_MEM_R`, the guest did not hang (at least on the current head of master).
+* The monitor can still be reached with `ctrl+a c` after the deadlock, but running the `quit` command does not terminate the emulator (I don't think this is related to #1195 since things start hanging before the shutdown begins)
+
+Gdb shows the following backtraces (from the head of master) across the running threads. It seems that thread 3 and thread 2 are stuck, though I'm not too familiar with what they're doing.
+```
+(gdb) thread apply all bt
+
+Thread 3 (Thread 0x7f9677fff640 (LWP 754761) "qemu-system-x86"):
+#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x55a9c1047748 <exclusive_cond+40>) at ./nptl/futex-internal.c:57
+#1  __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55a9c1047748 <exclusive_cond+40>) at ./nptl/futex-internal.c:87
+#2  __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x55a9c1047748 <exclusive_cond+40>, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
+#3  0x00007f968280aa41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55a9c1047660 <qemu_cpu_list_lock>, cond=0x55a9c1047720 <exclusive_cond>) at ./nptl/pthread_cond_wait.c:503
+#4  ___pthread_cond_wait (cond=cond@entry=0x55a9c1047720 <exclusive_cond>, mutex=mutex@entry=0x55a9c1047660 <qemu_cpu_list_lock>) at ./nptl/pthread_cond_wait.c:627
+#5  0x000055a9bff8ce9f in qemu_cond_wait_impl (cond=0x55a9c1047720 <exclusive_cond>, mutex=0x55a9c1047660 <qemu_cpu_list_lock>, file=0x55a9bffc37b6 "../cpu-common.c", line=221) at ../util/qemu-thread-posix.c:225
+#6  0x000055a9bf8fc7b7 in start_exclusive () at ../cpu-common.c:221
+#7  start_exclusive () at ../cpu-common.c:192
+#8  0x000055a9bfc2f981 in ptw_setl_slow (new=23069091, old=23069059, in=0x7f9677ffa540) at ../target/i386/tcg/sysemu/excp_helper.c:112
+#9  ptw_setl (set=<optimized out>, old=23069059, in=0x7f9677ffa540) at ../target/i386/tcg/sysemu/excp_helper.c:130
+#10 ptw_setl (set=<optimized out>, old=23069059, in=0x7f9677ffa540) at ../target/i386/tcg/sysemu/excp_helper.c:121
+#11 mmu_translate (env=env@entry=0x55a9c2ab3bc0, in=in@entry=0x7f9677ffa5f0, out=out@entry=0x7f9677ffa5c0, err=err@entry=0x7f9677ffa5d0, ra=ra@entry=140283034940586) at ../target/i386/tcg/sysemu/excp_helper.c:412
+#12 0x000055a9bfc2fe4f in get_physical_address (ra=<optimized out>, err=<optimized out>, out=<optimized out>, mmu_idx=<optimized out>, access_type=<optimized out>, addr=25041848, env=<optimized out>) at ../target/i386/tcg/sysemu/excp_helper.c:583
+#13 x86_cpu_tlb_fill (cs=0x55a9c2ab1400, addr=25041848, size=<optimized out>, access_type=MMU_DATA_LOAD, mmu_idx=5, probe=<optimized out>, retaddr=140283034940586) at ../target/i386/tcg/sysemu/excp_helper.c:603
+#14 0x000055a9bfd92a59 in tlb_fill (retaddr=140283034940586, mmu_idx=5, access_type=MMU_DATA_LOAD, size=<optimized out>, addr=25041848, cpu=0x55a9c2ab1450) at ../accel/tcg/cputlb.c:1237
+#15 mmu_lookup1 (cpu=cpu@entry=0x55a9c2ab1400, data=data@entry=0x7f9677ffa750, mmu_idx=5, access_type=access_type@entry=MMU_DATA_LOAD, ra=ra@entry=140283034940586) at ../accel/tcg/cputlb.c:1634
+#16 0x000055a9bfd92b71 in mmu_lookup (cpu=cpu@entry=0x55a9c2ab1400, addr=addr@entry=25041848, oi=oi@entry=37, ra=ra@entry=140283034940586, type=type@entry=MMU_DATA_LOAD, l=l@entry=0x7f9677ffa750) at ../accel/tcg/cputlb.c:1724
+#17 0x000055a9bfd937b0 in do_ld4_mmu (cpu=cpu@entry=0x55a9c2ab1400, addr=addr@entry=25041848, oi=oi@entry=37, ra=140283034940586, ra@entry=37, access_type=access_type@entry=MMU_DATA_LOAD) at ../accel/tcg/cputlb.c:2356
+#18 0x000055a9bfd96afa in cpu_ldl_mmu (ra=37, oi=37, addr=25041848, env=0x55a9c2ab3bc0) at ../accel/tcg/ldst_common.c.inc:160
+#19 cpu_ldl_le_mmuidx_ra (env=env@entry=0x55a9c2ab3bc0, addr=25041848, mmu_idx=mmu_idx@entry=5, ra=ra@entry=140283034940586) at ../accel/tcg/ldst_common.c.inc:298
+#20 0x000055a9bfc9a639 in popl (sa=<synthetic pointer>) at ../target/i386/tcg/seg_helper.c:88
+#21 helper_ret_protected (env=0x55a9c2ab3bc0, shift=1, is_iret=0, addend=0, retaddr=140283034940586) at ../target/i386/tcg/seg_helper.c:2031
+#22 0x00007f96307734aa in code_gen_buffer ()
+#23 0x000055a9bfd855f6 in cpu_tb_exec (cpu=cpu@entry=0x55a9c2ab1400, itb=itb@entry=0x7f96307733c0 <code_gen_buffer+7811987>, tb_exit=tb_exit@entry=0x7f9677ffadd8) at ../accel/tcg/cpu-exec.c:458
+#24 0x000055a9bfd85b4c in cpu_loop_exec_tb (tb_exit=0x7f9677ffadd8, last_tb=<synthetic pointer>, pc=<optimized out>, tb=0x7f96307733c0 <code_gen_buffer+7811987>, cpu=0x55a9c2ab1400) at ../accel/tcg/cpu-exec.c:908
+#25 cpu_exec_loop (cpu=cpu@entry=0x55a9c2ab1400, sc=sc@entry=0x7f9677ffae70) at ../accel/tcg/cpu-exec.c:1022
+#26 0x000055a9bfd86351 in cpu_exec_setjmp (cpu=cpu@entry=0x55a9c2ab1400, sc=sc@entry=0x7f9677ffae70) at ../accel/tcg/cpu-exec.c:1039
+#27 0x000055a9bfd86b0e in cpu_exec (cpu=cpu@entry=0x55a9c2ab1400) at ../accel/tcg/cpu-exec.c:1065
+#28 0x000055a9bfdaafa4 in tcg_cpu_exec (cpu=cpu@entry=0x55a9c2ab1400) at ../accel/tcg/tcg-accel-ops.c:78
+#29 0x000055a9bfdab0ff in mttcg_cpu_thread_fn (arg=arg@entry=0x55a9c2ab1400) at ../accel/tcg/tcg-accel-ops-mttcg.c:95
+#30 0x000055a9bff8c2d1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:541
+#31 0x00007f968280bac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
+#32 0x00007f968289d850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+
+Thread 2 (Thread 0x7f967d990640 (LWP 754759) "qemu-system-x86"):
+#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
+#1  0x000055a9bff8d5b2 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /home/user/git/qemu/include/qemu/futex.h:29
+#2  qemu_event_wait (ev=ev@entry=0x55a9c1079588 <rcu_call_ready_event>) at ../util/qemu-thread-posix.c:464
+#3  0x000055a9bff97d82 in call_rcu_thread (opaque=opaque@entry=0x0) at ../util/rcu.c:278
+#4  0x000055a9bff8c2d1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:541
+#5  0x00007f968280bac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
+#6  0x00007f968289d850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+
+Thread 1 (Thread 0x7f967dc035c0 (LWP 754758) "qemu-system-x86"):
+#0  0x00007f968288fcce in __ppoll (fds=0x55a9c382dd00, nfds=5, timeout=<optimized out>, timeout@entry=0x7ffeadbd44d0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:42
+#1  0x000055a9bffa4e05 in ppoll (__ss=0x0, __timeout=0x7ffeadbd44d0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:64
+#2  qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=54822346) at ../util/qemu-timer.c:351
+#3  0x000055a9bffa1ed6 in os_host_main_loop_wait (timeout=54822346) at ../util/main-loop.c:305
+#4  main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:589
+#5  0x000055a9bfb47217 in qemu_main_loop () at ../system/runstate.c:826
+#6  0x000055a9bfee421b in qemu_default_main () at ../system/main.c:37
+#7  0x00007f96827a0d90 in __libc_start_call_main (main=main@entry=0x55a9bf8f9790 <main>, argc=argc@entry=9, argv=argv@entry=0x7ffeadbd46e8) at ../sysdeps/nptl/libc_start_call_main.h:58
+#8  0x00007f96827a0e40 in __libc_start_main_impl (main=0x55a9bf8f9790 <main>, argc=9, argv=0x7ffeadbd46e8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffeadbd46d8) at ../csu/libc-start.c:392
+#9  0x000055a9bf8fa7b5 in _start ()
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/257 b/gitlab/issues_text/target_missing/host_missing/accel_missing/257
new file mode 100644
index 00000000..094b6600
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/257
@@ -0,0 +1 @@
+[Archlinux][git]With git revision e58c7a3b, packaging with meson install is broken.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2570 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2570
new file mode 100644
index 00000000..13fc2979
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2570
@@ -0,0 +1,55 @@
+TCG Plugins: "Code should not be reached" error after resetting plugin from vcpu_tb_trans callback
+Description of problem:
+In a TCG plugin, using the `qemu_plugin_reset` method from within a `vcpu_tb_trans` callback produces the following error. If this isn't a supported use case, it should probably be described in the documentation. If this is supposed to work, it doesn't seem to.
+
+```
+**
+ERROR:/home/user/git/qemu/tcg/i386/tcg-target.c.inc:3018:tcg_out_op: code should not be reached
+Bail out! ERROR:/home/user/git/qemu/tcg/i386/tcg-target.c.inc:3018:tcg_out_op: code should not be reached
+Aborted (core dumped)
+```
+Steps to reproduce:
+1. Build the current head of master (4b7ea33074450bc6148c8e1545d78f179e64adb4) with the below `min` plugin (i.e., add to contrib/plugins and update contrib/plugins/Makefile so it is built)
+2. `../configure --enable-plugins --target-list=x86_64-softmmu --disable-docs`
+3. `make && make plugins`
+4. Get a qcow, e.g., the Ubuntu Bionic qcow from [here](https://panda.re/qcows/linux/ubuntu/1804/x86_64/bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2).
+5. `./qemu-system-x86_64 -plugin contrib/plugins/libmin.so bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2 -nographic`
+
+The first three lines are output by the plugin as expected, the error after that and the abort are unexpected:
+```
+Translating basic block
+Reset request issued
+Reset finished
+**
+ERROR:/home/user/git/qemu/tcg/i386/tcg-target.c.inc:3018:tcg_out_op: code should not be reached
+Bail out! ERROR:/home/user/git/qemu/tcg/i386/tcg-target.c.inc:3018:tcg_out_op: code should not be reached
+Aborted (core dumped)
+```
+Additional information:
+contrib/plugins/min.c
+```c
+#include <stdio.h>
+#include <qemu-plugin.h>
+
+QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION;
+
+qemu_plugin_id_t plugin_id = {0};
+
+static void post_reset(qemu_plugin_id_t id) {
+    printf("Reset finished\n");
+}
+
+static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb) {
+    printf("Translating basic block\n");
+    qemu_plugin_reset(plugin_id, post_reset);
+    printf("Reset request issued\n");
+}
+
+QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id,
+                   const qemu_info_t *info, int argc, char **argv) {
+
+    qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans);
+    plugin_id = id;
+    return 0;
+}
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2575 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2575
new file mode 100644
index 00000000..82a41fb5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2575
@@ -0,0 +1 @@
+cocoa: Remove deprecated CVDisplayLinkCreateWithCGDisplay() calls
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2576 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2576
new file mode 100644
index 00000000..8a1148d2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2576
@@ -0,0 +1 @@
+virtio-balloon: Assertion `mrs.mr' failed.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2579 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2579
new file mode 100644
index 00000000..4bb5329d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2579
@@ -0,0 +1 @@
+Is there a plan to fix the vulnerabilities CVE-2023-1386 and CVE-2021-3735?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/258 b/gitlab/issues_text/target_missing/host_missing/accel_missing/258
new file mode 100644
index 00000000..0bf8921c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/258
@@ -0,0 +1 @@
+Add Illumnos VM image
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2584 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2584
new file mode 100644
index 00000000..afea4ac6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2584
@@ -0,0 +1,16 @@
+nbd URI wrong export name (regression in qemu 9.1)
+Description of problem:
+qemu with an nbd URI seems to pass the wrong export name to the server, if the exportname is `.`.  This seems
+to be a regression in qemu 9.1, because it didn't happen in 9.0.
+Steps to reproduce:
+```
+$ nbdkit -fv -U - null --run 'qemu-img info "nbd+unix:///.?socket=$unixsocket"'
+...
+nbdkit: null[1]: debug: null: open readonly=0 exportname="" tls=0
+```
+
+In qemu 9.0 this was correct:
+
+```
+nbdkit: null[1]: debug: null: open readonly=0 exportname="." tls=0
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2587 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2587
new file mode 100644
index 00000000..0e3f09f7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2587
@@ -0,0 +1 @@
+Avoid using error_setg(&error_fatal, ...)  in the QEMU sources
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2589 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2589
new file mode 100644
index 00000000..06c4dbf9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2589
@@ -0,0 +1,56 @@
+Support guest shutdown of Alpine Linux in guest agent
+Description of problem:
+The qemu-guest-agent's shutdown calls `/sbin/shutdown` with the apropriate flags to shut down a posix system. On Alpine Linux, which is based on busybox, there is no `/sbin/shutdown`, instead there are `/sbin/poweroff`, `/sbin/halt` and `/sbin/reboot`. We have used a downstream patch for years that will exec those as a fallback in case execing `/sbin/shutdown` fails.
+
+With qemu 9.2 this patch no longer applies and it is probably time to solve this properly in upstream qemu.
+
+The question is how?
+
+Some options:
+
+- Set the powerdown, halt and reboot commands via build time configure option
+- Add a fallback if the `execlp` fails (similar to what downstream Alpine's patch does now). We could for example give `ga_run_command` a `const char **argv[]`, and try `execvp` all of them before erroring out.
+- Test the existence of `/sbin/shutdown` before calling `ga_run_command`.
+- Do nothing. Let downstream Alpine Linux handle it.
+Steps to reproduce:
+1. Build qemu-guest-agent for Alpine Linux
+2. boot a Alpine linux VM and install the qemu-guest-agent
+3. Try shutdown the VM via qmp command.
+Additional information:
+The patch that we previously used that no longer applies:
+```diff
+diff --git a/qga/commands-posix.c b/qga/commands-posix.c
+index 954efed01..61427652c 100644
+--- a/qga/commands-posix.c
++++ b/qga/commands-posix.c
+@@ -84,6 +84,7 @@ static void ga_wait_child(pid_t pid, int *status, Error **errp)
+ void qmp_guest_shutdown(bool has_mode, const char *mode, Error **errp)
+ {
+     const char *shutdown_flag;
++    const char *fallback_cmd = NULL;
+     Error *local_err = NULL;
+     pid_t pid;
+     int status;
+@@ -101,10 +102,13 @@ void qmp_guest_shutdown(bool has_mode, const char *mode, Error **errp)
+     slog("guest-shutdown called, mode: %s", mode);
+     if (!has_mode || strcmp(mode, "powerdown") == 0) {
+         shutdown_flag = powerdown_flag;
++        fallback_cmd = "/sbin/poweroff";
+     } else if (strcmp(mode, "halt") == 0) {
+         shutdown_flag = halt_flag;
++        fallback_cmd = "/sbin/halt";
+     } else if (strcmp(mode, "reboot") == 0) {
+         shutdown_flag = reboot_flag;
++        fallback_cmd = "/sbin/reboot";
+     } else {
+         error_setg(errp,
+                    "mode is invalid (valid values are: halt|powerdown|reboot");
+@@ -125,6 +129,7 @@ void qmp_guest_shutdown(bool has_mode, const char *mode, Error **errp)
+ #else
+         execl("/sbin/shutdown", "shutdown", "-h", shutdown_flag, "+0",
+                "hypervisor initiated shutdown", (char *)NULL);
++        execle(fallback_cmd, fallback_cmd, (char*)NULL, environ);
+ #endif
+         _exit(EXIT_FAILURE);
+     } else if (pid < 0) {
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/259 b/gitlab/issues_text/target_missing/host_missing/accel_missing/259
new file mode 100644
index 00000000..fae787c1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/259
@@ -0,0 +1 @@
+dma_blk_cb leaks memory map handles on misaligned IO
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2592 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2592
new file mode 100644
index 00000000..3e2f82a0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2592
@@ -0,0 +1,37 @@
+qemu-aarch64 cannot properly support some python functions from the `time` module
+Description of problem:
+When a function is run in python (for example, `time.time()`), python returns the following error:
+```
+Traceback (most recent call last):
+  File "<string>", line 1, in <module>
+OSError: [Errno 0] Error
+```
+I am absolutely sure that this problem is related to `qemu-aarch64`, because the same python build works perfectly in aarch64 machine. In addition, python for arm architecture with `qemu-arm` does not have such a problem.
+Steps to reproduce:
+Note, this instruction specifies the stage of installation of that very python. But since it is compiled for Termux, you will have to use some scripts.
+1. Create a simple codespace environment.
+2. Run the following commands through the terminal:
+```
+git clone https://github.com/termux-pacman/glibc-packages
+cd glibc-packages
+./get-build-package.sh
+sudo mkdir /data
+sudo chown codespace /data
+sudo chgrp codespace /data
+sudo apt update
+sudo apt install patchelf
+./scripts/setup-cgct.sh
+```
+3. Run the following command. Note that the installation phase will start there. You should stop the script when the installation phase is complete.
+```
+./build-package.sh -I -w --library glibc gpkg/gobject-introspection
+```
+4. Install standard qemu via apt.
+5. Run the following command:
+```
+qemu-aarch64 /data/data/com.termux/files/usr/glibc/bin/python3.12 -c "import time; time.time()"
+```
+Additional information:
+- For some reason this error only occurs in the environment from GitHub. On my computer this error does not occur.
+ - Here is a log of one of the github actions, which shows an attempt to compile packages with python on different architectures - https://github.com/termux-pacman/glibc-packages/actions/runs/11023254502.  
+For reference, I use qemu for more flexible compilation of packages. And in github actions, qemu is installed here - https://github.com/termux-pacman/glibc-packages/blob/main/.github/workflows/build.yml#L35.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2596 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2596
new file mode 100644
index 00000000..01406fee
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2596
@@ -0,0 +1 @@
+linux-user elf parsing endianness issue (Invalid note in PT_GNU_PROPERTY)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2602 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2602
new file mode 100644
index 00000000..7d8ea256
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2602
@@ -0,0 +1,9 @@
+Windows installer being signed with an expired certificate
+Description of problem:
+Digital Signature for setup is invalid
+Steps to reproduce:
+1. Downloaded the latest 64-bit windows installer
+2. Right Click and select Digital Signature tab
+3. Observe certificate shows valid dates are 12/8/2022 - 12/9/2023
+Additional information:
+![image](/uploads/cdfc8be6c7bf9648aa4e02dde15114f9/image.png){width=621 height=393}
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2603 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2603
new file mode 100644
index 00000000..2cb6522c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2603
@@ -0,0 +1,102 @@
+Recent libslirp commit broke Qemu network stack: qemu and libslirp teams should settle on SOCKET handler type
+Description of problem:
+https://gitlab.freedesktop.org/slirp/libslirp/-/commit/72f85005a2307fd0961543e3cea861ad7a4d201e introduced regression causing QEMU compilation for Windows to error out due to missing 64-bit SOCKET handler pointer type.
+
+```
+x86_64-w64-mingw32-gcc -m64 ... -MD -MQ libcommon.a.p/net_slirp.c.obj -MF libcommon.a.p/net_slirp.c.obj.d -o libcommon.a.p/net_slirp.c.obj -c ../net/slirp.c
+../net/slirp.c:289:25: error: initialization of 'void (*)(slirp_os_socket,  void *)' {aka 'void (*)(long long unsigned int,  void *)'} from incompatible pointer type 'void (*)(int,  void *)' [-Wincompatible-pointer-types]
+  289 |     .register_poll_fd = net_slirp_register_poll_fd,
+      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~
+../net/slirp.c:289:25: note: (near initialization for 'slirp_cb.register_poll_fd')
+../net/slirp.c:290:27: error: initialization of 'void (*)(slirp_os_socket,  void *)' {aka 'void (*)(long long unsigned int,  void *)'} from incompatible pointer type 'void (*)(int,  void *)' [-Wincompatible-pointer-types]
+  290 |     .unregister_poll_fd = net_slirp_unregister_poll_fd,
+      |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../net/slirp.c:290:27: note: (near initialization for 'slirp_cb.unregister_poll_fd')
+../net/slirp.c: In function 'net_slirp_poll_notify':
+../net/slirp.c:367:28: error: passing argument 3 of 'slirp_pollfds_fill' from incompatible pointer type [-Wincompatible-pointer-types]
+  367 |                            net_slirp_add_poll, poll->pollfds);
+      |                            ^~~~~~~~~~~~~~~~~~
+      |                            |
+      |                            int (*)(int,  int,  void *)
+In file included from ../net/slirp.c:41:
+/home/cross-qemu-deps/include/slirp/libslirp.h:255:40: note: expected 'SlirpAddPollCb' {aka 'int (*)(long long unsigned int,  int,  void *)'} but argument is of type 'int (*)(int,  int,  void *)'
+  255 |                         SlirpAddPollCb add_poll, void *opaque);
+      |                         ~~~~~~~~~~~~~~~^~~~~~~~
+```
+
+Possible solution relying on cross-platform MACRO: https://handsonnetworkprogramming.com/articles/socket-function-return-value-windows-linux-macos/
+Steps to reproduce:
+1. Prepare cross-compilation build of qemu 9.1.0 using following steps (It's not necessary to set up a virtual machine if your main OS has good mingw repository, like Fedora, Arch linux, Manjaro. But if you're on Debian or Ubuntu, it's required):
+2. Download official Fedora workstation 40 x86_64 ISO and install it to a virtual disk and boot that disk.
+3. On Fedora, do:\
+   `wget https://download.qemu.org/qemu-9.1.0.tar.xz`\
+   ` tar xvJf qemu-9.1.0.tar.xz`\
+   ` cd qemu-9.1.0`
+4. `sudo yum install git meson ninja-build python3-sphinx python3-sphinx_rtd_theme gcc mingw64-gcc mingw64-pkg-config mingw64-glib2`
+5. `git clone https://gitlab.freedesktop.org/slirp/libslirp.git`
+6. create file x86_64-w64-mingw32.txt in qemu-9.1.0 directory with the content as follows:
+
+```
+[binaries]
+c = '/usr/bin/x86_64-w64-mingw32-gcc'
+cpp = '/usr/bin/x86_64-w64-mingw32-g++'
+ar = '/usr/bin/x86_64-w64-mingw32-ar'
+strip = '/usr/bin/x86_64-w64-mingw32-strip'
+pkg-config = '/usr/bin/x86_64-w64-mingw32-pkg-config'
+exe_wrapper = 'wine'
+
+[host_machine]
+system = 'windows'
+cpu_family = 'x86_64'
+cpu = 'i686'
+endian = 'little'
+```
+
+ 7. Run 2 commands:
+
+    `export CROSS_QEMU_DEPS="/home/cross-qemu-deps"`\
+    ` sudo mkdir -p $CROSS_QEMU_DEPS`
+ 8. Install libslirp so that future qemu binaries can have internet access via \`-netdev user\`\
+    \
+    `cd libslirp`\
+    \
+    ` meson setup --cross-file ../x86_64-w64-mingw32.txt --prefix "$CROSS_QEMU_DEPS" build-mingw/`\
+    ` meson compile -C build-mingw`\
+    ` cd build-mingw`\
+    ` ninja install`
+ 9. Set environment variables for cross-compilation\
+    \
+    ` sudo find / -type f -name '*.pc'` and make sure all mingw \*.pc files live in /usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/. Correct this path in PKG_CONFIG_PATH if you see it was altered by mingw or package contributors.\
+    \
+    ` export PKG_CONFIG_PATH="/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/:$PKG_CONFIG_PATH"`\
+    ` export PKG_CONFIG_LIBDIR="${CROSS_QEMU_DEPS}/lib/pkgconfig/:$PKG_CONFIG_LIBDIR"`\
+    ` export PKG_CONFIG_SYSROOT_DIR=""`
+10. Configure Qemu makefile:\
+    \
+    `cd ../../`\
+    `./configure --cross-prefix=x86_64-w64-mingw32- --enable-slirp`\
+    \
+    and make sure you see this in the output of configure:\
+    `Compilation`\
+    `host CPU : x86_64`\
+    `host endianness : little`\
+    `C compiler : x86_64-w64-mingw32-gcc -m64`\
+    `Host C compiler : cc`
+11. Cross-compile qemu: `` make -j`nproc` ``
+12. Get the error `initialization of 'void (*)(slirp_os_socket,  void *)' {aka 'void (*)(long long unsigned int,  void *)'} from incompatible pointer type 'void (*)(int,  void *)'` as above.
+Additional information:
+After having seen this bug, do these steps (revert to the commit right before the buggy one).
+
+`    cd libslirp`\
+`    git reset --hard 5e97a93b`
+
+`    meson setup --cross-file ../x86_64-w64-mingw32.txt --prefix "$CROSS_QEMU_DEPS" build-mingw/ --reconfigure`\
+`    meson compile -C build-mingw`\
+`    cd build-mingw`\
+`    ninja install`
+
+``     cd ../../ ``\
+``     ./configure --cross-prefix=x86_64-w64-mingw32- --enable-slirp ``\
+``    make -j`nproc` ``
+
+=\> Cross-compilation comes to an end just fine, building all compilation targets without any errors.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2606 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2606
new file mode 100644
index 00000000..697309b2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2606
@@ -0,0 +1,198 @@
+PowerPC host code is broken on Darwin
+Description of problem:
+Existing code is just wrong for Darwin ppc, it won’t compile. Assembler syntax needs to be fixed and likely adjusted to correct ABI.
+Steps to reproduce:
+1. Run the build of qemu on Darwin ppc, see it fail.
+Additional information:
+This is a patch I used earlier to fix the build (together with few minor unrelated to powerpc fixes):
+```
+--- common-user/host/ppc/safe-syscall.inc.S.orig	2022-04-20 03:10:27.000000000 +0800
++++ common-user/host/ppc/safe-syscall.inc.S	2023-08-18 18:08:15.000000000 +0800
+@@ -25,17 +25,11 @@
+ # else
+ #  error "Unknown ABI"
+ # endif
+-#endif 
+-
+-#ifndef _CALL_SYSV
+-# error "Unsupported ABI"
+ #endif
+ 
+-
+         .global safe_syscall_base
+         .global safe_syscall_start
+         .global safe_syscall_end
+-        .type   safe_syscall_base, @function
+ 
+         .text
+ 
+@@ -47,11 +41,8 @@
+          * arguments being syscall arguments (also 'long').
+          */
+ safe_syscall_base:
+-        .cfi_startproc
+-        stwu    1, -8(1)
+-        .cfi_def_cfa_offset 8
+-        stw     30, 4(1)
+-        .cfi_offset 30, -4
++        stwu    r1, -8(r1)
++        stw     r30, 4(r1)
+ 
+         /*
+          * We enter with r3 == &signal_pending
+@@ -64,14 +55,14 @@
+          *               and returns the result in r3
+          * Shuffle everything around appropriately.
+          */
+-        mr      30, 3           /* signal_pending */
+-        mr      0, 4            /* syscall number */
+-        mr      3, 5            /* syscall arguments */
+-        mr      4, 6
+-        mr      5, 7
+-        mr      6, 8
+-        mr      7, 9
+-        mr      8, 10
++        mr      r30, r3           /* signal_pending */
++        mr      r0, r4            /* syscall number */
++        mr      r3, r5            /* syscall arguments */
++        mr      r4, r6
++        mr      r5, r7
++        mr      r6, r8
++        mr      r7, r9
++        mr      r8, r10
+ 
+         /*
+          * This next sequence of code works in conjunction with the
+@@ -83,25 +74,22 @@
+          */
+ safe_syscall_start:
+         /* if signal_pending is non-zero, don't do the call */
+-        lwz     12, 0(30)
+-        cmpwi   0, 12, 0
++        lwz     r12, 0(r30)
++        cmpwi   cr0, r12, 0
+         bne-    2f
+         sc
+ safe_syscall_end:
+         /* code path when we did execute the syscall */
+-        lwz     30, 4(1)        /* restore r30 */
+-        addi    1, 1, 8         /* restore stack */
+-        .cfi_restore 30
+-        .cfi_def_cfa_offset 0
++        lwz     r30, 4(r1)        /* restore r30 */
++        addi    r1, r1, 8         /* restore stack */
++
+         bnslr+                  /* return on success */
+         b       safe_syscall_set_errno_tail
+ 
+         /* code path when we didn't execute the syscall */
+-2:      lwz     30, 4(1)
+-        addi    1, 1, 8
+-        addi    3, 0, QEMU_ERESTARTSYS
++2:      lwz     r30, 4(r1)
++        addi    r1, r1, 8
++        addi    r3, 0, QEMU_ERESTARTSYS
+         b       safe_syscall_set_errno_tail
+ 
+-        .cfi_endproc
+-
+         .size   safe_syscall_base, .-safe_syscall_base
+
+
+--- common-user/host/ppc64/safe-syscall.inc.S.orig	2022-04-20 03:10:27.000000000 +0800
++++ common-user/host/ppc64/safe-syscall.inc.S	2022-05-31 13:23:21.000000000 +0800
+@@ -13,7 +13,6 @@
+         .global safe_syscall_base
+         .global safe_syscall_start
+         .global safe_syscall_end
+-        .type   safe_syscall_base, @function
+ 
+         .text
+ 
+@@ -23,19 +22,10 @@
+          * second one the system call number (as a 'long'), and all further
+          * arguments being syscall arguments (also 'long').
+          */
+-#if _CALL_ELF == 2
+-safe_syscall_base:
+-        .cfi_startproc
+-        .localentry safe_syscall_base,0
+-#else
+-        .section ".opd","aw"
++
+         .align  3
+ safe_syscall_base:
+-        .quad   .L.safe_syscall_base,.TOC.@tocbase,0
+-        .previous
+-.L.safe_syscall_base:
+-        .cfi_startproc
+-#endif
++
+         /* We enter with r3 == &signal_pending
+          *               r4 == syscall number
+          *               r5 ... r10 == syscall arguments
+@@ -46,16 +36,15 @@
+          *               and returns the result in r3
+          * Shuffle everything around appropriately.
+          */
+-        std     14, 16(1) /* Preserve r14 in SP+16 */
+-        .cfi_offset 14, 16
+-        mr      14, 3   /* signal_pending */
+-        mr      0, 4    /* syscall number */
+-        mr      3, 5    /* syscall arguments */
+-        mr      4, 6
+-        mr      5, 7
+-        mr      6, 8
+-        mr      7, 9
+-        mr      8, 10
++        std     r14, 16(r1) /* Preserve r14 in SP+16 */
++        mr      r14, r3   /* signal_pending */
++        mr      r0, r4    /* syscall number */
++        mr      r3, r5    /* syscall arguments */
++        mr      r4, r6
++        mr      r5, r7
++        mr      r6, r8
++        mr      r7, r9
++        mr      r8, r10
+ 
+         /* This next sequence of code works in conjunction with the
+          * rewind_if_safe_syscall_function(). If a signal is taken
+@@ -66,29 +55,20 @@
+          */
+ safe_syscall_start:
+         /* if signal_pending is non-zero, don't do the call */
+-        lwz     12, 0(14)
+-        cmpwi   0, 12, 0
++        ld      r12, 0(r14)
++        cmpdi   cr0, r12, 0
+         bne-    2f
+         sc
+ safe_syscall_end:
+         /* code path when we did execute the syscall */
+-        ld      14, 16(1) /* restore r14 */
++        ld      r14, 16(r1) /* restore r14 */
+         bso-    1f
+         blr
+ 
+         /* code path when we didn't execute the syscall */
+-2:      ld      14, 16(1) /* restore r14 */
+-        addi    3, 0, QEMU_ERESTARTSYS
++2:      ld      r14, 16(r1) /* restore r14 */
++        addi    r3, 0, QEMU_ERESTARTSYS
+ 
+         /* code path setting errno */
+ 1:      b       safe_syscall_set_errno_tail
+         nop     /* per abi, for the linker to modify */
+-
+-        .cfi_endproc
+-
+-#if _CALL_ELF == 2
+-        .size   safe_syscall_base, .-safe_syscall_base
+-#else
+-        .size   safe_syscall_base, .-.L.safe_syscall_base
+-        .size   .L.safe_syscall_base, .-.L.safe_syscall_base
+-#endif
+```
+(Obviously, it is not made in a portable way – that was not needed at the time.)
+
+Unfortunately, while build itself worked, the binary crashed on launch. So something is not quite right, maybe with ABI compliance.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2607 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2607
new file mode 100644
index 00000000..365c734f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2607
@@ -0,0 +1,67 @@
+msys2 build failed
+Description of problem:
+
+Steps to reproduce:
+1. Install MSYS2 and QEMU build dependencies
+2. Update (pacman -Syu)
+3. Build:
+```
+./configure  --enable-sdl --enable-fdt=system --disable-docs --target-list=arm-softmmu,aarch64-softmmu --enable-avx2
+make -j16
+```
+Additional information:
+See: https://github.com/msys2/MINGW-packages/issues/22104#issuecomment-2393727818
+
+output:
+```
+FAILED: libcommon.a.p/net_tap-win32.c.obj 
+"cc" "-m64" "-Ilibcommon.a.p" "-ID:/a/_temp/msys64/mingw64/include/capstone" "-ID:/a/_temp/msys64/mingw64/include/p11-kit-1" "-ID:/a/_temp/msys64/mingw64/include/pixman-1" "-ID:/a/_temp/msys64/mingw64/include/libpng16" "-ID:/a/_temp/msys64/mingw64/include/spice-server" "-ID:/a/_temp/msys64/mingw64/include/spice-1" "-ID:/a/_temp/msys64/mingw64/include/cacard" "-ID:/a/_temp/msys64/mingw64/include/nss3" "-ID:/a/_temp/msys64/mingw64/include/nspr" "-ID:/a/_temp/msys64/mingw64/include/glib-2.0" "-ID:/a/_temp/msys64/mingw64/lib/glib-2.0/include" "-ID:/a/_temp/msys64/mingw64/include/libusb-1.0" "-ID:/a/_temp/msys64/mingw64/include/SDL2" "-ID:/a/_temp/msys64/mingw64/include/slirp" "-ID:/a/_temp/msys64/mingw64/include/ncursesw" "-ID:/a/_temp/msys64/mingw64/include/gtk-3.0" "-ID:/a/_temp/msys64/mingw64/include/pango-1.0" "-ID:/a/_temp/msys64/mingw64/include/harfbuzz" "-ID:/a/_temp/msys64/mingw64/include/cairo" "-ID:/a/_temp/msys64/mingw64/include/freetype2" "-ID:/a/_temp/msys64/mingw64/include/gdk-pixbuf-2.0" "-ID:/a/_temp/msys64/mingw64/include/webp" "-ID:/a/_temp/msys64/mingw64/include/atk-1.0" "-ID:/a/_temp/msys64/mingw64/include/fribidi" "-ID:/a/_temp/msys64/mingw64/include/rav1e" "-ID:/a/_temp/msys64/mingw64/include/svt-av1" "-fdiagnostics-color=auto" "-Wall" "-Winvalid-pch" "-Werror" "-std=gnu11" "-O2" "-g" "-fstack-protector-strong" "-Wempty-body" "-Wendif-labels" "-Wexpansion-to-defined" "-Wformat-security" "-Wformat-y2k" "-Wignored-qualifiers" "-Wimplicit-fallthrough=2" "-Winit-self" "-Wmissing-format-attribute" "-Wmissing-prototypes" "-Wnested-externs" "-Wold-style-declaration" "-Wold-style-definition" "-Wredundant-decls" "-Wshadow=local" "-Wstrict-prototypes" "-Wtype-limits" "-Wundef" "-Wvla" "-Wwrite-strings" "-Wno-missing-include-dirs" "-Wno-psabi" "-Wno-shift-negative-value" "-iquote" "." "-iquote" "D:/a/qemu/qemu" "-iquote" "D:/a/qemu/qemu/include" "-iquote" "D:/a/qemu/qemu/host/include/x86_64" "-iquote" "D:/a/qemu/qemu/host/include/generic" "-iquote" "D:/a/qemu/qemu/tcg/i386" "-msse2" "-mcx16" "-D_GNU_SOURCE" "-D_FILE_OFFSET_BITS=64" "-D_LARGEFILE_SOURCE" "-fno-strict-aliasing" "-fno-common" "-fwrapv" "-fno-pie" "-no-pie" "-ftrivial-auto-var-init=zero" "-fzero-call-used-regs=used-gpr" "-DHWY_SHARED_DEFINE" "-DAVIF_DLL" "-DEB_DLL" "-DLIBDEFLATE_DLL" "-DNCURSES_WIDECHAR" "-DNCURSES_WIDECHAR=1" "-Dmain=SDL_main" "-DSTRUCT_IOVEC_DEFINED" -MD -MQ libcommon.a.p/net_tap-win32.c.obj -MF "libcommon.a.p/net_tap-win32.c.obj.d" -o libcommon.a.p/net_tap-win32.c.obj "-c" ../net/tap-win32.c
+../net/tap-win32.c: In function 'tap_win32_open':
+../net/tap-win32.c:343:19: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 176 [-Werror=format-truncation=]
+  343 |              "%s\\%s\\Connection",
+      |                   ^~
+  344 |              NETWORK_CONNECTIONS_KEY, enum_name);
+      |                                       ~~~~~~~~~
+In function 'get_device_guid',
+    inlined from 'tap_win32_open' at ../net/tap-win32.c:616:10:
+../net/tap-win32.c:341:9: note: 'snprintf' output between 92 and 347 bytes into a destination of size 256
+  341 |         snprintf(connection_string,
+      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
+  342 |              sizeof(connection_string),
+      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~
+  343 |              "%s\\%s\\Connection",
+      |              ~~~~~~~~~~~~~~~~~~~~~
+  344 |              NETWORK_CONNECTIONS_KEY, enum_name);
+      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../net/tap-win32.c: In function 'tap_win32_open':
+../net/tap-win32.c:242:58: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 178 [-Werror=format-truncation=]
+  242 |         snprintf (unit_string, sizeof(unit_string), "%s\\%s",
+      |                                                          ^~
+  243 |                   ADAPTER_KEY, enum_name);
+      |                                ~~~~~~~~~                  
+In function 'is_tap_win32_dev',
+    inlined from 'get_device_guid' at ../net/tap-win32.c:368:21,
+    inlined from 'tap_win32_open' at ../net/tap-win32.c:616:10:
+../net/tap-win32.c:242:9: note: 'snprintf' output between 79 and 334 bytes into a destination of size 256
+  242 |         snprintf (unit_string, sizeof(unit_string), "%s\\%s",
+      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+  243 |                   ADAPTER_KEY, enum_name);
+      |                   ~~~~~~~~~~~~~~~~~~~~~~~
+../net/tap-win32.c: In function 'tap_win32_open':
+../net/tap-win32.c:620:52: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 245 [-Werror=format-truncation=]
+  620 |     snprintf (device_path, sizeof(device_path), "%s%s%s",
+      |                                                    ^~
+  621 |               USERMODEDEVICEDIR,
+  622 |               device_guid,
+      |               ~~~~~~~~~~~                           
+../net/tap-win32.c:620:5: note: 'snprintf' output between 16 and 271 bytes into a destination of size 256
+  620 |     snprintf (device_path, sizeof(device_path), "%s%s%s",
+      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+  621 |               USERMODEDEVICEDIR,
+      |               ~~~~~~~~~~~~~~~~~~
+  622 |               device_guid,
+      |               ~~~~~~~~~~~~
+  623 |               TAPSUFFIX);
+      |               ~~~~~~~~~~
+cc1.exe: all warnings being treated as errors
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2611 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2611
new file mode 100644
index 00000000..8432b3f5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2611
@@ -0,0 +1,3 @@
+[Documentation]What is a Block driver?
+Additional information:
+Using Windows 11 but can use Linux
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2613 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2613
new file mode 100644
index 00000000..11c80cab
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2613
@@ -0,0 +1 @@
+I was trying to build QEMU from source(noble) using debian commands  in ubuntu24.04 derived docker and I got this error: cc1: error: ‘-fcf-protection’ is not compatible with this target
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2614 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2614
new file mode 100644
index 00000000..ca217c73
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2614
@@ -0,0 +1 @@
+vhost user documentation for VHOST_USER_ADD_MEM_REG incorrect
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2615 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2615
new file mode 100644
index 00000000..73eba601
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2615
@@ -0,0 +1,10 @@
+tpm_emulator: the qemu process will be blocked while receiving an unexpected ctrl command's response from the swtpm
+Description of problem:
+When the swtpm sends the unexpected ctrl command's repsonse to the qemu process, the qemu will be blocked. When we use the gdb to attach the qemu process, we will find out that the qemu process is blocked in `recv_msg` function.
+Steps to reproduce:
+1.The QEMU process sends a `CMD_GET_TPMESTABLISHED` control command to the swtpm.
+2.If the swtpm is not currently active (`tpm_running` is false), it responds to the QEMU process with an err_not_running message, which has a fixed size of 4 bytes.
+(Reference: https://github.com/stefanberger/swtpm/blob/master/src/swtpm/ctrlchannel.c#L938)
+3. However, the QEMU process expects to receive a valid response (ptm_est est) of 8 bytes. Consequently, the QEMU process will be blocked in the recv_msg function if the response does not match the expected format.
+Additional information:
+After analysing the source codes in `tpm_emulator.c`, we found that qemu does not process the unexpected ctrol command response from the swtpm correctly (e.g. `CMD_GET_TPMESTABLISHED`). The qemu would be blocked in this function if it received unexpected response from the swtpm (https://gitlab.com/qemu-project/qemu/-/blob/3e9f48bcdabe57f8f90cf19f01bbbf3c86937267/backends/tpm/tpm_emulator.c#L140).
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2617 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2617
new file mode 100644
index 00000000..ee26f7b0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2617
@@ -0,0 +1,9 @@
+Go no
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2619 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2619
new file mode 100644
index 00000000..0b8c9c4d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2619
@@ -0,0 +1 @@
+INTEGER_OVERFLOW in nios2.c
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/262 b/gitlab/issues_text/target_missing/host_missing/accel_missing/262
new file mode 100644
index 00000000..83a7b049
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/262
@@ -0,0 +1 @@
+Broken scaling with gtk,gl=on on a hidpi display
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2621 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2621
new file mode 100644
index 00000000..503e6912
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2621
@@ -0,0 +1,15 @@
+virtgpu does not return error for misconfigured virgl command
+Description of problem:
+When ```virgl_renderer_submit_cmd``` reports error, cmd->error should be set. Otherwise driver cannot know if there is error.
+https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu-virgl.c?ref_type=heads#L233
+
+Probably 0x1200 (unspec) or 0x1205 (invalid param) should return as error. 
+
+
+If there is problem in cmd virgl freezes drawing window.
+Steps to reproduce:
+1. Send misformated command to virgl over vgpu device
+2.
+3.
+Additional information:
+Misformated 3d commands stops opengl's drawings. Without returning error we cannot know any error, hence we cannot reset vgpu.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2623 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2623
new file mode 100644
index 00000000..6a8d8e79
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2623
@@ -0,0 +1 @@
+Timeout waiting for ARP/RARP packets
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2624 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2624
new file mode 100644
index 00000000..2ea0c0c1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2624
@@ -0,0 +1,39 @@
+qemu-system-aarch64: tpm-emulator: TPM result for CMD_INIT: 0x9 operation failed
+Description of problem:
+I'm using QEMU (compile from the latest source code) to simulate a tpm2 device with the above command, it just returns an error message:
+```
+qemu-system-aarch64: tpm-emulator: TPM result for CMD_INIT: 0x9 operation failed
+```
+swtpm start command:
+```
+TPMSOCK=/tmp/swtpm-sock$$                                                                                                                                                  
+swtpm socket --tpm2 -t -d --tpmstate dir=$PWD/tpm --ctrl type=unixio,path=$TPMSOCK --log level=20                                                                          
+```
+swtpm version:
+```
+TPM emulator version 0.7.3, Copyright (c) 2014-2021 IBM Corp.
+```
+Also tried the latest swtpm, encountered the same error.
+
+swtpm log (0.7.3):
+```
+swtpm: Data client disconnected
+swtpm: SWTPM_NVRAM_Lock_Dir: Could not open lockfile: Permission denied
+swtpm: Error: Could not initialize libtpms.
+swtpm: Error: Could not initialize the TPM
+swtpm: Data client disconnected
+```
+
+swtpm log (0.10.0):
+```
+swtpm: SWTPM_NVRAM_StoreData: Error (fatal) opening tpm/TMP2-00.permall for write failed, Permission denied
+swtpm: SWTPM_NVRAM_Lock_Dir: Could not open lockfile: Permission denied
+swtpm: Error: Could not initialize the TPM
+swtpm: Data client disconnected
+```
+
+Any clues about this error? Best regrads.
+Steps to reproduce:
+Refer to [Description of problem](#description-of-problem)
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2628 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2628
new file mode 100644
index 00000000..f30ba793
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2628
@@ -0,0 +1,20 @@
+dpkg-deb in userspace emulation crashes in compression routine (armv7, aarch64, s390) on some machines
+Description of problem:
+chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_s390x.deb Version
+
+dpkg-deb: error: subprocess was killed by signal (Aborted), core dumped 
+
+chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version
+
+dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped 
+
+chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_armhf.deb Version
+
+dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped
+Steps to reproduce:
+1. debootstrap --arch=arm64 stable /scratch/debian-stable
+2. chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version
+Additional information:
+Working environment: Debian 12 x86_64 Linux 6.1.0-25-amd64 qemu 7.2.13 AMD E-450 APU
+
+chroot can be created on this machine, when transferred to the broken machine (including the qemu binary used for emulation) dpkg cannot extract packages and crashes
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2629 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2629
new file mode 100644
index 00000000..ed1b312c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2629
@@ -0,0 +1 @@
+dpkg-deb in userspace emulation crashes in compression routine (armv7, aarch64, s390) on some machines
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/263 b/gitlab/issues_text/target_missing/host_missing/accel_missing/263
new file mode 100644
index 00000000..cafb1917
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/263
@@ -0,0 +1 @@
+readdir() returns NULL (errno=EOVERFLOW) for 32-bit user-static qemu on 64-bit host
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2630 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2630
new file mode 100644
index 00000000..ab8f1096
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2630
@@ -0,0 +1 @@
+Issue template broken
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2633 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2633
new file mode 100644
index 00000000..72eff0d8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2633
@@ -0,0 +1,26 @@
+migration-test occassionally hangs with "Failed to peek at channel"
+Description of problem:
+Running the 'migration-test' qtest in a loop, eventually resulted in a hang.
+
+```
+# Running /x86_64/migration/multifd/tcp/plain/cancel
+# Using machine type: pc-q35-9.2
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/qtest-75145.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-75145.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.2, -name source,debug-threads=on -m 150M -serial file:/tmp/migration-test-DJLYV2/src_serial -drive if=none,id=d0,file=/tmp/migration-test-DJLYV2/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1    2>/dev/null -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/qtest-75145.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-75145.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.2, -name target,debug-threads=on -m 150M -serial file:/tmp/migration-test-DJLYV2/dest_serial -incoming defer -drive if=none,id=d0,file=/tmp/migration-test-DJLYV2/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1    2>/dev/null -accel qtest
+# Using machine type: pc-q35-9.2
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/qtest-75145.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-75145.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.2, -name target,debug-threads=on -m 150M -serial file:/tmp/migration-test-DJLYV2/dest_serial -incoming defer -drive if=none,id=d0,file=/tmp/migration-test-DJLYV2/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+qemu-system-x86_64: Failed to peek at channel
+....hang here....
+```
+Steps to reproduce:
+In host run
+
+```
+make vm-build-openbsd DEBUG=1'
+```
+when it is done and gives a shell account then run
+
+1. `cd /home/qemu/qemu-test.*/build`
+2. `export QTEST_QEMU_BINARY=./qemu-system-x86_64`
+3. `while true ; do ./tests/qtest/migration-test ; done`
+4.  ....wait some time until it shows the above hang....
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2635 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2635
new file mode 100644
index 00000000..ac875080
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2635
@@ -0,0 +1,12 @@
+A use-after-free bug in pflash_cfi01 snapshot implementation
+Description of problem:
+The flash snapshot restore does not function correctly. Basically when you use “if=pflash,format=raw,unit=0,file=OVMF_VAR.fd", it crashes when trying to restore a snapshot.
+
+The root cause is:
+
+1. In system/runstate.c, function vm_state_notify loops through vm_change_state_head list and calls the callback function for each entry.
+2. One of the callback function pointer points to function postload_update_cb in hw/block/pflash_cfi01.c.
+3. In function postload_update_cb, it calls qemu_del_vm_change_state_handler in which the entry element memory is freed.
+4. Note that, it is still running in the loop, the entry will be visited and get executed, the function pointer may point to a wide memory.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2637 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2637
new file mode 100644
index 00000000..92dfa7c7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2637
@@ -0,0 +1,53 @@
+ubuntu 22.04 virtio-vga-gl notwork
+Description of problem:
+
+Steps to reproduce:
+1.qemu-system-x86_64 \
+    -m 2048 \
+    -smp 2 \
+    -hda /home/perilla/virt/redroid.qcow2 \
+    -boot d \
+    -net nic -net user,hostfwd=tcp::1122-:22,hostfwd=tcp::19000-:9000,hostfwd=tcp::15555-:5555 \
+    -vnc :0 \
+    -device virtio-vga-gl \
+    -display sdl,gl=on \
+    -enable-kvm 
+
+the machine can't startup normally
+
+host console output:
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]\n
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]\n
+gl_version 46 - core profile enabled\n
+
+after`gl_version` line, startup prograss stopped![image]
+
+vm console output:
+it seems different every startup progress
+
+first time:
+
+![image](/uploads/4bbdb263db3faa812aeb568e7e5d2c9f/image.png){width=764 height=467}
+second time:
+
+![image](/uploads/0d7c92b8f5b2e5241b15da1681b10eda/image.png){width=780 height=415}
+
+2.
+3.
+Additional information:
+when I use -device virtio-gpu, it works fine 
+qemu-system-x86_64 \
+    -m 2048 \
+    -smp 2 \
+    -hda /home/username/virt/redroid.qcow2 \
+    -boot d \
+    -net nic -net user,hostfwd=tcp::1122-:22,hostfwd=tcp::19000-:9000,hostfwd=tcp::15555-:5555 \
+    -vnc :0 \
+    -device virtio-gpu \
+    -display sdl,gl=on \
+    -enable-kvm \
+     -device qxl
+
+host console output:\n
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]\n
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]\n
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2638 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2638
new file mode 100644
index 00000000..b865a5ec
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2638
@@ -0,0 +1,17 @@
+Incorrect SPDX license expression
+Description of problem:
+In the source code, the syntax of license expressions after the keyword SPDX-License-Identifier is not always correct.
+
+"GPL-2.0" should be "GPL-2.0-only"
+
+"GPL-2.0 WITH Linux-syscall-note" should be "GPL-2.0-only WITH Linux-syscall-note"
+
+"GPL-2.0+" should be "GPL-2.0-or-later"
+
+"GPL-2.0+ WITH Linux-syscall-note" should be "GPL-2.0-or-later WITH Linux-syscall-note"
+
+"GPL-v2-only" should be "GPL-2.0-only"
+
+"LGPL-2.1+" should be "LGPL-2.1-or-later"
+
+"MIT CC0-1.0" should be "MIT"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2639 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2639
new file mode 100644
index 00000000..5c429384
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2639
@@ -0,0 +1,22 @@
+[Regression] v9.1.1: hw/audio/hda audio output stream closes (SPICE)
+Description of problem:
+Beginning with QEMU 9.1.1, SPICE is unable to route audio from the guest to host. This affects `virt-viewer` as well as `Looking Glass`. Reverting packages to 9.1.0 restores functionality.
+
+Reported at [Arch Linux forums](https://bbs.archlinux.org/viewtopic.php?id=300475) and [Looking Glass discord](https://discord.com/channels/804108879436316733/1298405109210022038)
+
+----
+
+I've confirmed https://gitlab.com/qemu-project/qemu/-/commit/6d03242a7e47815ed56687ecd13f683d8da3f2fe caused the regression, applying reverse patch to 9.1.1 resolves the issue
+Additional information:
+Debugging output from the [Looking Glass discord](https://discord.com/channels/804108879436316733/1298405109210022038/1298669405118664767):
+```
+00:00:00.633 [I]              main.c:1735 | lg_run                         | Starting session
+[New Thread 0x7fffd12006c0 (LWP 10071)]
+[New Thread 0x7fffc7e006c0 (LWP 10072)]
+00:00:00.633 [I]              main.c:553  | main_frameThread               | Using DMA buffer support
+00:00:01.339 [I]              main.c:710  | main_frameThread               | Format: FRAME_TYPE_BGRA 2560x1400 (2560x1400) stride:2560 pitch:10240 rotation:0 hdr:0 pq:0
+
+Thread 2 "spiceThread" received signal SIGPIPE, Broken pipe.
+[Switching to Thread 0x7fffdba006c0 (LWP 10024)]
+0x00007ffff712a6ea in send () from /usr/lib/libc.so.6
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/264 b/gitlab/issues_text/target_missing/host_missing/accel_missing/264
new file mode 100644
index 00000000..1e000425
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/264
@@ -0,0 +1 @@
+qed leaked clusters
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2640 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2640
new file mode 100644
index 00000000..90e1aa3c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2640
@@ -0,0 +1 @@
+QEMU twice logging when use SDL.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2641 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2641
new file mode 100644
index 00000000..df0a2429
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2641
@@ -0,0 +1 @@
+Possible DEREF_OF_NULL in linux-user/syscall.c
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2642 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2642
new file mode 100644
index 00000000..d6d26a96
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2642
@@ -0,0 +1,5 @@
+guest-set-time not supported
+Description of problem:
+guest-set-time is not supported un Ubuntu 24.04 guests. It still works on a Ubuntu 22.04 guest and on W10 and W11 guests
+
+feedback from the Ubuntu 24.04 guest: error: internal error: unable to execute QEMU agent command 'guest-set-time': this feature or command is not currently supported
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2643 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2643
new file mode 100644
index 00000000..5f92b1b4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2643
@@ -0,0 +1,52 @@
+gtk initialization failed
+Description of problem:
+I compiled latest qemu version from sources with gtk enabled like below but still there is an issue of gtk initialization failed
+   ```
+   ./configure --enable-gtk --enable-slirp
+   ```
+Steps to reproduce:
+1. building qemu from sources or installing from packages results with gtk initialization failed message
+Additional information:
+```
+   # virt-host-validate
+  QEMU: Checking for hardware virtualization                                 : PASS
+  QEMU: Checking if device /dev/kvm exists                                   : PASS
+  QEMU: Checking if device /dev/kvm is accessible                            : PASS
+  QEMU: Checking if device /dev/vhost-net exists                             : PASS
+  QEMU: Checking if device /dev/net/tun exists                               : PASS
+  QEMU: Checking for cgroup 'cpu' controller support                         : PASS
+  QEMU: Checking for cgroup 'cpuacct' controller support                     : PASS
+  QEMU: Checking for cgroup 'cpuset' controller support                      : PASS
+  QEMU: Checking for cgroup 'memory' controller support                      : PASS
+  QEMU: Checking for cgroup 'devices' controller support                     : PASS
+  QEMU: Checking for cgroup 'blkio' controller support                       : PASS
+  QEMU: Checking for device assignment IOMMU support                         : WARN (No ACPI IVRS table found, IOMMU either disabled in BIOS or not supported by this hardware platform)
+  QEMU: Checking for secure guest support                                    : WARN (Unknown if this platform has Secure Guest support)
+   LXC: Checking for Linux >= 2.6.26                                         : PASS
+   LXC: Checking for namespace ipc                                           : PASS
+   LXC: Checking for namespace mnt                                           : PASS
+   LXC: Checking for namespace pid                                           : PASS
+   LXC: Checking for namespace uts                                           : PASS
+   LXC: Checking for namespace net                                           : PASS
+   LXC: Checking for namespace user                                          : PASS
+   LXC: Checking for cgroup 'cpu' controller support                         : PASS
+   LXC: Checking for cgroup 'cpuacct' controller support                     : PASS
+   LXC: Checking for cgroup 'cpuset' controller support                      : PASS
+   LXC: Checking for cgroup 'memory' controller support                      : PASS
+   LXC: Checking for cgroup 'devices' controller support                     : PASS
+   LXC: Checking for cgroup 'freezer' controller support                     : FAIL (Enable 'freezer' in kernel Kconfig file or mount/enable cgroup controller in your system)
+   LXC: Checking for cgroup 'blkio' controller support                       : PASS
+   LXC: Checking if device /sys/fs/fuse/connections exists                   : PASS
+   ```
+   ```
+# apt list --installed | grep gtk
+gir1.2-gtk-3.0/noble-updates,now 3.24.41-4ubuntu1.2 amd64 [installed,automatic]
+gtk-update-icon-cache/noble-updates,now 3.24.41-4ubuntu1.2 amd64 [installed,automatic]
+libavahi-ui-gtk3-0/noble,now 0.8-13ubuntu6 amd64 [installed,automatic]
+libavahi-ui-gtk3-dev/noble,now 0.8-13ubuntu6 amd64 [installed]
+libdecor-0-plugin-1-gtk/noble,now 0.2.2-1build2 amd64 [installed,automatic]
+libgtk-3-0t64/noble-updates,now 3.24.41-4ubuntu1.2 amd64 [installed,automatic]
+libgtk-3-bin/noble-updates,now 3.24.41-4ubuntu1.2 amd64 [installed,automatic]
+libgtk-3-common/noble-updates,now 3.24.41-4ubuntu1.2 all [installed,automatic]
+libgtk-3-dev/noble-updates,now 3.24.41-4ubuntu1.2 amd64 [installed,automatic]
+   ```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2644 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2644
new file mode 100644
index 00000000..fd105cf0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2644
@@ -0,0 +1,66 @@
+openbsd 7.5 crashes with QEMU since "virtio-pci: Add lookup subregion of VirtIOPCIRegion MR"
+Description of problem:
+Attempt to boot OpenBSD 7.5 in QEMU current git HEAD fdf250e5a37830615e324017cb3a503e84b3712c.
+
+It immediately aborts with
+
+```
+Thread 6 (Thread 0x7fe06d2006c0 (LWP 2797401) "CPU 0/KVM"):
+#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
+#1  0x00007fe0764476d3 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:78
+#2  0x00007fe0763eec4e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
+#3  0x00007fe0763d6902 in __GI_abort () at abort.c:79
+#4  0x00007fe0763d681e in __assert_fail_base (fmt=0x7fe076562b98 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55a00b998b4d "mrs.mr", file=file@entry=0x55a00b998b33 "../hw/virtio/virtio-pci.c", line=line@entry=620, function=function@entry=0x55a00bb596b0 <__PRETTY_FUNCTION__.13> "virtio_address_space_lookup") at assert.c:94
+#5  0x00007fe0763e6d87 in __assert_fail (assertion=assertion@entry=0x55a00b998b4d "mrs.mr", file=file@entry=0x55a00b998b33 "../hw/virtio/virtio-pci.c", line=line@entry=620, function=function@entry=0x55a00bb596b0 <__PRETTY_FUNCTION__.13> "virtio_address_space_lookup") at assert.c:103
+#6  0x000055a00b49d368 in virtio_address_space_lookup (proxy=proxy@entry=0x55a0213a59d0, off=off@entry=0x7fe06d1f3370, len=len@entry=1) at ../hw/virtio/virtio-pci.c:620
+#7  0x000055a00b4a127f in virtio_address_space_write (proxy=0x55a0213a59d0, addr=<optimized out>, buf=0x55a0213b32c8 "", len=1) at ../hw/virtio/virtio-pci.c:654
+#8  virtio_write_config (pci_dev=<optimized out>, address=<optimized out>, val=<optimized out>, len=<optimized out>) at ../hw/virtio/virtio-pci.c:790
+#9  0x000055a00b6edc30 in memory_region_write_accessor (mr=0x55a01fa1b470, addr=4194520, value=<optimized out>, size=1, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../system/memory.c:497
+#10 0x000055a00b6ed4be in access_with_adjusted_size (addr=addr@entry=4194520, value=0x7fe06d1f34c8, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55a00b6edbb0 <memory_region_write_accessor>, mr=<optimized out>, attrs=...) at ../system/memory.c:573
+#11 0x000055a00b6ed7fa in memory_region_dispatch_write (mr=mr@entry=0x55a01fa1b470, addr=addr@entry=4194520, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../system/memory.c:1560
+#12 0x000055a00b6f593f in flatview_write_continue_step (attrs=attrs@entry=..., buf=buf@entry=0x7fe07988e028 "", mr_addr=4194520, l=l@entry=0x7fe06d1f3590, mr=0x55a01fa1b470, len=1) at ../system/physmem.c:2786
+#13 0x000055a00b6f6058 in flatview_write_continue (fv=0x7fdf505079f0, addr=2956984536, attrs=..., ptr=0xb04000d8, len=1, mr_addr=<optimized out>, l=<optimized out>, mr=<optimized out>) at .--Type <RET> for more, q to quit, c to continue without paging--
+./system/physmem.c:2816
+#14 flatview_write (fv=0x7fdf505079f0, addr=addr@entry=2956984536, attrs=attrs@entry=..., buf=buf@entry=0x7fe07988e028, len=len@entry=1) at ../system/physmem.c:2847
+#15 0x000055a00b6f97a1 in address_space_write (as=0x55a00ca34600 <address_space_memory>, addr=2956984536, attrs=..., buf=0x7fe07988e028, len=1) at ../system/physmem.c:2967
+#16 address_space_rw (as=0x55a00ca34600 <address_space_memory>, addr=2956984536, attrs=attrs@entry=..., buf=buf@entry=0x7fe07988e028, len=1, is_write=<optimized out>) at ../system/physmem.c:2977
+#17 0x000055a00b75c256 in kvm_cpu_exec (cpu=cpu@entry=0x55a01f9cb690) at ../accel/kvm/kvm-all.c:3184
+#18 0x000055a00b75da25 in kvm_vcpu_thread_fn (arg=arg@entry=0x55a01f9cb690) at ../accel/kvm/kvm-accel-ops.c:50
+#19 0x000055a00b94daa8 in qemu_thread_start (args=0x55a01f9d2140) at ../util/qemu-thread-posix.c:541
+#20 0x00007fe0764456d7 in start_thread (arg=<optimized out>) at pthread_create.c:447
+#21 0x00007fe0764c9414 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100
+
+```
+
+Git bisect points to
+
+```
+commit ffa8a3e3b2e6ff017113b98d500d6a9e05b1560a (HEAD)
+Author: Gao Shiyuan <gaoshiyuan@baidu.com>
+Date:   Tue Sep 3 20:03:04 2024 +0800
+
+    virtio-pci: Add lookup subregion of VirtIOPCIRegion MR
+    
+    Now virtio_address_space_lookup only lookup common/isr/device/notify
+    MR and exclude their subregions.
+    
+    When VHOST_USER_PROTOCOL_F_HOST_NOTIFIER enable, the notify MR has
+    host-notifier subregions and we need use host-notifier MR to
+    notify the hardware accelerator directly instead of eventfd notify.
+    
+    Further more, maybe common/isr/device MR also has subregions in
+    the future, so need memory_region_find for each MR incluing
+    their subregions.
+    
+    Add lookup subregion of VirtIOPCIRegion MR instead of only lookup container MR.
+    
+    Fixes: a93c8d8 ("virtio-pci: Replace modern_as with direct access to modern_bar")
+    Co-developed-by: Zuo Boqun <zuoboqun@baidu.com>
+    Signed-off-by: Gao Shiyuan <gaoshiyuan@baidu.com>
+    Signed-off-by: Zuo Boqun <zuoboqun@baidu.com>
+    Message-Id: <20240903120304.97833-1-gaoshiyuan@baidu.com>
+    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
+    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+```
+
+cc @mstredhat
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2646 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2646
new file mode 100644
index 00000000..46c5bf72
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2646
@@ -0,0 +1,25 @@
+osx 10.6.8 guest on x86-64 macos 10.12 host can't boot on HVF, boots on tcg
+Description of problem:
+for some reason HVF acceleration does not work with mac-on-mac. Haiku beta5 (x64), win10 x64, Debian netinstall 12.7.0 - all works.
+Steps to reproduce:
+```
+1. get 10.6.8 image from archive.org
+2. bin/qemu-system-x86_64 -device isa-applesmc,osk="well_known_string" -usb -M pc-q35-2.11 -device usb-kbd -device usb-tablet -m 1536 -smp 1 -cpu Penryn,vendor=GenuineIntel,+ssse3,+sse4.1,+sse4.2 -L /opt/local/share/qemu -device ac97 -vnc :3 --no-reboot -accel hvf  -boot c  -bios usr/share/edk2-ovmf-x64/OVMF_CODE.fd -hda osx-10.6-xcode-compressed-efi.qcow2 -d unimp
+audio: Could not create a backend for voice `ac97.pi'
+audio: Could not create a backend for voice `ac97.mc'
+audio: Could not create a backend for voice `ac97.pi'
+audio: Could not create a backend for voice `ac97.mc'
+ahci: IRQ#0 level:1
+ahci: IRQ#0 level:1
+
+{many more of those}
+```
+and at this point qemu quits. 
+
+without --no-reboot it reboots
+
+tried both UEFI boot (using https://github.com/khronokernel/khronokernel.github.io/blob/master/Binaries/OpenCore/EFI-LEGACY.img.zip?raw=true , currently integrated into hdd image) and Clover-5160-X64.iso 
+
+if I remove -accel hvf and replace it with accel tcg guest boots.
+
+i tried to capture moment when it reboots on video but I can't catch anything :(
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2647 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2647
new file mode 100644
index 00000000..ccef48f1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2647
@@ -0,0 +1,47 @@
+A code error in accel/tcg/user-exec.c
+Description of problem:
+accel/tcg/user-exec.c:
+```
+static int probe_access_internal(CPUArchState *env, vaddr addr,
+                                 int fault_size, MMUAccessType access_type,
+                                 bool nonfault, uintptr_t ra)
+{
+    int acc_flag;
+    bool maperr;
+
+    switch (access_type) {
+    case MMU_DATA_STORE:
+        acc_flag = PAGE_WRITE_ORG;
+        break;
+    case MMU_DATA_LOAD:
+        acc_flag = PAGE_READ;
+        break;
+    case MMU_INST_FETCH:
+        acc_flag = PAGE_EXEC;
+        break;
+    default:
+        g_assert_not_reached();
+    }
+
+    if (guest_addr_valid_untagged(addr)) {
+        int page_flags = page_get_flags(addr);
+        if (page_flags & acc_flag) {
+            if ((acc_flag == PAGE_READ || acc_flag == PAGE_WRITE)
+                && cpu_plugin_mem_cbs_enabled(env_cpu(env))) {
+                return TLB_MMIO;
+            }
+            return 0; /* success */
+        }
+        maperr = !(page_flags & PAGE_VALID);
+    } else {
+        maperr = true;
+    }
+
+    if (nonfault) {
+        return TLB_INVALID_MASK;
+    }
+
+    cpu_loop_exit_sigsegv(env_cpu(env), addr, access_type, maperr, ra);
+}
+```
+The conditional judgment "acc_flag == PAGE_WRITE" seems to have an issue, because acc_flag can only be PAGE_WRITE_ORG, PAGE_READ or PAGE_EXEC from the previous code.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2648 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2648
new file mode 100644
index 00000000..4dfbd0b5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2648
@@ -0,0 +1,11 @@
+Possible dereference of NULL in block/qapi.c
+Description of problem:
+qdict_get can return NULL if the "data" key is not found in the obj dictionary. Then if NULL is passed to the qobject_is_empty_dump function, it will be dereferenced when calling the qobject_type function.
+
+https://github.com/qemu/qemu/blob/92ec7805190313c9e628f8fc4eb4f932c15247bd/block/qapi.c#L891-L892
+
+I think that data check for NULL should be added.
+
+Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
+
+Author A. Burke.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2649 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2649
new file mode 100644
index 00000000..d8b6ad5a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2649
@@ -0,0 +1,40 @@
+Data corruption with qcow2 images
+Steps to reproduce:
+```
+# Create an example file with old version of qemu-img and fill it with random data.
+$ qemu-img-8.2.2 create -f qcow2 file.qcow2 600000000000
+$ qemu-nbd-8.2.2 -c /dev/nbd0 file.qcow2
+$ dd if=/dev/random of=/dev/nbd0 bs=1000000 count=600000
+$ qemu-nbd-8.2.2 -d /dev/nbd0
+/dev/nbd0 disconnected
+
+# Get the correct checksum of both qcow2 file and its contents
+$ sha256sum -b file.qcow2
+ca471f6822af4fcf3c81bc5cc671493be06a837b71b43c1f747042759da587b9 *file.qcow2
+$ qemu-nbd-8.2.2 -r -c /dev/nbd0 file.qcow2
+$ sha256sum -b /dev/nbd0
+5dac11e88f891740da3b655588b2e62037962d1ba6377efce30124d6224dd0d1 */dev/nbd0
+$ qemu-nbd-8.2.2 -d /dev/nbd0
+/dev/nbd0 disconnected
+
+# Use the qcow2 file with new version.
+# We're using qemu-nbd here, but the same happens when qcow2 is attached to a guest
+# running in the new version qemu-system-86_64-9.1.1 and can be seen through guest's
+# /dev/vda.
+# Note that the checksum is different than before, and also non-deterministic
+# (running sha256sum twice produces different results even though the file is
+# read-only and hasn't changed).
+$ sha256sum -b file.qcow2
+ca471f6822af4fcf3c81bc5cc671493be06a837b71b43c1f747042759da587b9 *file.qcow2
+$ qemu-nbd-9.1.1 -r -c /dev/nbd0 file.qcow2
+$ sha256sum -b /dev/nbd0
+1793a38b9b964d3fc643629284722373e9d5dedea68e35900ace777b57688926 */dev/nbd0
+$ sha256sum -b /dev/nbd0
+98f900f9cd174493d0bfcf06e2bc86f5ee99dfa04c90d6832fa941e384b62d49 */dev/nbd0
+$ qemu-nbd-9.1.1 -d /dev/nbd0
+/dev/nbd0 disconnected
+$ sha256sum -b file.qcow2
+ca471f6822af4fcf3c81bc5cc671493be06a837b71b43c1f747042759da587b9 *file.qcow2
+```
+Additional information:
+No errors in either host or guest logs. When using a qcow2 with an actual filesystem, you may see reports of corruption from the filesystem driver.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2650 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2650
new file mode 100644
index 00000000..deb6c7c5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2650
@@ -0,0 +1,192 @@
+qemu-system-x86_64: util/hbitmap.c:614: serialization_chunk: Assertion `(last >> hb->granularity) < hb->size' failed
+Description of problem:
+If a named dirty bitmap already exists on a disk and another disk is added via hotplug after the guest has booted, it will definitely cause the hot migration to fail.
+Steps to reproduce:
+1. Create 2 images of type qcow2
+
+   ```
+   qemu-img create -f qcow2 vda.qcow2 50G
+   qemu-img create -f qcow2 vdb.qcow2 2G     # set to 2G
+   ```
+2. Start the guest using the following libvirt xml
+
+   ```
+   # virsh create i-btacsctt.xml
+   
+   <domain xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0" type="kvm">
+     <name>i-btacsctt</name>
+     <uuid>973f7352-ad1d-31ea-9a9f-237f3e9a384f</uuid>
+     <memory unit="MiB">2048</memory>
+     <vcpu current="2">2</vcpu>
+     <os>
+       <type arch="x86_64" machine="pc">hvm</type>
+     </os>
+     <features>
+       <acpi/>
+       <apic/>
+       <pae/>
+     </features>
+     <devices>
+       <emulator>/opt/qemu-5.1.0.9/usr/bin/qemu-system-x86_64</emulator>
+       <disk device="disk" type="file">
+         <driver cache="writeback" discard="ignore" io="threads" name="qemu" type="qcow2"/>
+         <source file="/tmp/echohu3/vda.qcow2"/>
+         <target dev="vda"/>
+       </disk>
+       <disk device="disk" type="file">
+         <driver cache="none" io="threads" name="qemu" type="qcow2"/>
+         <source file="/tmp/echohu3/vdb.qcow2"/>
+         <target dev="vdb"/>
+       </disk>
+     </devices>
+   </domain>
+   ```
+3. Create bitmap for vda
+
+   ```
+   # The node name of vda is "libvirt-2-format"
+   virsh qemu-monitor-command i-btacsctt --hmp "info block"
+   libvirt-2-format: /tmp/echohu3/vda.qcow2 (qcow2)
+       Attached to:      /machine/peripheral/virtio-disk0/virtio-backend
+       Cache mode:       writethrough
+   
+   libvirt-1-format: /tmp/echohu3/vdb.qcow2 (qcow2)
+       Attached to:      /machine/peripheral/virtio-disk1/virtio-backend
+       Cache mode:       writeback, direct
+   
+   # Create bitmap
+   virsh qemu-monitor-command i-btacsctt '{"execute":"block-dirty-bitmap-add","arguments":{"node":"libvirt-2-format","name":"bitmap0","persistent":true}}'
+   ```
+4. Create vdc and run hotpluggin
+
+   ```
+   qemu-img create -f qcow2 vdc.qcow2 50G
+   
+   cat disk.xml
+   <disk device="disk" type="file">
+      <driver cache="none" discard="ignore" io="threads" name="qemu" type="qcow2"/>
+      <source file="/tmp/echohu3/vdc.qcow2"/>
+      <target dev="vdc"/>
+   </disk>
+   
+   virsh attach-device i-btacsctt disk.xml 
+   ```
+5. Start live migrationg
+
+   ```
+   # scp *.qcow2 172.31.68.42:/tmp/echohu3/
+   virsh qemu-monitor-command i-btacsctt --hmp "migrate_set_capability dirty-bitmaps on"
+   virsh dumpxml --migratable i-btacsctt >/tmp/ivm-btacsctt.xml
+   virsh migrate --live --abort-on-error --xml /tmp/ivm-btacsctt.xml i-btacsctt qemu+tcp://172.31.68.42/system
+   error: internal error: qemu unexpectedly closed the monitor: qemu-system-x86_64: util/hbitmap.c:614: serialization_chunk: Assertion `(last >> hb->granularity) < hb->size' failed.
+   ```
+Additional information:
+Set breakpoints on the source side
+
+```
+gdb -p $pid -ex "break add_bitmaps_to_list" -ex "handle SIGUSR1 nostop" -ex "continue"
+(gdb) bt 
+#0  add_bitmaps_to_list (bs=bs@entry=0x55c5bbaf85d0, bs_name=0x55c5bbafc674 "libvirt-2-format", alias_map=alias_map@entry=0x0, s=<optimized out>) at migration/block-dirty-bitmap.c:502
+#1  0x000055c5ba3b2878 in init_dirty_bitmap_migration (s=0x55c5bb11a080 <dbm_state>) at migration/block-dirty-bitmap.c:660
+#2  dirty_bitmap_save_setup (f=0x55c5bc981c40, opaque=0x55c5bb11a080 <dbm_state>) at migration/block-dirty-bitmap.c:1226
+#3  0x000055c5ba3a3c4d in qemu_savevm_state_setup (f=0x55c5bc981c40) at migration/savevm.c:1176
+#4  0x000055c5ba39e16b in migration_thread (opaque=opaque@entry=0x55c5bbaa2400) at migration/migration.c:3487
+#5  0x000055c5ba530cf3 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521
+#6  0x00007f39846d9609 in start_thread (arg=<optimized out>) at pthread_create.c:477
+#7  0x00007f3983d11293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
+(gdb) p bs->node_name
+$4 = "libvirt-2-format", '\000' <repeats 15 times>
+(gdb) p bitmap->name
+$5 = 0x55c5bbaf13d0 "bitmap0"
+```
+
+Set a breakpoint on the target side after hitting the breakpoint on the source side.
+
+```
+gdb -p $pid -ex "break serialization_chunk if ((start + count - 1) >> hb->granularity) >= hb->size" -ex "break dirty_bitmap_load_header"  -ex "handle SIGUSR1 nostop" -ex "continue"
+(gdb) bt
+#0  dirty_bitmap_load_header (alias_map=0x0, s=0x557488aef0a8 <dbm_state+40>, f=0x55748bcfd8f0) at migration/block-dirty-bitmap.c:1146
+#1  dirty_bitmap_load (f=0x55748bcfd8f0, opaque=0x557488aef080 <dbm_state>, version_id=<optimized out>) at migration/block-dirty-bitmap.c:1187
+#2  0x0000557487d7759a in vmstate_load (se=0x55748adfb8b0, f=0x55748bcfd8f0) at migration/savevm.c:883
+#3  vmstate_load (f=0x55748bcfd8f0, se=0x55748adfb8b0) at migration/savevm.c:879
+#4  0x0000557487d79fdd in qemu_loadvm_section_part_end (mis=0x55748ad55be0, f=0x55748bcfd8f0) at migration/savevm.c:2365
+#5  qemu_loadvm_state_main (f=f@entry=0x55748bcfd8f0, mis=mis@entry=0x55748ad55be0) at migration/savevm.c:2518
+#6  0x0000557487d7b2ad in qemu_loadvm_state (f=0x55748bcfd8f0) at migration/savevm.c:2590
+#7  0x0000557487d7078f in process_incoming_migration_co (opaque=<optimized out>) at migration/migration.c:480
+#8  0x0000557487f15283 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:173
+#9  0x00007f5360189660 in __start_context () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91
+```
+
+in dirty_bitmap_load_header
+
+```
+s->bs = bdrv_lookup_bs(s->node_name, s->node_name, &local_err);   // node_name is "libvirt-2-format"
+s->bitmap = bdrv_find_dirty_bitmap(s->bs, s->bitmap_name);        // bitmap_name is "bitmap0"
+
+# Target side: “libvirt-2-format” is the node name of vdb.
+(gdb) p s->bs->node_name
+$10 = "libvirt-2-format", '\000' <repeats 15 times>
+(gdb) p s->bs->filename
+$11 = "/tmp/echohu3/vdb.qcow2", '\000' <repeats 4073 times>
+```
+
+We can also see from the target /var/log/libvirt/qemu/i-btacsctt.log file that “libvirt-2-format” is the node name of the vdb，while the node name of vda is libvirt-3-format.
+
+```
+-blockdev '{"driver":"file","filename":"/tmp/echohu3/vda.qcow2","aio":"threads","node-name":"libvirt-3-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-3-format","read-only":false,"discard":"ignore","cache":{"direct":false,"no-flush":false},"driver":"qcow2","file":"libvirt-3-storage","backing":null}' \
+-device virtio-blk-pci,bus=pci.0,addr=0x2,drive=libvirt-3-format,id=virtio-disk0,bootindex=1,write-cache=on \
+-blockdev '{"driver":"file","filename":"/tmp/echohu3/vdb.qcow2","aio":"threads","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-2-storage","backing":null}' \
+-device virtio-blk-pci,bus=pci.0,addr=0x3,drive=libvirt-2-format,id=virtio-disk1,write-cache=on \
+-blockdev '{"driver":"file","filename":"/tmp/echohu3/vdc.qcow2","aio":"threads","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-1-format","read-only":false,"discard":"ignore","cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \
+```
+
+From the source code, we know that HBitmap.size is from vdb size (2G), but bitmap is from vda (50G), so it triggers assert exception in serialization_chunk.
+
+```
+(gdb) bt
+#0  serialization_chunk (hb=hb@entry=0x55748ba28470, start=2147483648, count=536870912, first_el=first_el@entry=0x7f53503ffd20, el_count=el_count@entry=0x7f53503ffd18) at util/hbitmap.c:610
+#1  0x0000557487f18654 in hbitmap_deserialize_zeroes (hb=0x55748ba28470, start=start@entry=2147483648, count=count@entry=536870912, finish=finish@entry=false) at util/hbitmap.c:701
+#2  0x0000557487e7cfb0 in bdrv_dirty_bitmap_deserialize_zeroes (bitmap=<optimized out>, offset=offset@entry=2147483648, bytes=bytes@entry=536870912, finish=finish@entry=false) at block/dirty-bitmap.c:749
+#3  0x0000557487d86b51 in dirty_bitmap_load_bits (s=0x557488aef0a8 <dbm_state+40>, f=0x55748bcfd8f0) at migration/block-dirty-bitmap.c:992
+#4  dirty_bitmap_load (f=0x55748bcfd8f0, opaque=0x557488aef080 <dbm_state>, version_id=<optimized out>) at migration/block-dirty-bitmap.c:1198
+#5  0x0000557487d7759a in vmstate_load (se=0x55748adfb8b0, f=0x55748bcfd8f0) at migration/savevm.c:883
+#6  vmstate_load (f=0x55748bcfd8f0, se=0x55748adfb8b0) at migration/savevm.c:879
+#7  0x0000557487d79fdd in qemu_loadvm_section_part_end (mis=0x55748ad55be0, f=0x55748bcfd8f0) at migration/savevm.c:2365
+#8  qemu_loadvm_state_main (f=f@entry=0x55748bcfd8f0, mis=mis@entry=0x55748ad55be0) at migration/savevm.c:2518
+#9  0x0000557487d7b2ad in qemu_loadvm_state (f=0x55748bcfd8f0) at migration/savevm.c:2590
+#10 0x0000557487d7078f in process_incoming_migration_co (opaque=<optimized out>) at migration/migration.c:480
+#11 0x0000557487f15283 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:173
+#12 0x00007f5360189660 in __start_context () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91
+#13 0x00007ffffb29c410 in  ()
+#14 0x0000000000000000 in  ()
+(gdb) p *hb
+$16 = {orig_size = 2147483648, size = 32768, count = 0, granularity = 16, meta = 0x0, levels = {0x55748ad55ad0, 0x55748acd8df0, 0x55748b0866a0, 0x55748acf8c10, 0x55748b1c4180, 0x55748b154f60, 0x55748adf2370}, sizes = {1, 1, 1, 1, 1, 8,
+    512}}
+```
+
+```
+(gdb) f  4
+#4  dirty_bitmap_load (f=0x55748bcfd8f0, opaque=0x557488aef080 <dbm_state>, version_id=<optimized out>) at migration/block-dirty-bitmap.c:1198
+(gdb) p *s->bs
+$21 = {open_flags = 10274, read_only = false, encrypted = false, sg = false, probed = false, force_share = false, implicit = false, drv = 0x557488aa2ee0 <bdrv_qcow2>, opaque = 0x55748acf8c90, aio_context = 0x55748acd1080,
+  aio_notifiers = {lh_first = 0x0}, walking_aio_notifiers = false, filename = "/tmp/echohu3/vdb.qcow2", '\000' <repeats 4073 times>, backing_file = '\000' <repeats 4095 times>, auto_backing_file = '\000' <repeats 4095 times>,
+  backing_format = '\000' <repeats 15 times>, full_open_options = 0x55748b3c68e0, exact_filename = "/tmp/echohu3/vdb.qcow2", '\000' <repeats 4073 times>, backing = 0x0, file = 0x55748aa5de40, bl = {request_alignment = 1,
+    max_pdiscard = 0, pdiscard_alignment = 65536, max_pwrite_zeroes = 0, pwrite_zeroes_alignment = 65536, opt_transfer = 0, max_transfer = 0, min_mem_alignment = 512, opt_mem_alignment = 4096, max_iov = 1024}, supported_write_flags = 0,
+  supported_zero_flags = 260, supported_truncate_flags = 2, node_name = "libvirt-2-format", '\000' <repeats 15 times>, node_list = {tqe_next = 0x55748adeb060, tqe_circ = {tql_next = 0x55748adeb060, tql_prev = 0x55748ad4d0e8}},
+  bs_list = {tqe_next = 0x55748adeb060, tqe_circ = {tql_next = 0x55748adeb060, tql_prev = 0x55748ad4d0f8}}, monitor_list = {tqe_next = 0x55748adeb060, tqe_circ = {tql_next = 0x55748adeb060, tql_prev = 0x55748ad4d108}}, refcnt = 2,
+  op_blockers = {{lh_first = 0x0} <repeats 16 times>}, inherits_from = 0x0, children = {lh_first = 0x55748aa5de40}, parents = {lh_first = 0x55748bbc0380}, options = 0x55748ad4d2d0, explicit_options = 0x55748ad525a0,
+  detect_zeroes = BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF, backing_blocker = 0x0, total_sectors = 4194304, before_write_notifiers = {notifiers = {lh_first = 0x0}}, write_threshold_offset = 0, write_threshold_notifier = {notify = 0x0, node = {
+      le_next = 0x0, le_prev = 0x0}}, dirty_bitmap_mutex = {lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}},
+      __size = '\000' <repeats 39 times>, __align = 0}, initialized = true}, dirty_bitmaps = {lh_first = 0x55748b4655f0}, wr_highest_offset = {value = 0}, copy_on_read = 0, in_flight = 0, serialising_in_flight = 0, io_plugged = 0,
+  enable_write_cache = 0, quiesce_counter = 0, recursive_quiesce_counter = 0, write_gen = 0, reqs_lock = {locked = 0, ctx = 0x0, from_push = {slh_first = 0x0}, to_pop = {slh_first = 0x0}, handoff = 0, sequence = 0, holder = 0x0},
+  tracked_requests = {lh_first = 0x0}, flush_queue = {entries = {sqh_first = 0x0, sqh_last = 0x55748ad52570}}, active_flush_req = false, flushed_gen = 0, never_freeze = false}
+```
+
+When we merge into commit https://gitlab.com/qemu-project/qemu/-/commit/31e4c354b38cd42a051ad030eb7779d5e7ee32fe and then run `block-bitmap-mapping` before migration, the hot migration can be completed successfully. I would like to confirm with the community whether this solution is reasonable and if there are any other solutions to address this issue.
+
+```
+virsh qemu-monitor-command i-btacsctt '{"execute": "migrate-set-parameters", "arguments":{"block-bitmap-mapping":[{"node-name":"libvirt-2-format", "alias":"libvirt-3-format","bitmaps":[{"name":"bitmap0", "alias":"bitmap0"}]}]}}'
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2651 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2651
new file mode 100644
index 00000000..53488b35
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2651
@@ -0,0 +1,8 @@
+MPC5553/MPC5554 Emulation (information request)
+Additional information:
+If it is not planned, I'll most likely start educating myself on this project to try and patch it in as it's a need that is quite important for me.
+I'll try not to waste your time and read as much as I can about your guidelines.
+Would you advise me against trying to do this?
+I'd like to know how hard you think this will be.
+
+DISCLAIMER : I am still very much a newbie in embedded systems, I'm only in the first year of my master's degree in embedded systems.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2653 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2653
new file mode 100644
index 00000000..d1bef7bf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2653
@@ -0,0 +1 @@
+Intel iGPU sriov
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2658 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2658
new file mode 100644
index 00000000..2ebf32cf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2658
@@ -0,0 +1 @@
+How to simulate the L2MERRSR_EL1 register in KVM mode？
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2659 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2659
new file mode 100644
index 00000000..d2009004
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2659
@@ -0,0 +1 @@
+msys2-64bit test-aio intermittent CI failure with "test_timer_schedule: assertion failed: (aio_poll(ctx, true)) FAIL"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2660 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2660
new file mode 100644
index 00000000..8e12a2ac
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2660
@@ -0,0 +1 @@
+EDK2 subhook submodule missing
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2664 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2664
new file mode 100644
index 00000000..ca968e0b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2664
@@ -0,0 +1,9 @@
+Building in Windows MSYS2/Mingw64 fails
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2667 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2667
new file mode 100644
index 00000000..b50fc5a6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2667
@@ -0,0 +1,212 @@
+Heavy graphic glitches when using Virtio with 3D acceleration
+Description of problem:
+Virtio with 3D acceleration enabled under "Video" and the corresponding OpenGL activated under "Display" with Spice leads to heavy artifacts in the graphical console.
+
+This error has been observed on Arch Linux with Intel Meteor Lake CPU (Intel Arc Graphics iGPU) as well as on OpenSuse Tumbleweed with Intel Kaby Lake CPU (Intel HD 630 iGPU)
+Steps to reproduce:
+1. Enable Virtio Graphics with 3D acceleration under "Video".
+2. Activate the corresponding OpenGL under "Spice".
+3. Start the VM and open the graphical console.
+Additional information:
+![virtio_without_acceleration](/uploads/dedb6180515f1402f895cc89de72a39f/virtio_without_acceleration.png)
+(virtio without acceleration enabled)
+
+![Glitch_virtmanager_virtio](/uploads/437cd0bebe0f531701a395c966143378/Glitch_virtmanager_virtio.png)
+(Same VM, same settings, but with 3D acceleration and OpenGL enabled)
+
+![signal-2024-11-09-132624_002](/uploads/0860850ab722e995dbf7f8061a9d1fc8/signal-2024-11-09-132624_002.png)
+(Same issue on a fresh install of OpenSuse Tumbleweed on a system that is in no way linked to the first one)
+
+```
+<domain type='kvm'>
+  <name>debian12</name>
+  <uuid>1d39d86a-b341-47bb-9847-4c78da9df863</uuid>
+  <metadata>
+    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
+      <libosinfo:os id="http://debian.org/debian/12"/>
+    </libosinfo:libosinfo>
+  </metadata>
+  <memory unit='KiB'>4194304</memory>
+  <currentMemory unit='KiB'>4194304</currentMemory>
+  <vcpu placement='static'>4</vcpu>
+  <os firmware='efi'>
+    <type arch='x86_64' machine='pc-q35-9.1'>hvm</type>
+    <firmware>
+      <feature enabled='no' name='enrolled-keys'/>
+      <feature enabled='no' name='secure-boot'/>
+    </firmware>
+    <loader readonly='yes' type='pflash'>/usr/share/edk2/x64/OVMF_CODE.4m.fd</loader>
+    <nvram template='/usr/share/edk2/x64/OVMF_VARS.4m.fd'>/var/lib/libvirt/qemu/nvram/debian12_VARS.fd</nvram>
+    <boot dev='hd'/>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+    <vmport state='off'/>
+  </features>
+  <cpu mode='host-passthrough' check='none' migratable='on'/>
+  <clock offset='utc'>
+    <timer name='rtc' tickpolicy='catchup'/>
+    <timer name='pit' tickpolicy='delay'/>
+    <timer name='hpet' present='no'/>
+  </clock>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>destroy</on_crash>
+  <pm>
+    <suspend-to-mem enabled='no'/>
+    <suspend-to-disk enabled='no'/>
+  </pm>
+  <devices>
+    <emulator>/usr/bin/qemu-system-x86_64</emulator>
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2' discard='unmap'/>
+      <source file='/var/lib/libvirt/images/debian12.qcow2'/>
+      <target dev='vda' bus='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
+    </disk>
+    <disk type='file' device='cdrom'>
+      <driver name='qemu' type='raw'/>
+      <target dev='sda' bus='sata'/>
+      <readonly/>
+      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+    </disk>
+    <controller type='usb' index='0' model='qemu-xhci' ports='15'>
+      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
+    </controller>
+    <controller type='pci' index='0' model='pcie-root'/>
+    <controller type='pci' index='1' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='1' port='0x10'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
+    </controller>
+    <controller type='pci' index='2' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='2' port='0x11'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
+    </controller>
+    <controller type='pci' index='3' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='3' port='0x12'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
+    </controller>
+    <controller type='pci' index='4' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='4' port='0x13'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
+    </controller>
+    <controller type='pci' index='5' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='5' port='0x14'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
+    </controller>
+    <controller type='pci' index='6' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='6' port='0x15'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
+    </controller>
+    <controller type='pci' index='7' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='7' port='0x16'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/>
+    </controller>
+    <controller type='pci' index='8' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='8' port='0x17'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x7'/>
+    </controller>
+    <controller type='pci' index='9' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='9' port='0x18'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/>
+    </controller>
+    <controller type='pci' index='10' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='10' port='0x19'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/>
+    </controller>
+    <controller type='pci' index='11' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='11' port='0x1a'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x2'/>
+    </controller>
+    <controller type='pci' index='12' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='12' port='0x1b'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x3'/>
+    </controller>
+    <controller type='pci' index='13' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='13' port='0x1c'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x4'/>
+    </controller>
+    <controller type='pci' index='14' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='14' port='0x1d'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x5'/>
+    </controller>
+    <controller type='sata' index='0'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
+    </controller>
+    <controller type='virtio-serial' index='0'>
+      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
+    </controller>
+    <interface type='network'>
+      <mac address='52:54:00:d6:22:67'/>
+      <source network='default'/>
+      <model type='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
+    </interface>
+    <serial type='pty'>
+      <target type='isa-serial' port='0'>
+        <model name='isa-serial'/>
+      </target>
+    </serial>
+    <console type='pty'>
+      <target type='serial' port='0'/>
+    </console>
+    <channel type='unix'>
+      <target type='virtio' name='org.qemu.guest_agent.0'/>
+      <address type='virtio-serial' controller='0' bus='0' port='1'/>
+    </channel>
+    <channel type='spicevmc'>
+      <target type='virtio' name='com.redhat.spice.0'/>
+      <address type='virtio-serial' controller='0' bus='0' port='2'/>
+    </channel>
+    <input type='tablet' bus='usb'>
+      <address type='usb' bus='0' port='1'/>
+    </input>
+    <input type='mouse' bus='ps2'/>
+    <input type='keyboard' bus='ps2'/>
+    <graphics type='spice'>
+      <listen type='none'/>
+      <image compression='off'/>
+      <gl enable='yes'/>
+    </graphics>
+    <sound model='ich9'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
+    </sound>
+    <audio id='1' type='spice'/>
+    <video>
+      <model type='virtio' heads='1' primary='yes'>
+        <acceleration accel3d='yes'/>
+      </model>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
+    </video>
+    <redirdev bus='usb' type='spicevmc'>
+      <address type='usb' bus='0' port='2'/>
+    </redirdev>
+    <redirdev bus='usb' type='spicevmc'>
+      <address type='usb' bus='0' port='3'/>
+    </redirdev>
+    <watchdog model='itco' action='reset'/>
+    <memballoon model='virtio'>
+      <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
+    </memballoon>
+    <rng model='virtio'>
+      <backend model='random'>/dev/urandom</backend>
+      <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
+    </rng>
+  </devices>
+</domain>
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2668 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2668
new file mode 100644
index 00000000..38d26c27
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2668
@@ -0,0 +1,3 @@
+h.264 encoding/compression support
+Additional information:
+noVNC now support h.264 decoding.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2670 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2670
new file mode 100644
index 00000000..6d7dcc5b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2670
@@ -0,0 +1,44 @@
+The virglrenderer depency causes qemu native recipe building to fail for NXP QEMU
+Description of problem:
+nativesdk-qemu-8.2.2.imx-r0 do_compile: oe_runmake failed
+...
+ [87/4472] Compiling C object libcommon.fa.p/hw_display_virtio-gpu.c.o
+| FAILED: libcommon.fa.p/hw_display_virtio-gpu.c.o
+...
+ ../hw/display/virtio-gpu.c:36:10: fatal error: virglrenderer.h: No such file or directory
+|    36 | #include <virglrenderer.h>
+|       |          ^~~~~~~~~~~~~~~~~
+| compilation terminated.
+
+This issue was originally exposed after updating Yocto release to Scarthgap
+
+https://lists.yoctoproject.org/g/yocto/topic/building_sdk_fails_after/109275322
+
+which seems to relate to commit https://github.com/nxp-imx/imx-qemu/commit/628105edbd816458dbf154a128cc3dd3ac809c7e that seemingly induces dependency to virglrenderer.h for virtio_gpu driver.
+
+Enabling opengl in our Distribution features is not a solution because that pulls in VGA graphics dependencies to our target binaries and we have no graphics hardware on our system. I have tried to disable the virglrenderer through QEMU build configuration but that does not fix the issue.
+Steps to reproduce:
+1. Clone NXP BSP Scarthgap
+```
+$ mkdir nxp-bsp
+$ cd nxp-bsp
+nxp-bsp$ repo init -u https://github.com/nxp-imx/imx-manifest -b scarthgap -m imx-6.6.36-2.1.0.xml
+nxp-bsp$ repo sync
+```
+
+2. Remove opengl from `fsl-imx-xwayland` DISTRO_FEATURES
+
+```
+sources/meta-imx/meta-imx-sdk/conf/distro/fsl-imx-wayland.conf:
+...
++DISTRO_FEATURES:remove = "opengl "
+...
+```
+
+3. Build qemu-native_8.2.2.imx
+
+```
+$ bitbake qemu-native_8.2.2.imx
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2671 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2671
new file mode 100644
index 00000000..4016d3e0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2671
@@ -0,0 +1,17 @@
+[Virtio-GPU Venus] I compiled virglrenderer with Venus support on 1.1.0,but could not boot QEMU with virtio-gpu Venus
+Description of problem:
+When I tried to use virtio-gpu-gl with venus=true like the template,it shows:
+![图片](/uploads/6481812acb0d2ada333f4b47b110cbb8/图片.png){width=1251 height=75}
+But I have already compile virglrenderer using:
+  meson setup build \
+  -Dvenus=true \
+  -Drender-server=true \
+  -Drender-server-worker=thread \
+  -Dbuildtype=release \
+  -Dprefix=${INSTDIR}
+
+and run QEMU with designated environment variables,but it still cannot boot,but if I use QEMU-8.0 with Venus-v17 patch and it works😭
+Steps to reproduce:
+Just use "-device virtio-gpu-gl,hostmem=4G,blob=true,venus=true" and it will show the problem
+Additional information:
+No
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2676 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2676
new file mode 100644
index 00000000..0155be97
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2676
@@ -0,0 +1,7 @@
+GTK+ UI has serious problems on macOS hosts
+Description of problem:
+The GTK+ UI simply does not work on macOS at this stage. One major reason is that there does not appear to be any regular polling of the (macOS) UI event loop. The Cocoa back-end for GTK [sets a custom event polling function in GLib's event handler](https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/macos/gdkmacoseventsource.c?ref_type=heads#L1089) but Qemu never actually calls GLib/GTK's event polling.
+
+Thanks to @bonzini for discovering this as part of a [discussion on a patch generalising runloop event handling on macOS](https://patchew.org/QEMU/20241113142343.40832-1-phil@philjordan.eu/20241113142343.40832-2-phil@philjordan.eu/#CABgObfat1JwiBFNKHK6wwMkW5kgaqZfKJa=rW._5F9VvEdMWJR75A@mail.gmail.com).
+
+There is also a reasonable chance that QEMU might not reliably call GTK+ functions from the main thread (thread 0), which causes problems when GTK then calls through to the native Cocoa APIs which must be called from thread 0.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2677 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2677
new file mode 100644
index 00000000..a322bc31
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2677
@@ -0,0 +1 @@
+edit doc on building
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2678 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2678
new file mode 100644
index 00000000..93de13b0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2678
@@ -0,0 +1,9 @@
+virsh blockcommit failed, however the snapshot was merged into base successfully.
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2679 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2679
new file mode 100644
index 00000000..f2af3103
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2679
@@ -0,0 +1 @@
+TCX emulation missing 1152x900 mode
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2680 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2680
new file mode 100644
index 00000000..d221febc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2680
@@ -0,0 +1,14 @@
+GTK accelerators (including releasing input grab) don't work in keyboard layouts that utilize AltGr on Windows
+Description of problem:
+With a non-QWERTY (in my case, Colemak) layout active, it's not possible to ungrab input from the window using the Ctrl-Alt-G. The key combination is simply ignored, whether the G is typed using the physical key G on the keyboard or the one where it would be mapped by the keyboard layout (physical T key for Colemak). Thankfully, because of #2225, the mouse cursor isn't actually captured, which allows me to move the mouse outside the window and close QEMU from the taskbar instead.
+
+Temporarily switching back to a QWERTY layout before the grab happens allows input to be released using the key combo. However this needs to be done before the capture as otherwise QEMU will simply intercept any shortcuts to toggle the layout.
+
+I suspect there's some mismatch between the input grabbing code and the GTK UI, where one is using the keyboard scancode to determine when to forward the key, but the GTK UI then uses the mapped letter from the layout and fails to activate the shortcut.
+Steps to reproduce:
+1. Configure a non-QWERTY layout (such as Dvorak or Colemak) in the system settings
+1. Launch QEMU (it's not necessary to load any guest, booting the BIOS is fine)
+2. Click on the window which will automatically capture input
+3. Try to release using the Ctrl-Shift-G shortcut (in either layout), which should be ignored
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2681 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2681
new file mode 100644
index 00000000..d4288569
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2681
@@ -0,0 +1 @@
+QEMU build system should halt, if glib version is lower than needed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2682 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2682
new file mode 100644
index 00000000..d7c4037f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2682
@@ -0,0 +1,41 @@
+QEMU throws errors at the beginning of building
+Description of problem:
+QEMU throws errors at the beginning of building:
+```
+ninja: no work to do.
+/tmp/qemu-8.1.5/build/pyvenv/bin/meson introspect --targets --tests --benchmarks | /tmp/qemu-8.1.5/build/pyvenv/bin/python3 -B scripts/mtest2make.py > Makefile.mtest
+pc-bios/optionrom: -fcf-protection=none detected
+pc-bios/optionrom: -fno-pie detected
+pc-bios/optionrom: -no-pie detected
+pc-bios/optionrom: -fno-stack-protector detected
+pc-bios/optionrom: -Wno-array-bounds detected
+pc-bios/optionrom: Assembling multiboot.o
+pc-bios/optionrom: Assembling linuxboot.o
+pc-bios/optionrom: Assembling multiboot_dma.o
+pc-bios/optionrom: Compiling linuxboot_dma.o
+pc-bios/optionrom: Assembling pvh.o
+pc-bios/optionrom: Assembling kvmvapic.o
+pc-bios/optionrom: Compiling pvh_main.o
+pc-bios/optionrom: Linking multiboot.img
+pc-bios/optionrom: Linking linuxboot.img
+pc-bios/optionrom: Linking kvmvapic.img
+pc-bios/optionrom: Extracting raw object multiboot.raw
+/bin/sh: 1: -O: not found
+make[1]: *** [Makefile:53: multiboot.raw] Error 127
+make[1]: *** Waiting for unfinished jobs....
+pc-bios/optionrom: Linking multiboot_dma.img
+pc-bios/optionrom: Extracting raw object linuxboot.raw
+/bin/sh: 1: -O: not found
+make[1]: *** [Makefile:53: linuxboot.raw] Error 127
+make: *** [Makefile:190: pc-bios/optionrom/all] Error 2
+make: *** Waiting for unfinished jobs....
+[1/10003] Generating trace/trace-hw_i2c.h with a custom command
+
+...
+```
+Then proceeds the building. Whether it is failing at the end is not reliabily reproducible as it do fail one time and builds successfully at the next time. However, i don't know if these errors will cause runtime problems in the case of a successful build.
+Steps to reproduce:
+1. `../configure --enable-strip --audio-drv-list=alsa --enable-tools --enable-modules`
+2. `make -j16`
+Additional information:
+Configuration log is available here: http://oscomp.hu/depot/qemu-8.1.5-configure.log
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2684 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2684
new file mode 100644
index 00000000..6b147dd8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2684
@@ -0,0 +1 @@
+scripts/archive-source.sh is not documented
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2686 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2686
new file mode 100644
index 00000000..b5e3e27c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2686
@@ -0,0 +1,48 @@
+rng-seed addition causing test_loongarch64_virt.py to hang in EFI startup
+Description of problem:
+Since the rng-seed addition, the test_loongarch64_virt.py test will periodically hang.
+
+git bisect blames this
+
+```
+commit d9bd1ccbf1d84d872aed684c65fec33814b8ac1b
+Author: Jason A. Donenfeld <Jason@zx2c4.com>
+Date:   Thu Sep 5 17:33:16 2024 +0200
+
+    hw/loongarch: virt: pass random seed to fdt
+    
+    If the FDT contains /chosen/rng-seed, then the Linux RNG will use it to
+    initialize early. Set this using the usual guest random number
+    generation function.
+    
+    This is the same procedure that's done in b91b6b5a2c ("hw/microblaze:
+    pass random seed to fdt"), e4b4f0b71c ("hw/riscv: virt: pass random seed
+    to fdt"), c6fe3e6b4c ("hw/openrisc: virt: pass random seed to fdt"),
+    67f7e426e5 ("hw/i386: pass RNG seed via setup_data entry"), c287941a4d
+    ("hw/rx: pass random seed to fdt"), 5e19cc68fb ("hw/mips: boston: pass
+    random seed to fdt"), 6b23a67916 ("hw/nios2: virt: pass random seed to fdt")
+    c4b075318e ("hw/ppc: pass random seed to fdt"), and 5242876f37
+    ("hw/arm/virt: dt: add rng-seed property").
+    
+    These earlier commits later were amended to rerandomize the RNG seed on
+    snapshot load, but the LoongArch code somehow already does that, despite
+    not having this patch here, presumably due to some lucky copy and
+    pasting.
+    
+    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
+    Reviewed-by: Song Gao <gaosong@loongson.cn>
+    Message-Id: <20240905153316.2038769-1-Jason@zx2c4.com>
+    Signed-off-by: Song Gao <gaosong@loongson.cn>
+```
+
+When it hangs, test_loongarch64_virt.py will get stuck waiting for serial console output from the guest.
+
+Looking at the console.log file shows it to be completely empty. 
+
+This appears to indicate it has hung before EDK has even initialized, as it has not even printed the 'Entering C environment' message
+Steps to reproduce:
+1. ./configure --target-list=loongarch64-softmmu
+2. make -j 20
+3. n=0 ; while true ; do n=$(expr $n + 1); echo $n ; QEMU_TEST_QEMU_BINARY=./build/qemu-system-loongarch64  PYTHONPATH=./python ./tests/functional/test_loongarch64_virt.py  ; done
+
+Most commonly it will hang within 10 iterations, very occasionally needing upto 25
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2687 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2687
new file mode 100644
index 00000000..cffe5d98
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2687
@@ -0,0 +1,49 @@
+regression in qtest clock_set/clock_step
+Description of problem:
+As of QEMU 9.0 the script included below would increment the time via qtest, but it is now broken and time doesn't seem to be updated. I do note that the QEMU sources use clock_step extensively via qtest_clock_step, but nothing seems to be using the return value so maybe that's why it hasn't been noticed?
+ 
+It seems to have been broken in bc02be4508d8753d1f6071b77d10f4661587df6f which was trying to prevent some deadlock. You can prove that this breaks it by setting a breakpoint in `qemu_virtual_clock_set_ns` -- it never gets called.
+Steps to reproduce:
+Run this python script from your QEMU build directory:
+
+```python
+#!/usr/bin/env python3
+
+import subprocess
+import socket
+import typing
+
+qemu_path = "./qemu-system-x86_64"
+
+
+def main():
+    s1, s2 = socket.socketpair()
+
+    qemu = subprocess.Popen(
+        [
+            qemu_path,
+            "-S",
+            "-display",
+            "none",
+            "-chardev", f"socket,id=qtest,fd={s1.fileno()},nodelay=on",
+            "-qtest", "chardev:qtest",
+            "-qtest-log", "/dev/fd/2",
+            "-accel", "qtest",
+        ],
+        pass_fds=[s1.fileno()],
+    )
+
+    try:
+
+        fp = s2.makefile("rw", buffering=1)
+
+        fp.write(f"clock_set 1234\n")
+        result = fp.readline()[:-1].split(" ")
+        assert result == ["OK", "1234"], f"Unexpected result: {result}"
+    finally:
+        qemu.kill()
+
+
+if __name__ == "__main__":
+    main()
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2688 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2688
new file mode 100644
index 00000000..82196e3f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2688
@@ -0,0 +1 @@
+Add `disable_host_loopback` for network user backend
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2690 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2690
new file mode 100644
index 00000000..baf3b465
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2690
@@ -0,0 +1,20 @@
+"Guest says index 40947 is available"
+Description of problem:
+As discussed [here](https://github.com/danobi/vmtest/issues/96) I have been running several instances of QEMU in parallel at `SCHED_IDLE`, and I've been getting QGA setup failures.
+Steps to reproduce:
+1. Install [vmtest](https://github.com/danobi/vmtest)
+2. Run lots of copies of the command in the [github issues](https://github.com/danobi/vmtest/issues/96) via `chrt --idle 0`.
+3. Unclear if this is the cause, but then I use the computer in the meantime so probably starve the `SCHED_IDLE` QEMU threads running from 2.
+
+This leads to failures to connect to the guest agent and then at the end I see this:
+
+```
+Guest says index 40947 is available
+    qemu-system-x86_64: Guest says index 40947 is available
+    qemu-system-x86_64: Guest says index 40947 is available
+```
+
+
+The developer of vmtest seemed to think this may be of interest to QEMU developers based on the tone of the [comment they found](https://github.com/danobi/vmtest/issues/96#issuecomment-2483860554) in the QEMU code.
+
+I've now installed QEMU from Git master so I can report back whether the bug still appeared.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2693 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2693
new file mode 100644
index 00000000..f564d4ed
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2693
@@ -0,0 +1,6 @@
+hv-balloon Migration
+Description of problem:
+since QEMU version 8.2, the hv-balloon feature has been officially merged, but migration is still not supported.
+Are there any planned enhancements to the hv-balloon migration in the near future?
+Steps to reproduce:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2694 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2694
new file mode 100644
index 00000000..7d6c2a1e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2694
@@ -0,0 +1,24 @@
+error: implicit declaration of function 'IOMainPort' is invalid in C99
+Description of problem:
+Build in MacOS
+    Hardware Overview:
+
+      Model Name: MacBook Air
+      Chip: Apple M1
+      Total Number of Cores: 8 (4 performance and 4 efficiency)
+      Memory: 16 GB
+Steps to reproduce:
+1. ./configure --cpu=aarch64 --target-list=aarch64-softmmu --enable-slirp
+2. make -j
+Additional information:
+```
+FAILED: libblock.a.p/block_file-posix.c.o
+cc -Ilibblock.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -Iblock -I/opt/homebrew/opt/zstd/include -I/opt/homebrew/Cellar/glib/2.82.2/include/glib-2.0 -I/opt/homebrew/Cellar/glib/2.82.2/lib/glib-2.0/include -I/opt/homebrew/opt/gettext/include -I/opt/homebrew/Cellar/pcre2/10.44/include -I/opt/homebrew/Cellar/glib/2.82.2/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -fstack-protector-strong -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wformat-security -Wformat-y2k -Wignored-qualifiers -Winit-self -Wmissing-format-attribute -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wredundant-decls -Wstrict-prototypes -Wtype-limits -Wundef -Wvla -Wwrite-strings -Wno-gnu-variable-sized-type-not-at-end -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-psabi -Wno-shift-negative-value -Wno-string-plus-int -Wno-tautological-type-limit-compare -Wno-typedef-redefinition -iquote . -iquote /Users/august/qemu/src -iquote /Users/august/qemu/src/include -iquote /Users/august/qemu/src/host/include/aarch64 -iquote /Users/august/qemu/src/host/include/generic -iquote /Users/august/qemu/src/tcg/aarch64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -fno-pie -MD -MQ libblock.a.p/block_file-posix.c.o -MF libblock.a.p/block_file-posix.c.o.d -o libblock.a.p/block_file-posix.c.o -c ../block/file-posix.c
+../block/file-posix.c:3940:18: error: implicit declaration of function 'IOMainPort' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
+    kernResult = IOMainPort(MACH_PORT_NULL, &mainPort);
+                 ^
+1 error generated.
+ninja: build stopped: subcommand failed.
+make[1]: *** [run-ninja] Error 1
+make: *** [build] Error 2
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2695 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2695
new file mode 100644
index 00000000..5fb21c01
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2695
@@ -0,0 +1,3 @@
+how to onboard fw_cfg to other machines
+Additional information:
+Would it be doable for other machines actually? I didn't dig deeper into this device to understand, but I guess it is connected to the VM somehow and it has some memory mapped to the OS?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2697 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2697
new file mode 100644
index 00000000..3e70f439
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2697
@@ -0,0 +1 @@
+system/physmem: gdb memory rw no access on armv7m MPU
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/270 b/gitlab/issues_text/target_missing/host_missing/accel_missing/270
new file mode 100644
index 00000000..82d6aedc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/270
@@ -0,0 +1 @@
+virtio only support packed ring size power of 2
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2700 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2700
new file mode 100644
index 00000000..ae5f2f5b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2700
@@ -0,0 +1,8 @@
+Windows 11 24H2 (x64) fails to boot
+Description of problem:
+When trying to boot Windows 11 24H2 (including the installer), the guest will just restart.
+Steps to reproduce:
+1. Download Windows 11 ISO from: https://www.microsoft.com/en-us/software-download/windows11
+2. Run the command above
+Additional information:
+I tested it on an M4 Pro Mac running TCG. Other users have reported the same issue with M3 running TCG and Intel i9 running HVF.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2701 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2701
new file mode 100644
index 00000000..20d8c3e4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2701
@@ -0,0 +1 @@
+VGPU migration under VFIO. nvidia-vgpu-mgr: Error saving page in pipelined mode on 550.90.05 driver (Debian12,libvirt 10.5.0 qemu 9.1.1)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2703 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2703
new file mode 100644
index 00000000..e3e129c5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2703
@@ -0,0 +1,40 @@
+ptimer period sporadically too long
+Description of problem:
+A ptimer in a custom device with a frequency of 10kHz is sporadically called after more than 100,000ns in virtual time have elapsed.
+
+With a icount shift of 4 or 5 this happens almost everytime before the linux guest can even finish booting.
+
+With a shift of 0 this happens very rarely, but it does occur from time to time.
+Steps to reproduce:
+1. setup a ptimer with a frequency of 10kHz and assert that the time passed between callbacks is exactly 100,000ns
+2. run
+3. wait for boom
+Additional information:
+```
+// Timer setup
+ptimer_transaction_begin(state->timer);
+
+ptimer_set_freq(state->timer, 10000);
+ptimer_run(state->timer, 0);
+   
+ptimer_transaction_commit(state->timer);
+```
+```
+// timer callback
+int64_t now  = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
+static int64_t last = 0;
+if (last > 0)
+{
+   if (now - last != 100000)
+   {
+       fprintf(stderr, "error tick %ld after %ld is incorrect: %ld\n", now, last, now - last);
+       assert(0);
+   }
+}
+last = now;
+```
+
+```
+error tick 47867503135 after 47867400000 is incorrect: 103135
+qemu-system-x86_64: ../...file.c:119: timer_callback: Assertion `0' failed.
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2705 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2705
new file mode 100644
index 00000000..2d2b7cb7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2705
@@ -0,0 +1,17 @@
+USB event delivery does not work correctly for macOS guests with XHCI controller without MSI(-X)
+Steps to reproduce:
+1. Get a macOS VM working. Either on x86-64 with a Q35 machine type, AppleSMC device, and OpenCore bootloader, or on aarch64 using the patch set and instructions linked above.
+2. On x86-64, switch to a NEC XHCI controller with MSI and MSI-X support forcibly disabled: `-device nec-usb-xhci,id=xhci,msi=off,msix=off`
+3. Boot macOS.
+
+USB events are now extremely laggy. A USB keyboard or mouse becomes almost unusable.
+
+
+While narrowing down the problem, I established the following facts by experimentation, tracing, and code inspection:
+
+ * Although the vmapple platform uses an emulated XHCI PCI device for connecting virtual USB devices, it does not support message-signalled interrupts, in either the MSI or MSI-X persuasion. (This is true in Apple's implementation as well, but the macOS guest's XHCI driver unsurprisingly does work with Apple's PCI/XHCI implementation.)
+ * macOS guests (and the iBoot bootloader) appear to refuse to drive XHCI controllers with `numintrs < 4`, for both aarch64 and x86-64 architectures. They will generally set up event rings 0, 1, and 2.
+ * QEMU's PCI XHCI implementation does not appear to implement (as of 9.2.0-rc2) any mitigations for when the controller is used in pin-based IRQ mode. It will happily attempt to use event rings >0 in this case, but interrupts are dropped.
+ * Linux and FreeBSD guests appear to use only interrupter 0 anyway, so these are not useful references.
+
+It's not entirely clear to me what component is ultimately responsible for the failure here - I suspect there might be some not-quite-right behaviour in both macOS's XHCI driver and Qemu's XHCI implementation, and that these conspire to a non-functional setup.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2706 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2706
new file mode 100644
index 00000000..230fd499
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2706
@@ -0,0 +1 @@
+MigrationCapability "dirty-bitmaps off"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2707 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2707
new file mode 100644
index 00000000..7a5f25ae
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2707
@@ -0,0 +1,10 @@
+virtio-balloon crashes in a object assert when querying stats
+Description of problem:
+Fetch virtio-balloon stats will crash a QEMU crash with assert failures
+Steps to reproduce:
+1. ./qemu-system-x86_64 -device virtio-balloon,id=balloon -qmp qmp.sock
+2. Connect to qmp.sock
+3. Issue  'qom-get path=/machine/peripheral/balloon property=guest-stats'
+4. QEMU go boom!
+Additional information:
+This is a regression caused by commit 0d2eeef77a33315187df8519491a900bde4a3d83, which failed to update `balloon_stat_names` with the new stats names, causing code to try to add a QDict entry with a NULL key.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2709 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2709
new file mode 100644
index 00000000..841ff0e5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2709
@@ -0,0 +1 @@
+Contributing to docs is very confusing
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2714 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2714
new file mode 100644
index 00000000..7c04645c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2714
@@ -0,0 +1,7 @@
+Potential memory leak in virtio-crytpto
+Description of problem:
+There is a potential memory leak while using virtio-crypto with vhost-user backend.
+
+The problem is due to misuse of error_setg in [backends/cryptodev-vhost-user.c#L284](https://gitlab.com/qemu-project/qemu/-/blob/master/backends/cryptodev-vhost-user.c#L284). After invoking error_setg(&local_error, ...), current procedure should not return without freeing err object pointed by local_error.
+
+The same problem occured in cryptodev-builtin, which has been discussed in #2283 and fixed in f6abce29cc4afa0445cb3b29a265a114ac9fa744. The same fixes should be applied to cryptodev-vhost-user.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2716 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2716
new file mode 100644
index 00000000..54f28314
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2716
@@ -0,0 +1,7 @@
+migrate incoming with fd transfer issue
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2717 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2717
new file mode 100644
index 00000000..980caff0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2717
@@ -0,0 +1,12 @@
+semihosting link to risc-v details in document is changed
+Description of problem:
+
+Steps to reproduce:
+1. Open https://gitlab.com/qemu-project/qemu/-/blob/master/docs/about/emulation.rst
+2. Goto Supported Targets section
+3. Click RISC-V link in the table
+4. Got 404
+
+New url looks like https://github.com/riscv-non-isa/riscv-semihosting/blob/main/riscv-semihosting.adoc
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2719 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2719
new file mode 100644
index 00000000..55be575f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2719
@@ -0,0 +1 @@
+9.2.0 tarball contains unrelated files
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/272 b/gitlab/issues_text/target_missing/host_missing/accel_missing/272
new file mode 100644
index 00000000..d8051bc9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/272
@@ -0,0 +1 @@
+QEMU: block/vvfat driver issues
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2720 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2720
new file mode 100644
index 00000000..9438fedb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2720
@@ -0,0 +1,70 @@
+migration failure from qemu 7.1.0 to qemu 9.2.0+ with multifd capability enabled
+Description of problem:
+Enabling multifd when doing migration from qemu 7.1.0 to 9.2.0+ causes the migration to fail.
+The migration status reported is:
+
+```
+Migration status: failed (Unable to write to socket: Broken pipe)
+```
+
+I could reproduce on qemu 9.2.0 and from a build from master. The migration is successful if I don't enable multifd.
+
+I could not reproduce this issue migrating from 7.1.0 to 9.1.2.
+Steps to reproduce:
+Minimal setup to reproduce below, running both qemu instances on the same host.
+
+1. Start qemu instance receiving the migration:
+
+```
+$ qemu-system-x86_64 -version
+QEMU emulator version 9.2.50 (v9.2.0-28-ga5ba0a7e4e)
+
+$ qemu-system-x86_64 -M pc-q35-7.1 -m 16G -nographic -incoming defer -net none -trace 'migration*'
+[...]
+(qemu) migrate_set_capability multifd on
+(qemu) migrate_set_parameter multifd-channels 4
+(qemu) migrate_incoming tcp:0:12345
+[...]
+(qemu) migration_socket_incoming_accepted
+migration_set_incoming_channel ioc=0x5619735b1800 ioctype=qio-channel-socket
+migration_socket_incoming_accepted
+migration_set_incoming_channel ioc=0x561972dff670 ioctype=qio-channel-socket
+migration_socket_incoming_accepted
+migration_set_incoming_channel ioc=0x561972dad800 ioctype=qio-channel-socket
+migration_socket_incoming_accepted
+migration_set_incoming_channel ioc=0x561972c9d670 ioctype=qio-channel-socket
+migration_socket_incoming_accepted
+migration_set_incoming_channel ioc=0x561972c7b270 ioctype=qio-channel-socket
+
+```
+
+2. Start the qemu instance that will be used to initiate the migration with multifd enabled, and initiate the migration
+
+```
+$ qemu-system-x86_64 -version
+QEMU emulator version 7.1.0 (v7.1.0)
+
+$ qemu-system-x86_64 -M pc-q35-7.1 -m 16G -nographic -net none -trace 'migration*'
+[...]
+(qemu) migrate_set_capability multifd on
+(qemu) migrate_set_parameter multifd-channels 4
+(qemu) migrate -d tcp:0:12345
+(qemu) migration_socket_outgoing_connected hostname=0
+migration_set_outgoing_channel ioc=0x558ea2051400 ioctype=qio-channel-socket hostname=0 err=(nil)
+migration_bitmap_sync_start
+migration_bitmap_sync_end dirty_pages 0
+migration_thread_setup_complete
+migration_bitmap_clear_dirty rb pc.ram start 0x0 size 0x40000000 page 0x0
+migration_thread_after_loop
+qemu-system-x86_64: Unable to write to socket: Broken pipe
+(qemu) info migrate
+globals:
+store-global-state: on
+only-migratable: off
+send-configuration: on
+send-section-footer: on
+decompress-error-check: on
+clear-bitmap-shift: 18
+Migration status: failed (Unable to write to socket: Broken pipe)
+total time: 0 ms
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2722 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2722
new file mode 100644
index 00000000..5cd09cff
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2722
@@ -0,0 +1,48 @@
+TLB Invalidation time out on i915 SR-IOV passthrough
+Description of problem:
+Hello,
+
+I tried to use SR-IOV on i915 driver freshly available on the [LTS intel kernel](https://github.com/intel/linux-intel-lts) with this [kernel version ](https://github.com/intel/linux-intel-lts/tree/lts-v6.6.34-linux-240626T131354Z) for pci passthrough purpose.
+After setting up SR-IOV (kernel compilation, kernel cmdline, vfio-pci driver attribution to the new pci..)
+ I've got my two new pci.
+
+```
+00:02.0 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c)
+DeviceName: Onboard IGD
+
+Subsystem: Hewlett-Packard Company Alder Lake-P Integrated Graphics Controller
+Kernel driver in use: i915
+
+00:02.1 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c)
+Subsystem: Hewlett-Packard Company Alder Lake-P Integrated Graphics Controller
+Kernel driver in use: vfio-pci
+
+00:02.2 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c)
+Subsystem: Hewlett-Packard Company Alder Lake-P Integrated Graphics Controller
+Kernel driver in use: vfio-pci
+```
+I gave one of those pci to my VM with this qemu cmdline:
+```
+-cpu host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-passthrough,hv-vendor-id=IrisXE
+...
+-device vfio-pci-nohotplug,host=0000:00:02.1,id=hostdev0,bus=pci.4,addr=0x0
+```
+Sometimes it working properly when I start the qemu cmdline but most of the time I've got those kernel errors and a GPU hang:
+```
+    kernel [ 2252.208134] i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679
+    kernel [ 2252.208134] i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679
+    kernel i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679
+    kernel i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679
+    ....
+    kernel Fence expiration time out i915-0000:00:02.0:renderThread22381:6e0!
+    kernel i915 0000:00:02.0: [drm] GT0: GuC firmware i915/adlp_guc_70.bin version 70.13.1
+    kernel i915 0000:00:02.0: [drm] GT0: HuC firmware i915/tgl_huc.bin version 7.9.3
+    kernel i915 0000:00:02.0: [drm] GT0: HuC: authenticated for all workloads
+    kernel i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
+    kernel i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
+    kernel [ 2730.991019] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:85dfbfff, in renderThread [22381]
+    kernel [ 2730.991084] i915 0000:00:02.0: [drm] renderThread22381 context reset due to GPU hang
+```
+It mostly appears when Qemu is starting..
+
+Any help would be appreciate, thanks a lot
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2724 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2724
new file mode 100644
index 00000000..459be653
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2724
@@ -0,0 +1,8 @@
+Invalid DRM modifier in ScanoutDMABUF call
+Description of problem:
+`modifier` parameter in `ScanoutDMABUF` callback is always `0xffffffffffffff` (`DRM_FORMAT_RESERVED`)
+Steps to reproduce:
+1. Run QEMU with D-Bus display
+2. Connect D-Bus display client and print modifier
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2726 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2726
new file mode 100644
index 00000000..ab29ea84
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2726
@@ -0,0 +1 @@
+please make qemu-img capable of using with pipes
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2727 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2727
new file mode 100644
index 00000000..031d10de
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2727
@@ -0,0 +1 @@
+`Debian testing` (2024-12-16) - `qemu-system-x86_64 9.2.0` : bug with the `virtio-net` and a DHCP connection with a virtual bridge.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2728 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2728
new file mode 100644
index 00000000..3fbee177
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2728
@@ -0,0 +1,15 @@
+QEMU/Virt-Manager + QXL 4k Resolution + Win 10 and Win 11 Guest freeze
+Description of problem:
+I use two 4k displays in my VM with 150% display scaling. After a random amount of time the screen locks up. It can lock up before i can log in or it can wait a few minutes into using it before it stops responding. It still pings but is unresponsive via the display. I've tried several different builds of the guest drivers but that did not work, the only solution has been to revert to QEMU v9.0.2-1.
+Steps to reproduce:
+1.Create new x86 VM using QXl video, Install Windows 10 or Windows 11 and latest guest drivers from spice and fedora
+2.Open with virt viewer and resize both screens to 3840 x 2160 or use autosize 
+3.Set display scaling to 150%
+4.Lockup occurs at some point after that but not more than 5 minutes.
+Additional information:
+There seems to be a similar bug here:https://gitlab.com/qemu-project/qemu/-/issues/1628#note_214460662
+also a debian forum post here: https://forums.debian.net/viewtopic.php?t=160631
+QEMU v9.0.2-1 does not have this problem, eliminating the guest drivers as a culprit
+
+
+/label ~"kind::Bug"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/273 b/gitlab/issues_text/target_missing/host_missing/accel_missing/273
new file mode 100644
index 00000000..5549ef89
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/273
@@ -0,0 +1 @@
+xhci_find_stream: Assertion `streamid != 0' failed.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2732 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2732
new file mode 100644
index 00000000..b640373b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2732
@@ -0,0 +1,39 @@
+Segmentation fault with PCI GPU
+Description of problem:
+Upon attempting to launch the virtual machine, Qemu crashes with Segfault. The issue only occurs it's launched with a passthrough GPU with the vfio driver. It is an Nvidia RTX 3060 GPU. The VM boots fine without the GPU PCI device added.
+Steps to reproduce:
+1. Create a VM with the GPU PCI device added
+2. Attempt to boot it
+3. virt-manager will display: "libvirt.libvirtError: internal error: QEMU unexpectedly closed the monitor"
+Additional information:
+GDB backtrace:
+```                                                                                                                                                                                            
+Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
+Downloading 116.51 K source file /usr/src/debug/qemu/build/../qemu-9.1.2/system/memory.c
+memory_region_update_container_subregions () at ../qemu-9.1.2/system/memory.c:2616                                                                                                            
+2616	    QTAILQ_FOREACH(other, &mr->subregions, subregions_link) {
+(gdb) bt
+#0  memory_region_update_container_subregions () at ../qemu-9.1.2/system/memory.c:2616
+#1  memory_region_add_subregion_common () at ../qemu-9.1.2/system/memory.c:2640
+#2  0x0000555555ade66a in memory_region_add_subregion_overlap () at ../qemu-9.1.2/system/memory.c:2657
+#3  vfio_probe_nvidia_bar0_quirk () at ../qemu-9.1.2/hw/vfio/pci-quirks.c:966
+#4  vfio_bar_quirk_setup () at ../qemu-9.1.2/hw/vfio/pci-quirks.c:1259
+#5  0x0000555555ae8212 in vfio_realize () at ../qemu-9.1.2/hw/vfio/pci.c:3133
+#6  0x000055555586c3ab in pci_qdev_realize () at ../qemu-9.1.2/hw/pci/pci.c:2097
+#7  0x0000555555b924f3 in device_set_realized () at ../qemu-9.1.2/hw/core/qdev.c:510
+#8  0x0000555555b9c37f in property_set_bool () at ../qemu-9.1.2/qom/object.c:2354
+#9  0x0000555555b9a21a in object_property_set () at ../qemu-9.1.2/qom/object.c:1463
+#10 0x0000555555b9abbf in object_property_set_qobject () at ../qemu-9.1.2/qom/qom-qobject.c:28
+#11 object_property_set_bool () at ../qemu-9.1.2/qom/object.c:1533
+#12 0x000055555594dafb in qdev_device_add_from_qdict () at ../qemu-9.1.2/system/qdev-monitor.c:719
+#13 0x00005555559586f1 in qemu_create_cli_devices () at ../qemu-9.1.2/system/vl.c:2664
+#14 qmp_x_exit_preconfig () at ../qemu-9.1.2/system/vl.c:2721
+#15 0x0000555555962396 in qemu_init () at ../qemu-9.1.2/system/vl.c:3766
+#16 0x00005555556d2abd in main () at ../qemu-9.1.2/system/main.c:47
+```
+
+dmesg:
+```
+[ 4846.200960] qemu-system-x86[26518]: segfault at b8 ip 00006149e75a64e6 sp 00007fff4c85fbe0 error 4 in qemu-system-x86_64[5c24e6,6149e7155000+72c000] likely on CPU 4 (core 4, socket 0)
+[ 4846.200968] Code: 2e 01 83 c0 01 89 05 0d cd 2e 01 48 8b 43 40 48 85 c0 74 16 ba 01 00 00 00 f0 0f c1 50 18 81 fa fe ff ff 7f 0f 87 c4 00 00 00 <49> 8b 84 24 b8 00 00 00 48 85 c0 74 55 8b 93 b0 00 00 00 eb 11 0f
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2735 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2735
new file mode 100644
index 00000000..b6095780
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2735
@@ -0,0 +1,10 @@
+Couldn't find rom image 'canon-a1100-rom1.bin'.
+Description of problem:
+```
+$ qemu-system-aarch64 -machine canon-a1100
+qemu-system-aarch64: Couldn't find rom image 'canon-a1100-rom1.bin'.
+```
+Steps to reproduce:
+```
+qemu-system-aarch64 -machine canon-a1100
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2737 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2737
new file mode 100644
index 00000000..f3659b49
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2737
@@ -0,0 +1 @@
+Plans for Adding RISC-V Vector (RVV) Backend Support?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/274 b/gitlab/issues_text/target_missing/host_missing/accel_missing/274
new file mode 100644
index 00000000..639aeeb5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/274
@@ -0,0 +1 @@
+FIXME xhci_alloc_device_streams:972 guest streams config not identical for all eps
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2740 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2740
new file mode 100644
index 00000000..409e61fd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2740
@@ -0,0 +1,67 @@
+Out-of-bounds access and heap-use-after-free in smc91c111_writeb()
+Description of problem:
+An out-of-bounds access bug was triggered by my fuzzer.
+
+The error is:
+
+```
+../hw/net/smc91c111.c:457:17: runtime error: index 48 out of bounds for type 'uint8_t[4][2048]' (aka 'unsigned char[4][2048]')
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/net/smc91c111.c:457:17 in
+=================================================================
+==60006==ERROR: AddressSanitizer: heap-use-after-free on address 0x6290000385b4 at pc 0x5de3d1ac6add bp 0x7ffc4d4b2b30 sp 0x7ffc4d4b2b28
+WRITE of size 1 at 0x6290000385b4 thread T0
+warning: DWARF unit at offset 0x00417a37 has unsupported address size: 31 (supported are 2, 4, 8)
+    #0 0x5de3d1ac6adc in smc91c111_writeb smc91c111.c
+    #1 0x5de3d1abf6e3 in smc91c111_writefn smc91c111.c
+    #2 0x5de3d2d9e2d3 in memory_region_write_accessor memory.c
+    #3 0x5de3d2d9da4a in access_with_adjusted_size memory.c
+    #4 0x5de3d2d9ce78 in memory_region_dispatch_write
+    #5 0x5de3d2df5e44 in flatview_write_continue_step physmem.c
+    #6 0x5de3d2de2d40 in flatview_write physmem.c
+    #7 0x5de3d2de29d7 in address_space_write
+    ...
+
+0x6290000385b4 is located 5044 bytes inside of 16176-byte region [0x629000037200,0x62900003b130)
+freed by thread T0 here:
+    #0 0x5de3d1100027 in __interceptor_free.part.0 asan_malloc_linux.cpp
+    #1 0x5de3d2f35106 in object_unref
+    #2 0x5de3d24ac45c in qemu_get_nic_models
+    #3 0x5de3d24acead in qemu_create_nic_bus_devices
+    #4 0x5de3d2722553 in realview_init realview.c
+    #5 0x5de3d1468182 in machine_run_board_init
+    #6 0x5de3d237e40a in qmp_x_exit_preconfig
+    #7 0x5de3d238505c in qemu_init
+    ...
+
+previously allocated by thread T0 here:
+    #0 0x5de3d1101217 in malloc
+    #1 0x7ea39d40a738 in g_malloc
+    #2 0x5de3d24acead in qemu_create_nic_bus_devices
+    #3 0x5de3d2722553 in realview_init realview.c
+    #4 0x5de3d1468182 in machine_run_board_init
+    #5 0x5de3d237e40a in qmp_x_exit_preconfig
+    #6 0x5de3d238505c in qemu_init
+    ...
+```
+Steps to reproduce:
+```
+export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine realview-eb"
+cat << EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio
+clock_step
+readw 0x4e000000
+readw 0x4e000000
+clock_step
+writel 0x4e00000c 0x2402e660
+readb 0x4e000008
+readl 0x4e000000
+clock_step
+readb 0x4e000000
+writel 0x4e000000 0x66308c81
+writew 0x4e000008 0xe40ba4c
+readb 0x4e000000
+readw 0x4e000000
+readl 0x4e000008
+EOF
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2742 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2742
new file mode 100644
index 00000000..8faf42a0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2742
@@ -0,0 +1,66 @@
+heap-buffer-overflow in smc91c111_do_tx()
+Description of problem:
+A buffer-overflow bug was triggered by my fuzzer at smc91c111_do_tx().
+
+I've patched hw/net/smc91c111.c with:
+
+```
+diff --git a/hw/net/smc91c111.c b/hw/net/smc91c111.c
+index 702d0e8e83..286298bf06 100644
+--- a/hw/net/smc91c111.c
++++ b/hw/net/smc91c111.c
+@@ -429,7 +429,7 @@ static void smc91c111_writeb(void *opaque, hwaddr offset,
+              /* Ignore.  */
+              return;
+          case 2: /* Packet Number Register */
+-            s->packet_num = value;
++            s->packet_num = value & (NUM_PACKETS - 1);
+              return;
+          case 3: case 4: case 5:
+              /* Should be readonly, but linux writes to them anyway. Ignore.  */
+```
+
+The error is:
+
+```
+==2724739==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x629000022941 at pc 0x595ebbed687b bp 0x7fffa0098a50 sp 0x7fffa0098a48
+READ of size 1 at 0x629000022941 thread T0
+    #0 0x595ebbed687a in smc91c111_do_tx hw/net/smc91c111.c:240:19
+    #1 0x595ebbed687a in smc91c111_queue_tx hw/net/smc91c111.c:284:5
+    #2 0x595ebbed687a in smc91c111_writeb hw/net/smc91c111.c:419:17
+    #3 0x595ebbed687a in smc91c111_writefn hw/net/smc91c111.c:666:9
+    #4 0x595ebd174d33 in memory_region_write_accessor system/memory.c:497:5
+    #5 0x595ebd1744aa in access_with_adjusted_size system/memory.c:573:18
+    #6 0x595ebd1738d8 in memory_region_dispatch_write system/memory.c
+    #7 0x595ebd1cc984 in flatview_write_continue_step system/physmem.c:2786:18
+    #8 0x595ebd1b9880 in flatview_write_continue system/physmem.c:2816:19
+    #9 0x595ebd1b9880 in flatview_write system/physmem.c:2847:12
+    #10 0x595ebd1b9517 in address_space_write system/physmem.c:2967:18
+    #11 0x595ebc77d5c3 in qtest_process_command system/qtest.c:522:13
+    #12 0x595ebc77b83b in qtest_process_inbuf system/qtest.c:776:9
+    ...
+```
+Steps to reproduce:
+```
+export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine realview-eb"
+cat << EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio
+clock_step
+clock_step
+writel 0x4e000000 0x2b1e08f5
+writew 0x4e000000 0x2b1e08f5
+writel 0x4e00000c 0x66027d24
+clock_step
+readb 0x4e000000
+writel 0x4e000008 0x238e1f29
+writew 0x4e000000 0x41d9fe3b
+writel 0x4e00000c 0x27022a2d
+clock_step
+readw 0x4e000004
+clock_step
+readb 0x4e000008
+clock_step
+writew 0x4e000000 0x620c5fdf
+EOF
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2743 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2743
new file mode 100644
index 00000000..05dfcfad
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2743
@@ -0,0 +1,3 @@
+The command Qemu-img did not work, cannot convert raw file to vhd file
+Description of problem:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2744 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2744
new file mode 100644
index 00000000..fef28deb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2744
@@ -0,0 +1,5 @@
+Avoid defining custom machine-definition macros for each new machine type
+Additional information:
+There are already some semi-generic implementations of this macro, such as [`DEFINE_PC_VER_MACHINE()`](https://gitlab.com/qemu-project/qemu/-/blob/aa3a285b5bc56a4208b3b57d4a55291e9c260107/include/hw/i386/pc.h#L326), which is used for the 'q35', 'pc' and 'isapc' machine types. 
+
+There does appear to be some deviation from the template macro in some cases. We would have to enumerate what the nature of these deviations is, why only some machine types need them, and how they would fit into the proposed generic macro. Still, if we could have a generic macro that simplifies 80% of machine types' version definitions, then that seems like a win.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2745 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2745
new file mode 100644
index 00000000..f8d500b5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2745
@@ -0,0 +1,26 @@
+Qemu should send RARP for vhostuser regardless of whether virtio supports GUEST_ANNOUNCE
+Description of problem:
+When virtio reports to qemu that GUEST_ANNOUNCE is supported, qemu will not send RARP. The assumption, I think, is that guest kernel will do whatever is needed to announce the guest. The problem with this assumption is that 1) kernel won't send RARPs; 2) for IPv4 and IPv6 it will send GARPs and NAs; 3) for interfaces with no IP addresses, I think it won't send anything at all.
+
+RARPs are useful because they allow to notify regardless of IP configuration. I've [asked](https://issues.redhat.com/browse/RHEL-71919]) RHEL kernel folks to consider issuing RARPs from the guest kernel, but it won't happen overnight, and regardless, it's not a complete solution since we cannot expect all guests running a patched kernel with such feature.
+
+RARP packets are also often expected by underlying network components. For example, OVN controller has a special "activation-strategy=rarp" configuration that makes OVN wait for a RARP from destination chassis on live migration, and only then unblock traffic for the port. Since RARP is not issed by Qemu nor virtio-net, the OVN port is never unblocked (until its configuration is reset by CMS).
+
+I think what should be done from Qemu side is to send RARP for vhostuser ports regardless of whether virtio supports GUEST_ANNOUNCE. I **think** this can be achieved by removing this code:
+
+```
+    /* If guest supports GUEST_ANNOUNCE do nothing */
+    if (virtio_has_feature(dev->acked_features, VIRTIO_NET_F_GUEST_ANNOUNCE)) {
+        return 0;
+    }
+```
+Steps to reproduce:
+1. Start a VM with vhostuser* port and fresh virtio guest driver.
+2. Live migrate it.
+3. Observe that RARP is not sent from the migrated port. GARP (or NA for IPv6) is sent instead.
+Additional information:
+Some external bugs that may be relevant:
+
+- RHEL kernel request to send RARPs from virtio: https://issues.redhat.com/browse/RHEL-71919 (won't fix the issue for older unpatched kernels)
+- Request for OVN to handle GARPs and NAs: https://issues.redhat.com/browse/FDP-1042 (won't solve for unaddressed ports!)
+- An attempt to work around the issue in OpenStack Neutron OVN env by disabling activation strategy: https://issues.redhat.com/browse/OSPRH-12571 (not a great long term solution)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2746 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2746
new file mode 100644
index 00000000..a4d55d47
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2746
@@ -0,0 +1 @@
+NO_CAST.INTEGER_OVERFLOW in /hw/net/e1000.c
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2747 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2747
new file mode 100644
index 00000000..344924bb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2747
@@ -0,0 +1,9 @@
+External snapshots are created world-readable when connecting via qemu+ssh://root
+Description of problem:
+External snapshots are created with world-readable permissions when connecting via `qemu+ssh://root`.
+Steps to reproduce:
+1. Create a VM over `qemu+ssh://root@$SERVER/system`
+2. Create an external snapshot via virt-manager or with `virsh snapshot-create-as  --domain testvm --name test --disk-only --diskspec vda,file=/var/lib/libvirt/images/test.qcow2  --atomic`
+3. `ls -l /var/lib/libvirt/images/test.qcow2`
+Additional information:
+Issue doesn't seem to go away by adding `umask 077` in `$HOME/.profile`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2749 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2749
new file mode 100644
index 00000000..008bbeb4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2749
@@ -0,0 +1,79 @@
+TSAN/RaceHunter data race on bh->flags in aio_compute_bh_timeout
+Description of problem:
+Switching the TSAN build for `test-aio-multithread` unit test reveals the data race on `bh->flags` in `aio_compute_bh_timeout`.
+
+The same data race can be found in the list of warnings in #851 and #1496.
+
+I investigated the data race and I can reproduce the same race with our tool RaceHunter on the test `tests/unit/test-thread-pool.c` where two accesses may happen simultaneously. It is not false alarm, because RaceHunter introduces the delay and catches both accesses exactly at the same time, not just predicting the race due to missing happens-before as TSAN does.
+
+```
+WARNING: SMC RaceHunter: Data race found:
+  read access from thread 0 [handle=0]  at pc=0x55b851f660b9, addr=7b1000000168 (4 bytes)
+    #0 aio_compute_bh_timeout util/async.c:259:18
+    #1 aio_compute_timeout util/async.c:282:15
+    #2 aio_poll util/aio-posix.c:628:26 (test-thread-pool+0xa4223f)
+    #3 test_submit_aio tests/unit/test-thread-pool.c:70:9
+    #4 main tests/unit/test-thread-pool.c
+
+  Previous atomic write access from thread 4 [handle=4]  at pc=0x55b851f65e24, addr=7b1000000168 (4 bytes)
+    #0 aio_bh_enqueue util/async.c:81:17
+    #1 qemu_bh_schedule util/async.c:235:5
+    #2 worker_thread util/thread-pool.c:118:9
+    #3 qemu_thread_start util/qemu-thread-posix.c:543:9
+```
+
+Both are accesses to `flags` in `BHList` (`bh->flags`)
+The write access in `aio_bh_enqueue` is protected by atomic operation `qatomic_fetch_or` while second read access is not atomic and not protected by locks.
+
+The read access in `aio_compute_bh_timeout` seems to rely on RCU mechanism `QSLIST_FOREACH_RCU(bh, head, next)`, but in this case the writer should also use RCU protected assign.
+Steps to reproduce:
+1. configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp
+2. make check-unit test-aio-multithread
+3. See the warning in the log
+```
+WARNING: ThreadSanitizer: data race (pid=3514443)
+  Atomic write of size 4 at 0x7b1000000168 by thread T17:
+    #0 aio_bh_enqueue /home/mordan/qemu/build/../util/async.c:81:17 (test-thread-pool+0xa5e933)
+    #1 qemu_bh_schedule /home/mordan/qemu/build/../util/async.c:235:5 (test-thread-pool+0xa5e933)
+    #2 worker_thread /home/mordan/qemu/build/../util/thread-pool.c:118:9 (test-thread-pool+0xa66153)
+    #3 qemu_thread_start /home/mordan/qemu/build/../util/qemu-thread-posix.c:543:9 (test-thread-pool+0xa496c0)
+
+  Previous read of size 4 at 0x7b1000000168 by main thread:
+    #0 aio_compute_bh_timeout /home/mordan/qemu/build/../util/async.c:259:18 (test-thread-pool+0xa5ebc8)
+    #1 aio_compute_timeout /home/mordan/qemu/build/../util/async.c:282:15 (test-thread-pool+0xa5ebc8)
+    #2 aio_poll /home/mordan/qemu/build/../util/aio-posix.c:628:26 (test-thread-pool+0xa42d4f)
+    #3 do_test_cancel /home/mordan/qemu/build/../tests/unit/test-thread-pool.c:199:9 (test-thread-pool+0x50f0e8)
+    #4 test_cancel_async /home/mordan/qemu/build/../tests/unit/test-thread-pool.c:230:5 (test-thread-pool+0x50ec01)
+    #5 <null> <null> (libglib-2.0.so.0+0x7daed) (BuildId: e845b8fd2f396872c036976626389ffc4f50c9c5)
+    #6 __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 (libc.so.6+0x29d8f) (BuildId: 490fef8403240c91833978d494d39e537409b92e)
+
+  As if synchronized via sleep:
+    #0 nanosleep out/lib/clangrt-x86_64-unknown-linux-gnu/./out/lib/clangrt-x86_64-unknown-linux-gnu/./toolchain/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:365:3 (test-thread-pool+0x34507d)
+    #1 g_usleep <null> (libglib-2.0.so.0+0x7ff76) (BuildId: e845b8fd2f396872c036976626389ffc4f50c9c5)
+    #2 worker_thread /home/mordan/qemu/build/../util/thread-pool.c:111:15 (test-thread-pool+0xa66115)
+    #3 qemu_thread_start /home/mordan/qemu/build/../util/qemu-thread-posix.c:543:9 (test-thread-pool+0xa496c0)
+
+  Location is heap block of size 56 at 0x7b1000000140 allocated by main thread:
+    #0 malloc out/lib/clangrt-x86_64-unknown-linux-gnu/./out/lib/clangrt-x86_64-unknown-linux-gnu/./toolchain/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:667:5 (test-thread-pool+0x346151)
+    #1 g_malloc <null> (libglib-2.0.so.0+0x5e738) (BuildId: e845b8fd2f396872c036976626389ffc4f50c9c5)
+    #2 thread_pool_init_one /home/mordan/qemu/build/../util/thread-pool.c:333:27 (test-thread-pool+0xa655c8)
+    #3 thread_pool_new /home/mordan/qemu/build/../util/thread-pool.c:348:5 (test-thread-pool+0xa655c8)
+    #4 aio_get_thread_pool /home/mordan/qemu/build/../util/async.c:441:28 (test-thread-pool+0xa5ed54)
+    #5 thread_pool_submit_aio /home/mordan/qemu/build/../util/thread-pool.c:246:24 (test-thread-pool+0xa64f0d)
+    #6 thread_pool_submit /home/mordan/qemu/build/../util/thread-pool.c:295:5 (test-thread-pool+0xa65362)
+    #7 test_submit /home/mordan/qemu/build/../tests/unit/test-thread-pool.c:49:5 (test-thread-pool+0x50e53f)
+    #8 <null> <null> (libglib-2.0.so.0+0x7daed) (BuildId: e845b8fd2f396872c036976626389ffc4f50c9c5)
+    #9 __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 (libc.so.6+0x29d8f) (BuildId: 490fef8403240c91833978d494d39e537409b92e)
+
+  Thread T17 'worker' (tid=3514461, running) created by thread T16 at:
+    #0 pthread_create out/lib/clangrt-x86_64-unknown-linux-gnu/./out/lib/clangrt-x86_64-unknown-linux-gnu/./toolchain/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:1022:3 (test-thread-pool+0x34793d)
+    #1 qemu_thread_create /home/mordan/qemu/build/../util/qemu-thread-posix.c:583:11 (test-thread-pool+0xa49550)
+    #2 do_spawn_thread /home/mordan/qemu/build/../util/thread-pool.c:146:5 (test-thread-pool+0xa65f5e)
+    #3 worker_thread /home/mordan/qemu/build/../util/thread-pool.c:83:5 (test-thread-pool+0xa65f5e)
+    #4 qemu_thread_start /home/mordan/qemu/build/../util/qemu-thread-posix.c:543:9 (test-thread-pool+0xa496c0)
+
+SUMMARY: ThreadSanitizer: data race /home/mordan/qemu/build/../util/async.c:81:17 in aio_bh_enqueue
+```
+
+
+@hreitz, @kmwolf, @bonzini Are there any other synchronization that was intended to ensure that the accesses do not happen simultaneously?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/275 b/gitlab/issues_text/target_missing/host_missing/accel_missing/275
new file mode 100644
index 00000000..147469e3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/275
@@ -0,0 +1 @@
+Error in user-mode calculation of ELF aux vector's AT_PHDR
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2750 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2750
new file mode 100644
index 00000000..2733ce92
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2750
@@ -0,0 +1,11 @@
+Data race in the goflag global variable in the rcutorture test.
+Description of problem:
+A data race involving the `goflag` global variable in `tests/unit/rcutorture.c` was identified using TSAN.
+Steps to reproduce:
+```sh
+QEMU_BUILD_DIR=<path to the QEMU build directory>
+QEMU_DIR=<path to the QEMU repository directory>
+configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp
+make tests/unit/rcutorture
+MALLOC_PERTURB_=194 G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_SRCDIR=$QEMU_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/rcutorture --tap -k
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2751 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2751
new file mode 100644
index 00000000..7cd7e681
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2751
@@ -0,0 +1 @@
+QEMU user emulation gdbstub emits incorrect file descriptor and errno values
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2752 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2752
new file mode 100644
index 00000000..056b6884
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2752
@@ -0,0 +1,277 @@
+Heap use after free in virtio-crypto with vhost-user backend
+Description of problem:
+An heap-use-after-free happens in virtio-crypto device with vhost-user backend created by a dpdk example program.
+Steps to reproduce:
+1.Build dpdk vhost-user crypto backend. Following instructions here: [DPDK installation](https://doc.dpdk.org/guides/prog_guide/build-sdk-meson.html)
+```
+wget https://fast.dpdk.org/rel/dpdk-24.11.tar.xz
+meson setup -Dexamples=all build
+cd build
+ninja
+meson install
+cd examples
+sudo ./dpdk-vhost_crypto --vdev  'crypto_aesni_mb0' -- --config \(7,0,0\) --socket-file=7,/tmp/my-crypto.sock
+```
+After setting up the backend, should see something like:
+```
+EAL: Detected CPU lcores: 48
+EAL: Detected NUMA nodes: 2
+EAL: Detected static linkage of DPDK
+EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
+EAL: Selected IOVA mode 'PA'
+EAL: VFIO support initialized
+CRYPTODEV: Creating cryptodev crypto_aesni_mb0
+CRYPTODEV: Initialisation parameters - name: crypto_aesni_mb0,socket id: 0, max queue pairs: 8
+IPSEC_MB: ipsec_mb_create() line 168: IPSec Multi-buffer library version used: 2.0.0
+USER1: Processing on Core 7 started
+VHOST_CONFIG: (/tmp/my-crypto.sock) logging feature is disabled in async copy mode
+VHOST_CONFIG: (/tmp/my-crypto.sock) vhost-user server: socket created, fd: 213
+VHOST_CONFIG: (/tmp/my-crypto.sock) binding succeeded
+```
+
+2.Build qemu with ASAN (i.e., --enable-asan) and vhost support (i.e., --enable-vhost-user --enable-vhost-crypto)
+
+3.Ensure that /dev/hugemaps and /tmp/my-crypto.sock can be accessed. You may need to change their permissions by chmod, or run qemu-system as root.
+
+4.Run the command below to reproduce UAF. Here, Setting ASAN_OPTIONS=max_malloc_fill_size=0 avoids capturing another unintialized read in vhost_user_backend_init, which happens ealier than the UAF. 
+
+I can reproduce it 7 times in 10 runs, seems to be racing.
+```
+cat << EOF | ASAN_OPTIONS=max_malloc_fill_size=0 \
+./qemu-system-x86_64 --enable-kvm -m 512M \
+-object \
+memory-backend-file,id=mem,size=512M,mem-path=/dev/hugepages,share=on \
+-numa node,memdev=mem -smp cpus=4 -machine q35 -chardev \
+socket,id=chardev0,path=/tmp/my-crypto.sock -object \
+cryptodev-vhost-user,id=cryptodev0,chardev=chardev0 -device \
+virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -display none -qtest \
+stdio
+outl 0xcf8 0x80001800
+inw 0xcfc
+outl 0xcf8 0x80001814
+outl 0xcfc 0xffffffff
+outl 0xcf8 0x80001814
+inl 0xcfc
+outl 0xcf8 0x80001814
+outl 0xcfc 0xe0000000
+outl 0xcf8 0x80001820
+outl 0xcfc 0xffffffff
+outl 0xcf8 0x80001820
+inl 0xcfc
+outl 0xcf8 0x80001820
+outl 0xcfc 0xe0004000
+outl 0xcf8 0x80001804
+inw 0xcfc
+outl 0xcf8 0x80001804
+outw 0xcfc 0x7
+outl 0xcf8 0x80001804
+inw 0xcfc
+writeq 0xe0004023 0x5f5f5f5f5f5f0d00
+writeq 0xe0004015 0x10b2d007a210fff
+writeq 0xe0004011 0xb2616007a006425
+writeq 0xe0004011 0x5a5546a2d40b6425
+EOF
+```
+Additional information:
+Here is the information reported by ASAN: 
+```
+==2277232==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+[I 0.000000] OPENED
+qemu-system-x86_64: warning: vhost-user backend supports VHOST_USER_PROTOCOL_F_CONFIG but QEMU does not.
+[R +0.119439] outl 0xcf8 0x80001800
+[S +0.119564] OK
+OK
+[R +0.119607] inw 0xcfc
+[S +0.119667] OK 0x1af4
+OK 0x1af4
+[R +0.119721] outl 0xcf8 0x80001814
+[S +0.119770] OK
+OK
+[R +0.119817] outl 0xcfc 0xffffffff
+[S +0.119889] OK
+OK
+[R +0.119929] outl 0xcf8 0x80001814
+[S +0.119977] OK
+OK
+[R +0.120037] inl 0xcfc
+[S +0.120090] OK 0xfffff000
+OK 0xfffff000
+[R +0.120140] outl 0xcf8 0x80001814
+[S +0.120165] OK
+OK
+[R +0.120193] outl 0xcfc 0xe0000000
+[S +0.120242] OK
+OK
+[R +0.120303] outl 0xcf8 0x80001820
+[S +0.120324] OK
+OK
+[R +0.120343] outl 0xcfc 0xffffffff
+[S +0.120390] OK
+OK
+[R +0.120431] outl 0xcf8 0x80001820
+[S +0.120487] OK
+OK
+[R +0.120541] inl 0xcfc
+[S +0.120578] OK 0xffffc00c
+OK 0xffffc00c
+[R +0.120635] outl 0xcf8 0x80001820
+[S +0.120680] OK
+OK
+[R +0.120747] outl 0xcfc 0xe0004000
+[S +0.120815] OK
+OK
+[R +0.120858] outl 0xcf8 0x80001804
+[S +0.120881] OK
+OK
+[R +0.120930] inw 0xcfc
+[S +0.120975] OK 0x0000
+OK 0x0000
+[R +0.121017] outl 0xcf8 0x80001804
+[S +0.121053] OK
+OK
+[R +0.121081] outw 0xcfc 0x7
+[S +0.132297] OK
+OK
+[R +0.132330] outl 0xcf8 0x80001804
+[S +0.132345] OK
+OK
+[R +0.132357] inw 0xcfc
+[S +0.132373] OK 0x0007
+OK 0x0007
+[R +0.132392] writeq 0xe0004023 0x5f5f5f5f5f5f0d00
+[S +0.132409] OK
+OK
+[R +0.132419] writeq 0xe0004015 0x10b2d007a210fff
+[S +0.132447] OK
+OK
+[R +0.132460] writeq 0xe0004011 0xb2616007a006425
+[S +0.132480] OK
+OK
+[R +0.132489] writeq 0xe0004011 0x5a5546a2d40b6425
+qemu-system-x86_64: Failed initializing vhost-user memory map, consider using -object memory-backend-file share=on
+qemu-system-x86_64: vhost_set_mem_table failed: Invalid argument (22)
+qemu-system-x86_64: Failed to write msg. Wrote -1 instead of 52.
+qemu-system-x86_64: vhost_set_vring_addr failed: Invalid argument (22)
+=================================================================
+==2277232==ERROR: AddressSanitizer: heap-use-after-free on address 0x618000000b28 at pc 0x5570e3541a1b bp 0x7fff627ef550 sp 0x7fff627ef548
+READ of size 8 at 0x618000000b28 thread T0
+    #0 0x5570e3541a1a in vhost_virtqueue_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:1359:33
+    #1 0x5570e3562051 in vhost_dev_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:2041:13
+    #2 0x5570e37c10c1 in cryptodev_vhost_start_one /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:96:9
+    #3 0x5570e37c067f in cryptodev_vhost_start /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:213:13
+    #4 0x5570e34f06ce in virtio_crypto_vhost_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1189:13
+    #5 0x5570e34ce991 in virtio_crypto_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1205:5
+    #6 0x5570e49725e5 in virtio_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio.c:2242:9
+    #7 0x5570e3496356 in virtio_pci_common_write /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-pci.c:1612:9
+    #8 0x5570e4bbdc93 in memory_region_write_accessor /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:497:5
+    #9 0x5570e4bbd385 in access_with_adjusted_size /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:573:18
+    #10 0x5570e4bbb2f9 in memory_region_dispatch_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:1553:16
+    #11 0x5570e4c64dfe in flatview_write_continue_step /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2786:18
+    #12 0x5570e4c64694 in flatview_write_continue /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2816:19
+    #13 0x5570e4c3b3eb in flatview_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2847:12
+    #14 0x5570e4c3aec8 in address_space_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2967:18
+    #15 0x5570e375da7c in qtest_process_command /mnt/Hypervisor/qemu/build/master/fuzz/../system/qtest.c:532:13
+    #16 0x5570e375856d in qtest_process_inbuf /mnt/Hypervisor/qemu/build/master/fuzz/../system/qtest.c:776:9
+    #17 0x5570e3767b6e in qtest_read /mnt/Hypervisor/qemu/build/master/fuzz/../system/qtest.c:788:5
+    #18 0x5570e564cafd in qemu_chr_be_write_impl /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:214:9
+    #19 0x5570e564cbb9 in qemu_chr_be_write /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:226:9
+    #20 0x5570e5658a35 in fd_chr_read /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fd.c:72:9
+    #21 0x5570e500cf6c in qio_channel_fd_source_dispatch /mnt/Hypervisor/qemu/build/master/fuzz/../io/channel-watch.c:84:12
+    #22 0x7f8fc04adf7d in g_main_dispatch /home/lmy/glib-2.68.0/_build/../glib/gmain.c:3337:28
+    #23 0x7f8fc04adf7d in g_main_context_dispatch /home/lmy/glib-2.68.0/_build/../glib/gmain.c:4055:7
+    #24 0x5570e5a014e9 in glib_pollfds_poll /mnt/Hypervisor/qemu/build/master/fuzz/../util/main-loop.c:287:9
+    #25 0x5570e59ffe23 in os_host_main_loop_wait /mnt/Hypervisor/qemu/build/master/fuzz/../util/main-loop.c:310:5
+    #26 0x5570e59ff9ec in main_loop_wait /mnt/Hypervisor/qemu/build/master/fuzz/../util/main-loop.c:589:11
+    #27 0x5570e376f217 in qemu_main_loop /mnt/Hypervisor/qemu/build/master/fuzz/../system/runstate.c:835:9
+    #28 0x5570e5679ecc in qemu_default_main /mnt/Hypervisor/qemu/build/master/fuzz/../system/main.c:37:14
+    #29 0x5570e5679f17 in main /mnt/Hypervisor/qemu/build/master/fuzz/../system/main.c:48:12
+    #30 0x7f8fbe74f082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #31 0x5570e18f189d in _start (/mnt/Hypervisor/qemu/build/master/fuzz/qemu-system-x86_64+0x2c8b89d)
+
+0x618000000b28 is located 680 bytes inside of 800-byte region [0x618000000880,0x618000000ba0)
+freed by thread T0 here:
+    #0 0x5570e196dde2 in __interceptor_free /home/brian/src/llvm_releases/llvm-project/llvm/utils/release/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:111:3
+    #1 0x5570e37befc1 in cryptodev_vhost_cleanup /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:45:5
+    #2 0x5570e37ce272 in cryptodev_vhost_user_stop /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:86:9
+    #3 0x5570e37cd728 in cryptodev_vhost_user_event /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:171:9
+    #4 0x5570e5655ed1 in chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:62:5
+    #5 0x5570e564b465 in qemu_chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:82:5
+    #6 0x5570e5646076 in tcp_chr_disconnect_locked /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-socket.c:482:9
+    #7 0x5570e5632534 in tcp_chr_write /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-socket.c:131:17
+    #8 0x5570e564c1f5 in qemu_chr_write_buffer /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:122:15
+    #9 0x5570e564b8a2 in qemu_chr_write /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:186:11
+    #10 0x5570e5615f82 in qemu_chr_fe_write_all /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:52:12
+    #11 0x5570e49ec22c in vhost_user_write /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:410:11
+    #12 0x5570e4a0e512 in vhost_user_write_sync /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:1141:11
+    #13 0x5570e49f84f9 in vhost_user_set_vring_addr /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:1384:12
+    #14 0x5570e3543fcb in vhost_virtqueue_set_addr /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:979:9
+    #15 0x5570e3540a0b in vhost_virtqueue_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:1321:9
+    #16 0x5570e3562051 in vhost_dev_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:2041:13
+    #17 0x5570e37c10c1 in cryptodev_vhost_start_one /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:96:9
+    #18 0x5570e37c067f in cryptodev_vhost_start /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:213:13
+    #19 0x5570e34f06ce in virtio_crypto_vhost_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1189:13
+    #20 0x5570e34ce991 in virtio_crypto_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1205:5
+    #21 0x5570e49725e5 in virtio_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio.c:2242:9
+    #22 0x5570e3496356 in virtio_pci_common_write /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-pci.c:1612:9
+    #23 0x5570e4bbdc93 in memory_region_write_accessor /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:497:5
+    #24 0x5570e4bbd385 in access_with_adjusted_size /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:573:18
+    #25 0x5570e4bbb2f9 in memory_region_dispatch_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:1553:16
+    #26 0x5570e4c64dfe in flatview_write_continue_step /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2786:18
+    #27 0x5570e4c64694 in flatview_write_continue /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2816:19
+    #28 0x5570e4c3b3eb in flatview_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2847:12
+    #29 0x5570e4c3aec8 in address_space_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2967:18
+
+previously allocated by thread T0 here:
+    #0 0x5570e196e04d in malloc /home/brian/src/llvm_releases/llvm-project/llvm/utils/release/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
+    #1 0x7f8fc04b3dc8 in g_malloc /home/lmy/glib-2.68.0/_build/../glib/gmem.c:106:13
+    #2 0x5570e37cdca6 in cryptodev_vhost_user_start /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:108:30
+    #3 0x5570e37cd599 in cryptodev_vhost_user_event /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:164:13
+    #4 0x5570e5655ed1 in chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:62:5
+    #5 0x5570e564b465 in qemu_chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:82:5
+    #6 0x5570e5618d42 in qemu_chr_fe_set_handlers_full /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:283:13
+    #7 0x5570e5618674 in qemu_chr_fe_set_handlers /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:297:5
+    #8 0x5570e37cb960 in cryptodev_vhost_user_init /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:220:5
+    #9 0x5570e37a4e98 in cryptodev_backend_complete /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev.c:420:9
+    #10 0x5570e4eb0c40 in user_creatable_complete /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:28:9
+    #11 0x5570e4eb16a8 in user_creatable_add_type /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:125:10
+    #12 0x5570e4eb1c74 in user_creatable_add_qapi /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:157:11
+    #13 0x5570e378882b in object_option_foreach_add /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:1809:13
+    #14 0x5570e378553c in qemu_create_late_backends /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:2029:5
+    #15 0x5570e3779efe in qemu_init /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:3726:5
+    #16 0x5570e5679f11 in main /mnt/Hypervisor/qemu/build/master/fuzz/../system/main.c:47:5
+    #17 0x7f8fbe74f082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16
+
+SUMMARY: AddressSanitizer: heap-use-after-free /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:1359:33 in vhost_virtqueue_start
+Shadow bytes around the buggy address:
+  0x0c307fff8110: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c307fff8120: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c307fff8130: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c307fff8140: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c307fff8150: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+=>0x0c307fff8160: fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd
+  0x0c307fff8170: fd fd fd fd fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c307fff8180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c307fff8190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c307fff81a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c307fff81b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+Shadow byte legend (one shadow byte represents 8 application bytes):
+  Addressable:           00
+  Partially addressable: 01 02 03 04 05 06 07
+  Heap left redzone:       fa
+  Freed heap region:       fd
+  Stack left redzone:      f1
+  Stack mid redzone:       f2
+  Stack right redzone:     f3
+  Stack after return:      f5
+  Stack use after scope:   f8
+  Global redzone:          f9
+  Global init order:       f6
+  Poisoned by user:        f7
+  Container overflow:      fc
+  Array cookie:            ac
+  Intra object redzone:    bb
+  ASan internal:           fe
+  Left alloca redzone:     ca
+  Right alloca redzone:    cb
+==2277232==ABORTING
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2753 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2753
new file mode 100644
index 00000000..af1fefd1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2753
@@ -0,0 +1,124 @@
+Uninitialized read in vhost_user_backend_init.
+Description of problem:
+In backends/cryptodev-vhost.c::cryptodev_vhost_init, crypto->dev.config_ops is not initialized (See code below). I think here `g_new0` should be used instead of `g_new`.
+```
+struct CryptoDevBackendVhost *
+cryptodev_vhost_init(
+             CryptoDevBackendVhostOptions *options)
+{
+    ...
+    crypto = g_new(CryptoDevBackendVhost, 1);
+    crypto->dev.max_queues = 1;
+    crypto->dev.nvqs = 1;
+    crypto->dev.vqs = crypto->vqs;
+
+    crypto->cc = options->cc;
+
+    crypto->dev.protocol_features = 0;
+    crypto->backend = -1;
+    ...
+}
+```
+In vhost_user_backend_init, crypto->dev.config_ops will be dereferenced. Since it is uninitialized with 0, it is possible that a random value pointer will be dereferenced.
+```
+static int vhost_user_backend_init(struct vhost_dev *dev, void *opaque,
+                                   Error **errp)
+{
+    ...
+    if (virtio_has_feature(features, VHOST_USER_F_PROTOCOL_FEATURES)) {
+        bool supports_f_config = vus->supports_config ||
+            (dev->config_ops && dev->config_ops->vhost_dev_config_notifier);
+        uint64_t protocol_features;
+    ...
+```
+
+
+As a result, ASAN will capture this uninitialized, since it assigns 0xbe to every bytes of allocated but uninitilized memory.
+Steps to reproduce:
+1.Build dpdk vhost-user crypto backend. Following instructions here: [DPDK installation](https://doc.dpdk.org/guides/prog_guide/build-sdk-meson.html)
+```
+wget https://fast.dpdk.org/rel/dpdk-24.11.tar.xz
+meson setup -Dexamples=all build
+cd build
+ninja
+meson install
+cd examples
+sudo ./dpdk-vhost_crypto --vdev  'crypto_aesni_mb0' -- --config \(7,0,0\) --socket-file=7,/tmp/my-crypto.sock
+```
+After setting up the backend, should see something like:
+```
+EAL: Detected CPU lcores: 48
+EAL: Detected NUMA nodes: 2
+EAL: Detected static linkage of DPDK
+EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
+EAL: Selected IOVA mode 'PA'
+EAL: VFIO support initialized
+CRYPTODEV: Creating cryptodev crypto_aesni_mb0
+CRYPTODEV: Initialisation parameters - name: crypto_aesni_mb0,socket id: 0, max queue pairs: 8
+IPSEC_MB: ipsec_mb_create() line 168: IPSec Multi-buffer library version used: 2.0.0
+USER1: Processing on Core 7 started
+VHOST_CONFIG: (/tmp/my-crypto.sock) logging feature is disabled in async copy mode
+VHOST_CONFIG: (/tmp/my-crypto.sock) vhost-user server: socket created, fd: 213
+VHOST_CONFIG: (/tmp/my-crypto.sock) binding succeeded
+```
+
+2.Build qemu with ASAN (i.e., --enable-asan) and vhost support (i.e., --enable-vhost-user --enable-vhost-crypto)
+
+3.Ensure that /dev/hugemaps and /tmp/my-crypto.sock can be accessed. You may need to change their permissions by chmod, or run qemu-system as root.
+
+4.Run the command below to reproduce problem.  
+```
+cat << EOF | \
+./qemu-system-x86_64 --enable-kvm -m 512M \
+-object \
+memory-backend-file,id=mem,size=512M,mem-path=/dev/hugepages,share=on \
+-numa node,memdev=mem -smp cpus=4 -machine q35 -chardev \
+socket,id=chardev0,path=/tmp/my-crypto.sock -object \
+cryptodev-vhost-user,id=cryptodev0,chardev=chardev0 -device \
+virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -display none -qtest \
+stdio
+EOF
+```
+Additional information:
+Here is the information reported by ASAN: 
+```
+==2270320==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+[I 0.000000] OPENED
+../hw/virtio/vhost-user.c:2183:50: runtime error: member access within misaligned address 0xbebebebebebebebe for type 'const VhostDevConfigOps' (aka 'const struct VhostDevConfigOps'), which requires 8 byte alignment
+0xbebebebebebebebe: note: pointer points here
+<memory cannot be printed>
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/virtio/vhost-user.c:2183:50 in
+../hw/virtio/vhost-user.c:2183:50: runtime error: load of misaligned address 0xbebebebebebebebe for type 'int (*const)(struct vhost_dev *)', which requires 8 byte alignment
+0xbebebebebebebebe: note: pointer points here
+<memory cannot be printed>
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/virtio/vhost-user.c:2183:50 in
+AddressSanitizer:DEADLYSIGNAL
+=================================================================
+==2270320==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x5619d01bd606 bp 0x7fffc6d3add0 sp 0x7fffc6d3a4e0 T0)
+==2270320==The signal is caused by a READ memory access.
+==2270320==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
+    #0 0x5619d01bd606 in vhost_user_backend_init /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:2183:50
+    #1 0x5619ced13a08 in vhost_dev_init /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:1523:9
+    #2 0x5619cef8cc30 in cryptodev_vhost_init /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:69:9
+    #3 0x5619cef9aca6 in cryptodev_vhost_user_start /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:108:30
+    #4 0x5619cef9a599 in cryptodev_vhost_user_event /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:164:13
+    #5 0x5619d0e22ed1 in chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:62:5
+    #6 0x5619d0e18465 in qemu_chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:82:5
+    #7 0x5619d0de5d42 in qemu_chr_fe_set_handlers_full /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:283:13
+    #8 0x5619d0de5674 in qemu_chr_fe_set_handlers /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:297:5
+    #9 0x5619cef98960 in cryptodev_vhost_user_init /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:220:5
+    #10 0x5619cef71e98 in cryptodev_backend_complete /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev.c:420:9
+    #11 0x5619d067dc40 in user_creatable_complete /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:28:9
+    #12 0x5619d067e6a8 in user_creatable_add_type /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:125:10
+    #13 0x5619d067ec74 in user_creatable_add_qapi /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:157:11
+    #14 0x5619cef5582b in object_option_foreach_add /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:1809:13
+    #15 0x5619cef5253c in qemu_create_late_backends /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:2029:5
+    #16 0x5619cef46efe in qemu_init /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:3726:5
+    #17 0x5619d0e46f11 in main /mnt/Hypervisor/qemu/build/master/fuzz/../system/main.c:47:5
+    #18 0x7efeef09a082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #19 0x5619cd0be89d in _start (/mnt/Hypervisor/qemu/build/master/fuzz/qemu-system-x86_64+0x2c8b89d)
+
+AddressSanitizer can not provide additional info.
+SUMMARY: AddressSanitizer: SEGV /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:2183:50 in vhost_user_backend_init
+==2270320==ABORTING
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2755 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2755
new file mode 100644
index 00000000..c29af7e7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2755
@@ -0,0 +1,11 @@
+shrink attached rbd size is not allowed by default
+Description of problem:
+
+Steps to reproduce:
+1. attach a disk with size 100GiB to a running vm
+2. writing some data to the attached disk
+3. executing block_resize command and shrink the size to 1GiB
+
+the result is virtual disk is resized successfully and causing data lost.
+Additional information:
+Tested QEMU version is 4.2
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2756 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2756
new file mode 100644
index 00000000..c47a11b9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2756
@@ -0,0 +1,42 @@
+Unexpected port id 2909357808 for device virtio-serial0.0
+Description of problem:
+when the VM runs for a period of time.qemu log always print the error：“Unexpected port id 2909357808 for device virtio-serial0.0”.And the spice connet display black screen.Restart the vm,it recovery. my channel is 16,Normally it will always output port less than 16,but when error it report a lage port. why it get a lage port "2909357808",Is there a data overflow?
+Steps to reproduce:
+1.The VM runs for a period of time
+
+2.report the error: "Unexpected port id 2909357808 for device virtio-serial0.0".
+
+3.restart to recovery.
+Additional information:
+qemu log:
+
+when vm is ok:
+```
+virtio serial port 16 send control message event = 1, value = 1
+virtio serial port 0 send control message event = 1, value = 1
+virtio serial port '1' handle control message event = 3, value = 1
+virtio serial port '2' handle control message event = 3, value = 1
+virtio serial port 2 send control message event = 6, value = 1
+virtio serial port '3' handle control message event = 3, value = 1
+virtio serial port 3 send control message event = 6, value = 1
+virtio serial port '4' handle control message event = 3, value = 1
+virtio serial port 4 send control message event = 6, value = 1
+```
+
+
+when error:
+
+```
+2024-11-07T07:19:50.969383Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2909357808 for device virtio-serial0.0
+virtio serial port '2400366800' handle control message event = 49671, value = 65535
+2024-11-07T07:19:50.969706Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2400366800 for device virtio-serial0.0
+virtio serial port '2909357808' handle control message event = 52747, value = 65535
+2024-11-07T07:20:00.944495Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2909357808 for device virtio-serial0.0
+virtio serial port '2400366800' handle control message event = 49671, value = 65535
+2024-11-07T07:20:00.950544Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2400366800 for device virtio-serial0.0
+virtio serial port '2909357808' handle control message event = 52747, value = 65535
+2024-11-07T07:20:47.923564Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2909357808 for device virtio-serial0.0
+virtio serial port '2400366800' handle control message event = 49671, value = 65535
+2024-11-07T07:20:47.924422Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2400366800 for device virtio-serial0.0
+virtio serial port '2909357808' handle control message event = 52747, value = 65535
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2757 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2757
new file mode 100644
index 00000000..3fb480e4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2757
@@ -0,0 +1 @@
+EGL can't handle multi plane textures
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2758 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2758
new file mode 100644
index 00000000..85598563
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2758
@@ -0,0 +1,23 @@
+Out-of-bounds access smc91c111_readb()
+Description of problem:
+An out-of-bounds bug was triggered by my fuzzer.
+
+It looks like the code doesn't have boundary checks for `data`'s access.
+
+The error is `hw/net/smc91c111.c:605:24: runtime error: index 2048 out of bounds for type 'uint8_t[2048]' (aka 'unsigned char[2048]')`
+
+It's likely that the line 457 also needs a check.
+Steps to reproduce:
+```
+export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine realview-eb"
+cat << EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio
+writew 0x4e00000c 0x46084a4a
+writel 0x4e00000c 0x5c022fcc
+clock_step
+writel 0x4e000004 0x2fffa1b1
+clock_step
+readl 0x4e000008
+EOF
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2759 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2759
new file mode 100644
index 00000000..1f4e50c6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2759
@@ -0,0 +1 @@
+hw/usb/redirect.c: usbredir_buffered_bulk_packet() may leak memory (or worse)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/276 b/gitlab/issues_text/target_missing/host_missing/accel_missing/276
new file mode 100644
index 00000000..8c8887d9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/276
@@ -0,0 +1 @@
+Error in user-mode calculation of ELF program's brk
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2761 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2761
new file mode 100644
index 00000000..9851c07c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2761
@@ -0,0 +1,8 @@
+Emulation of x86_64 binary on ARM64 fails with "Unable to find a guest_base to satisfy all guest address mapping requirements"
+Description of problem:
+Virtualisation fails with error "Unable to find a guest_base to satisfy all guest address mapping requirements"
+
+```
+file   /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash
+/nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.10.0, BuildID[sha1]=2938b076ebbc4ea582b8eb1ea5c3f65d7a1b6261, stripped
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2762 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2762
new file mode 100644
index 00000000..7d3154d4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2762
@@ -0,0 +1,5 @@
+virtio-net regression for aarch64 guests
+Description of problem:
+The host system is running DHCP via dnsmasq 2.88. QEMU 9.1 works properly and completes DHCP handshake. QEMU 9.2 fails the DHCP handshake after DHCPOFFER with "eth0: checksum failure from 10.2.83.1".
+
+I found by bisecting that the issue was introduced by commit 7987d2be5a8bc3a502f89ba8cf3ac3e09f64d1ce "virtio-net: Copy received header to buffer". Reverting that commit on 9.2.0 corrects the issue.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2764 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2764
new file mode 100644
index 00000000..84632bb9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2764
@@ -0,0 +1,47 @@
+W32 Docker build fails
+Description of problem:
+Docker build fails:
+
+```
+make docker-test-mingw@fedora-win64-cross V=1 J=4
+```
+
+with the following error:
+
+```
+Initialized empty Git repository in /tmp/qemu-test/src/subprojects/dtc/.git/
+fatal: unable to access 'https://gitlab.com/qemu-project/dtc.git/': Could not resolve host: gitlab.com
+
+../meson.build:2090:16: ERROR: Git command failed: ['/usr/bin/git', 'fetch', '--depth', '1', 'origin', 'b6910bec11614980a21e46fbccc35934b671bd81']
+```
+Steps to reproduce:
+1. `make docker-test-mingw@fedora-win64-cross V=1 J=4 DEBUG=1`
+2. `cd $QEMU_SRC`
+3. `mkdir build`
+4. `cd build`
+5. `../configure --cross-prefix=x86_64-w64-mingw32-`
+Additional information:
+The problem can be worked around by changing the line
+
+```
+subprojects="keycodemapdb libvfio-user berkeley-softfloat-3 berkeley-testfloat-3"
+```
+
+to
+
+```
+subprojects="keycodemapdb libvfio-user berkeley-softfloat-3 berkeley-testfloat-3 dtc"
+```
+
+in `archive-source.sh`.
+
+Additionally, https://wiki.qemu.org/Hosts/W32#Docker_based_cross_builds is outdated.
+```
+make docker-test-mingw@fedora V=1 DEBUG=1 J=4
+```
+should be
+```
+make docker-test-mingw@fedora-win64-cross V=1 DEBUG=1 J=4
+```
+
+Additionally, i would suggest to create and enter build directory before calling configure and also add the make commands as shown in the "Steps to reproduce" section of this ticket.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2765 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2765
new file mode 100644
index 00000000..c43fbf60
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2765
@@ -0,0 +1 @@
+InputMethodKit warnings on macOS Sequoia
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2766 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2766
new file mode 100644
index 00000000..4e7513ff
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2766
@@ -0,0 +1,23 @@
+Qemu 9.2: stubs: build issue with --enable-user --disable-system --enable-tools
+Description of problem:
+Since commit "[stubs: avoid duplicate symbols in libqemuutil.a](https://gitlab.com/qemu-project/qemu/-/commit/388b849fb6c33882b481123568995a749a54f648)", Qemu doesn't build with:
+
+  ./configure --enable-user --disable-system --enable-tools
+
+  /usr/bin/ld: libhwcore.a.p/hw_core_qdev.c.o: in function 'device_finalize': \
+  /home/autobuild/autobuild/instance-2/output-1/build/host-qemu-9.2.0/build/../hw/core/qdev.c:689:(.text+0x75c): undefined reference to 'qapi_event_send_device_deleted'
+  collect2: error: ld returned 1 exit status
+
+See Buildroot automated build results:
+http://autobuild.buildroot.org/?reason=host-qemu-9.2.0
+
+Indeed, with have_system = false and have_tools = true, Qemu needs the stubs for QAPI events added by stub_ss.add(files('qdev.c')) to provide qapi_event_send_device_deleted.
+
+Maybe the change in stubs/meson.build should have been: \
+
+if not have_system and have_tools \
+stub_ss.add(files('qdev.c')) \
+endif
+
+Best regards,
+Romain
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2767 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2767
new file mode 100644
index 00000000..e7fbd59c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2767
@@ -0,0 +1,37 @@
+sigfaul on netdev stream
+Description of problem:
+qemu sigfault if use netdev socket and hubport
+Steps to reproduce:
+1. Preconfigure network interface on /etc/network/interface or try connect from qemu server port another qemu process or other softvare (gnuradio, etc)
+```
+auto qt-test0
+iface qt-test0 
+        address 192.168.10.1/30
+        mtu 16384
+        pre-up ip tuntap add $IFACE mode tap
+        post-down ip link del dev $IFACE
+```
+2. Run qemu from the cmdline
+Additional information:
+```
+(gdb) bt
+#0  0x0000555555b547d0 in object_get_class ()
+#1  0x0000555555b9d44c in qio_channel_writev ()
+#2  0x000055555598295c in ?? ()
+#3  0x000055555597cf67 in ?? ()
+#4  0x0000555555980eb9 in qemu_net_queue_send_iov ()
+#5  0x000055555597b8e4 in ?? ()
+#6  0x000055555597ce32 in ?? ()
+#7  0x0000555555980df5 in qemu_net_queue_send ()
+#8  0x000055555598fb52 in ?? ()
+#9  0x0000555555d26755 in ?? ()
+#10 0x0000555555d270d2 in aio_dispatch ()
+#11 0x0000555555d3f5ef in ?? ()
+#12 0x00007ffff70f100e in ?? () from /usr/lib/libglib-2.0.so.0
+#13 0x00007ffff70f4988 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
+#14 0x0000555555d40f69 in main_loop_wait ()
+#15 0x000055555592fc83 in qemu_main_loop ()
+#16 0x0000555555c7c817 in qemu_default_main ()
+#17 0x00007ffff7f9a496 in libc_start_main_stage2 (main=0x5555556cc0f0 <main>, argc=12, argv=0x7fffffffebd8) at src/env/__libc_start_main.c:95
+#18 0x00005555556cd0d8 in _start ()
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/277 b/gitlab/issues_text/target_missing/host_missing/accel_missing/277
new file mode 100644
index 00000000..50063db7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/277
@@ -0,0 +1 @@
+Multi-queue vhost-user fails to reconnect with qemu version >=4.2
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2770 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2770
new file mode 100644
index 00000000..2a082a56
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2770
@@ -0,0 +1,14 @@
+Build failure due to missing  keyctl_pkey_encrypt
+Description of problem:
+
+Steps to reproduce:
+1. git checkout v7.2.0
+2. ./configure --target-list=arm-softmmu;make
+3. ../backends/cryptodev-lkcf.c: In function ‘cryptodev_lkcf_execute_task’:
+../backends/cryptodev-lkcf.c:358:19: error: implicit declaration of function ‘keyctl_pkey_encrypt’; did you mean ‘keyctl_reject’? [-Werror=implicit-function-declaration]
+             ret = keyctl_pkey_encrypt(key_id, op_desc,
+                   ^~~~~~~~~~~~~~~~~~~
+                   keyctl_reject
+../backends/cryptodev-lkcf.c:358:19: error: nested extern declaration of ‘keyctl_pkey_encrypt’ [-Werror=nested-externs]
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2771 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2771
new file mode 100644
index 00000000..bf435634
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2771
@@ -0,0 +1 @@
+qemu-system-x86_64: ../block/block-backend.c:1290: blk_in_drain: Assertion `qemu_in_main_thread()' failed.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2772 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2772
new file mode 100644
index 00000000..827fe2fb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2772
@@ -0,0 +1,74 @@
+qemu-img map command omits `offset` key in output for encrypted qcow2 files
+Description of problem:
+We use the `qemu-img map` command to retrieve metadata information from a qcow2 image. It functions as expected for non-encrypted qcow2 images. However, when the same command is executed on an encrypted qcow2 image, the output omits the `offset` key, which is critical for subsequent processing in our workflow.
+Steps to reproduce:
+1. Run qemu-img map on the encrypted incremental qcow2:
+Command:
+
+```
+ qemu-img map --object secret,id=sec0,data=trilio --output json -U --image-opts driver=qcow2,file.filename=incremental.qcow2,encrypt.format=luks,encrypt.key-secret=sec0
+```
+**Observed Output:** The command executes but does not include the offset key in the JSON output.
+For example:
+```
+[{ "start": 32191217664, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true},
+{ "start": 32191283200, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false},
+{ "start": 32193314816, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true},
+{ "start": 32193380352, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false},
+{ "start": 32195411968, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true},
+{ "start": 32195477504, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false},
+{ "start": 32197509120, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true},
+{ "start": 32197574656, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false},
+{ "start": 32199606272, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true},
+{ "start": 32199671808, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false},
+{ "start": 32201703424, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true},
+{ "start": 32201768960, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false},
+{ "start": 32203800576, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true},
+{ "start": 32203866112, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false},
+{ "start": 32205897728, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true},
+{ "start": 32205963264, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false},
+{ "start": 32207994880, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true},
+{ "start": 32208060416, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false},
+{ "start": 32210092032, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true},
+{ "start": 32210157568, "length": 2031616, "depth": 1, "present": false, "zero": true, "data": false},
+{ "start": 32212189184, "length": 65536, "depth": 1, "present": true, "zero": false, "data": true}]
+```
+
+2. Decrypt the same encrypted incremental qcow2 image and re-run the qemu-img map command:
+**Decryption command:**
+```
+qemu-img convert -t writeback --object secret,id=sec0,data=trilio -O qcow2 --image-opts driver=qcow2,encrypt.key-secret=sec0,file.filename=incremental.qcow2 decrypt.qcow2
+```
+3. Run qemu-img map on the decrypted image:
+**Command:**
+```
+qemu-img map --output json -U decrypt.qcow2 
+```
+Here, we don't need to pass the encryption key as we have already decrypted the qcow2.
+
+**Observed Output:** The JSON output includes the offset key as expected. Example:
+```
+[{ "start": 0, "length": 106954752, "depth": 0, "present": false, "zero": true, "data": false},
+{ "start": 106954752, "length": 2097152, "depth": 0, "present": true, "zero": false, "data": true, "offset": 327680},
+{ "start": 109051904, "length": 786432000, "depth": 0, "present": false, "zero": true, "data": false},
+{ "start": 895483904, "length": 2097152, "depth": 0, "present": true, "zero": false, "data": true, "offset": 2490368},
+{ "start": 897581056, "length": 1866924032, "depth": 0, "present": false, "zero": true, "data": false},
+{ "start": 2764505088, "length": 1638400, "depth": 0, "present": true, "zero": false, "data": true, "offset": 4653056},
+{ "start": 2766143488, "length": 402587648, "depth": 0, "present": false, "zero": true, "data": false},
+{ "start": 3168731136, "length": 2162688, "depth": 0, "present": true, "zero": false, "data": true, "offset": 6291456},
+{ "start": 3170893824, "length": 140443648, "depth": 0, "present": false, "zero": true, "data": false},
+{ "start": 3311337472, "length": 54394880, "depth": 0, "present": true, "zero": false, "data": true, "offset": 8519680},
+{ "start": 3365732352, "length": 2056388608, "depth": 0, "present": false, "zero": true, "data": false},
+{ "start": 5422120960, "length": 1114112, "depth": 0, "present": true, "zero": false, "data": true, "offset": 62980096},
+{ "start": 5423235072, "length": 4128768, "depth": 0, "present": false, "zero": true, "data": false},
+{ "start": 5427363840, "length": 2162688, "depth": 0, "present": true, "zero": false, "data": true, "offset": 64094208},
+{ "start": 5429526528, "length": 469696512, "depth": 0, "present": false, "zero": true, "data": false},
+{ "start": 5899223040, "length": 2162688, "depth": 0, "present": true, "zero": false, "data": true, "offset": 66256896},
+{ "start": 5901385728, "length": 90112000, "depth": 0, "present": false, "zero": true, "data": false},
+{ "start": 5991497728, "length": 1638400, "depth": 0, "present": true, "zero": false, "data": true, "offset": 68485120},
+{ "start": 5993136128, "length": 2086600704, "depth": 0, "present": false, "zero": true, "data": false},
+{ "start": 8079736832, "length": 2686976, "depth": 0, "present": true, "zero": false, "data": true, "offset": 70189056},
+{ "start": 8082423808, "length": 24129830912, "depth": 0, "present": false, "zero": true, "data": false}]
+```
+
+The missing `offset` key in the output of the `qemu-img map` command for encrypted qcow2 images disrupts downstream processes that rely on this metadata.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2774 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2774
new file mode 100644
index 00000000..cd620a53
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2774
@@ -0,0 +1,3 @@
+Consider adding an `aliases` node to RISC-V DTB that includes `serial0` alias
+Additional information:
+Example of an [aliases section for physical SoC](https://github.com/torvalds/linux/blob/b62cef9a5c673f1b8083159f5dc03c1c5daced2f/arch/riscv/boot/dts/sophgo/cv1800b-milkv-duo.dts#L14-L20).
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2776 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2776
new file mode 100644
index 00000000..8f1ddb73
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2776
@@ -0,0 +1 @@
+OHCI: Incorrectly reports an overrun error
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2777 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2777
new file mode 100644
index 00000000..4c48c61e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2777
@@ -0,0 +1,59 @@
+Assert failure in ahci-hd device
+Description of problem:
+Assert 
+
+```
+qemu-system-x86_64: ../hw/ide/core.c:934: void ide_dma_cb(void *, int): Assertion `prep_size >= 0 && prep_size <= n * 512' failed.
+```
+can be triggered with some qtest commands. This was found by fuzzing.
+Steps to reproduce:
+Command:
+
+```
+cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -machine q35 -nodefaults -drive file=null-co://,if=none,format=raw,id=disk0 -device ide-hd,drive=disk0  -qtest stdio
+outl 0xcf8 0x8000fa24
+outl 0xcfc 0xe0000000
+outl 0xcf8 0x8000fa04
+outw 0xcfc 0x06
+write 0x0 0x1 0x27
+write 0x1 0x1 0x80
+write 0x2 0x1 0x25
+write 0xe00003b8 0x1 0x02
+write 0xe0000398 0x1 0x01
+EOF
+```
+
+Results in 
+
+```
+[I 0.000001] OPENED
+[R +0.076075] outl 0xcf8 0x8000fa24
+[S +0.076165] OK
+OK
+[R +0.076198] outl 0xcfc 0xe0000000
+[S +0.076242] OK
+OK
+[R +0.076320] outl 0xcf8 0x8000fa04
+[S +0.076344] OK
+OK
+[R +0.076379] outw 0xcfc 0x06
+[S +0.077676] OK
+OK
+[R +0.077760] write 0x0 0x1 0x27
+[S +0.079429] OK
+OK
+[R +0.079552] write 0x1 0x1 0x80
+[S +0.079592] OK
+OK
+[R +0.079618] write 0x2 0x1 0x25
+[S +0.079645] OK
+OK
+[R +0.079669] write 0xe00003b8 0x1 0x02
+[S +0.079709] OK
+OK
+[R +0.079733] write 0xe0000398 0x1 0x01
+qemu-system-x86_64: ../hw/ide/core.c:934: void ide_dma_cb(void *, int): Assertion `prep_size >= 0 && prep_size <= n * 512' failed.
+Aborted
+```
+Additional information:
+Maybe we can just `goto eot;` instead of assert?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2778 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2778
new file mode 100644
index 00000000..4f540ae9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2778
@@ -0,0 +1,99 @@
+Null Dereference in ahci-hd device
+Description of problem:
+Issue was found by fuzzing. With some qtest commands we can crash qemu-system-x86_64 because of Null dereference.
+Steps to reproduce:
+Command:
+
+```
+cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest -m 512M -machine q35 -nodefaults -drive file=null-co://,if=none,format=raw,id=disk0 -device ide-hd,drive=disk0  -qtest stdio
+outl 0xcf8 0x8000fa24
+outl 0xcfc 0xe0000000
+outl 0xcf8 0x8000fa04
+outw 0xcfc 0x06
+write 0xe00003b8 0x1 0x01
+write 0x0 0x1 0x27
+write 0x1 0x1 0x80
+write 0x2 0x1 0x20
+write 0x7 0x1 0x01
+write 0xe0000398 0x1 0x01
+write 0xe0000398 0x1 0x00
+write 0xe0000398 0x1 0x01
+EOF
+```
+
+Results in 
+
+```
+[I 0.000001] OPENED
+[R +0.082978] outl 0xcf8 0x8000fa24
+[S +0.083040] OK
+OK
+[R +0.083070] outl 0xcfc 0xe0000000
+[S +0.083115] OK
+OK
+[R +0.083132] outl 0xcf8 0x8000fa04
+[S +0.083152] OK
+OK
+[R +0.083180] outw 0xcfc 0x06
+[S +0.084233] OK
+OK
+[R +0.084291] write 0xe00003b8 0x1 0x01
+[S +0.084344] OK
+OK
+[R +0.084384] write 0x0 0x1 0x27
+[S +0.085007] OK
+OK
+[R +0.085041] write 0x1 0x1 0x80
+[S +0.085055] OK
+OK
+[R +0.085071] write 0x2 0x1 0x20
+[S +0.085084] OK
+OK
+[R +0.085096] write 0x7 0x1 0x01
+[S +0.085110] OK
+OK
+[R +0.085123] write 0xe0000398 0x1 0x01
+[S +0.085254] OK
+OK
+[R +0.085294] write 0xe0000398 0x1 0x00
+[S +0.085324] OK
+OK
+[R +0.085349] write 0xe0000398 0x1 0x01
+[S +0.085408] OK
+OK
+../hw/ide/ahci.c:1377:46: runtime error: member access within null pointer of type 'AHCICmdHdr' (aka 'struct AHCICmdHdr')
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/ide/ahci.c:1377:46 in 
+../hw/ide/ahci.c:1377:46: runtime error: load of null pointer of type 'uint16_t' (aka 'unsigned short')
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/ide/ahci.c:1377:46 in 
+AddressSanitizer:DEADLYSIGNAL
+=================================================================
+==2547739==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55abf3a79f9c bp 0x7ffc213000d0 sp 0x7ffc212fffa0 T0)
+==2547739==The signal is caused by a READ memory access.
+==2547739==Hint: address points to the zero page.
+    #0 0x55abf3a79f9c in ahci_pio_transfer /home/artemiin/Work/original_qemu/build/../hw/ide/ahci.c:1377:46
+    #1 0x55abf3a8a396 in ide_transfer_start_norecurse /home/artemiin/Work/original_qemu/build/../hw/ide/core.c:581:5
+    #2 0x55abf3aab79e in ide_transfer_start /home/artemiin/Work/original_qemu/build/../hw/ide/core.c:588:9
+    #3 0x55abf3aab79e in ide_sector_read_cb /home/artemiin/Work/original_qemu/build/../hw/ide/core.c:789:5
+    #4 0x55abf3a8d6e2 in ide_buffered_readv_cb /home/artemiin/Work/original_qemu/build/../hw/ide/core.c:684:9
+    #5 0x55abf4f31d33 in blk_aio_complete /home/artemiin/Work/original_qemu/build/../block/block-backend.c:1552:9
+    #6 0x55abf545010b in aio_bh_call /home/artemiin/Work/original_qemu/build/../util/async.c:172:5
+    #7 0x55abf545089f in aio_bh_poll /home/artemiin/Work/original_qemu/build/../util/async.c:219:13
+    #8 0x55abf53e746a in aio_dispatch /home/artemiin/Work/original_qemu/build/../util/aio-posix.c:424:5
+    #9 0x55abf545469a in aio_ctx_dispatch /home/artemiin/Work/original_qemu/build/../util/async.c:361:5
+    #10 0x7f358845b7a8 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x547a8) (BuildId: 9f90bd7bbfcf84a1f1c5a6102f70e6264837b9d4)
+    #11 0x55abf5455787 in glib_pollfds_poll /home/artemiin/Work/original_qemu/build/../util/main-loop.c:287:9
+    #12 0x55abf5455787 in os_host_main_loop_wait /home/artemiin/Work/original_qemu/build/../util/main-loop.c:310:5
+    #13 0x55abf5455787 in main_loop_wait /home/artemiin/Work/original_qemu/build/../util/main-loop.c:589:11
+    #14 0x55abf425c296 in qemu_main_loop /home/artemiin/Work/original_qemu/build/../system/runstate.c:835:9
+    #15 0x55abf51df1c6 in qemu_default_main /home/artemiin/Work/original_qemu/build/../system/main.c:48:14
+    #16 0x55abf51df1a1 in main /home/artemiin/Work/original_qemu/build/../system/main.c:76:9
+    #17 0x7f3587219249 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
+    #18 0x7f3587219304 in __libc_start_main csu/../csu/libc-start.c:360:3
+    #19 0x55abf353be60 in _start (/home/artemiin/Work/original_qemu/build/qemu-system-x86_64+0x1828e60) (BuildId: f91712a3af40a999ce35e39809ce00f92c35ae25)
+
+AddressSanitizer can not provide additional info.
+SUMMARY: AddressSanitizer: SEGV /home/artemiin/Work/original_qemu/build/../hw/ide/ahci.c:1377:46 in ahci_pio_transfer
+==2547739==ABORTING
+```
+Additional information:
+This issue may need a complicated patch so I ask developers to take a look at this issue.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/278 b/gitlab/issues_text/target_missing/host_missing/accel_missing/278
new file mode 100644
index 00000000..86c42cc4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/278
@@ -0,0 +1 @@
+jack audio dev produces no sound
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2780 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2780
new file mode 100644
index 00000000..d16b99d5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2780
@@ -0,0 +1,17 @@
+Out-of-bounds access in smc91c111_receive()
+Description of problem:
+An out-of-bounds access happens at hw/net/smc91c111.c:705.
+
+`hw/net/smc91c111.c:705:5: runtime error: index -1 out of bounds for type 'int[4]'`
+Steps to reproduce:
+```
+export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine realview-eb"
+cat << EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio
+writew 0x4e000005 0x227
+writel 0x4e00000b 0x25ab1f2
+writew 0x4e000000 0xaa6c
+clock_step
+EOF
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2781 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2781
new file mode 100644
index 00000000..075a4210
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2781
@@ -0,0 +1 @@
+Open logfiles for append
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2785 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2785
new file mode 100644
index 00000000..d882eab9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2785
@@ -0,0 +1,16 @@
+Cannot build qemu after the latest addition of NBD docs
+Description of problem:
+```
+[5584/5962] Generating docs/QEMU manual with a custom command
+FAILED: docs/docs.stamp
+"C:\msys64\usr\bin/env.EXE" "CONFDIR=etc/" "C:/msys64/home/user/qemu/build/pyvenv/bin/sphinx-build.exe" "-q" "-W" "-Dkerneldoc_werror=1" "-j" "auto" "-Dversion=9.2.50" "-Drelease=" "-Ddepfile=docs/docs.d" "-Ddepfile_stamp=docs/docs.stamp" "-b" "html" "-d" "C:/msys64/home/user/qemu/build/docs/manual.p" "C:/msys64/home/user/qemu/docs" "C:/msys64/home/user/qemu/build/docs/manual"
+C:/msys64/home/user/qemu/docs/system/qemu-block-drivers.rst.inc:506: WARNING: duplicate label nbd, other instance in C:/msys64/home/user/qemu/docs/system/images.rst
+[5593/5962] Compiling C object tests/qtest/ide-test.exe.p/ide-test.c.obj
+ninja: build stopped: subcommand failed.
+```
+Steps to reproduce:
+1.meson compile
+2.
+3.
+Additional information:
+excluding NBD from the build targets allows successful compilation
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2786 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2786
new file mode 100644
index 00000000..00984e9e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2786
@@ -0,0 +1,11 @@
+deleting files fails on vvfat (was: "error handling renames")
+Description of problem:
+When working with files, renaming or saving from IDE, QEMU halts with the error message: 
+
+"Error handling renames (-2)"
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+a previous del failed, the directories are not synced so the rename on the drive fails when the file with the target file name still exists on the real directory. So the real issue is a failed del.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2788 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2788
new file mode 100644
index 00000000..9f51a439
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2788
@@ -0,0 +1,13 @@
+[solved] input mouse and keyboard not working on a distro
+Description of problem:
+The distro work but does not take input from either keyboard or mouse.
+At the boot menu (syslinux) where I have to choose the boot mode the keyboard works, but it stops working when the desktop has booted.
+The distro is not blocked I can tell by observing that the clock in the panel keeps running and if I click in the qemu menubar on machine > power down, the distro correctly performs the shutdown procedure.
+I have tried other distributions (porteus and tinycore) and both do not have this problem.
+I also tried using as -display vnc and sdl but I have the same problem.
+I am using a [portable version of qemu](https://gitlab.com/qemu-project/qemu/-/issues/new) but I also tried with the repository version having the same problem.
+Steps to reproduce:
+Simply boot the virtual machine with the distro, in my case with the portable qemu version:
+./QEMU-git-x86_64.AppImage qemu-system-x86_64 -m 512 -enable-kvm -boot d -cdrom ./Nemesis-v25.01-XFCE-x86_64.iso
+Additional information:
+I am not expert in qemu, if you need some more data I can try to produce it
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2789 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2789
new file mode 100644
index 00000000..7915c6eb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2789
@@ -0,0 +1 @@
+Emulate a folder instead of creating the iso
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2793 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2793
new file mode 100644
index 00000000..cf2fb808
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2793
@@ -0,0 +1,242 @@
+Upgrading from qemu-kvm-* (17:9.1.0-7.el9) to (17:9.1.0-9.el9) causes VM to crash within cockpit-machines (v326-1.el9) with qemu-kvm: ../qapi/qobject-output-visitor.c:95: void qobject_output_add_obj(QObjectOutputVisitor *, const char *, QObject *): Assert
+Description of problem:
+** From the /var/log/libvirt/qemu/WinDesktop03-log **
+
+2025-01-21 21:50:57.464+0000: Starting external device: TPM Emulator
+/usr/bin/swtpm socket --ctrl type=unixio,path=/run/libvirt/qemu/swtpm/1-WinDesktop-03-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/fb44aa6f-8127-4df7-afc3-2ba54b7b7790/tpm2,mode=0600 --log file=/var/log/swtpm/libvirt/qemu/WinDesktop-03-swtpm.log --terminate --tpm2
+2025-01-21 21:50:57.501+0000: starting up libvirt version: 10.10.0, package: 3.el9 (builder@centos.org, 2024-12-20-13:49:58, ), qemu version: 9.1.0qemu-kvm-9.1.0-7.el9, kernel: 6.12.9, hostname: amd-strat-3
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+HOME=/var/lib/libvirt/qemu/domain-1-WinDesktop-03 \
+XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-1-WinDesktop-03/.local/share \
+XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-1-WinDesktop-03/.cache \
+XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-1-WinDesktop-03/.config \
+/usr/libexec/qemu-kvm \
+-name guest=WinDesktop-03,debug-threads=on \
+-S \
+-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-1-WinDesktop-03/master-key.aes"}' \
+-blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \
+-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/WinDesktop-03_VARS.fd","node-name":"libvirt-pflash1-storage","read-only":false}' \
+-machine pc-q35-rhel9.6.0,usb=off,smm=on,dump-guest-core=off,memory-backend=pc.ram,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-storage,hpet=off,acpi=on \
+-accel kvm \
+-cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff,hv-vpindex=on,hv-runtime=on,hv-synic=on,hv-stimer=on,hv-frequencies=on,hv-tlbflush=on,hv-ipi=on,hv-avic=on \
+-global driver=cfi.pflash01,property=secure,value=on \
+-m size=8388608k \
+-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":8589934592}' \
+-overcommit mem-lock=off \
+-smp 8,sockets=1,dies=1,clusters=1,cores=8,threads=1 \
+-uuid fb44aa6f-8127-4df7-afc3-2ba54b7b7790 \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=23,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=localtime,driftfix=slew \
+-global kvm-pit.lost_tick_policy=delay \
+-no-shutdown \
+-global ICH9-LPC.disable_s3=1 \
+-global ICH9-LPC.disable_s4=1 \
+-boot strict=on \
+-device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \
+-device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \
+-device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \
+-device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \
+-device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \
+-device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \
+-device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \
+-device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \
+-device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \
+-device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \
+-device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \
+-device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \
+-device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \
+-device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \
+-device '{"driver":"qemu-xhci","p2":15,"p3":15,"id":"usb","bus":"pci.2","addr":"0x0"}' \
+-device '{"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.4","addr":"0x0"}' \
+-blockdev '{"driver":"file","filename":"/stratistor/clustermounts/machines/WinDesktop-03/WinDesktop-03.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \
+-device '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":1}' \
+-netdev '{"type":"tap","fd":"25","vhost":true,"vhostfd":"27","id":"hostnet0"}' \
+-device '{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:d4:af:c9","bus":"pci.1","addr":"0x0"}' \
+-chardev pty,id=charserial0 \
+-device '{"driver":"isa-serial","chardev":"charserial0","id":"serial0","index":0}' \
+-chardev socket,id=charchannel0,fd=22,server=on,wait=off \
+-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \
+-chardev socket,id=chrtpm,path=/run/libvirt/qemu/swtpm/1-WinDesktop-03-swtpm.sock \
+-tpmdev emulator,id=tpm-tpm0,chardev=chrtpm \
+-device '{"driver":"tpm-crb","tpmdev":"tpm-tpm0","id":"tpm0"}' \
+-device '{"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"}' \
+-audiodev '{"id":"audio1","driver":"none"}' \
+-vnc 0.0.0.0:0,audiodev=audio1 \
+-device '{"driver":"virtio-vga","id":"video0","max_outputs":1,"bus":"pcie.0","addr":"0x1"}' \
+-global ICH9-LPC.noreboot=off \
+-watchdog-action reset \
+-incoming defer \
+-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.3","addr":"0x0"}' \
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
+2025-01-21 21:50:57.502+0000: Domain id=1 is tainted: high-privileges
+2025-01-21 21:50:57.502+0000: Domain id=1 is tainted: host-cpu
+char device redirected to /dev/pts/0 (label charserial0)
+2025-01-21 21:51:07.797+0000: Domain id=1 is tainted: custom-ga-command
+2025-01-25T20:54:12.923119Z qemu-kvm: terminating on signal 15 from pid 279229 (/usr/sbin/virtqemud)
+2025-01-25 20:54:13.215+0000: shutting down, reason=shutdown
+2025-01-25 20:54:18.392+0000: Starting external device: TPM Emulator
+/usr/bin/swtpm socket --ctrl type=unixio,path=/run/libvirt/qemu/swtpm/2-WinDesktop-03-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/fb44aa6f-8127-4df7-afc3-2ba54b7b7790/tpm2,mode=0600 --log file=/var/log/swtpm/libvirt/qemu/WinDesktop-03-swtpm.log --terminate --tpm2
+2025-01-25 20:54:18.414+0000: starting up libvirt version: 10.10.0, package: 3.el9 (builder@centos.org, 2024-12-20-13:49:58, ), qemu version: 9.1.0qemu-kvm-9.1.0-9.el9, kernel: 6.12.9, hostname: amd-strat-3
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+HOME=/var/lib/libvirt/qemu/domain-2-WinDesktop-03 \
+XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-2-WinDesktop-03/.local/share \
+XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-2-WinDesktop-03/.cache \
+XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-2-WinDesktop-03/.config \
+/usr/libexec/qemu-kvm \
+-name guest=WinDesktop-03,debug-threads=on \
+-S \
+-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-2-WinDesktop-03/master-key.aes"}' \
+-blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \
+-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/WinDesktop-03_VARS.fd","node-name":"libvirt-pflash1-storage","read-only":false}' \
+-machine pc-q35-rhel9.6.0,usb=off,smm=on,dump-guest-core=off,memory-backend=pc.ram,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-storage,hpet=off,acpi=on \
+-accel kvm \
+-cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff,hv-vpindex=on,hv-runtime=on,hv-synic=on,hv-stimer=on,hv-frequencies=on,hv-tlbflush=on,hv-ipi=on,hv-avic=on \
+-global driver=cfi.pflash01,property=secure,value=on \
+-m size=8388608k \
+-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":8589934592}' \
+-overcommit mem-lock=off \
+-smp 8,sockets=1,dies=1,clusters=1,cores=8,threads=1 \
+-uuid fb44aa6f-8127-4df7-afc3-2ba54b7b7790 \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=25,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=localtime,driftfix=slew \
+-global kvm-pit.lost_tick_policy=delay \
+-no-shutdown \
+-global ICH9-LPC.disable_s3=1 \
+-global ICH9-LPC.disable_s4=1 \
+-boot strict=on \
+-device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \
+-device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \
+-device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \
+-device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \
+-device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \
+-device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \
+-device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \
+-device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \
+-device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \
+-device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \
+-device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \
+-device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \
+-device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \
+-device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \
+-device '{"driver":"qemu-xhci","p2":15,"p3":15,"id":"usb","bus":"pci.2","addr":"0x0"}' \
+-device '{"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.4","addr":"0x0"}' \
+-blockdev '{"driver":"file","filename":"/stratistor/clustermounts/machines/WinDesktop-03/WinDesktop-03.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \
+-device '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":1}' \
+-netdev '{"type":"tap","fd":"27","vhost":true,"vhostfd":"34","id":"hostnet0"}' \
+-device '{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:d4:af:c9","bus":"pci.1","addr":"0x0"}' \
+-chardev pty,id=charserial0 \
+-device '{"driver":"isa-serial","chardev":"charserial0","id":"serial0","index":0}' \
+-chardev socket,id=charchannel0,fd=23,server=on,wait=off \
+-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \
+-chardev socket,id=chrtpm,path=/run/libvirt/qemu/swtpm/2-WinDesktop-03-swtpm.sock \
+-tpmdev emulator,id=tpm-tpm0,chardev=chrtpm \
+-device '{"driver":"tpm-crb","tpmdev":"tpm-tpm0","id":"tpm0"}' \
+-device '{"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"}' \
+-audiodev '{"id":"audio1","driver":"none"}' \
+-vnc 0.0.0.0:0,audiodev=audio1 \
+-device '{"driver":"virtio-vga","id":"video0","max_outputs":1,"bus":"pcie.0","addr":"0x1"}' \
+-global ICH9-LPC.noreboot=off \
+-watchdog-action reset \
+-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.3","addr":"0x0"}' \
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
+2025-01-25 20:54:18.414+0000: Domain id=2 is tainted: high-privileges
+char device redirected to /dev/pts/0 (label charserial0)
+qemu-kvm: ../qapi/qobject-output-visitor.c:95: void qobject_output_add_obj(QObjectOutputVisitor *, const char *, QObject *): Assertion `name' failed.
+2025-01-25 20:54:19.395+0000: shutting down, reason=crashed
+2025-01-25 20:54:25.221+0000: Starting external device: TPM Emulator
+/usr/bin/swtpm socket --ctrl type=unixio,path=/run/libvirt/qemu/swtpm/3-WinDesktop-03-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/fb44aa6f-8127-4df7-afc3-2ba54b7b7790/tpm2,mode=0600 --log file=/var/log/swtpm/libvirt/qemu/WinDesktop-03-swtpm.log --terminate --tpm2
+2025-01-25 20:54:25.242+0000: starting up libvirt version: 10.10.0, package: 3.el9 (builder@centos.org, 2024-12-20-13:49:58, ), qemu version: 9.1.0qemu-kvm-9.1.0-9.el9, kernel: 6.12.9, hostname: amd-strat-3
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+HOME=/var/lib/libvirt/qemu/domain-3-WinDesktop-03 \
+XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-3-WinDesktop-03/.local/share \
+XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-3-WinDesktop-03/.cache \
+XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-3-WinDesktop-03/.config \
+/usr/libexec/qemu-kvm \
+-name guest=WinDesktop-03,debug-threads=on \
+-S \
+-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-3-WinDesktop-03/master-key.aes"}' \
+-blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \
+-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/WinDesktop-03_VARS.fd","node-name":"libvirt-pflash1-storage","read-only":false}' \
+-machine pc-q35-rhel9.6.0,usb=off,smm=on,dump-guest-core=off,memory-backend=pc.ram,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-storage,hpet=off,acpi=on \
+-accel kvm \
+-cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff,hv-vpindex=on,hv-runtime=on,hv-synic=on,hv-stimer=on,hv-frequencies=on,hv-tlbflush=on,hv-ipi=on,hv-avic=on \
+-global driver=cfi.pflash01,property=secure,value=on \
+-m size=8388608k \
+-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":8589934592}' \
+-overcommit mem-lock=off \
+-smp 8,sockets=1,dies=1,clusters=1,cores=8,threads=1 \
+-uuid fb44aa6f-8127-4df7-afc3-2ba54b7b7790 \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=25,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=localtime,driftfix=slew \
+-global kvm-pit.lost_tick_policy=delay \
+-no-shutdown \
+-global ICH9-LPC.disable_s3=1 \
+-global ICH9-LPC.disable_s4=1 \
+-boot strict=on \
+-device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \
+-device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \
+-device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \
+-device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \
+-device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \
+-device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \
+-device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \
+-device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \
+-device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \
+-device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \
+-device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \
+-device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \
+-device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \
+-device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \
+-device '{"driver":"qemu-xhci","p2":15,"p3":15,"id":"usb","bus":"pci.2","addr":"0x0"}' \
+-device '{"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.4","addr":"0x0"}' \
+-blockdev '{"driver":"file","filename":"/stratistor/clustermounts/machines/WinDesktop-03/WinDesktop-03.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \
+-device '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":1}' \
+-netdev '{"type":"tap","fd":"27","vhost":true,"vhostfd":"34","id":"hostnet0"}' \
+-device '{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:d4:af:c9","bus":"pci.1","addr":"0x0"}' \
+-chardev pty,id=charserial0 \
+-device '{"driver":"isa-serial","chardev":"charserial0","id":"serial0","index":0}' \
+-chardev socket,id=charchannel0,fd=23,server=on,wait=off \
+-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \
+-chardev socket,id=chrtpm,path=/run/libvirt/qemu/swtpm/3-WinDesktop-03-swtpm.sock \
+-tpmdev emulator,id=tpm-tpm0,chardev=chrtpm \
+-device '{"driver":"tpm-crb","tpmdev":"tpm-tpm0","id":"tpm0"}' \
+-device '{"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"}' \
+-audiodev '{"id":"audio1","driver":"none"}' \
+-vnc 0.0.0.0:0,audiodev=audio1 \
+-device '{"driver":"virtio-vga","id":"video0","max_outputs":1,"bus":"pcie.0","addr":"0x1"}' \
+-global ICH9-LPC.noreboot=off \
+-watchdog-action reset \
+-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.3","addr":"0x0"}' \
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
+2025-01-25 20:54:25.242+0000: Domain id=3 is tainted: high-privileges
+char device redirected to /dev/pts/0 (label charserial0)
+**qemu-kvm: ../qapi/qobject-output-visitor.c:95: void qobject_output_add_obj(QObjectOutputVisitor *, const char *, QObject *): Assertion `name' failed.
+2025-01-25 20:54:29.967+0000: shutting down, reason=crashed**
+Steps to reproduce:
+1. Could not produce crash with qemu version 9.1.0-7, upgraded to 9.1.0-9.
+2. Started VM using cockpit web interface
+3. Crashes within 5 seconds of starting
+4. Opening a ticket with cockpit-machines tracker as well as this only happens in cockpit-machines. I am able to open console using virt-manager without crashing, it's only with the cockpit-machines web interface on the VM summary page for the specific VM that appears to cause this.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2795 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2795
new file mode 100644
index 00000000..f99167c9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2795
@@ -0,0 +1,160 @@
+qemu-system-aarch64 crash when issuing set_link net on in monitor
+Description of problem:
+Boot the guest. On the host, connect to the qemu monitor and issue the following commmands:
+```
+set_link net0 off
+ethtool enp0s1 on the guest now shows the link going down
+set_link net0 on
+```
+
+qemu crashes as follows (virtio net):
+```
+Thread 1 "qemu-system-aar" received signal SIGSEGV, Segmentation fault.
+object_get_class (obj=obj@entry=0x0) at ../qemu/qom/object.c:1049
+1049	    return obj->class;
+(gdb) bt
+#0  object_get_class (obj=obj@entry=0x0) at ../qemu/qom/object.c:1049
+#1  0x000055555602dd0f in QIO_CHANNEL_GET_CLASS (obj=0x0)
+    at /home/tsailer/src/daedalean/exp-bertcard-emu/qemu/include/io/channel.h:29
+#2  qio_channel_writev_full
+    (errp=0x0, flags=0, nfds=0, fds=0x0, niov=2, iov=0x7fffffff5190, ioc=0x0)
+    at ../qemu/io/channel.c:87
+#3  qio_channel_writev
+    (ioc=0x0, iov=iov@entry=0x7fffffff5190, niov=2, errp=errp@entry=0x0)
+    at ../qemu/io/channel.c:305
+#4  0x0000555555c42a66 in net_stream_receive
+    (nc=0x5555578477d0, buf=<optimized out>, size=90)
+    at ../qemu/net/stream.c:98
+#5  0x0000555555c3d327 in nc_sendv_compat
+    (flags=<optimized out>, iovcnt=1, iov=0x7fffffff52f0, nc=0x5555578477d0)
+    at ../qemu/net/net.c:784
+#6  qemu_deliver_packet_iov
+    (sender=<optimized out>, flags=<optimized out>, iov=0x7fffffff52f0, iovcnt=1, opaque=0x5555578477d0) at ../qemu/net/net.c:830
+#7  0x0000555555c4106c in qemu_net_queue_deliver_iov
+    (iovcnt=1, iov=0x7fffffff52f0, flags=0, sender=0x5555583049d8, queue=0x55555783c5e0) at ../qemu/net/queue.c:179
+#8  qemu_net_queue_send_iov
+    (queue=0x55555783c5e0, sender=0x5555583049d8, flags=flags@entry=0, iov=iov@entry=0x7fffffff52f0, iovcnt=iovcnt@entry=1, sent_cb=sent_cb@entry=0x555555f28fa0 <virtio_net_tx_complete>) at ../qemu/net/queue.c:235
+#9  0x0000555555c3ed63 in qemu_sendv_packet_async
+    (sent_cb=0x555555f28fa0 <virtio_net_tx_complete>, iovcnt=1, iov=0x7fffffff52f0, sender=<optimized out>) at ../qemu/net/net.c:875
+#10 0x0000555555f28c1d in virtio_net_flush_tx (q=q@entry=0x5555582fcb00)
+    at ../qemu/hw/net/virtio-net.c:2795
+#11 0x0000555555f28f18 in virtio_net_tx_bh (opaque=0x5555582fcb00)
+    at ../qemu/hw/net/virtio-net.c:2948
+#12 0x00005555561c2f47 in aio_bh_call (bh=bh@entry=0x5555582d0b30)
+    at ../qemu/util/async.c:172
+#13 0x00005555561c311e in aio_bh_poll (ctx=ctx@entry=0x5555574c3c10)
+    at ../qemu/util/async.c:219
+#14 0x00005555561ab382 in aio_dispatch (ctx=0x5555574c3c10)
+    at ../qemu/util/aio-posix.c:424
+#15 0x00005555561c2d82 in aio_ctx_dispatch
+    (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../qemu/util/async.c:361
+#16 0x00007ffff7ad5d3b in g_main_context_dispatch ()
+    at /lib/x86_64-linux-gnu/libglib-2.0.so.0
+#17 0x00005555561c45d8 in glib_pollfds_poll () at ../qemu/util/main-loop.c:287
+#18 os_host_main_loop_wait (timeout=0) at ../qemu/util/main-loop.c:310
+#19 main_loop_wait (nonblocking=nonblocking@entry=0)
+    at ../qemu/util/main-loop.c:589
+#20 0x0000555555bf2569 in qemu_main_loop () at ../qemu/system/runstate.c:835
+#21 0x00005555561047fa in qemu_default_main () at ../qemu/system/main.c:37
+#22 0x00007ffff7229d90 in __libc_start_call_main
+     (main=main@entry=0x5555558e5080 <main>, argc=argc@entry=44, argv=argv@entry=0x7fffffffd6c8)
+    at ../sysdeps/nptl/libc_start_call_main.h:58
+#23 0x00007ffff7229e40 in __libc_start_main_impl
+     (main=0x5555558e5080 <main>, argc=44, argv=0x7fffffffd6c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd6b8)
+    at ../csu/libc-start.c:392
+#24 0x00005555558e6095 in _start ()
+
+Crash with e1000e:
+[   16.846673] e1000e 0000:00:02.0 enp0s2: NIC Link is Down
+[   18.495388] e1000e 0000:00:02.0 enp0s2: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
+
+Thread 5 "qemu-system-aar" received signal SIGSEGV, Segmentation fault.
+[Switching to Thread 0x7fffafe00640 (LWP 641377)]
+object_get_class (obj=obj@entry=0x0) at ../qemu/qom/object.c:1049
+1049	    return obj->class;
+(gdb) bt
+#0  object_get_class (obj=obj@entry=0x0) at ../qemu/qom/object.c:1049
+#1  0x000055555602dd0f in QIO_CHANNEL_GET_CLASS (obj=0x0)
+    at /home/tsailer/src/daedalean/exp-bertcard-emu/qemu/include/io/channel.h:29
+#2  qio_channel_writev_full
+    (errp=0x0, flags=0, nfds=0, fds=0x0, niov=2, iov=0x7fffafdfe9b0, ioc=0x0)
+    at ../qemu/io/channel.c:87
+#3  qio_channel_writev
+    (ioc=0x0, iov=iov@entry=0x7fffafdfe9b0, niov=2, errp=errp@entry=0x0)
+    at ../qemu/io/channel.c:305
+#4  0x0000555555c42a66 in net_stream_receive
+    (nc=0x5555578589b0, buf=<optimized out>, size=90)
+    at ../qemu/net/stream.c:98
+#5  0x0000555555c3d327 in nc_sendv_compat
+    (flags=<optimized out>, iovcnt=3, iov=0x55555850b280, nc=0x5555578589b0)
+    at ../qemu/net/net.c:784
+#6  qemu_deliver_packet_iov
+    (sender=<optimized out>, flags=<optimized out>, iov=0x55555850b280, iovcnt=3, opaque=0x5555578589b0) at ../qemu/net/net.c:830
+#7  0x0000555555c4106c in qemu_net_queue_deliver_iov
+    (iovcnt=3, iov=0x55555850b280, flags=0, sender=0x5555584facf8, queue=0x55555783c6d0) at ../qemu/net/queue.c:179
+#8  qemu_net_queue_send_iov
+    (queue=0x55555783c6d0, sender=0x5555584facf8, flags=0, iov=0x55555850b280, iovcnt=3, sent_cb=0x0) at ../qemu/net/queue.c:235
+#9  0x0000555555a62737 in net_tx_pkt_send_custom
+    (pkt=0x5555584fb200, offload=<optimized out>, callback=0x555555a61150 <net_tx_pkt_sendv>, context=0x5555584facf8) at ../qemu/hw/net/net_tx_pkt.c:847
+#10 0x0000555555a62819 in net_tx_pkt_send
+    (pkt=<optimized out>, nc=<optimized out>)
+    at ../qemu/hw/net/net_tx_pkt.c:816
+#11 0x0000555555a6dd2a in e1000e_tx_pkt_send
+    (queue_index=<optimized out>, tx=0x555558480cc8, core=0x555558460a60)
+    at ../qemu/hw/net/e1000e_core.c:654
+#12 e1000e_process_tx_desc
+    (queue_index=<optimized out>, dp=0x7fffafdfeb20, tx=0x555558480cc8, core=0x555558460a60) at ../qemu/hw/net/e1000e_core.c:731
+#13 e1000e_start_xmit (core=0x555558460a60, txr=txr@entry=0x7fffafdfeb90)
+    at ../qemu/hw/net/e1000e_core.c:921
+#14 0x0000555555a6dfcc in e1000e_set_tdt
+    (core=<optimized out>, index=<optimized out>, val=<optimized out>)
+    at ../qemu/hw/net/e1000e_core.c:2432
+#15 0x0000555555f72044 in memory_region_write_accessor
+    (mr=0x555558460610, addr=14360, value=<optimized out>, size=4, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../qemu/system/memory.c:497
+#16 0x0000555555f7320e in access_with_adjusted_size
+    (addr=addr@entry=14360, value=value@entry=0x7fffafdfece8, size=size@entry=4,
+     access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x555555f71fc0 <memory_region_write_accessor>, mr=<optimized out>, attrs=...) at ../qemu/system/memory.c:573
+#17 0x0000555555f743ad in memory_region_dispatch_write
+    (mr=mr@entry=0x555558460610, addr=addr@entry=14360, data=<optimized out>, 
+    data@entry=19, op=op@entry=MO_32, attrs=...)
+    at ../qemu/system/memory.c:1560
+#18 0x0000555555fc6cc9 in int_st_mmio_leN
+    (cpu=cpu@entry=0x55555789a140, full=full@entry=0x7fffa47eab90, val_le=val_le@entry=19, addr=addr@entry=18446743801007585304, size=size@entry=4, mmu_idx=mmu_idx@entry=2, ra=140736286290890, mr=0x555558460610, mr_offset=14360)
+    at ../qemu/accel/tcg/cputlb.c:2489
+#19 0x0000555555fc6ec8 in do_st_mmio_leN
+    (cpu=0x55555789a140, full=0x7fffa47eab90, val_le=19, addr=18446743801007585304, size=4, mmu_idx=2, ra=140736286290890) at ../qemu/accel/tcg/cputlb.c:2524
+#20 0x0000555555fcb55a in do_st_4
+    (ra=<optimized out>, memop=<optimized out>, mmu_idx=<optimized out>, val=19, p=<optimized out>, cpu=<optimized out>) at ../qemu/accel/tcg/cputlb.c:2694
+#21 do_st4_mmu
+    (cpu=0x55555789a140, addr=140736144075184, val=19, oi=2, ra=140736286290890) at ../qemu/accel/tcg/cputlb.c:2770
+#22 0x00007fffb859f416 in code_gen_buffer ()
+#23 0x0000555555fbb6a6 in cpu_tb_exec
+    (cpu=cpu@entry=0x55555789a140, itb=itb@entry=0x7fffb859f2c0 <code_gen_buffer+140112531>, tb_exit=tb_exit@entry=0x7fffafdff444)
+    at ../qemu/accel/tcg/cpu-exec.c:458
+#24 0x0000555555fbbc2f in cpu_loop_exec_tb
+    (tb_exit=0x7fffafdff444, last_tb=<synthetic pointer>, pc=<optimized out>, tb=0x7fffb859f2c0 <code_gen_buffer+140112531>, cpu=0x55555789a140)
+    at ../qemu/accel/tcg/cpu-exec.c:908
+#25 cpu_exec_loop (cpu=cpu@entry=0x55555789a140, sc=sc@entry=0x7fffafdff4f0)
+    at ../qemu/accel/tcg/cpu-exec.c:1022
+#26 0x0000555555fbc3d1 in cpu_exec_setjmp
+    (cpu=cpu@entry=0x55555789a140, sc=sc@entry=0x7fffafdff4f0)
+    at ../qemu/accel/tcg/cpu-exec.c:1039
+#27 0x0000555555fbcb9d in cpu_exec (cpu=cpu@entry=0x55555789a140)
+    at ../qemu/accel/tcg/cpu-exec.c:1065
+#28 0x0000555555fd8123 in tcg_cpu_exec (cpu=cpu@entry=0x55555789a140)
+    at ../qemu/accel/tcg/tcg-accel-ops.c:78
+#29 0x0000555555fd8280 in mttcg_cpu_thread_fn (arg=arg@entry=0x55555789a140)
+    at ../qemu/accel/tcg/tcg-accel-ops-mttcg.c:95
+#30 0x00005555561ae740 in qemu_thread_start (args=0x555557883000)
+    at ../qemu/util/qemu-thread-posix.c:541
+#31 0x00007ffff7294ac3 in start_thread (arg=<optimized out>)
+    at ./nptl/pthread_create.c:442
+#32 0x00007ffff7326850 in clone3 ()
+    at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+```
+Steps to reproduce:
+1. Boot guest
+2. monitor: set_link net0 off
+3. monitor: set_link net0 on
+Additional information:
+Same behaviour with d6430c17d7113d3c38480dc34e59d00b0504e2f7 (master as of 2025-01-19).
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2798 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2798
new file mode 100644
index 00000000..9a898d08
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2798
@@ -0,0 +1,38 @@
+Cannot disconnect Split VMDK
+Description of problem:
+I used to mount VDI with qemu-nbd and it worked, I could mount/unmount many times. Since VDI was 400 GB, I converted to Split2G VMDK.
+In addition to file.vmdk, there are file-s001.vmdk, file-s002.vmdk..file-s201.vmdk 
+With that, I can mount, but disconnect does not work. Tried also with `blockdev`, did not help, not sure if that is needed.
+I know that with LV deactivation of volume group is needed before disconnect. Not aware if there is equivalent with Split VMDK.
+Cannot say if issue in qemu-nbd or qemu vmdk driver.
+Experienced in qemu 6.2.0 and also when upgraded to 9.0.2. May try later with master that seems to build 9.2.50.
+Steps to reproduce:
+1. sudo modprobe nbd max_part=4 && sudo qemu-nbd -f vmdk -c /dev/nbd1 file.vmdk && sudo mount /dev/nbd1p1 /mnt/vmdk
+2. sudo umount -l /mnt/vmdk && sleep 2 && sudo blockdev --flushbufs /dev/nbd1  && sleep 2 && sudo qemu-nbd -dv /dev/nbd1 
+3. lsblk # see still nbd1
+Additional information:
+```
+[  424.020397] block nbd1: NBD_DISCONNECT
+[  424.020417] block nbd1: Disconnected due to user request.
+[  424.020420] block nbd1: shutting down sockets
+[  424.024278] I/O error, dev nbd1, sector 842468736 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
+[  424.024318] I/O error, dev nbd1, sector 842468736 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[  424.024327] Buffer I/O error on dev nbd1, logical block 105308592, async page read
+[  424.028202] I/O error, dev nbd1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
+[  424.028229] I/O error, dev nbd1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[  424.028233] Buffer I/O error on dev nbd1, logical block 0, async page read
+[  424.028249] I/O error, dev nbd1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[  424.028252] Buffer I/O error on dev nbd1, logical block 0, async page read
+--
+[  548.931610] block nbd1: NBD_DISCONNECT
+[  548.931620] block nbd1: Send disconnect failed -32
+[  548.935594] blk_print_req_error: 6 callbacks suppressed
+[  548.935598] I/O error, dev nbd1, sector 842468736 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
+[  548.935634] I/O error, dev nbd1, sector 842468736 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[  548.935642] buffer_io_error: 2 callbacks suppressed
+[  548.935644] Buffer I/O error on dev nbd1, logical block 105308592, async page read
+[  548.940187] I/O error, dev nbd1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
+[  548.940211] I/O error, dev nbd1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[  548.940215] Buffer I/O error on dev nbd1, logical block 0, async page read
+[  548.940230] I/O error, dev nbd1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2799 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2799
new file mode 100644
index 00000000..4f82daa7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2799
@@ -0,0 +1,41 @@
+compile failure for linux-user when host libc defines "struct sched_attr" in its sched.h
+Description of problem:
+When I tried to build commit 871af84d the build process stopped in  [3306/9698] Compiling C object libqemu...-linux-user.a.p/linux-user_syscall.c.o
+
+Here is the error log:
+
+```
+../linux-user/syscall.c:364:8: error: redefinition of 'struct sched_attr'
+  364 | struct sched_attr {
+      |        ^~~~~~~~~~
+In file included from /usr/include/bits/sched.h:63,
+                 from /usr/include/sched.h:43,
+                 from /usr/include/pthread.h:22,
+                 from /usr/include/glib-2.0/glib/deprecated/gthread.h:126,
+                 from /usr/include/glib-2.0/glib.h:115,
+                 from /home/fred/qemu-git/src/qemu/include/glib-compat.h:32,
+                 from /home/fred/qemu-git/src/qemu/include/qemu/osdep.h:161,
+                 from ../linux-user/syscall.c:20:
+/usr/include/linux/sched/types.h:98:8: note: originally defined here
+   98 | struct sched_attr {
+      |        ^~~~~~~~~~
+```
+Steps to reproduce:
+1. Grab commit 871af84d 
+2. Use this configure command line: 
+
+```
+--prefix=/usr \
+    --sysconfdir=/etc \
+    --localstatedir=/var \
+    --libexecdir=/usr/lib/qemu \
+    --smbd=/usr/bin/smbd \
+    --enable-modules \
+    --enable-sdl \
+    --disable-werror \
+    "${@:2}"
+```
+
+3. Launch ninja and wait.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2801 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2801
new file mode 100644
index 00000000..859fd4a7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2801
@@ -0,0 +1 @@
+Implement Raspberry PI Zero 2 W.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2803 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2803
new file mode 100644
index 00000000..f2f0d201
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2803
@@ -0,0 +1,108 @@
+Assert failure in virtio-net device in address_space_lduw_le_cached
+Description of problem:
+Issue was found by fuzzing. Assert 
+
+```
+qemu/include/exec/memory_ldst_cached.h.inc:30: uint16_t address_space_lduw_le_cached(MemoryRegionCache *, hwaddr, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed.
+```
+can be triggered with some qtest commands. This is pretty similar to [issue_302](https://gitlab.com/qemu-project/qemu/-/issues/302) and [issue_781](https://gitlab.com/qemu-project/qemu/-/issues/781), but kinda different. In [issue_781](https://gitlab.com/qemu-project/qemu/-/issues/781) there is a comment, that issue was `Possibly fixed by commit 10d35e58 ("virtio-pci: fix queue_enable write").`, but unfortunately it is not - we can still trigger this assert with other set of command-line arguments and qtest commands.
+Steps to reproduce:
+Command:
+
+```
+cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -M q35 -nodefaults -device virtio-net,netdev=net0,packed=on -netdev user,id=net0 -qtest stdio
+outl 0xcf8 0x80000810
+outl 0xcfc 0xc000
+outl 0xcf8 0x80000820
+outl 0xcfc 0xe0004000
+outl 0xcf8 0x80000804
+outw 0xcfc 0x7
+write 0xe0004008 0x1 0x01
+write 0xe000400c 0x1 0x04
+outl 0xc00b 0x01000000
+outl 0xc006 0x38380000
+outl 0xc001 0x00
+outl 0xc00f 0x04000100
+write 0x3839003 0x1 0x01
+EOF
+```
+
+Results in 
+
+```
+[I 0.000000] OPENED
+[R +0.028638] outl 0xcf8 0x80000810
+[S +0.028692] OK
+OK
+[R +0.028705] outl 0xcfc 0xc000
+[S +0.028729] OK
+OK
+[R +0.028738] outl 0xcf8 0x80000820
+[S +0.028748] OK
+OK
+[R +0.028763] outl 0xcfc 0xe0004000
+[S +0.028784] OK
+OK
+[R +0.028800] outl 0xcf8 0x80000804
+[S +0.029483] OK
+OK
+[R +0.029509] outw 0xcfc 0x7
+[S +0.029820] OK
+OK
+[R +0.029833] write 0xe0004008 0x1 0x01
+[S +0.029846] OK
+OK
+[R +0.029853] write 0xe000400c 0x1 0x04
+[S +0.029882] OK
+OK
+[R +0.029894] outl 0xc00b 0x01000000
+[S +0.029909] OK
+OK
+[R +0.029923] outl 0xc006 0x38380000
+[S +0.029938] OK
+OK
+[R +0.029944] outl 0xc001 0x00
+[S +0.029953] OK
+OK
+[R +0.029959] outl 0xc00f 0x04000100
+[S +0.030073] OK
+OK
+[R +0.030091] write 0x3839003 0x1 0x01
+[S +0.030106] OK
+OK
+qemu-system-x86_64: /home/artemiin/Work/original_qemu/include/exec/memory_ldst_cached.h.inc:30: uint16_t address_space_lduw_le_cached(MemoryRegionCache *, hwaddr, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed.
+```
+Additional information:
+There is a stack trace from libFuzzer output:
+
+```
+#0 0x5555561bcfc1 in __sanitizer_print_stack_trace (qemu/build/qemu-fuzz-x86_64+0xc68fc1) (BuildId: 97b846e788f9dda2a285e5ea004d922c4886a315)
+<some_asert_calls>
+#6 0x7ffff48d4471 in abort stdlib/abort.c:79:7
+#7 0x7ffff48d4394 in __assert_fail_base assert/assert.c:92:3
+#8 0x7ffff48e2eb1 in __assert_fail assert/assert.c:101:3
+#9 0x555557043c41 in address_space_lduw_le_cached qemu/include/exec/memory_ldst_cached.h.inc:30:5
+#10 0x555557043c41 in lduw_le_phys_cached qemu/include/exec/memory_ldst_phys.h.inc:67:12
+#11 0x555557043c41 in virtio_lduw_phys_cached qemu/include/hw/virtio/virtio-access.h:166:12
+#12 0x555557030a78 in vring_avail_ring qemu/build/../hw/virtio/virtio.c:389:12
+#13 0x555557030a78 in virtqueue_get_head qemu/build/../hw/virtio/virtio.c:1043:13
+#14 0x555557030a78 in virtqueue_split_pop qemu/build/../hw/virtio/virtio.c:1540:10
+#15 0x555557030a78 in virtqueue_pop qemu/build/../hw/virtio/virtio.c:1790:16
+#16 0x555556f9aaf9 in virtio_net_flush_tx qemu/build/../hw/net/virtio-net.c:2746:16
+#17 0x555556f9a4dc in virtio_net_tx_bh qemu/build/../hw/net/virtio-net.c:2953:11
+#18 0x5555577152e2 in aio_bh_call qemu/build/../util/async.c:171:5
+#19 0x555557715830 in aio_bh_poll qemu/build/../util/async.c:218:13
+#20 0x5555576ce2d7 in aio_dispatch qemu/build/../util/aio-posix.c:423:5
+#21 0x555557717918 in aio_ctx_dispatch qemu/build/../util/async.c:360:5
+#22 0x7ffff69837a8 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x547a8) (BuildId: 9f90bd7bbfcf84a1f1c5a6102f70e6264837b9d4)
+#23 0x5555577187cd in glib_pollfds_poll qemu/build/../util/main-loop.c:287:9
+#24 0x5555577187cd in os_host_main_loop_wait qemu/build/../util/main-loop.c:310:5
+#25 0x5555577187cd in main_loop_wait qemu/build/../util/main-loop.c:589:11
+#26 0x5555571ce309 in flush_events qemu/build/../tests/qtest/fuzz/fuzz.c:50:9
+#27 0x5555571d662b in generic_fuzz qemu/build/../tests/qtest/fuzz/generic_fuzz.c:669:13
+#28 0x5555571ce7de in LLVMFuzzerTestOneInput qemu/build/../tests/qtest/fuzz/fuzz.c:158:5
+<fuzzer_init_calls>
+#35 0x5555560e2510 in _start (qemu/build/qemu-fuzz-x86_64+0xb8e510) (BuildId: 97b846e788f9dda2a285e5ea004d922c4886a315
+```
+
+FYI @mstredhat
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2804 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2804
new file mode 100644
index 00000000..e684164b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2804
@@ -0,0 +1 @@
+Unclear meson error when trying to build plugins on macOS
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2805 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2805
new file mode 100644
index 00000000..d8de99ac
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2805
@@ -0,0 +1,22 @@
+vhost-device-snd does not report correctly the device conf size
+Description of problem:
+The vhost-user-snd frontend is incorrectly reporting the size of the device configuration space, which should be based on the features exposed by the device. For example, the `controls` field in the `virtio_snd_config` structure is optional and should only be included in the configuration size if the `VIRTIO_SND_F_CTLS` feature has been negotiated.  
+
+This issue became apparent after commit `ab0c7fb2`, where `virtio_snd_config` was updated to include the `controls` field. The vhost-user-snd frontend, relying on this structure, started expecting `sizeof(virtio_snd_config)` when communicating with the backend, regardless of whether the `VIRTIO_SND_F_CTLS` feature was negotiated. As a result, any backend reporting a smaller configuration size—for example, one that does not support controls—cannot communicate with the frontend. We observed this problem in the vhost-device-sound rust-vmm device, which we partially fixed [here](https://github.com/rust-vmm/vhost-device/commit/8e7b7109316e1027548bc91cfcbb4b096b032c24).  
+
+This behavior is incorrect because the configuration size should depend on the negotiated features.
+
+I am currently working on patch to fix this.
+Steps to reproduce:
+1. Run vhost-device-sound
+```bash
+ cargo run --bin vhost-device-sound -- --socket=/tmp/vhost-sound.socket --backend=pipewire
+```
+2. Run QEMU with the parameters above
+3. In the guest run:
+```bash
+root@syzkaller:~# aplay /usr/share/sounds/alsa/Front_Left.wav 
+aplay: main:830: audio open error: No such file or directory
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2806 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2806
new file mode 100644
index 00000000..40251c2b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2806
@@ -0,0 +1,9 @@
+Build from source failed on Arch Linux with target-list=arm-softmmu,arm-linux-user
+Description of problem:
+When I tried to build the latest QEMU version, the build process top at 'linking test-qos'
+Steps to reproduce:
+1. Clone the latest git version of QEMU
+2. Configure --target-list=arm-softmmu,arm-linux-user
+3. Make
+Additional information:
+![build_failed](/uploads/b9e2bd94fcc1fbd92539f66ae2d3003f/build_failed.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2809 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2809
new file mode 100644
index 00000000..03eb7c16
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2809
@@ -0,0 +1,11 @@
+Data races in TestBlockJob fields in test-block-iothread
+Description of problem:
+A data race in the access of `TestBlockJob` fields in `tests/unit/test-block-iothread.c` was identified using TSAN.
+Steps to reproduce:
+```sh
+QEMU_BUILD_DIR=<path to the QEMU build directory>
+QEMU_DIR=<path to the QEMU repository directory>
+configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp
+make tests/unit/test-block-iothread
+MALLOC_PERTURB_=67 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-block-iothread --tap -k
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2810 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2810
new file mode 100644
index 00000000..c3b5bad4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2810
@@ -0,0 +1 @@
+Boot zboot images on riscv64 and loogarch64
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2811 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2811
new file mode 100644
index 00000000..55bd6a60
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2811
@@ -0,0 +1,94 @@
+The release artifact for 9.2.1 can not be authenticated with the accompanying OpenPGP signature
+Description of problem:
+Hi! :wave: 
+
+I package this project for Arch Linux.
+This ticket is to inform you that the release artifact for 9.2.1 can not be validated using the accompanying OpenPGP signature.
+The signature has been created by the OpenPGP key with the fingerprint `CEACC9E15534EBABB82D3FA03353C9CEF108B584` (held by @mdroth).
+However, I am not able to validate the downloaded archive with the provided signature.
+
+Please make sure that the archive has not been tampered with and ideally do a full re-release and re-sign cycle.
+Steps to reproduce:
+Download sources and create checksum:
+
+```bash
+curl -O https://download.qemu.org/qemu-9.2.1.tar.xz 
+curl -O https://download.qemu.org/qemu-9.2.1.tar.xz.sig
+b2sum qemu-9.2.1.tar.xz
+062b2ef336dbc488bfd9e6c6a21cd95464ab76a98ce8f66bb314101d25a5dc72815ae4eb28028507c85ddade8a28e00cf8897302645ad6ddd2c093bde1cfba9a  qemu-9.2.1.tar.xz
+```
+
+Get latest version of certificate that can be used to verify the signature:
+
+```bash
+gpg --recv-keys CEACC9E15534EBABB82D3FA03353C9CEF108B584
+gpg: key 3353C9CEF108B584: "Michael Roth <michael.roth@amd.com>" not changed
+gpg: Total number processed: 1
+gpg:              unchanged: 1
+```
+
+Export certificate to file:
+
+```bash
+gpg --export CEACC9E15534EBABB82D3FA03353C9CEF108B584 > mdroth.pgp
+```
+
+Show info about the certificate:
+
+```
+gpg --list-sigs CEACC9E15534EBABB82D3FA03353C9CEF108B584
+pub   rsa2048 2013-10-18 [SC] [expires: 2026-05-11]
+      CEACC9E15534EBABB82D3FA03353C9CEF108B584
+      Keygrip = D85EA26924D8B15B55C659659E2864C375F1547D
+uid           [ unknown] Michael Roth <michael.roth@amd.com>
+sig 3        3353C9CEF108B584 2020-10-27  [self-signature]
+sig 3        3353C9CEF108B584 2024-05-11  [self-signature]
+uid           [ unknown] Michael Roth <flukshun@gmail.com>
+sig 3        3353C9CEF108B584 2013-10-18  [self-signature]
+uid           [ unknown] Michael Roth <mdroth@utexas.edu>
+sig 3        3353C9CEF108B584 2013-10-18  [self-signature]
+sub   rsa2048 2013-10-18 [E]
+      Keygrip = 9561B09210E2442DEE64237DBA17A9E9D7A58B04
+sig          3353C9CEF108B584 2013-10-18  [self-signature]
+```
+
+Try verifying the tarball using gpg:
+
+```bash
+gpg --verify qemu-9.2.1.tar.xz.sig
+gpg: assuming signed data in 'qemu-9.2.1.tar.xz'
+gpg: Signature made 2025-02-12T03:22:55 CET
+gpg:                using RSA key CEACC9E15534EBABB82D3FA03353C9CEF108B584
+gpg: BAD signature from "Michael Roth <michael.roth@amd.com>" [unknown]
+```
+
+Try verifying the tarball using the SOP implementation rsop:
+
+```bash
+rsop verify qemu-9.2.1.tar.xz.sig mdroth.pgp < qemu-9.2.1.tar.xz
+           No acceptable signatures found
+```
+
+Try verifying the tarball using sq:
+
+```bash
+sq cert import mdroth.pgp
+ - ┌ CEACC9E15534EBABB82D3FA03353C9CEF108B584
+   └ Michael Roth <michael.roth@amd.com> (UNAUTHENTICATED)
+   - imported
+
+
+Imported 0 new certificates, updated 0 certificates, 1 certificate unchanged, 0 errors.
+
+sq verify --signature-file qemu-9.2.1.tar.xz.sig qemu-9.2.1.tar.xz
+Error verifying signature made by CEACC9E15534EBABB82D3FA03353C9CEF108B584:
+
+  Error: Message has been manipulated
+0 authenticated signatures, 1 bad signature.
+
+  Error: Verification failed: could not authenticate any signatures
+```
+Additional information:
+On Arch Linux we use the provided release tarball and verify it using the detached signature.
+For validation we rely on the OpenPGP certificate with the fingerprint `CEACC9E15534EBABB82D3FA03353C9CEF108B584`.
+The fingerprint is locked in our [build script](https://gitlab.archlinux.org/archlinux/packaging/packages/qemu/-/blob/7cddf5aa82542d6ba511a22aeaa8eca6d6e7d949/PKGBUILD#L158).
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2814 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2814
new file mode 100644
index 00000000..e3206952
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2814
@@ -0,0 +1 @@
+Convert gdb_core_xml_file to function for https://linaro.atlassian.net/browse/QEMU-487
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2818 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2818
new file mode 100644
index 00000000..0543a513
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2818
@@ -0,0 +1,7 @@
+Passing `-M microvm` and `-smbios type=11...` results in smbios args being silently dropped
+Description of problem:
+(reporting as requested by `danpb` on IRC)
+
+Using the `-machine microvm` flag with the `smbios type=11...` argument results in the smbios options being silently discarded, because the microvm target doesn't seem to support the smbios feature.
+
+danpb on IRC suggested that passing those two incompatible flags should result in an error.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/282 b/gitlab/issues_text/target_missing/host_missing/accel_missing/282
new file mode 100644
index 00000000..ed8c3dd4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/282
@@ -0,0 +1 @@
+[Feature request] Provide a way to do TLS first in QEMU/NBD connections (not after NBD negotiation)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2822 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2822
new file mode 100644
index 00000000..0c7a5e1a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2822
@@ -0,0 +1,11 @@
+Data race with state field of ThreadPoolElement
+Description of problem:
+A data race in the access of `ThreadPoolElement` state field in `util/thread-pool.c` was identified using TSAN.
+Steps to reproduce:
+```sh
+QEMU_BUILD_DIR=<path to the QEMU build directory>
+QEMU_DIR=<path to the QEMU repository directory>
+configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp
+make tests/unit/test-thread-pool
+MALLOC_PERTURB_=111 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-thread-pool --tap -k
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2824 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2824
new file mode 100644
index 00000000..97ed11e2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2824
@@ -0,0 +1 @@
+compile from source on macOS error: "found no usable tomli, please install it"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2825 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2825
new file mode 100644
index 00000000..5d778760
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2825
@@ -0,0 +1,37 @@
+execveat with file descriptor and empty filename returns ENOENT when cross architectures
+Description of problem:
+On my x86_64 debian host (with binfmt_misc configured), when calling execveat with a fd , and empty pathname "", and flag AT_EMPTY_PATH. Then only x86_64 and x86 can be called normally, while programs of other architectures (arm64, arm, riscv64, etc.) will return ENOENT errors.
+
+I first encountered this problem when trying to run lxc-attach with qemu-aarch64. Its reference is [lxc/stable-6.0/src/include/fexecve.c#L30](https://github.com/lxc/lxc/blob/stable-6.0/src/include/fexecve.c#L30), which is the implementation of the fexecve function. So I wrote a simple test and compiled it with `x86_64/aarch64-linux-gnu-gcc -static test.c -o test`. execveat works fine when running natively or using qemu-x86_64/qemu-i386. When running versions for other architectures, using AT_EMPTY_PATH will result in ENOENT (No such file or directory); use /proc/self/fd/%d as the pathname and execve, it will work fine (like the rest part of the fexecve function). If binfmt_misc is turned off and run forign architectures ver, both calls will result in ENOEXEC (Exec format error).
+Steps to reproduce:
+1. Install qemu-user and binfmt_misc. Install gcc-aarch64-linux-gnu/gcc-riscv64-linux-gnu etc.
+2. Compile test.c with host gcc, then compile forign architectures ver with gcc-aarch64-linux-gnu/gcc-riscv64-linux-gnu etc. like `gcc -static test.c -o test` and `aarch64-linux-gnu-gcc -static test.c -o test-aarch64`
+3. Run different versions of test
+4. To disable/enable binfmt, you can `echo 0 > /proc/sys/fs/binfmt_misc/qemu-aarch64` or `echo 1 > /proc/sys/fs/binfmt_misc/qemu-aarch64`
+5. Sample outputs
+
+```
+rrex@debian:~/Downloads$ ./test
+****Running to prepare execve
+fd=3
+File size: 772296 bytes
+
+execveat with AT_EMPTY_PATH:
+**Running in execve
+
+execveat with fd path: /proc/self/fd/3
+**Running in execve
+
+rrex@debian:~/Downloads$ qemu-aarch64 ./test-aarch64 
+****Running to prepare execve
+fd=3
+File size: 706104 bytes
+
+execveat with AT_EMPTY_PATH:
+!!execveat a fd failed with errno: No such file or directory
+
+execveat with fd path: /proc/self/fd/3
+**Running in execve
+```
+Additional information:
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2827 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2827
new file mode 100644
index 00000000..cb6a7ead
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2827
@@ -0,0 +1 @@
+Document how to use QEMU user mode networking with passt
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2829 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2829
new file mode 100644
index 00000000..393ee5a5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2829
@@ -0,0 +1,21 @@
+SMB sharing on FIPS enabled hosts with Samba broken
+Description of problem:
+Similar to #2593 , newer security features on GNU+Linux host OSes are continuing
+to break communication with guests running older OSes.
+
+QEMU executes the `smbd` process in [slirp.c](net/slirp.c) to facilitate the SMB
+sharing between guest and host.
+
+The host `smbd` process links in GnuTLS for authentication ciphers and algorithm
+primitives.  When `smbd` processes SMB requests from these older OS's SMB implementations,
+it errors out with error lines:
+
+`Failed to setup SPNEGO negTokenInit request`
+
+`Failed to start SPNEGO handler for negprot OID list!`
+Steps to reproduce:
+1. Access a GNU+Linux machine with GnuTLS library in FIPS mode which `smbd` links against
+2. Run `qemu-system-*` with an older guest OS with a `smb` share to host
+3. See errors in `/tmp/qemu.smb*/log.smbd`
+Additional information:
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2830 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2830
new file mode 100644
index 00000000..70c403bc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2830
@@ -0,0 +1 @@
+gdbstub: breakpoint/watchpoint increments warp timer on single-core icount mode, breaking determinism
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2831 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2831
new file mode 100644
index 00000000..c37dadd3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2831
@@ -0,0 +1,20 @@
+unable to build on Sequoia 15.3
+Description of problem:
+
+Steps to reproduce:
+1. git clone https://gitlab.com/qemu-project/qemu.git
+2. ../configure --target-list=riscv32-softmmu --enable-debug
+3. make
+
+Error:
+ld: multiple errors: archive member '/' not a mach-o file in '../qemu/build/subprojects/dtc/libfdt/libfdt.a'; archive member '/' not a mach-o file in '../qemu/build/libqemuutil.a'
+Additional information:
+I tried the more detailed "build for macos" instructions 
+./configure --cc=clang-7 --cxx=clang++-7 --host-cc=clang-7 \
+--extra-cflags=-mavx2 \
+--extra-cxxflags="-I/usr/local/opt/llvm/include" \
+--extra-ldflags="-L/usr/local/opt/llvm/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib" \
+--target-list="<list of machines here>"
+
+but this didn't work for any version of clang I tried, giving me the error in all cases:
+ERROR: C compiler "clang-xxx" either does not exist or does not work.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2835 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2835
new file mode 100644
index 00000000..f7fc4200
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2835
@@ -0,0 +1,122 @@
+qtest-x86_64/migration-test times out (hangs?)
+Description of problem:
+The `qemu:qtest+qtest-x86_64 / qtest-x86_64/migration-test` always times out, after updating QEMU from 8.2.2 to 9.1.3 on GNU Guix.  Here's an excerpt from testlog.txt, attached in full below:
+```
+test:         qemu:qtest+qtest-x86_64 / qtest-x86_64/migration-test
+start time:   15:24:17
+duration:     480.01s
+result:       killed by signal 15 SIGTERM
+command:      QTEST_QEMU_BINARY=./qemu-system-x86_64 MESON_TEST_ITERATION=1 MALLOC_PERTURB_=66 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 PYTHON=/tmp/guix-build-qemu-9.1.3.drv-0/qemu-9.1.3/b/qemu/pyvenv/bin/python3 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_IMG=./qemu-img MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 G_TEST_DBUS_DAEMON=/tmp/guix-build-qemu-9.1.3.drv-0/qemu-9.1.3/tests/dbus-vmstate-daemon.sh UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 /tmp/guix-build-qemu-9.1.3.drv-0/qemu-9.1.3/b/qemu/tests/qtest/migration-test --tap -k
+----------------------------------- stdout -----------------------------------
+TAP version 13
+# random seed: R02S840f7fe2af5c1c1e5b9ead2a7f451731
+# Skipping test: userfaultfd not available
+1..56
+# Start of x86_64 tests
+# Start of migration tests
+# Running /x86_64/migration/bad_dest
+# Using machine type: pc-q35-9.1
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1    2>/dev/null -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming tcp:127.0.0.1:0 -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1    2>/dev/null -accel qtest
+ok 1 /x86_64/migration/bad_dest
+# slow test /x86_64/migration/bad_dest executed in 0.60 secs
+# Running /x86_64/migration/analyze-script
+# Using machine type: pc-q35-9.1
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1   -uuid 11111111-1111-1111-1111-111111111111  -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming tcp:127.0.0.1:0 -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+ok 2 /x86_64/migration/analyze-script
+# slow test /x86_64/migration/analyze-script executed in 0.88 secs
+# Running /x86_64/migration/vmstate-checker-script
+ok 3 /x86_64/migration/vmstate-checker-script # SKIP Test needs two different QEMU versions
+# Running /x86_64/migration/validate_uuid
+# Using machine type: pc-q35-9.1
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1   -uuid 11111111-1111-1111-1111-111111111111  -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1   -uuid 11111111-1111-1111-1111-111111111111  -accel qtest
+ok 4 /x86_64/migration/validate_uuid
+# slow test /x86_64/migration/validate_uuid executed in 32.74 secs
+# Running /x86_64/migration/validate_uuid_error
+# Using machine type: pc-q35-9.1
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1   -uuid 11111111-1111-1111-1111-111111111111 2>/dev/null -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1   -uuid 22222222-2222-2222-2222-222222222222 2>/dev/null -accel qtest
+ok 5 /x86_64/migration/validate_uuid_error
+# slow test /x86_64/migration/validate_uuid_error executed in 32.62 secs
+# Running /x86_64/migration/validate_uuid_src_not_set
+# Using machine type: pc-q35-9.1
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1    2>/dev/null -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1   -uuid 22222222-2222-2222-2222-222222222222 2>/dev/null -accel qtest
+ok 6 /x86_64/migration/validate_uuid_src_not_set
+# slow test /x86_64/migration/validate_uuid_src_not_set executed in 32.73 secs
+# Running /x86_64/migration/validate_uuid_dst_not_set
+# Using machine type: pc-q35-9.1
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1   -uuid 11111111-1111-1111-1111-111111111111 2>/dev/null -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1    2>/dev/null -accel qtest
+ok 7 /x86_64/migration/validate_uuid_dst_not_set
+# slow test /x86_64/migration/validate_uuid_dst_not_set executed in 32.74 secs
+# Running /x86_64/migration/dirty_ring
+# Using machine type: pc-q35-9.1
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm,dirty-ring-size=4096 -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm,dirty-ring-size=4096 -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+ok 8 /x86_64/migration/dirty_ring
+# slow test /x86_64/migration/dirty_ring executed in 33.89 secs
+# Running /x86_64/migration/vcpu_dirty_limit
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm,dirty-ring-size=4096 -name dirtylimit-test,debug-threads=on -m 150M -smp 1 -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/vm_serial -drive file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw  -accel qtest
+ok 9 /x86_64/migration/vcpu_dirty_limit
+# slow test /x86_64/migration/vcpu_dirty_limit executed in 13.17 secs
+# Start of precopy tests
+# Running /x86_64/migration/precopy/file
+# Using machine type: pc-q35-9.1
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming defer -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+ok 10 /x86_64/migration/precopy/file
+# slow test /x86_64/migration/precopy/file executed in 33.10 secs
+# Start of unix tests
+# Running /x86_64/migration/precopy/unix/plain
+# Using machine type: pc-q35-9.1
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+ok 11 /x86_64/migration/precopy/unix/plain
+# slow test /x86_64/migration/precopy/unix/plain executed in 33.89 secs
+# Running /x86_64/migration/precopy/unix/xbzrle
+# Using machine type: pc-q35-9.1
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+ok 12 /x86_64/migration/precopy/unix/xbzrle
+# slow test /x86_64/migration/precopy/unix/xbzrle executed in 59.80 secs
+# Start of suspend tests
+# Running /x86_64/migration/precopy/unix/suspend/live
+# Using machine type: pc-q35-9.1
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+ok 13 /x86_64/migration/precopy/unix/suspend/live
+# slow test /x86_64/migration/precopy/unix/suspend/live executed in 65.90 secs
+# Running /x86_64/migration/precopy/unix/suspend/notlive
+# Using machine type: pc-q35-9.1
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+ok 14 /x86_64/migration/precopy/unix/suspend/notlive
+# slow test /x86_64/migration/precopy/unix/suspend/notlive executed in 65.09 secs
+# End of suspend tests
+# Start of tls tests
+# Running /x86_64/migration/precopy/unix/tls/psk
+# Using machine type: pc-q35-9.1
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+ok 15 /x86_64/migration/precopy/unix/tls/psk
+# slow test /x86_64/migration/precopy/unix/tls/psk executed in 33.28 secs
+# Start of x509 tests
+# Running /x86_64/migration/precopy/unix/tls/x509/default-host
+# Using machine type: pc-q35-9.1
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1    2>/dev/null -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1    2>/dev/null -accel qtest
+ok 16 /x86_64/migration/precopy/unix/tls/x509/default-host
+# slow test /x86_64/migration/precopy/unix/tls/x509/default-host executed in 0.78 secs
+# Running /x86_64/migration/precopy/unix/tls/x509/override-host
+# Using machine type: pc-q35-9.1
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1     -accel qtest
+==============================================================================
+```
+Steps to reproduce:
+1. Run `make check`
+Additional information:
+[testlog.txt.gz](/uploads/29c9c4f259b255297a6418e8f7493397/testlog.txt.gz)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2836 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2836
new file mode 100644
index 00000000..51ea21f2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2836
@@ -0,0 +1,43 @@
+readconfig with [vnc] only causes assertion failure
+Description of problem:
+Given test.config containing
+```
+[vnc]
+```
+
+```
+$ qemu-system-amd64 -readconfig test.config
+qemu-system-amd64: ui/vnc.c:4294: vnc_init_func: Assertion `id' failed.
+Aborted
+```
+
+
+```
+(gdb) bt
+#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0)
+    at ./nptl/pthread_kill.c:44
+#1  0x00007ffff68f3e2f in __pthread_kill_internal (threadid=<optimized out>, signo=6) at ./nptl/pthread_kill.c:78
+#2  0x00007ffff689fd02 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
+#3  0x00007ffff68884f0 in __GI_abort () at ./stdlib/abort.c:79
+#4  0x00007ffff6888418 in __assert_fail_base (fmt=0x7ffff6a0cca0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
+    assertion=assertion@entry=0x55555608eef6 "id", file=file@entry=0x555556068a5e "ui/vnc.c", line=line@entry=4294,
+    function=function@entry=0x5555561c3fe0 <__PRETTY_FUNCTION__.0> "vnc_init_func") at ./assert/assert.c:96
+#5  0x00007ffff6898612 in __assert_fail (assertion=assertion@entry=0x55555608eef6 "id",
+    file=file@entry=0x555556068a5e "ui/vnc.c", line=line@entry=4294,
+    function=function@entry=0x5555561c3fe0 <__PRETTY_FUNCTION__.0> "vnc_init_func") at ./assert/assert.c:105
+#6  0x0000555555a03adb in vnc_init_func (opaque=<optimized out>, opts=<optimized out>,
+    errp=0x5555570db038 <error_fatal>) at ui/vnc.c:4294
+#7  0x0000555556037b31 in qemu_opts_foreach (list=<optimized out>, func=0x555555a039f0 <vnc_init_func>,
+    opaque=opaque@entry=0x0, errp=errp@entry=0x5555570db038 <error_fatal>) at util/qemu-option.c:1135
+#8  0x0000555555c41eff in qemu_init_displays () at system/vl.c:2619
+#9  qemu_init (argc=<optimized out>, argv=<optimized out>) at system/vl.c:3762
+#10 0x00005555559e1c0d in main (argc=<optimized out>, argv=<optimized out>) at system/main.c:47
+```
+
+https://gitlab.com/qemu-project/qemu/-/blob/master/ui/vnc.c#L4294
+
+Passing an invalid value to id results in `qemu-system-amd64: -readconfig test.config: Parameter 'id' expects an identifier
+Identifiers consist of letters, digits, '-', '.', '_', starting with a letter.` so perhaps a missing value should cause a similar error?
+
+
+PS: Where's the documentation for `-readconfig`?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2837 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2837
new file mode 100644
index 00000000..f71242d6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2837
@@ -0,0 +1 @@
+qcow2 corruption MinGW64
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2838 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2838
new file mode 100644
index 00000000..e78e3133
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2838
@@ -0,0 +1,8 @@
+searchindex.js in HTML doc is not reproducible
+Description of problem:
+Builds should be reproducible, at least when `SOURCE_DATE_EPOCH` set to some value (see: <https://reproducible-builds.org/docs/source-date-epoch/>), but the QEMU HTML doc contains a file which isn't reproducible.
+Steps to reproduce:
+1. `guix build --no-grafts qemu && guix build --no-grafts --check --keep-failed qemu`
+2. `diffoscope /gnu/store/3kym1ykv9r8n0hgbihqllch9ph136zx1-qemu-8.2.2-doc{,-check}`
+Additional information:
+[diffoscope-log.txt](/uploads/ab19f184082f343635df4fa7ef26b12e/diffoscope-log.txt)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2839 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2839
new file mode 100644
index 00000000..0bd8d286
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2839
@@ -0,0 +1,35 @@
+Physical memory usage spikes after migration for a VM using memory-backend-memfd memory
+Description of problem:
+When starting a virtual machine using the memory-backend-memfd type memory, configuring the virtual machine memory to 256GB or any other size, the QEMU process initially allocates only a little over 4GB of physical memory. However, after migrating the virtual machine, the physical memory occupied by the QEMU process almost equals 256GB. In an overcommitted memory environment, the increase in physical memory usage by the virtual machine can lead to insufficient host memory, triggering Out-Of-Memory (OOM).
+Steps to reproduce:
+1. start vm
+./qemu-system-x86_64  -accel kvm -cpu SandyBridge  -object memory-backend-memfd,id=mem1,size=256G -machine memory-backend=mem1  -smp 4  -drive file=/nvme0n1/luzhipeng/fusionos.qcow2,if=none,id=drive0,cache=none  -device virtio-blk,drive=drive0,bootindex=1  -monitor stdio -vnc :0
+2. start vm on another host
+./qemu-system-x86_64  -accel kvm -cpu SandyBridge  -object memory-backend-memfd,id=mem1,size=256G -machine memory-backend=mem1  -smp 4  -drive file=/nvme0n1/luzhipeng/fusionos.qcow2,if=none,id=drive0,cache=none  -device virtio-blk,drive=drive0,bootindex=1  -monitor stdio -vnc :0 -incoming tcp:0.0.0.0:4444
+3. migrate vm
+migrate -d tcp:xx.xx.xx.xx:4444
+4.
+Check QEMU process memory usage with the top command
+
+```
+top - 14:01:05 up 35 days, 20:16,  2 users,  load average: 0.22, 0.23, 0.18
+Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
+%Cpu(s):  0.2 us,  0.1 sy,  0.0 ni, 99.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
+MiB Mem : 514595.3 total,   2642.6 free, 401703.3 used, 506435.3 buff/cache
+MiB Swap:      0.0 total,      0.0 free,      0.0 used. 112892.0 avail Mem
+
+    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
+3865345 root      20   0  257.7g 256.1g 256.0g S   1.3  51.0   3:14.44 qemu-system-x86
+```
+Additional information:
+```
+The relevant code:
+void ram_handle_zero(void *host, uint64_t size)
+{
+    if (!buffer_is_zero(host, size)) {
+        memset(host, 0, size);
+    }
+}
+```
+
+In the memory migration process, for the migration of zero pages, the destination side calls buffer_is_zero to check whether the corresponding page is entirely zero. If it is not zero, it actively sets it as a full page. For memory of the memfd type, the first access will allocate physical memory, resulting in physical memory allocation for all zero pages of the virtual machine.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/284 b/gitlab/issues_text/target_missing/host_missing/accel_missing/284
new file mode 100644
index 00000000..89727856
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/284
@@ -0,0 +1 @@
+Assertion failed: (buf_len != 0), function soread, file socket.c, line 183.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2840 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2840
new file mode 100644
index 00000000..e8f1d39a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2840
@@ -0,0 +1,21 @@
+After converting the Windows 10 system disk from qcow2 to LUKS format with pre-allocated space, the system fails to boot
+Description of problem:
+When converting a qcow2 file containing an installed Windows 10 system to LUKS format, using the --target-is-zero parameter in the conversion command prevents the LUKS image from shrinking. However, when attempting to boot the virtual machine with the converted LUKS file, VNC login shows a black screen, and the system fails to start. If the conversion is performed without the --target-is-zero parameter, the system boots up normally
+Steps to reproduce:
+1. create a luks image
+qemu-img create -f qcow2 --object secret,data=123,id=sec0 -o preallocation=full,encrypt.format=luks,encrypt.key-secret=sec0 encry_ok.qcow2 50G
+2.
+qemu-img convert -t none -T none --object secret,id=sec0,data=123 -f qcow2 ./windows10.qcow2  -n -m 1 --target-image-opts driver=qcow2,encrypt.key-secret=sec0,file.filename=encry_ok.qcow2 --target-is-zero
+
+windows10.qcow2 container windows20 system and  it can be booted
+3.
+./qemu-system-x86_64  -accel kvm -cpu SandyBridge  -object memory-backend-memfd,id=mem1,size=4G -machine memory-backend=mem1  -smp 4  -object secret,id=sec0,data=123,format=raw -drive if=none,driver=qcow2,file.filename=/sdc1/luzhipeng/encry_ok.qcow2,encrypt.key-secret=sec0,id=drive0,cache=none  -device virtio-blk,drive=drive0,bootindex=1  -monitor stdio -vnc :4
+
+4. vnc shows a black screen, and the system fails to start
+
+5. if use convert command:
+qemu-img convert -t none -T none --object secret,id=sec0,data=123 -f qcow2 ./windows10.qcow2  -n -m 1 --target-image-opts driver=qcow2,encrypt.key-secret=sec0,file.filename=encry_ok.qcow2
+
+6. the windows10 system can start successful
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2841 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2841
new file mode 100644
index 00000000..f7b29cba
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2841
@@ -0,0 +1,11 @@
+QEMU is increasing memory swap, the only solution is to reboot after a freeze.
+Description of problem:
+Swap starts increasing suddenly and gets to around  60GB before laptop freezes and “dies”.
+Steps to reproduce:
+Seemingly random, didn’t notice any pattern.. it just started happening more often.
+
+![image__2_](/uploads/70d007253835b2dafe17352f8facf0f8/image__2_.png)
+
+![image__4_](/uploads/0cde47d15ec6f988a0aa46dd4af3f799/im
+
+![image__3_](/uploads/f88a567693807d046e048ac6b3deab5a/image__3_.png)age__4_.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2843 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2843
new file mode 100644
index 00000000..7515128b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2843
@@ -0,0 +1,33 @@
+Strange stdin/out <-> console issue (paste problem) . May be char-win-stdio.c bug.
+Description of problem:
+I was trying to execute QEMU with VM from command line(shell) and work inside a VM within that initial console. All goes well except... pasting from clipboard. Pastings from clipboard are truncated to somewhat less (no more) then a terminal width (in columns).
+
+I understand that it seems to be far from QEMU but I tried different terminals/shells/guest systems with the same result. The only things remain the same - QEMU.
+Steps to reproduce:
+In Windows open a console (shell). Run QEMU with guest serial attached to QEMU stdio. Try to paste some text. Pasted text will be truncated to 15-35 characters. Before QEMU run and after QEMU exit text pasted normally.
+Additional information:
+-  Shell probed: **cmd**, **powershell**
+- Terminals probed: **Windows Terminal**, **Alacritty**, **Wezterm**, **Windows Terminal Preview**
+- Guest probed: **Alpine Linux**, **FreeBSD**
+- Setting inside guest probed: various terminal speed/options via **stty**
+- QEMU arguments probed: from **-nographics** to manually define **-chardev/-serial** with/without **-mon**.
+
+Finally I gave up. But want to mention that there are may be bug in source. When I tried to study source to find a hint for my issue I found that (char-win-stdio.c, line 162):
+```
+is_console = GetConsoleMode(stdio->hStdIn, &dwMode) != 0;
+    stdio->dwOldMode = dwMode;
+
+    if (is_console) {
+```
+
+Documentation of **GetConsoleMode** function says:
+```
+Return value:
+
+If the function succeeds, the return value is nonzero.
+If the function fails, the return value is zero.
+```
+
+If understand correctly **is_console** will always be _true_. It will be _false_ only in case of invalid **stdio->hStdIn**.
+
+I don't how this is related to my issue just put here all info I have in hope of resolving.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2845 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2845
new file mode 100644
index 00000000..2e7f6360
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2845
@@ -0,0 +1,32 @@
+memory leak in virtio-pci devices
+Description of problem:
+The Use-After-Free bug mentioned by #2440 **has not been solved**, but the same crash is not reproducable in the later versions. After reviewing the code, I found an initiailized address space `proxy->modern_cfg_mem_as` introduced by  [`55fa4be`](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-sandbox/workbench/workbench.html "Inspect Commit Details") in `virtio_pci@hw/virtio/virtio-pci.c` will not be destroyed if the later realization is failed. 
+This will cause memory leak of the device object, which has unused reference and will not be destroyed.
+
+Relative Code in `virtio_pci_realize@virtio-pci.c`:
+
+```c
+/* subclasses can enforce modern, so do this unconditionally */
+memory_region_init(&proxy->modern_bar, OBJECT(proxy), "virtio-pci",
+                    /* PCI BAR regions must be powers of 2 */
+                    pow2ceil(proxy->notify.offset + proxy->notify.size));
+
+address_space_init(&proxy->modern_cfg_mem_as, &proxy->modern_bar,
+                    "virtio-pci-cfg-mem-as");
+
+if (proxy->disable_legacy == ON_OFF_AUTO_AUTO) {
+    proxy->disable_legacy = pcie_port ? ON_OFF_AUTO_ON : ON_OFF_AUTO_OFF;
+}
+```
+Steps to reproduce:
+```bash
+cat <<EOF | qemu-system-i386 -M q35 -nodefaults -chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0
+device_add virtio-net,failover=on,rx_queue_size=0,bus=br1,id=dev0
+device_add virtio-net,failover=on,bus=br1,id=dev0
+quit
+EOF
+```
+
+**This will cause UAF report in version `9.0.2`, but will not in `9.2.0`,** despite the bug still existing in code.
+Additional information:
+For ASAN report, please refer to #2440.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2846 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2846
new file mode 100644
index 00000000..c10e0f7f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2846
@@ -0,0 +1 @@
+linux-user hangs if fd_trans_lock is held during fork
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2847 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2847
new file mode 100644
index 00000000..a04cb041
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2847
@@ -0,0 +1 @@
+Provide short option for UEFI firmware
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2849 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2849
new file mode 100644
index 00000000..b74f6dfb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2849
@@ -0,0 +1,18 @@
+Qemu 9.2.x & Ubuntu 24.04 Network Issue
+Description of problem:
+After successfully starting, I cannot access the Internet with the virtual machine. I can connect to the VM via SSH and execute various commands. We want a simple NAT network..
+
+We built the Qemu distribution ourselves with the following command:
+
+./configure --target-list=x86_64-softmmu --disable-install-blobs --enable-strip --enable-user --enable-system --enable-linux-user --disable-xen --enable-modules --enable-module-upgrades --enable-linux-aio --enable-fdt --enable-gnutls --enable-libiscsi --enable-libssh --enable-vnc --enable-kvm --enable-vhost-user
+make -j 12
+sudo make install
+
+Check Libvirt:
+$systemctl status libvirtd - active
+
+after the VM was successfully started, the IP 10.2.15 was set to ens3 altname enp0s3 assign.
+
+A ping to 8.8.8.8 can not be resolved.
+Additional information:
+We can rule out an image problem because this image runs without problems on the Windows Mac guest system and an Internet connection is possible.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2850 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2850
new file mode 100644
index 00000000..6e64bfc7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2850
@@ -0,0 +1,3 @@
+Available in a version for Windows on arm
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2851 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2851
new file mode 100644
index 00000000..1689e318
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2851
@@ -0,0 +1,51 @@
+Assert failure in ../util/error.c:68: void error_setv()
+Description of problem:
+If bdrv_snapshot_goto() returns an error, it is not handled immediately,
+allowing *errp to be reassigned when qcow_open() fails, which triggers
+assert(*errp == NULL) in util/error.c: void error_setv().
+Steps to reproduce:
+1. [test.qed](/uploads/17005dfba241f5a355e3592e12e356f6/test.qed)
+2. ./qemu-img snapshot -q -a test test.qed
+Additional information:
+<details>
+<pre>
+qemu-img-fuzz: ../util/error.c:68: void error_setv(Error **, const char *, int, const char *, ErrorClass, const char *, struct __va_list_tag *, const char *): Assertion `*errp == NULL' failed.
+==20841== ERROR: libFuzzer: deadly signal
+    #0 0x56384b84a46a in __sanitizer_print_stack_trace /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_stack.cpp:86:3
+    #1 0x56384b79bb79 in fuzzer::PrintStackTrace() /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x56384b77d5a6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:18
+    #3 0x56384b77d667 in fuzzer::Fuzzer::CrashCallback() /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:205:1
+    #4 0x56384b77d667 in fuzzer::Fuzzer::StaticCrashSignalCallback() /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:204:19
+    #5 0x7effd07c09df  (/lib64/libpthread.so.0+0x139df)
+    #6 0x7effcf659450 in raise (/lib64/libc.so.6+0x3d450)
+    #7 0x7effcf642547 in abort (/lib64/libc.so.6+0x26547)
+    #8 0x7effcf642430  (/lib64/libc.so.6+0x26430)
+    #9 0x7effcf651ce1 in __assert_fail (/lib64/libc.so.6+0x35ce1)
+    #10 0x56384bf211dc in error_setv /home/gerben/qemu-img_fuzz/build/../util/error.c:68:5
+    #11 0x56384bf213fc in error_setg_internal /home/gerben/qemu-img_fuzz/build/../util/error.c:105:5
+    #12 0x56384bb2b71f in qcow_open /home/gerben/qemu-img_fuzz/build/../block/qcow.c:306:5
+    #13 0x56384bb17654 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:299:20
+    #14 0x56384bdd52c1 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img-wrapper.c:3476:15
+    #15 0x56384bdbcede in qemu_img_main /home/gerben/qemu-img_fuzz/build/../qemu-img-wrapper.c:5624:20
+    #16 0x56384bdb6e7d in command_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img_fuzz.c:309:20
+    #17 0x56384bdb6e7d in generator_command /home/gerben/qemu-img_fuzz/build/../qemu-img_fuzz.c:1285:17
+    #18 0x56384bdaf718 in LLVMFuzzerTestOneInput /home/gerben/qemu-img_fuzz/build/../qemu-img_fuzz.c:1303:5
+    #19 0x56384b77e1c8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:559:17
+    #20 0x56384b781af0 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:471:18
+    #21 0x56384b784796 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:771:13
+    #22 0x56384b784c7e in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:800:28
+    #23 0x56384b76bb57 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:847:10
+    #24 0x56384b758fe2 in main /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #25 0x7effcf643efc in __libc_start_main (/lib64/libc.so.6+0x27efc)
+    #26 0x56384b759089 in _start /usr/src/RPM/BUILD/glibc-2.32-alt5.p10.3/csu/../sysdeps/x86_64/start.S:120
+
+NOTE: libFuzzer has rudimentary signal handlers.
+      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
+SUMMARY: libFuzzer: deadly signal
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+0x2b,0x25,0xff,0xff,0xff,0xff,0x3a,0x9a,0xc9,0xff,0xa,
++%\xff\xff\xff\xff:\x9a\xc9\xff\x0a
+artifact_prefix='./'; Test unit written to ./crash-e9c4f1b8a97ffa93544e87a5a819ac524aa82029
+Base64: KyX/////OprJ/wo=
+</pre>
+</details>
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2852 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2852
new file mode 100644
index 00000000..72efa286
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2852
@@ -0,0 +1,80 @@
+heap-use-after-free in timer_pending()
+Description of problem:
+In the QED block driver, the need_check_timer timer is freed in
+bdrv_qed_detach_aio_context, but the pointer to the timer is not
+set to NULL. This can lead to a use-after-free scenario
+in bdrv_qed_drain_begin().
+Steps to reproduce:
+1. [test.qed](/uploads/c8820345bfcd562308da99d9f83df3cf/test.qed)
+2. ./qemu-img snapshot -q -a test test.qed
+Additional information:
+<details>
+<pre>
+./qemu-img snapshot -q -a test test.qed
+==21083==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+=================================================================
+==21083==ERROR: AddressSanitizer: heap-use-after-free on address 0x60400004ca50 at pc 0x56050d1462b6 bp 0x7fff14d0d870 sp 0x7fff14d0d868
+READ of size 8 at 0x60400004ca50 thread T0
+    #0 0x56050d1462b5 in timer_pending /home/gerben/qemu-img_fuzz/build/../util/qemu-timer.c:483:16
+    #1 0x56050cddf82e in bdrv_qed_drain_begin /home/gerben/qemu-img_fuzz/build/../block/qed.c:378:32
+    #2 0x56050cb9bb65 in bdrv_do_drained_begin /home/gerben/qemu-img_fuzz/build/../block/io.c:364:13
+    #3 0x56050cb9ca03 in bdrv_drain_all_begin_nopoll /home/gerben/qemu-img_fuzz/build/../block/io.c:506:9
+    #4 0x56050cb96318 in bdrv_graph_wrlock /home/gerben/qemu-img_fuzz/build/../block/graph-lock.c:116:5
+    #5 0x56050cd0cbc4 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:294:9
+    #6 0x56050cf95dd2 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3500:15
+    #7 0x7f4adeddbefc in __libc_start_main (/lib64/libc.so.6+0x27efc)
+    #8 0x56050c96a9f9 in _start /usr/src/RPM/BUILD/glibc-2.32-alt5.p10.3/csu/../sysdeps/x86_64/start.S:120
+
+0x60400004ca50 is located 0 bytes inside of 48-byte region [0x60400004ca50,0x60400004ca80)
+freed by thread T0 here:
+    #0 0x56050ca0daef in free /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3
+    #1 0x56050cde6b86 in bdrv_qed_do_close /home/gerben/qemu-img_fuzz/build/../block/qed.c:619:5
+    #2 0x56050cddbe85 in bdrv_qed_close /home/gerben/qemu-img_fuzz/build/../block/qed.c:639:5
+    #3 0x56050cd0cbb2 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:290:13
+    #4 0x56050cf95dd2 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3500:15
+    #5 0x7f4adeddbefc in __libc_start_main (/lib64/libc.so.6+0x27efc)
+
+previously allocated by thread T0 here:
+    #0 0x56050ca0dfa7 in calloc /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3
+    #1 0x7f4adf359670 in g_malloc0 (/lib64/libglib-2.0.so.0+0x5c670)
+    #2 0x56050cde4bd0 in bdrv_qed_do_open /home/gerben/qemu-img_fuzz/build/../block/qed.c:543:5
+    #3 0x56050cde21a2 in bdrv_qed_open_entry /home/gerben/qemu-img_fuzz/build/../block/qed.c:569:16
+    #4 0x56050d137706 in coroutine_trampoline /home/gerben/qemu-img_fuzz/build/../util/coroutine-ucontext.c:175:9
+    #5 0x7f4adee066cf  (/lib64/libc.so.6+0x526cf)
+
+SUMMARY: AddressSanitizer: heap-use-after-free /home/gerben/qemu-img_fuzz/build/../util/qemu-timer.c:483:16 in timer_pending
+Shadow bytes around the buggy address:
+  0x0c08800018f0: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
+  0x0c0880001900: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
+  0x0c0880001910: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
+  0x0c0880001920: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fd
+  0x0c0880001930: fa fa 00 00 00 00 01 fa fa fa 00 00 00 00 00 fa
+=>0x0c0880001940: fa fa 00 00 00 00 00 fa fa fa[fd]fd fd fd fd fd
+  0x0c0880001950: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c0880001960: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c0880001970: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c0880001980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c0880001990: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+Shadow byte legend (one shadow byte represents 8 application bytes):
+  Addressable:           00
+  Partially addressable: 01 02 03 04 05 06 07 
+  Heap left redzone:       fa
+  Freed heap region:       fd
+  Stack left redzone:      f1
+  Stack mid redzone:       f2
+  Stack right redzone:     f3
+  Stack after return:      f5
+  Stack use after scope:   f8
+  Global redzone:          f9
+  Global init order:       f6
+  Poisoned by user:        f7
+  Container overflow:      fc
+  Array cookie:            ac
+  Intra object redzone:    bb
+  ASan internal:           fe
+  Left alloca redzone:     ca
+  Right alloca redzone:    cb
+  Shadow gap:              cc
+==21083==ABORTING
+</pre>
+</details>
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2853 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2853
new file mode 100644
index 00000000..cf0fb182
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2853
@@ -0,0 +1,54 @@
+double-free in vmdk_add_extent()
+Description of problem:
+A double-free issue in the VMDK driver occurs when handling snapshots.
+The memory allocated for extent structures is freed twice: first in
+vmdk_close (block/vmdk.c) and then in vmdk_add_extent (block/vmdk.c).
+Steps to reproduce:
+1. [test.raw](/uploads/deeb9dc3cab1916adadd211173cd175a/test.raw)
+2. ./qemu-img snapshot -q -a test test.raw
+Additional information:
+<details>
+<pre>
+./qemu-img snapshot -q -a test  test.raw
+==18180==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+=================================================================
+==18180==ERROR: AddressSanitizer: attempting double-free on 0x612000011bc0 in thread T0:
+    #0 0x5605ba505168 in realloc /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
+    #1 0x7f22be5fd6b7 in g_realloc (/lib64/libglib-2.0.so.0+0x5c6b7)
+    #2 0x5605ba866a79 in vmdk_add_extent /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:570:18
+    #3 0x5605ba86122e in vmdk_open_vmdk4 /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1059:11
+    #4 0x5605ba86122e in vmdk_open_sparse /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1127:20
+    #5 0x5605ba85723a in vmdk_open /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1371:19
+    #6 0x5605ba803ca4 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:299:20
+    #7 0x5605baa8cdd2 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3500:15
+    #8 0x7f22bd559efc in __libc_start_main (/lib64/libc.so.6+0x27efc)
+    #9 0x5605ba4619f9 in _start /usr/src/RPM/BUILD/glibc-2.32-alt5.p10.3/csu/../sysdeps/x86_64/start.S:120
+
+0x612000011bc0 is located 0 bytes inside of 272-byte region [0x612000011bc0,0x612000011cd0)
+freed by thread T0 here:
+    #0 0x5605ba504aef in free /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3
+    #1 0x5605ba857e6d in vmdk_close /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:2889:5
+    #2 0x5605ba803bb2 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:290:13
+    #3 0x5605baa8cdd2 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3500:15
+    #4 0x7f22bd559efc in __libc_start_main (/lib64/libc.so.6+0x27efc)
+
+previously allocated by thread T0 here:
+    #0 0x5605ba505168 in realloc /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
+    #1 0x7f22be5fd6b7 in g_realloc (/lib64/libglib-2.0.so.0+0x5c6b7)
+    #2 0x5605ba86122e in vmdk_open_vmdk4 /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1059:11
+    #3 0x5605ba86122e in vmdk_open_sparse /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1127:20
+    #4 0x5605ba85723a in vmdk_open /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1371:19
+    #5 0x5605ba56e3a2 in bdrv_open_driver /home/gerben/qemu-img_fuzz/build/../block.c:1660:15
+    #6 0x5605ba57ea50 in bdrv_open_common /home/gerben/qemu-img_fuzz/build/../block.c:1985:11
+    #7 0x5605ba57ea50 in bdrv_open_inherit /home/gerben/qemu-img_fuzz/build/../block.c:4153:11
+    #8 0x5605ba585cb8 in bdrv_open /home/gerben/qemu-img_fuzz/build/../block.c:4248:12
+    #9 0x5605ba637d4c in blk_new_open /home/gerben/qemu-img_fuzz/build/../block/block-backend.c:457:10
+    #10 0x5605baa9193b in img_open_file /home/gerben/qemu-img_fuzz/build/../qemu-img.c:405:11
+    #11 0x5605baa9143e in img_open /home/gerben/qemu-img_fuzz/build/../qemu-img.c:450:15
+    #12 0x5605baa8cc71 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3468:11
+    #13 0x7f22bd559efc in __libc_start_main (/lib64/libc.so.6+0x27efc)
+
+SUMMARY: AddressSanitizer: double-free /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3 in realloc
+==18180==ABORTING
+</pre>
+</details>
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2854 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2854
new file mode 100644
index 00000000..70c3d3bf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2854
@@ -0,0 +1,24 @@
+https://www.qemu.org/ is missing chance to provide (or at least link) some starting guide
+Description of problem:
+as a completely new (potential) user https://www.qemu.org/ main page is missing chance to easily link some hello world documentation
+Steps to reproduce:
+1. open https://www.qemu.org/
+2. try to click "Full-system emulation" with hope that it will link some starting hello world how to do so
+Additional information:
+On https://www.qemu.org/ you can click "support"
+
+Then you can click "documentation"
+
+Then "main documentation section"
+
+Then "system emulation"
+
+Then "introduction"
+
+At this point you have something that sort-of is viable as hello world.
+
+Maybe link https://www.qemu.org/docs/master/system/introduction.html from main page ("Full-system emulation")?
+
+Unless there is a better documentation?
+
+Though maybe someone who will not go through this link maze should not try to use QEMU at all?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2856 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2856
new file mode 100644
index 00000000..d8048b21
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2856
@@ -0,0 +1,90 @@
+segfault when passing x-vga=on on gpu(old) passthrough
+Description of problem:
+When using x-vga=on on the ati x550 gpu passthrough, qemu-system-x86 segfault occurs.(I think it may happen with other ati cards from same era, ati x300, ati x600, ati x800)
+Similar bug from 2017 on nvidia 7300GS:
+https://bugs.launchpad.net/qemu/+bug/1678466
+Additional information:
+```
+dmesg:
+[ 5050.113978] qemu-system-x86[8288]: segfault at b8 ip 000055c4f459ad47 sp 00007fff81f966e0 error 4 in qemu-system-x86_64[57ed47,55c
+4f418f000+69f000] likely on CPU 11 (core 20, socket 0)
+[ 5050.113987] Code: c0 75 f0 48 8b 6b 60 48 89 b3 80 00 00 00 67 e8 9f 82 00 00 48 8b 7b 40 83 05 b0 11 2e 01 01 48 85 ff 74 06 67 e
+8 59 1e 08 00 <48> 8b 85 b8 00 00 00 48 85 c0 74 7d 8b 93 b0 00 00 00 eb 11 0f 1f
+[ 5050.272446] vfio-pci 0000:07:00.0: Refused to change power state from D0 to D3hot
+```
+```
+lspci -vv:
+07:00.0 1002:5b63 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV370 [Radeon X300/X550/X1050 Series] (prog-if 00 [VGA controller])
+        Subsystem: PC Partner Limited / Sapphire Technology Device 1500
+        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
+        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
+        Interrupt: pin A routed to IRQ 3
+        IOMMU group: 18
+        Region 0: Memory at 54000000 (32-bit, prefetchable) [disabled] [size=64M]
+        Region 1: I/O ports at 3000 [disabled] [size=256]
+        Region 2: Memory at 59c30000 (32-bit, non-prefetchable) [disabled] [size=64K]
+        Expansion ROM at 59c00000 [disabled] [size=128K]
+        Capabilities: [50] Power Management version 2
+                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
+                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
+        Capabilities: [58] Express (v1) Endpoint, IntMsgNum 0
+                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us
+                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 10W TEE-IO-
+                DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+
+                        RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
+                        MaxPayload 128 bytes, MaxReadReq 128 bytes
+                DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
+                LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <128ns, L1 <1us
+                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
+                LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
+                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
+                LnkSta: Speed 2.5GT/s, Width x1 (downgraded)
+                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
+        Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit+
+                Address: 0000000000000000  Data: 0000
+        Capabilities: [100 v1] Advanced Error Reporting
+                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
+                        ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr-
+                        PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked-
+                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
+                        ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr-
+                        PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked-
+                UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
+                        ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr-
+                        PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked-
+                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CorrIntErr- HeaderOF-
+                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CorrIntErr- HeaderOF-
+                AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn-
+                        MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
+                HeaderLog: 04000001 0000030f 07070000 7efb9a03
+
+07:00.1 1002:5b73 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] RV370 [Radeon X300/X550/X1050 Series] (Secondary)
+        Subsystem: PC Partner Limited / Sapphire Technology Device 1501
+        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
+        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
+        IOMMU group: 18
+        Region 0: Memory at 59c20000 (32-bit, non-prefetchable) [disabled] [size=64K]
+        Capabilities: [50] Power Management version 2
+                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
+                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
+        Capabilities: [58] Express (v1) Endpoint, IntMsgNum 0
+                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us
+                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0W TEE-IO-
+                DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
+                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
+                        MaxPayload 128 bytes, MaxReadReq 128 bytes
+                DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
+                LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <128ns, L1 <1us
+                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
+                LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
+                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
+                LnkSta: Speed 2.5GT/s, Width x1 (downgraded)
+                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
+```
+
+(In win7 when the "07:00.1 Display controller" uses the gpu driver, dmesg spam errors occur and VM functions very very slow. I don't know where to report this, libvirt?. This I tested only in virt-manager. "07:00.1 Display controller" can be disabled in Win7 device manager and problems disappear. Independent if this, booting with x-vga=off image is corrupted on the monitor connected to passthrough gpu until driver is loaded. Image is white with vertical dark stripes.)
+```
+[ 3160.598553] DMAR: [INTR-REMAP] Request device [07:00.1] fault index 0x50 [fault reason 0x26] Blocked an interrupt request due to source-id verification failure
+[ 3161.098536] DMAR: DRHD: handling fault status reg 2
+[ 3165.098584] dmar_fault: 23 callbacks suppressed
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2857 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2857
new file mode 100644
index 00000000..efa5f397
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2857
@@ -0,0 +1,100 @@
+segmentation fault issue in qemu-option.c for both qemu-system-x86_64 and qemu-system-aarch64
+Description of problem:
+
+Steps to reproduce:
+1. Compile with;
+```
+| PKG_CONFIG_PATH="$PWD/../../lib/pkgconfig" ../../source/qemu-9.2.1/configure \     |
+|------------------------------------------------------------------------------------|
+|     --extra-cflags="-I$PWD/../../source/angle/include -march=armv8-a+crc+crypto" \ |
+|     --extra-ldflags="-L$PWD/../angle" \                                            |
+|     --disable-cocoa \                                                              |
+|     --enable-sdl \                                                                 |
+|     --prefix="$PWD/../.."                                                          |
+```
+2.`./bin/qemu-system-aarch64 -machine virt,accel=hvf -cpu host`
+3. Single liner for building:
+```
+curl -L https://gist.github.com/startergo/0d9a7425876c2b42f8b797af80fbe3d8/raw/run-arm-3dfx-sdl.sh | bash -
+```
+Additional information:
+```
+
+lldb -- ./bin/qemu-system-aarch64 -machine virt,accel=hvf -cpu host
+(lldb) target create "./bin/qemu-system-aarch64"
+Current executable set to '/Users/macbookpro/Downloads/qemu-3dfx-arch/bin/qemu-system-aarch64' (arm64).
+(lldb) settings set -- target.run-args  "-machine" "virt,accel=hvf" "-cpu" "host"
+(lldb) run
+Process 64856 launched: '/Users/macbookpro/Downloads/qemu-3dfx-arch/bin/qemu-system-aarch64' (arm64)
+Process 64856 stopped
+* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGUSR2
+    frame #0: 0x0000000199d78cc0 libsystem_kernel.dylib`__sigsuspend + 8
+libsystem_kernel.dylib`__sigsuspend:
+->  0x199d78cc0 <+8>:  b.lo   0x199d78ce0    ; <+40>
+    0x199d78cc4 <+12>: pacibsp 
+    0x199d78cc8 <+16>: stp    x29, x30, [sp, #-0x10]!
+    0x199d78ccc <+20>: mov    x29, sp
+Target 0: (qemu-system-aarch64) stopped.
+(lldb) continue
+Process 64856 resuming
+Process 64856 stopped
+* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
+    frame #0: 0x0000000000000000
+error: memory read failed for 0x0
+Target 0: (qemu-system-aarch64) stopped.
+(lldb) bt
+* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
+  * frame #0: 0x0000000000000000
+    frame #1: 0x00000001008539ec qemu-system-aarch64`get_opt_name_value [inlined] qemu_strchrnul(s="nic", c=44) at cutils.h:144:12 [opt]
+    frame #2: 0x00000001008539e0 qemu-system-aarch64`get_opt_name_value [inlined] get_opt_value(p="nic", value=0x000000016fdff058) at qemu-option.c:71:18 [opt]
+    frame #3: 0x00000001008539dc qemu-system-aarch64`get_opt_name_value(params=<unavailable>, firstname=<unavailable>, warn_on_flag=<unavailable>, help_wanted=0x0000000000000000, name=<unavailable>, value=0x000000016fdff058) at qemu-option.c:760:17 [opt]
+    frame #4: 0x0000000100853c84 qemu-system-aarch64`opts_do_parse(opts=0x0000600002e30460, params="nic", firstname=<unavailable>, warn_on_flag=false, help_wanted=0x0000000000000000, errp=0x00000001018fd500) at qemu-option.c:808:13 [opt]
+    frame #5: 0x0000000100853fbc qemu-system-aarch64`opts_parse(list=<unavailable>, params="nic", permit_abbrev=<unavailable>, warn_on_flag=false, help_wanted=0x0000000000000000, errp=0x00000001018fd500) at qemu-option.c:898:10 [opt]
+    frame #6: 0x0000000100853ea0 qemu-system-aarch64`qemu_opts_parse(list=<unavailable>, params=<unavailable>, permit_abbrev=<unavailable>, errp=<unavailable>) at qemu-option.c:917:12 [opt] [artificial]
+    frame #7: 0x00000001002937b4 qemu-system-aarch64`qemu_init [inlined] qemu_create_default_devices at vl.c:1446:9 [opt]
+    frame #8: 0x0000000100293640 qemu-system-aarch64`qemu_init(argc=<unavailable>, argv=0x000000016fdff500) at vl.c:3692:5 [opt]
+    frame #9: 0x00000001007b58c0 qemu-system-aarch64`main(argc=<unavailable>, argv=<unavailable>) at main.c:47:5 [opt]
+    frame #10: 0x0000000199a2c274 dyld`start + 2840
+
+lldb -- ./bin/qemu-system-x86_64 -machine q35,accel=hvf -cpu host
+(lldb) target create "./bin/qemu-system-x86_64"
+Current executable set to '/Users/macbookpro/Downloads/qemu-3dfx-arch/bin/qemu-system-x86_64' (arm64).
+(lldb) settings set -- target.run-args  "-machine" "q35,accel=hvf" "-cpu" "host"
+(lldb) run
+Process 65669 launched: '/Users/macbookpro/Downloads/qemu-3dfx-arch/bin/qemu-system-x86_64' (arm64)
+Process 65669 stopped
+* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGUSR2
+    frame #0: 0x0000000199d78cc0 libsystem_kernel.dylib`__sigsuspend + 8
+libsystem_kernel.dylib`__sigsuspend:
+->  0x199d78cc0 <+8>:  b.lo   0x199d78ce0    ; <+40>
+    0x199d78cc4 <+12>: pacibsp 
+    0x199d78cc8 <+16>: stp    x29, x30, [sp, #-0x10]!
+    0x199d78ccc <+20>: mov    x29, sp
+Target 0: (qemu-system-x86_64) stopped.
+(lldb) continue
+Process 65669 resuming
+Process 65669 stopped
+* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
+    frame #0: 0x0000000000000000
+error: memory read failed for 0x0
+Target 0: (qemu-system-x86_64) stopped.
+(lldb) bt
+* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
+  * frame #0: 0x0000000000000000
+    frame #1: 0x000000010053c7f0 qemu-system-x86_64`get_opt_name_value [inlined] qemu_strchrnul(s="nic", c=44) at cutils.h:144:12 [opt]
+    frame #2: 0x000000010053c7e4 qemu-system-x86_64`get_opt_name_value [inlined] get_opt_value(p="nic", value=0x000000016fdff058) at qemu-option.c:71:18 [opt]
+    frame #3: 0x000000010053c7e0 qemu-system-x86_64`get_opt_name_value(params=<unavailable>, firstname=<unavailable>, warn_on_flag=<unavailable>, help_wanted=0x0000000000000000, name=<unavailable>, value=0x000000016fdff058) at qemu-option.c:760:17 [opt]
+    frame #4: 0x000000010053ca88 qemu-system-x86_64`opts_do_parse(opts=0x0000600002476ee0, params="nic", firstname=<unavailable>, warn_on_flag=false, help_wanted=0x0000000000000000, errp=0x00000001014fa230) at qemu-option.c:808:13 [opt]
+    frame #5: 0x000000010053cdc0 qemu-system-x86_64`opts_parse(list=<unavailable>, params="nic", permit_abbrev=<unavailable>, warn_on_flag=false, help_wanted=0x0000000000000000, errp=0x00000001014fa230) at qemu-option.c:898:10 [opt]
+    frame #6: 0x000000010053cca4 qemu-system-x86_64`qemu_opts_parse(list=<unavailable>, params=<unavailable>, permit_abbrev=<unavailable>, errp=<unavailable>) at qemu-option.c:917:12 [opt] [artificial]
+    frame #7: 0x00000001001d6b00 qemu-system-x86_64`qemu_init [inlined] qemu_create_default_devices at vl.c:1446:9 [opt]
+    frame #8: 0x00000001001d698c qemu-system-x86_64`qemu_init(argc=<unavailable>, argv=0x000000016fdff500) at vl.c:3692:5 [opt]
+    frame #9: 0x000000010049e7c0 qemu-system-x86_64`main(argc=<unavailable>, argv=<unavailable>) at main.c:47:5 [opt]
+    frame #10: 0x0000000199a2c274 dyld`start + 2840
+
+-->
+
+```
+The line below ensures that proper tags are added to the issue.
+Please do not remove it.
+-->
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2858 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2858
new file mode 100644
index 00000000..e0b37e19
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2858
@@ -0,0 +1 @@
+QEMU Command Not Working
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2859 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2859
new file mode 100644
index 00000000..e0b37e19
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2859
@@ -0,0 +1 @@
+QEMU Command Not Working
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2860 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2860
new file mode 100644
index 00000000..3406638e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2860
@@ -0,0 +1,33 @@
+ps2 keyboard not work after boot and use libspice to connect it
+Description of problem:
+When I start almost 10 qemu virtual machines, there will always be one or two that have the ps2 keyboard not work well after booted.But I use mstsc to connect to the desktop, the keyboard works fine. But when reboot or migrate it well recovery.
+Steps to reproduce:
+1.Asynchronously start 40 qemu virtual machines, each with 4 cores and 4 threads
+
+2.there will always be one or two that have the ps2 keyboard not work well.
+
+4.And when i gdb debug it, i found i hang at the func "prepare_mmio_access"
+
+5.reboot or migrate it well recovery
+Additional information:
+the gdb debug as fllow:
+
+gdb attach $pid 
+
+gdb>b kbd_push_key      //spice input
+
+gdb>b kbd_read_data
+
+gdb>b ps2_keyboard_event
+
+gdb>c
+
+After continue, the code run on ps2_keyboard_event,but no work to "kbd_read_data".This Proves that the keyboard input has been added to the queue, but has not been read from the queue.
+
+gdb> thread 4   //switch to thread "CPU 0/KVM"
+
+gdb> bt
+
+![image](/uploads/82527d2b382cacd2d4e40793d78d3e59/image.png)
+
+I guess there is no event to notify the device to read after writing to the queue, or is it deadlocked? I'm not sure
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2862 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2862
new file mode 100644
index 00000000..50332a18
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2862
@@ -0,0 +1,24 @@
+unable to complete install when i try to load into qemu
+Description of problem:
+when i load up a vm, i get the message Unable to complete install: 'internal error: process exited while connecting to monitor: 2025-03-14T01:54:54.436804Z qemu-system-aarch64: can't apply global host-arm-cpu.hv-relaxed=on: Property 'host-arm-cpu.hv-relaxed' not found'
+
+Traceback (most recent call last):
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper
+    callback(asyncjob, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/createvm.py", line 2008, in _do_async_install
+    installer.start_install(guest, meter=meter)
+  File "/usr/share/virt-manager/virtinst/install/installer.py", line 695, in start_install
+    domain = self._create_guest(
+             ^^^^^^^^^^^^^^^^^^^
+  File "/usr/share/virt-manager/virtinst/install/installer.py", line 637, in _create_guest
+    domain = self.conn.createXML(initial_xml or final_xml, 0)
+             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/usr/lib/python3/dist-packages/libvirt.py", line 4481, in createXML
+    raise libvirtError('virDomainCreateXML() failed')
+libvirt.libvirtError: internal error: process exited while connecting to monitor: 2025-03-14T01:54:54.436804Z qemu-system-aarch64: can't apply global host-arm-cpu.hv-relaxed=on: Property 'host-arm-cpu.hv-relaxed' not found. If it's important, vmm recognizes my windows 10 iso as a windows 11.
+Steps to reproduce:
+1.i just tried to use the vm.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2863 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2863
new file mode 100644
index 00000000..083dbacb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2863
@@ -0,0 +1 @@
+Invalid read reason: rejected
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2866 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2866
new file mode 100644
index 00000000..688ca17c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2866
@@ -0,0 +1,185 @@
+In Win98 vm gpu driver issues with old ati gpu if it has BAR0: 64 bit,  BAR4: I/O; no issue if it has BAR0: 32 bit, BAR1: I/O
+Description of problem:
+In win98se vm no errors in device manager,ati control panel complains that the driver is not loaded and desktop can only be used in 16 color 640x480. The problematic old ati gpus work correctly when booting win98 directly(no qemu vm, same host hardware)
+
+Drivers fail to load in win98 vm for old ati gpu(x600, x700, x800, x850) that has:
+```
+        Region 0: Memory at 4020000000 (64-bit, prefetchable) [size=256M]
+        Region 2: Memory at 41b30000 (64-bit, non-prefetchable) [size=64K]
+        Region 4: I/O ports at 3000 [size=256]
+        Expansion ROM at 41b00000 [disabled] [size=128K]
+```
+Old ati gpu(x300, x550) that have this, load/work correctly in win98 vm:
+```
+        Region 0: Memory at 40000000 (32-bit, prefetchable) [size=64M]
+        Region 1: I/O ports at 3000 [size=256]
+        Region 2: Memory at 45b30000 (32-bit, non-prefetchable) [size=64K]
+        Expansion ROM at 45b00000 [disabled] [size=128K]
+```
+Additional information:
+I am using a QEMU build from branch master from a few days ago, with a fix for segfault when using 'x-vga=on' on some old ati gpu(Region 0: Memory at 40000000 (32-bit),Region 1: I/O ports) https://gitlab.com/qemu-project/qemu/-/issues/2856. (Win98 gpu driver issues with old ati gpu if it has "BAR0: 64 bit, BAR4: I/O" was the same with QEMU version 9.12).
+
+x700:
+```
+QEMU 9.2.50v9.2.0-2799-g0462a32b4f monitor> info pci:
+Bus  0, device   2, function 0:
+    VGA controller: PCI device 1002:5e4d
+      PCI subsystem 148c:2129
+      IRQ 10, pin A
+      BAR0: 64 bit prefetchable memory at 0xe0000000 [0xefffffff].
+      BAR2: 64 bit memory at 0x00010000 [0x0001ffff].
+      BAR4: I/O at 0xc000 [0xc0ff].
+      BAR6: 32 bit memory at (not mapped)
+      id ""
+  Bus  0, device   2, function 1:
+    Display controller: PCI device 1002:5e6d
+      PCI subsystem 148c:2128
+      BAR0: 64 bit memory at 0xfebf0000 [0xfebfffff].
+      id ""
+```
+```
+lspci -vv:
+
+08:00.0 0300: 1002:5e4d VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV410 [Radeon X700] (prog-if 00 [VGA controller])
+        Subsystem: Tul Corporation / PowerColor Device 2129
+        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
+        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
+        Interrupt: pin A routed to IRQ 16
+        Region 0: Memory at 4020000000 (64-bit, prefetchable) [size=256M]
+        Region 2: Memory at 41b30000 (64-bit, non-prefetchable) [size=64K]
+        Region 4: I/O ports at 3000 [size=256]
+        Expansion ROM at 41b00000 [disabled] [size=128K]
+        Capabilities: [50] Power Management version 2
+                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
+                Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
+        Capabilities: [58] Express (v1) Endpoint, MSI 00
+                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <4us
+                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 25.000W
+                DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
+                        RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
+                        MaxPayload 128 bytes, MaxReadReq 128 bytes
+                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
+                LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <256ns, L1 <2us
+                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
+                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
+                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
+                LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
+        Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit+
+                Address: 0000000000000000  Data: 0000
+        Capabilities: [100 v1] Advanced Error Reporting
+                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
+                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
+                UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
+                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
+                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
+                AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn-
+                        MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
+                HeaderLog: 40000001 00000003 000b0000 ffff0000
+        Kernel driver in use: vfio-pci
+        Kernel modules: radeon, amdgpu
+
+08:00.1 0380: 1002:5e6d Display controller: Advanced Micro Devices, Inc. [AMD/ATI] RV410 [Radeon X700] (Secondary)
+        Subsystem: Tul Corporation / PowerColor Device 2128
+        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
+        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
+        Region 0: Memory at 41b20000 (64-bit, non-prefetchable) [size=64K]
+        Capabilities: [50] Power Management version 2
+                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
+                Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
+        Capabilities: [58] Express (v1) Endpoint, MSI 00
+                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <4us
+                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W
+                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
+                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
+                        MaxPayload 128 bytes, MaxReadReq 128 bytes
+                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
+                LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <256ns, L1 <2us
+                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
+                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
+                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
+                LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
+        Kernel driver in use: vfio-pci
+        Kernel modules: amdgpu
+```
+
+x550:
+```
+QEMU 9.2.50v9.2.0-2799-g0462a32b4f monitor> info pci:
+us  0, device   2, function 0:
+    VGA controller: PCI device 1002:5b63
+      PCI subsystem 174b:1500
+      IRQ 10, pin A
+      BAR0: 32 bit prefetchable memory at 0xef800000 [0xfbffffff].
+      BAR1: I/O at 0xc000 [0xc0ff].
+      BAR2: 32 bit memory at 0x00010000 [0xfebdffff].
+      BAR6: 32 bit memory at (not mapped)
+      id ""
+  Bus  0, device   2, function 1:
+    Display controller: PCI device 1002:5b73
+      PCI subsystem 174b:1501
+      BAR0: 32 bit memory at 0xfebf0000 [0xfebfffff].
+      id ""
+
+
+lspci -vv:
+08:00.0 1002:5b63 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV370 [Radeon X300/X550/X1050 Series] (prog-if 00 [VGA controller])
+        Subsystem: PC Partner Limited / Sapphire Technology Device 1500
+        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
+        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
+        Interrupt: pin A routed to IRQ 16
+        Region 0: Memory at 40000000 (32-bit, prefetchable) [size=64M]
+        Region 1: I/O ports at 3000 [size=256]
+        Region 2: Memory at 45b30000 (32-bit, non-prefetchable) [size=64K]
+        Expansion ROM at 45b00000 [disabled] [size=128K]
+        Capabilities: [50] Power Management version 2
+                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
+                Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
+        Capabilities: [58] Express (v1) Endpoint, MSI 00
+                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us
+                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 25.000W
+                DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
+                        RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
+                        MaxPayload 128 bytes, MaxReadReq 128 bytes
+                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
+                LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <128ns, L1 <1us
+                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
+                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
+                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
+                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
+        Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit+
+                Address: 0000000000000000  Data: 0000
+        Capabilities: [100 v1] Advanced Error Reporting
+                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
+                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
+                UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
+                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
+                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
+                AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn-
+                        MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
+                HeaderLog: 02000001 00000002 000003c8 037bbfae
+        Kernel driver in use: vfio-pci
+        Kernel modules: radeon, amdgpu
+
+08:00.1 1002:5b73 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] RV370 [Radeon X300/X550/X1050 Series] (Secondary)
+        Subsystem: PC Partner Limited / Sapphire Technology Device 1501
+        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
+        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
+        Region 0: Memory at 45b20000 (32-bit, non-prefetchable) [size=64K]
+        Capabilities: [50] Power Management version 2
+                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
+                Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
+        Capabilities: [58] Express (v1) Endpoint, MSI 00
+                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us
+                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W
+                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
+                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
+                        MaxPayload 128 bytes, MaxReadReq 128 bytes
+                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
+                LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <128ns, L1 <1us
+                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
+                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
+                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
+                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
+        Kernel driver in use: vfio-pci
+        Kernel modules: amdgpu
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2867 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2867
new file mode 100644
index 00000000..82edfdf4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2867
@@ -0,0 +1,13 @@
+qemu:block / io-qcow2-161 fails non-deterministically
+Description of problem:
+The test suite failed non-deterministically with failure:
+```
+729/838 qemu:block / io-qcow2-161                                                 ERROR            2.08s   exit status 1
+```
+Steps to reproduce:
+1. guix time-machine --commit=d706c1b -- build qemu
+2. or git clone,  build and run `make check -j32 V=1`
+Additional information:
+[qemu-9.1.3-io-qcow2-041-failure-build-log.txt](/uploads/077f61d9dd1a26bcd351c0995009131c/qemu-9.1.3-io-qcow2-041-failure-build-log.txt)
+
+[testlog.txt](/uploads/0b0244a337f2175bdba9e258c778481d/testlog.txt)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/287 b/gitlab/issues_text/target_missing/host_missing/accel_missing/287
new file mode 100644
index 00000000..eb9765d2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/287
@@ -0,0 +1 @@
+block copy job sometimes hangs on the last block for minutes
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2872 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2872
new file mode 100644
index 00000000..2e252cec
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2872
@@ -0,0 +1 @@
+hw/net: Parameter 'driver' expects a pluggable device type
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2873 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2873
new file mode 100644
index 00000000..b27d259b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2873
@@ -0,0 +1,9 @@
+[chardev] In case of stdin redirection, SYS_READC semihost call will block in the chardev backend when EOF is reached.
+Description of problem:
+The previous command hangs, EOF is not detected.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2875 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2875
new file mode 100644
index 00000000..1875d6fc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2875
@@ -0,0 +1,29 @@
+[Virtio-GPU Venus] QEMU Virtio-GPU Venus with Lavapipe ICD shows corrupted graphical output along with error prints
+Description of problem:
+QEMU Virtio-GPU Venus with Lavapipe ICD shows corrupted graphical output (screenshots attached ahead) along with the following error prints, as guest_errors are enabled in QEMU command line `-d guest_errors`:
+```
+VK_DRIVER_FILES=/usr/share/vulkan/icd.d/lvp_icd.x86_64.json ./qemu-system-x86_64 -enable-kvm -M q35 -smp 4 -m 4G -cpu host -net nic,model=virtio -net user,hostfwd=tcp::2222-:22 -d guest_errors -device virtio-vga-gl,hostmem=4G,blob=true,venus=true -vga none -display gtk,gl=on,show-cursor=on -usb -device usb-tablet -object memory-backend-memfd,id=mem1,size=4G -machine memory-backend=mem1 -hda ubuntu-2504.qcow2 
+virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument
+virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
+virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument
+virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
+virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument
+virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
+virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument
+virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
+virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument
+virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
+virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument
+virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
+```
+Steps to reproduce:
+1. Used steps mentioned here: https://gist.github.com/peppergrayxyz/fdc9042760273d137dddd3e97034385f, to build virglrenderer-1.1.0 with Venus support, and to build QEMU (latest: v10.0.0-rc1) with virglrenderer support.
+2. Run QEMU with Lavapipe ICD using the command shared above.
+3. When the QEMU guest is up, install required packages such as `sudo apt-get install -y mesa* vulkan* libvulkan* vkmark` and run vkcube / vkmark with VirtIO ICD:
+```
+VK_DRIVER_FILES=/usr/share/vulkan/icd.d/virtio_icd.x86_64.json vkcube --wsi wayland
+```
+Additional information:
+Attaching screenshots for the error observed on guest side:
+![virtio-gpu-venus-_lvp_-vkcube](/uploads/a04f4006a07b25a078231b5d0396c508/virtio-gpu-venus-_lvp_-vkcube.png), ![virtio-gpu-venus-_lvp_-dmesg](/uploads/a8caea5c2bc926266f2268c35716518b/virtio-gpu-venus-_lvp_-dmesg.png)
+Collected logs with tracing enabled (`meson setup -Dvenus=true -Dvenus-validate=true -Dvideo=true -Dtracing=stderr build`) in virglrenderer as well: [virgl-tracing-stderr.log](/uploads/202c698b7c265cde7c83b441a6a7abdb/virgl-tracing-stderr.log). Search for error in the log file.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2876 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2876
new file mode 100644
index 00000000..0da636a9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2876
@@ -0,0 +1,14 @@
+IPv6 support for hostfwd + guestfwd
+Description of problem:
+When using hostfwd, only IPv4 connections are forwarded.
+Steps to reproduce:
+1. Start vm with the aforementioned command using a system image that comes with a socket listening on both IPv4 and IPv6. (I used Arch Linux Box which comes with `sshd` enabled by default).
+2. Connect to the forwarded socket:
+  - IPv4 succeeds:
+    - `ssh -oPasswordAuthentication=yes arch@127.0.0.1 -p 52022`
+    - `nc -zv 127.0.0.1 52022`
+  - IPv6 does not:
+    - `ssh -oPasswordAuthentication=yes arch@::1 -p 52022`
+    - `nc -zv ::1 52022`
+Additional information:
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2879 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2879
new file mode 100644
index 00000000..98ff4186
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2879
@@ -0,0 +1 @@
+-smbios type=11,path=xxx results in buffer overrun due to missing null terminator
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2880 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2880
new file mode 100644
index 00000000..463833be
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2880
@@ -0,0 +1,3 @@
+how to migrate storage live for the vm with vhostuser disk
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2881 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2881
new file mode 100644
index 00000000..6764786b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2881
@@ -0,0 +1,10 @@
+segfault on loadvm after migrate_set_capability multifd on
+Description of problem:
+A segfault occurs when running `loadvm` having set `migrate_set_capability multifd on` from the monitor.
+EDIT: also `savevm` segfaults.
+Steps to reproduce:
+1. Take a snapshot with `savevm test`
+2. From the monitor run `migrate_set_capability multifd on`
+3. Try to restore the snapshot with `loadvm test`
+Additional information:
+Sorry for not having triaged this much, I think it is worth reporting anyway.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2883 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2883
new file mode 100644
index 00000000..0d55c87a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2883
@@ -0,0 +1 @@
+Advice regarding implementation of smooth scrolling
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2888 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2888
new file mode 100644
index 00000000..dacfe7d6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2888
@@ -0,0 +1,14 @@
+mouse pointer does not move in USB pass in.
+Description of problem:
+I have this script to start qemu that passes in my mouse, keyboard and xbox controller. When I use it, it does not move the cursor(for my mouse) but the mouse is working because the hot corners do. Moving my mouse in a up left direction in GNOME will show the menu and apps. Key board works, My controller works, and My mouse works, but the cursor does not move.
+Steps to reproduce:
+1. use the script above with the right USB IDs for you mouse and keyboard (and controller if you want)
+2. When the VM boots it will not move the cursor. The mouse will work but the pointer stays still.
+Additional information:
+I am using thees patches in qemu but it does not work in vanilla ether:
+https://lore.kernel.org/all/20241010182427.1434605-1-seanjc@google.com/
+
+and this in the kernel (6.14.0):
+https://github.com/torvalds/linux/commit/377b2f359d1f71c75f8cc352b5c81f2210312d83
+
+I am ruining qemu 10.0.0-rc1 (but 9.2.2 also does not work), kernel 6.14.0.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2889 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2889
new file mode 100644
index 00000000..bfe1e42c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2889
@@ -0,0 +1,22 @@
+mouse does not work in pass in
+Description of problem:
+I have this script to start qemu that passes in my mouse, keyboard and xbox controler. When I use it, it does not move the cursor(for my mouse) but the mouse is working because the hot corners do work. Moving my mouse in a up left direction in GNOME will show the menu and apps. Key board works, My controller works, and My mouse works, but the cursor does not move. Here is the script:
+Steps to reproduce:
+1. run the script above with the right variables.
+2. Move your mouse in the screen. It will not move the pointer.
+Additional information:
+I am using thees patches in qemu but it does not work in vanilla ether:
+https://lore.kernel.org/all/20241010182427.1434605-1-seanjc@google.com/
+
+and this in the kernel (6.14.0):
+https://github.com/torvalds/linux/commit/377b2f359d1f71c75f8cc352b5c81f2210312d83
+
+I am ruining qemu 10.0.0-rc1 (but 9.2.2 also does not work), kernel 6.14.0.
+
+I am runing mint on my host and arch on my guest. on my host I have virglrenderer on and on my guest I installed the pacman package lib32-vulkan-virtio and vulkan-virtio.
+
+If it helps I can remove the pass throws and insted use:
+
+-usbdevice tablet -usbdevice mouse -usbdevice keyboard
+or
+-device virtio-mouse -device virtio-keyboard -device virtio-tablet
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2890 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2890
new file mode 100644
index 00000000..d88715d1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2890
@@ -0,0 +1 @@
+RFE:  Individual ON_SHUTDOWN
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2900 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2900
new file mode 100644
index 00000000..aa79102c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2900
@@ -0,0 +1,11 @@
+Data races in test-bdrv-drain test
+Description of problem:
+Data races in the access of `Job` fields in the `test-bdrv-drain` test were identified using TSAN.
+Steps to reproduce:
+```sh
+QEMU_BUILD_DIR=<path to the QEMU build directory>
+QEMU_DIR=<path to the QEMU repository directory>
+configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp
+make tests/unit/test-bdrv-drain
+MALLOC_PERTURB_=186 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-bdrv-drain --tap -k
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2901 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2901
new file mode 100644
index 00000000..70a4f3b9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2901
@@ -0,0 +1 @@
+Critical typo in qemu_source_dir/plugins/loader.c
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2902 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2902
new file mode 100644
index 00000000..2c205135
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2902
@@ -0,0 +1,11 @@
+Data Race with slh_first Field in test-aio-multithread
+Description of problem:
+Potential data races in the `QSLIST_INSERT_HEAD_ATOMIC` macro were identified using TSAN.
+Steps to reproduce:
+```sh
+QEMU_BUILD_DIR=<path to the QEMU build directory>
+QEMU_DIR=<path to the QEMU repository directory>
+configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp
+make tests/unit/test-bdrv-drain
+MALLOC_PERTURB_=102 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-aio-multithread --tap -k
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2903 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2903
new file mode 100644
index 00000000..07ffbe1e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2903
@@ -0,0 +1,11 @@
+Data Race in assertion in aio-posix.c
+Description of problem:
+Potential data races in the assertion in `test-aio-multithread` were identified using TSAN.
+Steps to reproduce:
+```sh
+QEMU_BUILD_DIR=<path to the QEMU build directory>
+QEMU_DIR=<path to the QEMU repository directory>
+configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp
+make tests/unit/test-bdrv-drain
+MALLOC_PERTURB_=102 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-aio-multithread --tap -k
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2904 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2904
new file mode 100644
index 00000000..7f472264
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2904
@@ -0,0 +1,11 @@
+Data Race in data->cb() call and cb assignment in test-aio-multithread
+Description of problem:
+Potential data races between the `data->cb()` call and the assignment of `cb` in `test-aio-multithread` were identified using TSAN.
+Steps to reproduce:
+```sh
+QEMU_BUILD_DIR=<path to the QEMU build directory>
+QEMU_DIR=<path to the QEMU repository directory>
+configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp
+make tests/unit/test-bdrv-drain
+MALLOC_PERTURB_=102 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-aio-multithread --tap -k
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2905 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2905
new file mode 100644
index 00000000..281d18e3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2905
@@ -0,0 +1,24 @@
+Windows Curses Display Infinite Loop
+Description of problem:
+The out-of-the-box `qemu-system-x86_64 -display curses` on Windows loops forever while displaying "VGA Blank Mode" instead of booting like `qemu-system-x86_64` does.
+
+This is caused by an infinite loop in the below simplified code in `curses_refresh` in `ui/curses.c`:
+```
+    int chr;
+    // ...trimmed
+    while (1) {
+        /* while there are any pending key strokes to process */
+        chr = console_getch(&maybe_keycode);
+
+        if (chr == -1) 
+            break;
+    // ...trimmed
+    }
+```
+`console_getch` has return type `wint_t`. However, on Windows, `wint_t` is `unsigned short`. Therefore when `console_getch` returns -1, the -1 value of `unsigned short` will be silently converted into the `int` value 65535. This causes `65535 == -1` to always be false, and the loop will never break. I can send a patch to qemu-devel which retypes `chr` to `wint_t` and replaces occurences of -1 with `WEOF` (an alias for `(wint_t) -1`).
+Steps to reproduce:
+1. Install `qemu-w64-setup-20250326.exe` Windows qemu from https://qemu.weilnetz.de/w64/2025/
+2. Run `./qemu-system-x86_64 -display curses`
+3. "VGA Blank Mode" will appear on the screen forever
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2908 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2908
new file mode 100644
index 00000000..3a945f6c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2908
@@ -0,0 +1,10 @@
+Display Output Not Sane After Driver Installation
+Description of problem:
+Using an S3 Diamond Stealth 3000 card through VFIO, after installing an official driver, either from the Windows disc or an updated download, the displayed output from the graphics card is not sane.
+Additional information:
+Driver: [https://theretroweb.com/expansioncards/s/diamond-stealth-3d-3000-pci#driver](https://theretroweb.com/expansioncards/s/diamond-stealth-3d-3000-pci#driver)  
+[https://diamond.retropc.se/driver/stealth/st3d3xx0/files.htm](https://diamond.retropc.se/driver/stealth/st3d3xx0/files.htm)
+
+Followed the instructions in the Readme. To install Standard VGA driver first then the Diamond 3000 driver. No change. It is not the only S3 card that I have tried that behaves like this. I have also used the bios rom downloaded directly from the card, again with no change.
+
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2909 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2909
new file mode 100644
index 00000000..f77ab362
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2909
@@ -0,0 +1,18 @@
+Corrupt qcow2 images with broken bitmap unfixable
+Description of problem:
+During a backup of a VM (via bitmaps), the disk of the VM/Snapshot went out of space.
+The VM was stopped, leaving the image in a bad state.
+
+But now when trying to repair it, it was stuck:
+```
+# qemu-img check -r all /dev/mapper/e1d2ff33--c3fd--4c1a--bcd1--2047e4efc362-efbd8056--720a--47b6--bede--4325d576ffb9
+qemu-img: Could not open '/dev/mapper/e1d2ff33--c3fd--4c1a--bcd1--2047e4efc362-efbd8056--720a--47b6--bede--4325d576ffb9': Bitmap '' doesn't satisfy the constraints
+```
+
+But if you want to remove the bitmap:
+```
+# qemu-img bitmap --remove /dev/mapper/e1d2ff33--c3fd--4c1a--bcd1--2047e4efc362-efbd8056--720a--47b6--bede--4325d576ffb9 ''
+qemu-img: Could not open '/dev/mapper/e1d2ff33--c3fd--4c1a--bcd1--2047e4efc362-efbd8056--720a--47b6--bede--4325d576ffb9': qcow2: Image is corrupt; cannot be opened read/write
+```
+
+It seems like qemu-img check needs some option to clear invalid bitmaps. So the image can be repaired including dropping the invalid bitmap.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/291 b/gitlab/issues_text/target_missing/host_missing/accel_missing/291
new file mode 100644
index 00000000..637ab724
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/291
@@ -0,0 +1 @@
+deadlock in e1000e
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2912 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2912
new file mode 100644
index 00000000..e5b24839
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2912
@@ -0,0 +1,13 @@
+qcow2 image corrupted after snapshot+bitmap action
+Description of problem:
+When taking a backup of the VM via snapshot + bitmap, the qcow2 image became corrupt:
+`qcow2: Marking image as corrupt: Preventing invalid write on metadata (overlaps with bitmap directory); further corruption events will be suppressed`
+
+This resulted in a corrupt (unfix-able) image (see #2909).
+
+While this process is something that happens multiple times a day, we never hit any issue.
+The underlying storage didn't report any error, so it seems like something inside qemu broke the image.
+Steps to reproduce:
+Unfortunately, I was unable to reproduce this issue yet.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2915 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2915
new file mode 100644
index 00000000..fdc5a8da
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2915
@@ -0,0 +1,29 @@
+qemu: error reading initrd /home/build/pooldir/w.linux.initramfs
+Description of problem:
+occasionally, qemu can't open the initrd file it's been supplied on the command line (I'm guessing this is qemu and not libvirt)
+
+```
+sudo virsh --connect qemu:///system start w.east --console
+error: Failed to start domain 'w.east'\r\nerror: internal error: QEMU unexpectedly closed the monitor (vm='w.east'): qemu: error reading initrd /home/build/pooldir/w.linux-transmogrify.initramfs: Failed to open file \xe2\x80\x9c/home/build/pooldir/w.linux-transmogrify.initramfs\xe2\x80\x9d: open() failed: Permission denied\r\n\r\n"
+```
+Steps to reproduce:
+1. create, using libvirt, a config that direct boots from initrd and kernel
+it creates a domain call linux, and from that creates {w.,w1,w2,w3}{east,west,north,road}
+1. boots and then destroys these domains 1000's of times
+2. occasionally above error occurs while trying to boot the domain
+Additional information:
+I suspect it is this:
+```
+        mapped_file = g_mapped_file_new(initrd_filename, false, &gerr);
+        if (!mapped_file) {
+            fprintf(stderr, "qemu: error reading initrd %s: %s\n",
+                    initrd_filename, gerr->message);
+            exit(1);
+        }
+        x86ms->initrd_mapped_file = mapped_file;
+```
+in `hw/i386/x86-common.c`.  Which would suggest `g_mapped_file_new()` occasionally fails, which is worrying.
+
+The test framework is [Libreswan](https://testing.libreswan.org/), unresolved test results indicate a failed boot, for instance [debug log of failure](https://testing.libreswan.org/v5.2-370-ga09c7f410b/interop-ikev2-strongswan-20-strongswan-eap/OUTPUT/debug.log).
+
+The problem didn't happen with f40.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2919 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2919
new file mode 100644
index 00000000..31ca12ab
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2919
@@ -0,0 +1,13 @@
+qemu-ga update resetting VssOption Registry key to default
+Description of problem:
+Before I installed the .exe from iso `virtio-win-0.1.271.iso`, I had value 5 in registry key `HKLM:\SYSTEM\CurrentControlSet\Services\QEMU Guest Agent VSS Provider\VssOption`.
+After the driver update by the .exe, the value was set to 1.
+
+This registry key shouldn't change in driver update, as its value was manually set to 5 and it is important to preserve MSSQL backups in Proxmox.
+Source:
+https://blog.datact.ch/backup-mssql-server-with-proxmox
+https://forum.proxmox.com/threads/pbs-breaking-customer-sql-backups-backups-without-fs-freeze.111526/
+Steps to reproduce:
+1. Set a value to `HKLM:\SYSTEM\CurrentControlSet\Services\QEMU Guest Agent VSS Provider\VssOption` other than 1.
+2. Install the .exe from version 0.1.271.
+3. Check the key value.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/292 b/gitlab/issues_text/target_missing/host_missing/accel_missing/292
new file mode 100644
index 00000000..b0748e1a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/292
@@ -0,0 +1 @@
+keyboard errors in DOS, found links to similar errors for reference
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2920 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2920
new file mode 100644
index 00000000..7694e5cc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2920
@@ -0,0 +1,12 @@
+VGA Passthrough I/O Lag on DOS (FreeDOS) System.
+Description of problem:
+VGA performance lags with passthrough when the OS is in graphics mode. It also seems to affect when key presses are registered with noticeable delay.
+Steps to reproduce:
+1. Install Doom (v1.9 Shareware.)
+2. Run setup and disable sound.
+3. Play game or watch demo.
+Additional information:
+I have tried multiple cards with no change in performance:
+
+**VGA compatible controller: S3 Graphics Ltd. 86c375 [ViRGE/DX] or 86c385 [ViRGE/GX] (rev 01) (prog-if 00 [VGA controller])   
+VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] R480 [Radeon X800 GTO] (prog-if 00 [VGA controller])**
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2923 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2923
new file mode 100644
index 00000000..7387c33e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2923
@@ -0,0 +1,13 @@
+Audio crackling issue when USB headset is pass thru via usb-host,hostbus=bus,hostaddr=addr
+Description of problem:
+When we pass thru USB headset via usb port pass-thru, and if the headset supports only 44100 Hz sampling rate, we hear the crackling sound.
+
+The headsets which support 48000Hz works fine.
+Steps to reproduce:
+1. Pass the usb device using hostbus,port.
+2. Connect a usb headset like Logitech H340 which supports only 44100Hz sampling rate.
+3. Play any audio file or youtube video, there is constant crackling sound.
+
+This issue is observed irrespective of the guest OS. Both ubuntu and windows guest, exhibit similar problem.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2924 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2924
new file mode 100644
index 00000000..75328c2b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2924
@@ -0,0 +1,15 @@
+qemu-user not responding to Ctrl-C from gdb
+Description of problem:
+When attached to qemu-x84_64's gdbserver via gdb, it is not possible to interrupt the binary being emulated. Usually, Ctrl-C will interrupt a running binary from gdb and I believe (though have not tested) it works in qemu-system.
+
+First Ctrl-C will do nothing and second will prompt to stop debugging.
+```
+(gdb) c
+Continuing.
+^C^CThe target is not responding to interrupt requests.
+Stop debugging it? (y or n)
+```
+Steps to reproduce:
+1. Run `./qemu-x86_64 -g 1234 ~/Downloads/base64-x64_64-static` or any static binary that will pause/hang
+2. Connect from gdb `(gdb) target remote :1234`
+3. Ctrl-C in gdb
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2925 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2925
new file mode 100644
index 00000000..2f3db5ab
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2925
@@ -0,0 +1,25 @@
+Cannot exec certain QMP guest commands using unix socket but Virsh can
+Description of problem:
+There are two channels configured to communicate the guest. 
+ - a) qemu.guest_agent.0
+ - b) unix socket: -qmp unix:/tmp/qmp_win7-101.sock,server,nowait
+
+
+**For unix socket connection, certain commands like ```guest-info``` and other guest functions are missing.** However, invoking guest-xx functions successfully in Virsh (through qemu.guest_agent.0).
+Steps to reproduce:
+```
+$sudo socat unix-connect:/tmp/qmp_win7-101.sock readline
+{"QMP": {"version": {"qemu": {"micro": 0, "minor": 2, "major": 4}, "package": "qemu-kvm-4.2.0-59.module_el8.5.0+1063+c9b9feff.1"}, "capabilities": ["oob"]}}
+
+{"execute":"qmp_capabilities"}
+{"return": {}}
+
+{"execute": "guest-info"}
+{"error": {"class": "CommandNotFound", "desc": "The command guest-info has not been found"}}
+```
+
+I checked ```/etc/sysconfig/qemu-ga``` and unmarked blacklist functions, but it did not solve this problem.
+```
+# original contents of qemu-ga
+#BLACKLIST_RPC=guest-file-open,guest-file-close,guest-file-read,guest-file-write,guest-file-seek,guest-file-flush,guest-exec,guest-exec-status
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2926 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2926
new file mode 100644
index 00000000..f04e1ed8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2926
@@ -0,0 +1,36 @@
+Excessive memory allocation on guest and host with gpu passthrough
+Description of problem:
+While gpu passthrough is enabled, the maximum amount of ram is allocated on the host (64 GB), even if the guest only has 8 GB configured as "currently allocated".
+If I disable the physical gpu, the guest only takes the 8 GB.
+Steps to reproduce:
+1. Install qemu-kvm virt-manager libvirt-daemon-system virtinst libvirt-clients and bridge-utils.
+1. Create a Windows vm with virt-manager
+1. Insert discrete GPU on a secondary pcie slot.
+1. Add `intel_iommu=on iommu=pt vfio-pci.ids=10de:17c8,10de:0fb0` to the GRUB kernel parameters.
+1. Add `options vfio-pci ids=10de:17c8,10de:0fb0` and `softdep nvidia pre: vfio-pci` to `/etc/modprobe.d/vfio.conf`.
+1. Update initrmfs image.
+1. Add pcie hardware on virt-manager.
+1. Install virtio and nvidia drivers on guest.
+Additional information:
+I'm using an Nvidia gtx 980Ti on a secondary slot for the guest.
+The first slot has an rtx 4090 used by the host.
+
+```
+OS: Linux Mint 22.1 x86_64 
+Host: MS-7E07 2.0 
+Kernel: 6.8.0-51-generic 
+Shell: bash 5.2.21 
+Resolution: 3840x2160, 3840x2160 
+DE: Cinnamon 6.4.8 
+WM: Mutter (Muffin) 
+Terminal: gnome-terminal 
+CPU: Intel i9-14900K (32) @ 5.700GHz 
+GPU: NVIDIA GeForce GTX 980 Ti 
+GPU: NVIDIA GeForce RTX 4090 
+GPU: Intel Raptor Lake-S GT1 [UHD Graphics 770] 
+Memory: 73717MiB / 96317MiB 
+```
+
+[vWin.xml](/uploads/3fe8133f67577f8724b060908b390c32/vWin.xml)
+[vWin.log](/uploads/efa029460a62b62cbcff464af7cdb72a/vWin.log)
+![Screenshot_from_2025-04-19_02-34-37](/uploads/0245ed4bf2dee96fcf396ef899ac2c2b/Screenshot_from_2025-04-19_02-34-37.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2927 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2927
new file mode 100644
index 00000000..f38c6e7b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2927
@@ -0,0 +1,171 @@
+Getting bare metal code running on tricore
+Description of problem:
+My code is stuck in
+Steps to reproduce:
+1. Open Infineon Aurix Development Studio (on Windows)
+2. Compile project (two examples that I've tested)
+a) New -> Project -> Board -> KIT_AURIX_TC277_TFT_DC-Step -> Build
+b) the example from here: https://github.com/Infineon/AURIX_code_examples/tree/master/code_examples/Blinky_LED_1_KIT_TC277_TFT
+3. Copy the elf and run qemu on the debian system
+Additional information:
+When running a blank binary on QEMU with the TriCore TC27x target, the CPU starts executing at address 0x80000020 and enters an infinite loop.
+The code seems to be stuck and waiting for some hardware signal. The binary (sample.elf) from this issue qemu-project/qemu#1363 works. 
+
+I know it's probably a rookie problem, but what am I missing? How can I get an example from Infineon running? Or any other example?
+
+Please let me know if you need additional information!
+
+```:~/qemu$ ./build/qemu-system-tricore   -M KIT_AURIX_TC277_TRB   -cpu tc27x   -nographic   -kernel ../qemu-examples/aurix_tricore_example_bins/Blank_project_TC277.elf -d in_asm
+QEMU 9.2.50 monitor - type 'help' for more information
+(qemu) ----------------
+IN: _START
+0x80000020:  
+OBJD-T: 91000028d9220681dc02
+
+----------------
+IN: _Core0_start
+0x80001206:  
+OBJD-T: 9130002f192200469120003737026e21d92200468ff2838180321b026029602a
+OBJD-T: 0d0080043b009820cd42e00f
+
+----------------
+IN: _Core0_start
+0x8000120a:  
+OBJD-T: 19220046
+
+----------------
+IN: _Core0_start
+0x8000120e:  
+OBJD-T: 9120003737026e21d92200468ff2838180321b026029602a0d0080043b009820
+OBJD-T: cd42e00f
+
+----------------
+IN: _Core0_start
+0x80001232:  
+OBJD-T: 4d00e02fb7021420cd02e00f8212cd4220094dc0e12f8f720021012203260122
+OBJD-T: 02265422542337026e218ff283216f134381
+
+----------------
+IN: _Core0_start
+0x80001254:  
+OBJD-T: 5422
+
+----------------
+IN: _Core0_start
+0x80001256:  
+OBJD-T: 542337026e218ff283216f134381
+
+----------------
+IN: _Core0_start
+0x80001256:  
+OBJD-T: 5423
+
+----------------
+IN: _Core0_start
+0x80001258:  
+OBJD-T: 37026e218ff283216f134381
+
+----------------
+IN: _Core0_start
+0x80001264:  
+OBJD-T: 8f2200305422b7021020a6328f224021742254226f02ffff
+
+----------------
+IN: _Core0_start
+0x80001268:  
+OBJD-T: 5422
+
+----------------
+IN: _Core0_start
+0x8000126a:  
+OBJD-T: b7021020a6328f224021742254226f02ffff
+
+----------------
+IN: _Core0_start
+0x80001274:  
+OBJD-T: 7422
+
+----------------
+IN: _Core0_start
+0x80001276:  
+OBJD-T: 54226f02ffff
+
+----------------
+IN: _Core0_start
+0x80001276:  
+OBJD-T: 5422
+
+----------------
+IN: _Core0_start
+0x80001278:  
+OBJD-T: 6f02ffff
+
+----------------
+IN: _Core0_start
+0x8000127c:  
+OBJD-T: 8202cdc2200954226f120900
+
+----------------
+IN: _Core0_start
+0x80001282:  
+OBJD-T: 5422
+
+----------------
+IN: _Core0_start
+0x80001284:  
+OBJD-T: 6f120900
+
+----------------
+IN: _Core0_start
+0x80001296:  
+OBJD-T: 5422b7021020a6328f324021742254226f02ff7f
+
+----------------
+IN: _Core0_start
+0x80001296:  
+OBJD-T: 5422
+
+----------------
+IN: _Core0_start
+0x80001298:  
+OBJD-T: b7021020a6328f324021742254226f02ff7f
+
+----------------
+IN: _Core0_start
+0x800012a2:  
+OBJD-T: 7422
+
+----------------
+IN: _Core0_start
+0x800012a4:  
+OBJD-T: 54226f02ff7f
+
+----------------
+IN: _Core0_start
+0x800012a4:  
+OBJD-T: 5422
+
+----------------
+IN: _Core0_start
+0x800012a6:  
+OBJD-T: 6f02ff7f
+
+
+(qemu) q
+```
+
+When I run it with the `-d in_asm,cpu,exec` flag it logs this infinitely often:
+```
+Trace 0: 0x7fb5205e9940 [00000000/00000000800012a4/00000002/ff011001] _Core0_start
+PC: 800012a4 PSW: 00000980 ICR: 00000000
+PCXI: 00000000 FCX: 00000000 LCX: 00000000
+GPR A00: 00000000 00000000 f0036100 70020000
+GPR A04: 00000000 00000000 00000000 00000000
+GPR A08: 00000000 00000000 70019600 00000000
+GPR A12: 00000000 00000000 00000000 00000000
+GPR D00: 00000000 00000000 00000000 000000fc
+GPR D04: 00000000 00000000 00000000 00000000
+GPR D08: 0000003f 00000000 00000000 00000000
+GPR D12: 00000000 00000000 00000000 00000000
+cpu_io_recompile: rewound execution of TB to 00000000800012a4
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2928 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2928
new file mode 100644
index 00000000..a0bf8a0e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2928
@@ -0,0 +1,56 @@
+Segmentation fault in most qemu-system commands on macOS ARM
+Description of problem:
+Most qemu-system binaries produce a segmentation fault:
+```
+raptor@fnord rust_os % qemu-system-x86_64
+zsh: segmentation fault  qemu-system-x86_64
+raptor@fnord rust_os % qemu-system-mips
+zsh: segmentation fault  qemu-system-mips
+raptor@fnord rust_os % qemu-system-sparc
+zsh: segmentation fault  qemu-system-sparc
+...
+```
+
+Some of them work properly:
+```
+raptor@fnord rust_os % qemu-system-aarch64
+qemu-system-aarch64: No machine specified, and there is no default
+Use -machine help to list supported machines
+raptor@fnord rust_os % qemu-system-arm
+qemu-system-arm: No machine specified, and there is no default
+Use -machine help to list supported machines
+raptor@fnord rust_os % qemu-system-avr
+qemu-system-avr: No machine specified, and there is no default
+Use -machine help to list supported machines
+...
+```
+Steps to reproduce:
+1. Install qemu via homebrew
+2. Run `qemu-system-x86_64`
+3. A segmentation fault error is produced
+Additional information:
+```
+raptor@fnord ~ % brew config
+HOMEBREW_VERSION: 4.4.32
+ORIGIN: https://github.com/Homebrew/brew
+HEAD: 12a3d4a6f1eedf483855716b989d828443438f79
+Last commit: 18 hours ago
+Branch: stable
+Core tap JSON: 23 Apr 08:36 UTC
+Core cask tap JSON: 23 Apr 08:36 UTC
+HOMEBREW_PREFIX: /opt/homebrew
+HOMEBREW_CASK_OPTS: []
+HOMEBREW_MAKE_JOBS: 8
+Homebrew Ruby: 3.3.8 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.3.8/bin/ruby
+CPU: octa-core 64-bit arm_ibiza
+Clang: 16.0.0 build 1600
+Git: 2.39.5 => /Library/Developer/CommandLineTools/usr/bin/git
+Curl: 8.7.1 => /usr/bin/curl
+macOS: 15.3.2-arm64
+CLT: 16.2.0.0.1.1733547573
+Xcode: N/A
+Rosetta 2: false
+
+raptor@fnord ~ % brew doctor
+Your system is ready to brew.
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2929 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2929
new file mode 100644
index 00000000..44fca419
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2929
@@ -0,0 +1,7 @@
+Ask to extend vhost-user protocol to carry implementation defined error contexts
+Additional information:
+I am working on the Google [crosvm](https://chromium.googlesource.com/crosvm/crosvm/) project, which implements some `vhost-user` clients/servers defined by [this QEMU doc](https://qemu-project.gitlab.io/qemu/interop/vhost-user.html). I am wondering if we could add a protocol feature/protocol header flag bit to allow the payload of the reply to carry detailed implementation defined error contexts?
+
+Specifically, I am working on the `vhost-user-gpu` device, which needs to send some memory mapping request to the frontend(the main process where VCPU lives), so that we can map some GPU memory to the guest. We are trying to diagnose a bug where the frontend can sometimes fail to perform the operation. However, we don't have access to the logs on the main process, so we are left with only very limited information on the `vhost-user-gpu` process. It could be helpful if we could send detailed implementation defined error contexts in the payload of the reply.
+
+I am wondering in order for the upstream QEMU to accept such "spec" change to the `vhost-user` protocol, what the process should be like? Thanks.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2931 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2931
new file mode 100644
index 00000000..03dfc930
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2931
@@ -0,0 +1,26 @@
+riscv: satp invalid while kvm set to cpu host
+Description of problem:
+After boot, no "mmu-type" in dtb
+```
+ cpu@0 {                                                                                        
+                                                                                                
+         phandle = <0x7>;                                                                       
+         device_type = "cpu";                                                                   
+         reg = <0x0>;                                                                           
+         status = "okay";                                                                       
+         compatible = "riscv";                                                                  
+         riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "zicntr", "zicsr", "zifencei", "zi
+bb";                                                                                            
+         riscv,isa-base = "rv64i";                                                              
+         riscv,isa = "rv64imafdc_zicntr_zicsr_zifencei_zihpm_zba_zbb";                                                                                   
+         interrupt-controller {                                                                 
+                                                                                                
+                 #interrupt-cells = <0x1>;                                                      
+                 interrupt-controller;                                                          
+                 compatible = "riscv,cpu-intc";                                                 
+                 phandle = <0x8>;                                                               
+         };                                                                                     
+ };                                                                                             
+```
+Steps to reproduce:
+1. boot any qemu with `-cpu host`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2932 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2932
new file mode 100644
index 00000000..6bcec1fd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2932
@@ -0,0 +1 @@
+QEMU flag fuzz targets not WAI
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2933 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2933
new file mode 100644
index 00000000..3be0d30a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2933
@@ -0,0 +1,22 @@
+After updating QEMU to 10.0, XNU kernel of OS X 10.8 throws kernel panic (type=0 divide error)
+Description of problem:
+Before updating to QEMU 10.0, my OS X 10.8 installation has worked pretty clear, but after QEMU update, XNU kernel now throws divide error during the boot.
+Steps to reproduce:
+1. Install OS X 10.8 on QEMU <10.0, for example 9.2.3.
+2. Update QEMU to 10.0 version
+3. Launch OS X
+Additional information:
+Screenshot of the issue:
+![Screenshot_2025-04-25_at_17.29.51](/uploads/b961258103a778ed8f12d036b3518eeb/Screenshot_2025-04-25_at_17.29.51.png)
+
+OpenCore config (not changed before update, so above suspicion):
+[config.plist](/uploads/4b80b60f9497e5ecd9237e4eeddcce8a/config.plist)
+
+Full OS X folder (without Installer.dmg):
+[OS_X_10.8.zip](/uploads/1af6150869495a8f196e18d18127011b/OS_X_10.8.zip)
+
+How I've done Installer.dmg:
+1. Go [here](https://updates.cdn-apple.com/2021/macos/031-0627-20210614-90D11F33-1A65-42DD-BBEA-E1D9F43A6B3F/InstallMacOSX.dmg)
+2. `xar -xf` to .pkg
+3. Show package contents to extracted .pkg
+4. Here it is: InstallESD.dmg, which I've renamed to Installer.dmg
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2934 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2934
new file mode 100644
index 00000000..586ed957
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2934
@@ -0,0 +1,64 @@
+RSS eBPF failed to load
+Description of problem:
+I am seeing a failure to load the eBPF program for rss steering.
+Steps to reproduce:
+1. Using libvirt, enable rss='on' for the vhost driver.
+2.
+3.
+Additional information:
+Libvirt log:
+```
+libbpf: prog 'tun_rss_steering_prog': BPF program load failed: Invalid argument
+libbpf: prog 'tun_rss_steering_prog': -- BEGIN PROG LOAD LOG --
+back-edge from insn 587 to 501
+processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0
+-- END PROG LOAD LOG --
+libbpf: prog 'tun_rss_steering_prog': failed to load: -22
+libbpf: failed to load object 'rss_bpf'
+libbpf: failed to load BPF skeleton 'rss_bpf': -22
+2025-04-26T09:22:19.054471Z qemu-system-x86_64: -device {"driver":"virtio-net-pci","packed":true,"tx":"bh","ioeventfd":true,"event_idx":true,"host_ecn":true,"mrg_rxbuf":true,"guest_ecn":true,"mq":true,"vectors":14,"rx_queue_size":1024,"tx_queue_size":256,"rss":true,"netdev":"hostnet0","id":"net0","mac":"52:54:00:c3:6f:c2","bus":"pci.1","addr":"0x0"}: warning: Unable to load eBPF program
+```
+[qemu-log.txt](/uploads/2d5e49a38a54297586a4b1f16423fc27/qemu-log.txt)
+
+XML:
+```xml
+   <interface type='bridge'>
+      <mac address='52:54:00:be:49:ff'/>
+      <source bridge='inet'/>
+      <model type='virtio'/>
+      <driver name='vhost' txmode='iothread' ioeventfd='on' event_idx='on' queues='6' rx_queue_size='1024' tx_queue_size='256' rss='on' packed='on'>
+        <host ecn='on' mrg_rxbuf='on'/>
+        <guest ecn='on'/>
+      </driver>
+      <link state='up'/>
+      <address type='pci' domain='0x0000' bus='0x08' slot='0x00' function='0x0'/>
+    </interface>
+```
+
+Host kernel .config:
+```
+❯ zcat /proc/config.gz |grep -i bpf
+CONFIG_BPF=y
+CONFIG_HAVE_EBPF_JIT=y
+CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
+# BPF subsystem
+CONFIG_BPF_SYSCALL=y
+CONFIG_BPF_JIT=y
+CONFIG_BPF_JIT_ALWAYS_ON=y
+CONFIG_BPF_JIT_DEFAULT_ON=y
+CONFIG_BPF_UNPRIV_DEFAULT_OFF=y
+# CONFIG_BPF_PRELOAD is not set
+# CONFIG_BPF_LSM is not set
+# end of BPF subsystem
+CONFIG_CGROUP_BPF=y
+CONFIG_NETFILTER_BPF_LINK=y
+CONFIG_NETFILTER_XT_MATCH_BPF=m
+CONFIG_NET_CLS_BPF=m
+CONFIG_NET_ACT_BPF=m
+CONFIG_BPF_STREAM_PARSER=y
+CONFIG_LWTUNNEL_BPF=y
+# HID-BPF support
+CONFIG_HID_BPF=y
+# end of HID-BPF support
+CONFIG_BPF_EVENTS=y
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2935 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2935
new file mode 100644
index 00000000..45fd099d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2935
@@ -0,0 +1,24 @@
+strchrnul detection not suitable for macOS
+Description of problem:
+When qemu is compiled on macOS 15.4, targeting an earlier macOS version (e.g., 15.1), and then run on this earlier macOS version (15.1), it segfaults. This is because:
+
+- the meson test for strchrnul succeeds (the function is present in the library)
+- the strchrnul function is therefore used
+- but that function was introduced in the system's libc in 15.4 only
+
+The root cause for the bug is that the meson test for strchrnul does not include the appropriate header. Indeed, see the documentation for meson on compiler.has_function (https://mesonbuild.com/Compiler-properties.html#does-a-function-exist)
+
+> Note that, on macOS programs can be compiled targeting older macOS versions than the one that the program is compiled on. It can't be assumed that the OS version that is compiled on matches the OS version that the binary will run on.
+> 
+> Therefore when detecting function availability with compiler.has_function(), it is important to specify the correct header in the prefix argument.
+
+The correct fix would be, in qemu's meson.build, to change:
+
+`cc.has_function('strchrnul')`
+
+into `cc.has_function('strchrnul', prefix : '#include <string>')`
+
+This is the recommended best practice and would allow correct detection on all platforms, including macOS.
+Steps to reproduce:
+1. Install qemu from Homebrew, which is built on macOS 15.4
+2. Run it on a machine with macOS < 15.4
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2937 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2937
new file mode 100644
index 00000000..7924cd50
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2937
@@ -0,0 +1 @@
+Request for Assistance: Properly Emulating USB Devices in QEMU for Custom USB Driver Testing
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2939 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2939
new file mode 100644
index 00000000..8e2d45bb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2939
@@ -0,0 +1 @@
+Add m68k board name called Macintosh llci
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/294 b/gitlab/issues_text/target_missing/host_missing/accel_missing/294
new file mode 100644
index 00000000..f998e37a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/294
@@ -0,0 +1 @@
+Keyboard keys get stuck
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2940 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2940
new file mode 100644
index 00000000..88267d9c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2940
@@ -0,0 +1 @@
+Fix i cant boot nextstep os in qemu m68k using next-cube
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2941 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2941
new file mode 100644
index 00000000..4ea71fd7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2941
@@ -0,0 +1 @@
+last chance add board called Macintosh llci
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2943 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2943
new file mode 100644
index 00000000..0f90795e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2943
@@ -0,0 +1,7 @@
+Please add a configurable for disabling, or by default disable, KVM_X86_QUIRK_IGNORE_GUEST_PAT on Intel host CPU
+Additional information:
+I am not familiar with QEMU code base or much programming in general. I did a quick grep through the latest QEMU sources pulled from this repository for the string `KVM_X86_QUIRK_IGNORE_GUEST_PAT`. It does not seem to occur anywhere which makes me think its existence and effect on QEMU users has gone unnoticed.
+
+If there is a handling of this flag which I have not noticed in the QEMU source code or documentation please guide me to where I can read about and probably configure it.
+
+Thank you.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2945 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2945
new file mode 100644
index 00000000..a29740c3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2945
@@ -0,0 +1,29 @@
+Commit da954d0e introduces a regression on sifive_unleashed when booting from SD card
+Description of problem:
+In U-Boot CI, we started to update from v8.2.0 to v9.2.3 and found that the sifive_unleashed target was failing to boot from SD card in our tests (we also test via SPI and this is fine). I have bisected the problem down to commit [da954d0e ("hw/sd/sdcard: Add spi_cmd_SEND_CSD/CID handlers (CMD9 & CMD10)")](https://gitlab.com/qemu-project/qemu/-/commit/da954d0e32444f122a41c24948d4d1c718bf66d4).
+
+When running QEMU we see the following output in the failure case as the only output:
+```
+U-Boot SPL 2025.07-rc1-00033-gad60d9792896 (May 01 2025 - 17:08:34 +0000)
+Trying to boot from MMC1
+spl: mmc init failed with error: -110
+Error: -110
+SPL: failed to boot from all boot devices
+#
+Steps to reproduce:
+1. wget -O - https://github.com/pengutronix/genimage/releases/download/v14/genimage-14.tar.xz | tar -C /tmp -xJ ; cd /tmp/genimage-14
+2. ./configure && make -j$(nproc)
+3. git clone https://source.denx.de/u-boot/u-boot.git; cd u-boot
+4. wget -O - https://github.com/riscv-software-src/opensbi/releases/download/v1.3.1/opensbi-1.3.1-rv-bin.tar.xz | tar -C /tmp -xJ
+5. export OPENSBI=/tmp/opensbi-1.3.1-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin
+6. make O=/tmp/sifive_unleashed CROSS_COMPILE=riscv64-linux- sifive_unleashed_defconfig
+7. make O=/tmp/sifive_unleashed CROSS_COMPILE=riscv64-linux- -sj$(nproc)
+8. mkdir -p root
+9. cp /tmp/sifive_unleashed/spl/u-boot-spl.bin .
+10. cp /tmp/sifive_unleashed/u-boot.itb .
+11. rm -rf tmp
+12. genimage --inputpath . --config board/sifive/unleashed/genimage_sdcard.cfg
+13. cp images/sdcard.img /tmp/sifive_unleashed/
+14. qemu-system-riscv64 -smp 5 -m 8G -nographic -M sifive_u,msel=11 -bios /tmp/sifive_unleashed/spl/u-boot-spl.bin -drive file=/tmp/sifive_unleashed/sdcard.img,format=raw,if=sd
+Additional information:
+The genimage tool is required for making the disk images used here. If building everything here is too much, I can provide the U-Boot binaries needed here out of band.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2946 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2946
new file mode 100644
index 00000000..953717b9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2946
@@ -0,0 +1,10 @@
+crypto/aes.c (used for emulating aes instructions) has a timing side-channel
+Description of problem:
+https://gitlab.com/qemu-project/qemu/-/blob/a9cd5bc6399a80fcf233ed0fffe6067b731227d8/crypto/aes.c#L1021
+
+much of the code in crypto/aes.c accesses memory arrays where the array index is based on the secret data being encrypted/decrypted. because of cpu caches and other things that can delay memory accesses based on their address, this is a timing side-channel, potentially allowing leaking secrets over a network based on timing how long cryptography operations take.
+
+compare to openssl which uses an algorithm where its execution time doesn't depend on the data being processed:
+https://github.com/openssl/openssl/commit/0051746e03c65f5970d8ca424579d50f58a877e0
+
+I initially reported this as a security issue, but was told that since it's only used by TCG, it isn't a security issue, since TCG isn't considered secure.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2947 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2947
new file mode 100644
index 00000000..8fc91087
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2947
@@ -0,0 +1,10 @@
+Tablet-like mouse under Linux guest even if no -device usb-tablet is specified
+Description of problem:
+Arch Linux guest has absolute mouse tracking even when there is `-nodefaults` and no -device usb-tablet is provided. The guest does not have qemu guest agent installed. This is the unwanted behavior. The expected behavior is that it has a separate mouse pointer under guest, like with Windows guest.
+Steps to reproduce:
+1. Install guest operating system
+2. Install gnome metapackage and enable GDM
+3. Reboot
+4. GDM has absolute mouse tracking and the mouse gets captured automatically, without having to click on the window or pressing Ctrl+Alt+G
+Additional information:
+[journalctl](/uploads/356952b8e2454c98e76ad82b700c518e/journalctl)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2948 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2948
new file mode 100644
index 00000000..ab3831f8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2948
@@ -0,0 +1,13 @@
+-display sdl causes mice with relative movement to read garbage offsets
+Description of problem:
+`-device virtio-mouse` and `-device usb-mouse` (and probably other mice which send relative mouse movement data) are behaving incorrectly under linux guest and jitter a lot. In this specific case it only seems to happen with `-display sdl` as I could not reproduce this same issue with other of the following configurations: `-display gtk` and `-display spice-app` running with virt-viewer.
+This behavior is not present when running a Windows guest with the same configuration using `-display sdl`
+
+Another weird side note: this behavior is less apparent when running `evtest` on the exact mouse device having issues.
+
+![Video_2025-05-05_20-11-56](/uploads/589d74106d2e9bb5713234de451f5326/Video_2025-05-05_20-11-56.mp4)
+Steps to reproduce:
+1. Install guest operating system
+2. Install gnome metapackage and enable GDM
+3. Reboot
+4. The mouse shows jittery motion on the GDM screen.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2949 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2949
new file mode 100644
index 00000000..2ac83975
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2949
@@ -0,0 +1,17 @@
+VNC: virtio-gpu outputs not displayed by VNC client
+Description of problem:
+When combining virtio-gpu multiple outputs with VNC display, only output 0 is enabled.
+Additional output are enabled when VNC client sent SetDesktopSize command.
+
+The following statement assumes that all displays (gtk, sdl) are disabled except VNC:
+
+#
+Steps to reproduce:
+1. Start Qemu
+2. Start a VNC client on 5900
+3. Start the second VNC client on 5901
+Additional information:
+The state of an output is controlled by the [enabled_output_bitmask](https://gitlab.com/qemu-project/qemu/-/blob/master/include/hw/virtio/virtio-gpu.h#L158) which is initialized to `1` at [device realization](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu-base.c#L204), thus VNC0 is always enabled.
+
+Other devices will set this parameter during inititliazation by calling [dpy_set_ui_info](https://gitlab.com/qemu-project/qemu/-/blob/master/ui/console.c#L754) which schedules a call to [virtio_gpu_ui_info](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu-base.c#L89). However VNC calls this function only when handling [VNC_MSG_CLIENT_SET_DESKTOP_SIZE](https://gitlab.com/qemu-project/qemu/-/blob/master/ui/vnc.c#L2607) client command.\
+If the client does not support this command or never changes the size of the default window, the respective display will remain disabled.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2950 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2950
new file mode 100644
index 00000000..08989a94
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2950
@@ -0,0 +1,65 @@
+QEMU 10 breaks Incus' NVME handling
+Description of problem:
+Incus is an open-source container and VM manager.
+For VMs we naturally use QEMU where we basically:
+ - Use QMP as much as possible to put together the VM prior to starting emulation
+ - Put the static pre-start stuff in a config file + use readconfig
+ - Keep the command line to a bare minimum
+
+This isn't particularly relevant to this issue except for the first point which is our use of QMP for most device handling. That means qemu is spawned without any disk or network attached. We have a `virtio-scsi` controller in the base config file but that's it.
+
+When doing NVME, we hotplug a new drive and a new nvme device pointing to that drive.
+This means that our setup has a 1:1 mapping between NVME controllers on the PCIe bus and drives.
+
+This worked great up until QEMU 10. With QEMU 10, I believe this commit https://gitlab.com/qemu-project/qemu/-/commit/cd59f50ab017183805a0dd82f5e85159ecc355ce by @birkelund now effectively causes the creation of a `nvme-subsys` device when we add a `nvme` device without a pre-existing subsystem.
+
+As `nvme-subsys` doesn't support hotplugging, this immediately breaks all our VMs that rely on NVME.
+
+```
+stgraber@dakara:~$ incus start test-nvme
+Error: Failed setting up device via monitor: Failed adding block device for disk device "root": Failed adding device: Device 'nvme-subsys' does not support hotplugging
+Try `incus info --show-log test-nvme` for more info
+```
+
+As you can see, QEMU returns `Device 'nvme-subsys' does not support hotplugging`.
+
+On the QMP front, we did:
+```
+stgraber@dakara:~$ sudo cat /var/log/incus/test-nvme/qemu.qmp.log
+[2025-05-06T11:42:30-04:00] QUERY: {"execute":"qom-get","arguments":{"path":"/machine","property":"type"}}
+[2025-05-06T11:42:30-04:00] REPLY: {"return": "pc-q35-10.0-machine"}
+
+[2025-05-06T11:42:30-04:00] QUERY: {"execute":"query-cpus-fast"}
+[2025-05-06T11:42:30-04:00] REPLY: {"return": [{"thread-id": 3885061, "props": {"core-id": 0, "thread-id": 0, "node-id": 0, "socket-id": 0}, "qom-path": "/machine/unattached/device[0]", "cpu-index": 0, "target": "x86_64"}]}
+
+[2025-05-06T11:42:30-04:00] QUERY: {"execute":"netdev_add","arguments":{"fds":"/dev/net/tun.0:/dev/net/tun.1","id":"incus_eth0","type":"tap","vhost":true,"vhostfds":"/dev/vhost-net.0:/dev/vhost-net.1"}}
+[2025-05-06T11:42:30-04:00] REPLY: {"return": {}}
+
+[2025-05-06T11:42:30-04:00] QUERY: {"execute":"device_add","arguments":{"addr":"00.0","bootindex":1,"bus":"qemu_pcie4","driver":"virtio-net-pci","id":"dev-incus_eth0","mac":"10:66:6a:30:97:66","mq":true,"netdev":"incus_eth0","vectors":6}}
+[2025-05-06T11:42:30-04:00] REPLY: {"return": {}}
+
+[2025-05-06T11:42:30-04:00] QUERY: {"execute":"blockdev-add","arguments":{"aio":"native","cache":{"direct":true,"no-flush":false},"discard":"unmap","driver":"host_device","filename":"/dev/fdset/0","locking":"off","node-name":"incus_root","read-only":false}}
+[2025-05-06T11:42:30-04:00] REPLY: {"return": {}}
+
+[2025-05-06T11:42:30-04:00] QUERY: {"execute":"device_add","arguments":{"addr":"00.0","bootindex":0,"bus":"qemu_pcie5","drive":"incus_root","driver":"nvme","id":"dev-incus_root","serial":"incus_root"}}
+[2025-05-06T11:42:30-04:00] QUERY: {"execute":"blockdev-del","arguments":{"node-name":"incus_root"}}
+[2025-05-06T11:42:30-04:00] REPLY: {"return": {}}
+
+[2025-05-06T11:42:30-04:00] QUERY: {"execute":"query-fdsets"}
+[2025-05-06T11:42:30-04:00] REPLY: {"return": [{"fds": [{"fd": 49, "opaque": "rdwr:incus_root"}], "fdset-id": 0}]}
+
+[2025-05-06T11:42:30-04:00] QUERY: {"execute":"remove-fd","arguments":{"fdset-id":0}}
+[2025-05-06T11:42:30-04:00] REPLY: {"return": {}}
+```
+Additional information:
+My limited understanding of NVME concepts is that NVME controllers are tied to a subsystem, then drives are tied to namespaces which themselves are tied to subsystems.
+
+So in a world where we need to deal with QEMU not supporting hotplugging subsystems, we would be able to create a single subsystem with a single controller and then hot plug/remove drives+namespaces into that.
+
+I've not actually tested this because to us it's not really an option.
+We have users that for better or for worse currently rely on the current behavior of having each drive have its own controller, and so on the Linux side expect to see one PCIe device per drive and then one `/dev/nvmeXn1` device per drive.
+
+Changing this to be multiple namespaces on controller 0 would break anyone who ever hardcoded /dev/nvmeXn1 on their system and may also lead to different performance characteristics due to now using a single controller. Multiple controllers would still be an option of course, but they'd be tied to the same subsystem and namespaces so effectively now having the guest do NVME multipath.
+
+
+Anyway, let me know if I'm missing a way to get QEMU 10 to behave as we did in releases prior, where I can start a VM with 0 NVME controllers, then add a couple of drives, each showing up as their own controller with the drive as namespace 1 on that.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2951 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2951
new file mode 100644
index 00000000..a1dc7009
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2951
@@ -0,0 +1,21 @@
+First byte of USB NIC is hardcoded to 0x40
+Description of problem:
+Incus recently added support for USB attached network interfaces.
+As with any network device, we generate a MAC address (using our MAC OUI) and allow the user to override that to a value of their choice.
+
+That's when we noticed that no matter what MAC address we set, the resulting MAC always has the prefix swapped to "40:". Looking into the code, this is done on purpose here:
+
+https://gitlab.com/qemu-project/qemu/-/blob/master/hw/usb/dev-network.c?ref_type=heads#L1386
+
+Unfortunately there is no comment in the code or in any of the commits touching that code as far as why that is.
+
+We've also looked at the libvirt code handling those devices and that code seems to also assume that a user provided MAC will be correctly passed through to the guest, no mention of the odd prefix override.
+
+This is a bit concerning as there are valid IEEE OUI with the "40:" prefix.
+So this means that QEMU may be generating collisions with actual physical MAC addresses...
+
+For a few months now, I've been applying this small patch to my own Incus packages (which bundle QEMU) and haven't heard or seen any obvious issue from the change.
+
+https://github.com/zabbly/incus/blob/daily/patches/qemu-0001-usb-net-mac.patch
+
+Does anyone know why this hardcoded MAC address prefix exists?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2952 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2952
new file mode 100644
index 00000000..15628b8c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2952
@@ -0,0 +1,14 @@
+Truncated bits while writing value to registers of RISC-V
+Description of problem:
+As mentioned above
+Steps to reproduce:
+```
+# 1. Compile the `test.S`:
+riscv32-unknown-linux-gnu-gcc -g -static -nostartfiles -o test hello.S
+
+# 2. Execute the binary:
+qemu-riscv32 ./test
+
+# 3. Check exit code
+echo $?
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2953 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2953
new file mode 100644
index 00000000..e4a26596
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2953
@@ -0,0 +1,66 @@
+"DMAR: DRHD: handling fault status reg 2" with vfio on kernel 6.13.11-200.fc41.x86_64, works with 6.13.9-200.fc41.x86_64
+Description of problem:
+Since kernel 6.13.11-200.fc41.x86_64, I cannot use VFIO to pass an NVIDIA GeForce GTX 1070 card to a Windows guest. The same setup works just fine in 6.13.9-200.fc41.x86_64. The issue symptoms are the same regardless if I use kernel command line arguments to isolate cpus or not.
+
+Symptoms:
+- qemu logs show:
+```
+2025-05-07T09:59:49.957891Z qemu-system-x86_64: vfio: Cannot reset device 0000:36:00.1, no available reset mechanism.
+2025-05-07T09:59:49.958444Z qemu-system-x86_64: vfio: Cannot reset device 0000:36:00.0, no available reset mechanism.
+2025-05-07T09:59:49.959119Z qemu-system-x86_64: vfio: Cannot reset device 0000:36:00.1, no available reset mechanism.
+2025-05-07T09:59:49.959635Z qemu-system-x86_64: vfio: Cannot reset device 0000:36:00.0, no available reset mechanism.
+```
+- in dmesg I see:
+```
+kernel: DMAR: DRHD: handling fault status reg 2
+kernel: DMAR: [INTR-REMAP] Request device [36:00.0] fault index 0x50 [fault reason 0x22] Present field in the IRTE entry is clear
+```
+- the VM hangs at boot (please see the notes below (*)).
+Steps to reproduce:
+Boot the same libvirt domain in kernel 6.13.9-200.fc41.x86_64 (works) and any other more recent kernel (>= 6.13.11-200.fc41.x86_64).
+Additional information:
+(*) Note that in a working kernel, the boot process is in any case finicky, and it shows these phases:
+1. tianocore logo shows, and one single cpu is fully utilized by the guest
+2. slowly, the loader find the Windows bootloader, and prints a message that it is loading and running it
+3. some time passes, while cpus seem idle
+4. finally the spinning wheel of the Windows bootloader appears
+
+Phase 1-3 can take anywhere from 0 to 60 seconds, in an apparently random manner.
+
+When running on the faulty kernels, it seems that the virtual machine gets stuck in phase 1, and I must use `virsh destroy` to interrupt it.
+
+lspci output:
+```
+-[0000:00]-+-00.0  Intel Corporation Tiger Lake-UP3/H35 4 cores Host Bridge/DRAM Registers
+           +-02.0  Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics]
+           +-04.0  Intel Corporation TigerLake-LP Dynamic Tuning Processor Participant
+           +-06.0-[01]----00.0  Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983
+           +-07.0-[02-33]--
+           +-0a.0  Intel Corporation Tigerlake Telemetry Aggregator Driver
+           +-0d.0  Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller
+           +-0d.2  Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #0
+           +-14.0  Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller
+           +-14.2  Intel Corporation Tiger Lake-LP Shared SRAM
+           +-15.0  Intel Corporation Tiger Lake-LP Serial IO I2C Controller #0
+           +-15.1  Intel Corporation Tiger Lake-LP Serial IO I2C Controller #1
+           +-15.2  Intel Corporation Tiger Lake-LP Serial IO I2C Controller #2
+           +-16.0  Intel Corporation Tiger Lake-LP Management Engine Interface
+           +-1c.0-[34]----00.0  Intel Corporation Wi-Fi 6 AX200
+           +-1c.5-[35]----00.0  Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader
+           +-1d.0-[36]--+-00.0  NVIDIA Corporation GP104 [GeForce GTX 1070]
+           |            \-00.1  NVIDIA Corporation GP104 High Definition Audio Controller
+           +-1f.0  Intel Corporation Tiger Lake-LP LPC Controller
+           +-1f.3  Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller
+           +-1f.4  Intel Corporation Tiger Lake-LP SMBus Controller
+           \-1f.5  Intel Corporation Tiger Lake-LP SPI Controller
+```
+
+kernel command line arguments (optimized with cpu isolation):
+```
+intel_pstate=per_cpu_perf_limits rd.driver.blacklist=nouveau modprobe.blacklist=nouveau module_blacklist=nouveau default_hugepagesz=1G hugepagesz=1G hugepages=13 i2c_i801.disable_features=0x10 rd.driver.pre=vfio_pci,vfio,vfio_iommu_type1 vfio-pci.ids=10de:1b81,10de:10f0 modprobe.blacklist=xpad systemd.unit=multi-user.target systemd.wants=bluetooth.service isolcpus=domain,managed_irq,1-3,5-7 rcu_nocbs=1-3,5-7 irqaffinity=0,4 nospectre_v2
+```
+
+kernel command line arguments (without cpu isolation, same symptoms):
+```
+intel_pstate=per_cpu_perf_limits rd.driver.blacklist=nouveau modprobe.blacklist=nouveau module_blacklist=nouveau default_hugepagesz=1G hugepagesz=1G hugepages=13 rd.driver.pre=vfio_pci,vfio,vfio_iommu_type1 vfio-pci.ids=10de:1b81,10de:10f0 modprobe.blacklist=xpad systemd.unit=multi-user.target systemd.wants=bluetooth.service
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2955 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2955
new file mode 100644
index 00000000..ad8db235
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2955
@@ -0,0 +1 @@
+Mellanox IRQs Still Showing In Host OS After Passthrough
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2958 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2958
new file mode 100644
index 00000000..58917791
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2958
@@ -0,0 +1,18 @@
+Vvfat crashes in WinXP-64 installation.
+Description of problem:
+
+Steps to reproduce:
+1. Download ISO (see above)
+2. Set up qemu
+3. Run command above
+
+Termux output:
+qemu-system-x86_64: Slirp: Failed to send packet, ret: -1 [repeated]
+
+../block/vvfat.c:105: void *array_get(array_t *, unsigned int): assertion "index < array->next" failed
+Aborted
+~ $
+Additional information:
+This was extremely annoying because the total abort occurs far into the installation, while setting up the network. The devices (presumably including the vvfat) had been installed OK. The XP installation can be restarted without the CD but starts at the beginning, needing location, passwords, licence key etc. all over again! I have XP64 installed now, without vvfat which is a marvellously convenient way of transferring files.
+
+BTW "vfat" usually means extended FAT, handling files over 4GB but vvfat does not. Can you fix that?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2959 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2959
new file mode 100644
index 00000000..177f4e75
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2959
@@ -0,0 +1,77 @@
+int 0x10 teletype output cuts final character in custom MBR on QEMU (i386 real mode)
+Description of problem:
+When using QEMU to test a custom bootloader in 16-bit real mode (i386), the BIOS interrupt `int 0x10` with AH=0x0E (teletype output) fails to display the last character of the printed message. For example, printing `"hello"` only renders `"hell"`.
+
+This happens only with this exact combination:
+
+real mode `int 0x10` teletype output
+
+message ends with `13, 10, 0`
+
+`QEMU` output cuts off the last character consistently
+
+All buffer and code logic has been verified to be correct. The same code, when run on Bochs or physical hardware, prints properly.
+Steps to reproduce:
+1.Assemble the following boot.asm:
+```nasm
+[org 0x7C00]
+[BITS 16]
+
+_start:
+    cli
+    xor ax, ax
+    mov ds, ax
+    mov es, ax
+    mov ss, ax
+    mov sp, 0x7C00
+
+    mov si, msg
+    call print
+
+    hlt
+    jmp $
+
+print:
+    pusha
+.loop:
+    lodsb
+    or al, al
+    jz .done
+    mov ah, 0x0E
+    int 0x10
+    jmp .loop
+.done:
+    popa
+    ret
+
+msg db 'hello', 13, 10, 0
+times 510 - ($ - $$) db 0
+dw 0xAA55
+```
+
+2. Compile and run:
+```bash
+$ nasm -f bin boot.asm -o boot.img
+$ qemu-system-i386 -nographic -boot a -drive format=raw,file=boot.img,index=0,if=floppy
+```
+
+3. Output will be:
+```text
+Booting from Floppy...
+hell
+```
+Expected output:
+```text
+Booting from Floppy...
+hello
+```
+Additional information:
+- Adding padding (extra 13, 10) does not solve the problem.
+
+- Confirmed that boot.img includes all bytes (xxd dump is correct).
+
+- Tested on multiple machines with same QEMU version.
+
+- May relate to VGA character output buffer not flushing after last INT 0x10?
+
+- This makes QEMU inaccurate for BIOS-level debugging of bootloaders.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/296 b/gitlab/issues_text/target_missing/host_missing/accel_missing/296
new file mode 100644
index 00000000..4d3f6ac9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/296
@@ -0,0 +1 @@
+Enabling OpenGL for GUI doesn't work on old laptop
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2960 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2960
new file mode 100644
index 00000000..2af7f34f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2960
@@ -0,0 +1,10 @@
+Mouse doesn't work correctly with SDL display backend
+Description of problem:
+The mouse starts moving like crazy, up and down or left and right.
+I tested it with -accel on and off, I make some test and seems to be the SDL display backed(GTK just crash before start execution of the vm).
+Steps to reproduce:
+1.Install Linux Mint 22.1
+2.Execute the command above.
+3.Log in and the problems start.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2962 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2962
new file mode 100644
index 00000000..43f4258c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2962
@@ -0,0 +1,22 @@
+DHCP UDP checksum workaround code appears to be broken
+Description of problem:
+I am running dnsmasq DHCP server in an lxc-container.  It is using a VETH pair for the network.  The VETH device on the host is in a bridge.  I create a TAP device and place it in the bridge.  When booting the guest, I notice that the DHCP OFFER has an invalid UDP checksum all the way through the bridge and into the guest.  I am able to fix this by disabling checksum offload inside the container, or adding an nftables rule that zeros out the checksum, or by reverting commit 7987d2be5a8bc3a502f89ba8cf3ac3e09f64d1ce.
+Steps to reproduce:
+1. From a debian 12 host, `apt-get install lxc lxc-templates`
+2. `ip link add brtest type bridge`
+3. `ip link set brtest up`
+4. Create a container: `lxc-create -n dhcp -t debian -- --package=dnsmasq`
+5. Edit the lxc container file `/var/lib/lxc/dhcp/config` and make sure the link is properly set to `lxc.net.0.link = brtest`, the type is set to `veth`, and give it an IP `lxc.net.0.ipv4.address = 192.168.255.1/24`
+6. Start the container: `lxc-start -n dhcp`
+7. Attach to the container: `lxc-attach -n dhcp`
+8. Stop dnsmasq and networking: `systemctl stop dnsmasq.service networking.service`
+9. Run a DHCP server: `dnsmasq --dhcp-authoritative --dhcp-range=192.168.255.2,192.168.255.254,255.255.255.0,1h --dns-loop-detect`
+10. Exit the container: `exit`
+11. Download the linux mint 22.1 installer: https://linuxmint.com/edition.php?id=319
+12. Create a TAP device and throw it in the bridge: `ip tuntap add dev taptest mode tap` .. `ip link set dev taptest up master brtest`
+13. Run qemu: `qemu-system-x86_64 -enable-kvm -smp 4,sockets=1,threads=1 -machine pc-q35-9.2,accel=kvm,kernel_irqchip=on -m 4096 -device virtio-net-pci,netdev=nic91 -netdev tap,id=nic91,ifname=taptest,script=no,downscript=no -cdrom linuxmint-22.1-cinnamon-64bit.iso` .. I run it with vnc as this is on a headless server.
+14. Once the guest has booted, you can run a tcpdump on the NIC and see that the guest receives the DHCP offer, but the UDP checksum is bunk.
+Additional information:
+I was able to test reverting the commit 7987d2be5a8bc3a502f89ba8cf3ac3e09f64d1ce and that appears to function once again.
+
+![image](/uploads/1d649230eabee269f78031eb0b2de265/image.png){width=901 height=38}
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2963 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2963
new file mode 100644
index 00000000..e791869d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2963
@@ -0,0 +1,24 @@
+QEMU crash with `qemu_mutex_unlock_impl: Operation not permitted` during block device operations
+Description of problem:
+We got a crash when I use a blockdev-add command while a blockdev-backup operation was nearly complete. The crash does not reproduce consistently.
+
+This message was printed in the QEMU debug log.
+`qemu: qemu_mutex_unlock_impl: Operation not permitted`
+
+We also collected a coredump at the time of the crash. but, when analyzing the coredump using gdb, the call stack only shows ?? for all frames, making it difficult to diagnose the root cause.
+
+so I have two main questions:
+
+1. Under what circumstances does `qemu_mutex_unlock_impl: Operation not permitted` occur? 
+Is there any known cause or workaround for this kind of crash?
+
+2. What should be done to ensure that the call stack in a coredump is visible? 
+Are there specific build flags or debug symbol requirements we should be aware of?
+We built QEMU with --enable-debug, but the call stack still shows only ?? in gdb when analyzing the core dump.
+Steps to reproduce:
+1. Start a VM with block devices configured.
+2. Begin a blockdev-backup operation.
+3. Near the completion of the blockdev-backup, issue a blockdev-add command for another device.
+4. Observe a crash. (The crash does not reproduce consistently)
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2964 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2964
new file mode 100644
index 00000000..94df2120
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2964
@@ -0,0 +1,9 @@
+How to get the icount value after qemu terminal exit
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+/label ~"kind::Bug"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2965 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2965
new file mode 100644
index 00000000..98bedb9d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2965
@@ -0,0 +1,14 @@
+crash when interacting with the UI in any way during record/replay mode on macOS
+Description of problem:
+```
+**
+ERROR:../replay/replay-events.c:119:replay_add_event: assertion failed: (replay_mutex_locked())
+Bail out! ERROR:../replay/replay-events.c:119:replay_add_event: assertion failed: (replay_mutex_locked())
+fish: Job 1, 'qemu-system-x86_64 -icount shif…' terminated by signal SIGABRT (Abort)
+```
+Steps to reproduce:
+1. run the qemu command
+2. click in the window
+3. observe crash
+Additional information:
+[qemu-system-x86_64-2025-05-15-032037.ips](/uploads/2cccc7b967dacc8a18be8a3d0a0cf297/qemu-system-x86_64-2025-05-15-032037.ips)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2967 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2967
new file mode 100644
index 00000000..8b86b143
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2967
@@ -0,0 +1,214 @@
+Heavy graphic glitches when using Virtio with 3D acceleration
+Description of problem:
+Virtio with 3D acceleration enabled under "Video" and the corresponding OpenGL activated under "Display" with Spice leads to heavy artifacts in the graphical console.
+
+This error has been observed on Arch Linux with Intel Meteor Lake CPU (Intel Arc Graphics iGPU) as well as on OpenSuse Tumbleweed with Intel Kaby Lake CPU (Intel HD 630 iGPU)
+
+![virtio_without_acceleration](/uploads/4a05041c944493736f22a013b74c5089/virtio_without_acceleration.png)
+(virtio without acceleration enabled)
+
+![Glitch_virtmanager_virtio](/uploads/50602ff94dc22f20af77c4b8d487a22d/Glitch_virtmanager_virtio.png)
+(Same VM, same settings, but with 3D acceleration and OpenGL enabled)
+
+![signal-2024-11-09-132624_002](/uploads/afe1ddedc17725ad9db21eb6f4e1554d/signal-2024-11-09-132624_002.png)
+(Same issue on a fresh install of OpenSuse Tumbleweed on a system that is in no way linked to the first one)
+Steps to reproduce:
+1. Enable Virtio Graphics with 3D acceleration under "Video".
+2. Activate the corresponding OpenGL under "Spice".
+3. Start the VM and open the graphical console.
+Additional information:
+XML config:
+
+```
+<domain type='kvm'>
+  <name>debian12</name>
+  <uuid>1d39d86a-b341-47bb-9847-4c78da9df863</uuid>
+  <metadata>
+    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
+      <libosinfo:os id="http://debian.org/debian/12"/>
+    </libosinfo:libosinfo>
+  </metadata>
+  <memory unit='KiB'>4194304</memory>
+  <currentMemory unit='KiB'>4194304</currentMemory>
+  <vcpu placement='static'>4</vcpu>
+  <os firmware='efi'>
+    <type arch='x86_64' machine='pc-q35-9.1'>hvm</type>
+    <firmware>
+      <feature enabled='no' name='enrolled-keys'/>
+      <feature enabled='no' name='secure-boot'/>
+    </firmware>
+    <loader readonly='yes' type='pflash'>/usr/share/edk2/x64/OVMF_CODE.4m.fd</loader>
+    <nvram template='/usr/share/edk2/x64/OVMF_VARS.4m.fd'>/var/lib/libvirt/qemu/nvram/debian12_VARS.fd</nvram>
+    <boot dev='hd'/>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+    <vmport state='off'/>
+  </features>
+  <cpu mode='host-passthrough' check='none' migratable='on'/>
+  <clock offset='utc'>
+    <timer name='rtc' tickpolicy='catchup'/>
+    <timer name='pit' tickpolicy='delay'/>
+    <timer name='hpet' present='no'/>
+  </clock>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>destroy</on_crash>
+  <pm>
+    <suspend-to-mem enabled='no'/>
+    <suspend-to-disk enabled='no'/>
+  </pm>
+  <devices>
+    <emulator>/usr/bin/qemu-system-x86_64</emulator>
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2' discard='unmap'/>
+      <source file='/var/lib/libvirt/images/debian12.qcow2'/>
+      <target dev='vda' bus='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
+    </disk>
+    <disk type='file' device='cdrom'>
+      <driver name='qemu' type='raw'/>
+      <target dev='sda' bus='sata'/>
+      <readonly/>
+      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+    </disk>
+    <controller type='usb' index='0' model='qemu-xhci' ports='15'>
+      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
+    </controller>
+    <controller type='pci' index='0' model='pcie-root'/>
+    <controller type='pci' index='1' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='1' port='0x10'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
+    </controller>
+    <controller type='pci' index='2' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='2' port='0x11'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
+    </controller>
+    <controller type='pci' index='3' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='3' port='0x12'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
+    </controller>
+    <controller type='pci' index='4' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='4' port='0x13'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
+    </controller>
+    <controller type='pci' index='5' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='5' port='0x14'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
+    </controller>
+    <controller type='pci' index='6' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='6' port='0x15'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
+    </controller>
+    <controller type='pci' index='7' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='7' port='0x16'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/>
+    </controller>
+    <controller type='pci' index='8' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='8' port='0x17'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x7'/>
+    </controller>
+    <controller type='pci' index='9' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='9' port='0x18'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/>
+    </controller>
+    <controller type='pci' index='10' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='10' port='0x19'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/>
+    </controller>
+    <controller type='pci' index='11' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='11' port='0x1a'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x2'/>
+    </controller>
+    <controller type='pci' index='12' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='12' port='0x1b'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x3'/>
+    </controller>
+    <controller type='pci' index='13' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='13' port='0x1c'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x4'/>
+    </controller>
+    <controller type='pci' index='14' model='pcie-root-port'>
+      <model name='pcie-root-port'/>
+      <target chassis='14' port='0x1d'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x5'/>
+    </controller>
+    <controller type='sata' index='0'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
+    </controller>
+    <controller type='virtio-serial' index='0'>
+      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
+    </controller>
+    <interface type='network'>
+      <mac address='52:54:00:d6:22:67'/>
+      <source network='default'/>
+      <model type='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
+    </interface>
+    <serial type='pty'>
+      <target type='isa-serial' port='0'>
+        <model name='isa-serial'/>
+      </target>
+    </serial>
+    <console type='pty'>
+      <target type='serial' port='0'/>
+    </console>
+    <channel type='unix'>
+      <target type='virtio' name='org.qemu.guest_agent.0'/>
+      <address type='virtio-serial' controller='0' bus='0' port='1'/>
+    </channel>
+    <channel type='spicevmc'>
+      <target type='virtio' name='com.redhat.spice.0'/>
+      <address type='virtio-serial' controller='0' bus='0' port='2'/>
+    </channel>
+    <input type='tablet' bus='usb'>
+      <address type='usb' bus='0' port='1'/>
+    </input>
+    <input type='mouse' bus='ps2'/>
+    <input type='keyboard' bus='ps2'/>
+    <graphics type='spice'>
+      <listen type='none'/>
+      <image compression='off'/>
+      <gl enable='yes'/>
+    </graphics>
+    <sound model='ich9'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
+    </sound>
+    <audio id='1' type='spice'/>
+    <video>
+      <model type='virtio' heads='1' primary='yes'>
+        <acceleration accel3d='yes'/>
+      </model>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
+    </video>
+    <redirdev bus='usb' type='spicevmc'>
+      <address type='usb' bus='0' port='2'/>
+    </redirdev>
+    <redirdev bus='usb' type='spicevmc'>
+      <address type='usb' bus='0' port='3'/>
+    </redirdev>
+    <watchdog model='itco' action='reset'/>
+    <memballoon model='virtio'>
+      <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
+    </memballoon>
+    <rng model='virtio'>
+      <backend model='random'>/dev/urandom</backend>
+      <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
+    </rng>
+  </devices>
+</domain>
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2968 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2968
new file mode 100644
index 00000000..1b49d64b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2968
@@ -0,0 +1,22 @@
+Regression: x-igd-opregion=off ignored in VFIO IGD quirk handling
+Description of problem:
+A regression in QEMU’s VFIO IGD initialization causes the `x-igd-opregion=off` parameter to be ignored, resulting in an error when passing through an Intel iGPU SR-IOV Virtual Function (VF) at PCI address `00:02.1`: `qemu-system-x86_64: -device vfio-pci,host=0000:00:02.1,...: Device does not supports IGD OpRegion feature: No such device`
+Automatic detection of IGD-OpRegion assumes any Intel iGPU (including GVT-g) will have it but SR-IOV VFs do not.
+Steps to reproduce:
+1. Configure an Intel iGPU with SR-IOV enabled, creating a VF at `00:02.1`.
+2. Bind the VF to the `vfio-pci` driver:
+```
+    echo 0000:00:02.1 > /sys/bus/pci/drivers/i915/unbind
+    either:
+      echo "8086 4680" > /sys/bus/pci/drivers/vfio-pci/new_id
+    or:
+      echo 0000:00:02.1 > /sys/bus/pci/drivers/vfio-pci/bind
+```
+3. Run QEMU with the command line above, including `-device vfio-pci,host=0000:00:02.1,...,x-igd-opregion=off`.
+Additional information:
+- **Hardware details**:
+  - `00:02.1 VGA compatible controller [0300]: Intel Corporation AlderLake-S GT1 [8086:4680] (rev 0c)`
+  - Host motherboard: MSI PRO Z690-A DDR4
+  - CPU: Intel Core i5 12600K
+- **Regression cause**: The issue was introduced by commit 7be29f2f1a3f5b037d27eedbd5df9f441e8c8c16, which changed `vfio_pci_igd_config_quirk` to detect OpRegion automatically, ignoring `vdev->igd_opregion=false`.
+- **Proposed fix**: I have a patch that adds checks for `vdev->igd_opregion` in `vfio_pci_igd_config_quirk` and `vfio_pci_kvmgt_config_quirk`, skipping OpRegion handling when `x-igd-opregion=off`. The patch has been tested, confirming the VM starts without errors. I will submit it to qemu-devel@nongnu.org with a reference to this issue.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2969 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2969
new file mode 100644
index 00000000..ebe071dc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2969
@@ -0,0 +1,212 @@
+Raspberry Pi 4 Model B Rev 1.5 ("raspi4b"): No keyboard input after booting; "raspi3b" works
+Description of problem:
+I am using a `non-root` setup.
+
+#
+Steps to reproduce:
+1. Install `latest` QEMU version from `Master branch`. As of writing commit hash `757a34115e7491744a63dfc3d291fd1de5297ee2`:
+```bash
+$ ACCEPT_KEYWORDS="**" \
+USE="qemu_softmmu_targets_aarch64 qemu_softmmu_targets_x86_64 qemu_user_targets_aarch64 qemu_user_targets_x86_64 -ncurses slirp spice virtfs aio alsa bzip2 curl dock fdt filecaps gnutls jpeg oss pam pin-upstream-blobs png pulseaudio python_targets_python3_12 python_targets_python3_13 seccomp slirp spice udev usb vhost-net virtfs vnc xattr zstd" \
+emerge --oneshot =app-emulation/qemu-9999
+```
+
+All `USE flags` can be found [below](#use-flags-app-emulationqemu).
+
+2. Install `slirp4netns`, `libslirp` and `tigervnc`:
+```bash
+$ USE="-opengl -server" emerge --oneshot =app-containers/slirp4netns-1.2.0 =net-libs/libslirp-4.7.0 =net-misc/tigervnc-1.15.0
+```
+
+All `USE flags` can be found [below](#use-flags-net-misctigervnc).
+
+3. Prepare directory structure in the `current working directory`:
+```bash
+$ mkdir "rpi3_model_b/" "rpi4_model_b_rev1.5/"
+```
+
+4. Download `DTB` and `Kernel image files` from the [`Raspberry Pi firmware Git repository`](https://github.com/raspberrypi/firmware/tree/0ea28740607daed588912930379ed6ad40cfc4be/boot):
+```bash
+$ wget "https://github.com/raspberrypi/firmware/raw/0ea28740607daed588912930379ed6ad40cfc4be/boot/bcm2710-rpi-3-b.dtb" \
+    --output-document="./rpi3_model_b/bcm2710-rpi-3-b_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.dtb"
+$ wget "https://github.com/raspberrypi/firmware/raw/0ea28740607daed588912930379ed6ad40cfc4be/boot/bcm2711-rpi-4-b.dtb" \
+    --output-document="./rpi4_model_b_rev1.5/bcm2711-rpi-4-b_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.dtb"
+$ wget "https://github.com/raspberrypi/firmware/raw/0ea28740607daed588912930379ed6ad40cfc4be/boot/kernel8.img" \
+    --output-document="./kernel8_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.img"
+```
+
+5. Download, verify and extract `Raspberry Pi OS Lite` image files:
+```bash
+$ wget \
+    "https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_arm64-2024-11-19/2024-11-19-raspios-bookworm-arm64-lite.img.xz" \
+    "https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_arm64-2024-11-19/2024-11-19-raspios-bookworm-arm64-lite.img.xz.sha256" \
+    "https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_arm64-2024-11-19/2024-11-19-raspios-bookworm-arm64-lite.img.xz.sig" \
+    "https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_arm64-2025-05-13/2025-05-13-raspios-bookworm-arm64-lite.img.xz" \
+    "https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_arm64-2025-05-13/2025-05-13-raspios-bookworm-arm64-lite.img.xz.sha256" \
+    "https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_arm64-2025-05-13/2025-05-13-raspios-bookworm-arm64-lite.img.xz.sig"
+$ sha256sum --check *.sha256
+2024-11-19-raspios-bookworm-arm64-lite.img.xz: OK
+2025-05-13-raspios-bookworm-arm64-lite.img.xz: OK
+$ for i in *.sig; do echo "${i}"; gpg --verify "${i}" "${i%\.sig}"; done
+2024-11-19-raspios-bookworm-arm64-lite.img.xz.sig
+gpg: Signature made Tue Nov 19 15:51:51 2024 CET
+gpg:                using RSA key 54C3DD610D9D1B4AF82A37758738CD6B956F460C
+gpg: Good signature from "Raspberry Pi Downloads Signing Key" [full]
+2025-05-13-raspios-bookworm-arm64-lite.img.xz.sig
+gpg: Signature made Tue May 13 08:52:21 2025 CEST
+gpg:                using RSA key 54C3DD610D9D1B4AF82A37758738CD6B956F460C
+gpg: Good signature from "Raspberry Pi Downloads Signing Key" [full]
+$ for i in *.xz; do pixz -d "${i}"; done
+$ LS_COLORS="" tree -FC --noreport
+./
+├── 2024-11-19-raspios-bookworm-arm64-lite.img.xz.sha256
+├── 2024-11-19-raspios-bookworm-arm64-lite.img.xz.sig
+├── 2024-11-19-raspios-bookworm-arm64-lite.img
+├── 2025-05-13-raspios-bookworm-arm64-lite.img.xz.sha256
+├── 2025-05-13-raspios-bookworm-arm64-lite.img.xz.sig
+├── 2025-05-13-raspios-bookworm-arm64-lite.img
+├── kernel8_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.img
+├── rpi3_model_b/
+│   ├── bcm2710-rpi-3-b_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.dtb
+└── rpi4_model_b_rev1.5/
+    └── bcm2711-rpi-4-b_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.dtb
+```
+
+6. Grow `image size` to make it be a `power of 2`:
+```bash
+$ qemu-img resize -f raw "./2024-11-19-raspios-bookworm-arm64-lite.img" 4G
+Image resized.
+$ qemu-img resize -f raw "./2025-05-13-raspios-bookworm-arm64-lite.img" 4G
+Image resized.
+```
+
+7. Get `DTB` and `Kernel images files` from the `Raspberry Pi OS image files`, prepare a `user` and `SSHD`:
+```bash
+$ losetup --find --partscan --show "./2024-11-19-raspios-bookworm-arm64-lite.img"
+/dev/loop0
+$ mount "/dev/loop0p1" "/mnt/"
+$ cp "/mnt/bcm2710-rpi-3-b.dtb" "./rpi3_model_b/bcm2710-rpi-3-b_2024-11-19.dtb"
+$ cp "/mnt/bcm2711-rpi-4-b.dtb" "./rpi4_model_b_rev1.5/bcm2711-rpi-4-b_2024-11-19.dtb"
+$ cp "/mnt/kernel8.img" "./kernel8_2024-11-19.img"
+$ touch "/mnt/ssh"
+$ echo "pi:$(openssl passwd -6)" > "/mnt/userconf"
+Password: 1234
+Verifying - Password: 1234
+$ umount "/mnt/"
+$ losetup --find --partscan --show "./2025-05-13-raspios-bookworm-arm64-lite.img"
+/dev/loop1
+$ mount "/dev/loop1p1" "/mnt/"
+$ cp "/mnt/bcm2710-rpi-3-b.dtb" "./rpi3_model_b/bcm2710-rpi-3-b_2025-05-13.dtb"
+$ cp "/mnt/bcm2711-rpi-4-b.dtb" "./rpi4_model_b_rev1.5/bcm2711-rpi-4-b_2025-05-13.dtb"
+$ cp "/mnt/kernel8.img" "./kernel8_2025-05-13.img"
+$ touch "/mnt/ssh"
+$ echo "pi:$(openssl passwd -6)" > "/mnt/userconf"
+Password: 1234
+Verifying - Password: 1234
+$ umount "/mnt/"
+$ losetup --list
+NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                                                                  DIO LOG-SEC
+/dev/loop1         0      0         0  0 /home/<some_username>/qemu/2025-05-13-raspios-bookworm-arm64-lite.img   0     512
+/dev/loop0         0      0         0  0 /home/<some_username>/qemu/2024-11-19-raspios-bookworm-arm64-lite.img   0     512
+$ losetup --detach "/dev/loop0" "/dev/loop1"
+$ losetup --list
+$ LS_COLORS="" tree -FC --noreport
+./
+├── 2024-11-19-raspios-bookworm-arm64-lite.img
+├── 2024-11-19-raspios-bookworm-arm64-lite.img.xz.sha256
+├── 2024-11-19-raspios-bookworm-arm64-lite.img.xz.sig
+├── 2025-05-13-raspios-bookworm-arm64-lite.img
+├── 2025-05-13-raspios-bookworm-arm64-lite.img.xz.sha256
+├── 2025-05-13-raspios-bookworm-arm64-lite.img.xz.sig
+├── kernel8_2024-11-19.img
+├── kernel8_2025-05-13.img
+├── kernel8_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.img
+├── rpi3_model_b/
+│   ├── bcm2710-rpi-3-b_2024-11-19.dtb
+│   ├── bcm2710-rpi-3-b_2025-05-13.dtb
+│   ├── bcm2710-rpi-3-b_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.dtb
+└── rpi4_model_b_rev1.5/
+    ├── bcm2711-rpi-4-b_2024-11-19.dtb
+    ├── bcm2711-rpi-4-b_2025-05-13.dtb
+    └── bcm2711-rpi-4-b_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.dtb
+```
+
+8. Execute the first `qemu-system-aarch64` command at `QEMU command line` [above](#host-environment):
+```bash
+$ qemu-system-aarch64 \
+    -vnc "unix:/run/user/$(id --user)/qemu-vnc.sock"
+    [...]
+```
+
+8.1. Warnings will be returned:
+
+`raspi4b`:
+```no-highlight
+qemu-system-aarch64: warning: bcm2711 dtc: brcm,bcm2711-pcie has been disabled!
+qemu-system-aarch64: warning: bcm2711 dtc: brcm,bcm2711-rng200 has been disabled!
+qemu-system-aarch64: warning: bcm2711 dtc: brcm,bcm2711-thermal has been disabled!
+qemu-system-aarch64: warning: bcm2711 dtc: brcm,bcm2711-genet-v5 has been disabled!
+```
+
+`raspi3b`:
+```no-highlight
+usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa
+usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa
+usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa
+```
+
+9. Connect via `VNC` via `UNIX socket`:
+```bash
+$ vncviewer "/run/user/$(id --user)/qemu-vnc.sock"
+```
+
+10. Press and hold the `f key` or `right arrow` in the `tigervnc window`, even while booting. There should be **no** characters at all. For `raspi3b` there will be.
+
+11. Open the `QEMU console` via `CTRL+ALT+2`.
+
+11.1. Try to send a `reboot command`:
+```bash
+> sendkey ctrl-alt-delete
+```
+
+11.2. `Raspberry Pi OS` will **not** reboot or receive any keyboard inputs, but `raspi3b` will.
+
+12. Try to connect via `SSH` from `another shell`:
+```bash
+$ ssh -p 2222 pi@127.0.0.1
+```
+
+12.1. The connection will time out:
+```no-highlight
+Connection timed out during banner exchange
+Connection to 127.0.0.1 port 2222 timed out
+```
+
+12.2. `slirp4netns` will continuously return errors in the shell, where `qemu-system-aarch64` was executed:
+```no-highlight
+[...]
+qemu-system-aarch64: Slirp: Failed to send packet, ret: -1
+qemu-system-aarch64: Slirp: Failed to send packet, ret: -1
+[...]
+```
+
+13. Go to the shell, where `qemu-system-aarch64` was executed and send a `SIGTERM (15)` signal to the process:
+```no-highlight
+Press CTRL+C
+```
+
+13.1. If this does not work, `terminate` the process form `another shell`:
+```bash
+$ ps aux | grep "qemu-system-aarch64"
+<some_username>    24399  149  3.1 4265780 522276 pts/2  SNl+ 21:32   4:21 qemu-system-aarch64 -vnc unix:/run/user/[...]
+$ kill -SIGTERM 24399
+```
+
+13.2. In the worst case, `kill` the process in a dirty way:
+```bash
+$ kill -SIGKILL 24339
+```
+
+14. Repeat step `8` to `13` with the next `qemu-system-aarch64` command at `QEMU command line` [above](#host-environment). `Keyboard inputs` will only work for `raspi3` and `SSH` only for number `4` and `6`. If keyboard inputs are possible, one can log in with the user `pi` and password `1234` or use the `QEMU console` (`CTRL+ALT+2`) to reboot: `sendkey ctrl-alt-delete`.
+Additional information:
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/297 b/gitlab/issues_text/target_missing/host_missing/accel_missing/297
new file mode 100644
index 00000000..0300dc8f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/297
@@ -0,0 +1 @@
+SD card size constraint conceptually wrong
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2970 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2970
new file mode 100644
index 00000000..67940962
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2970
@@ -0,0 +1 @@
+qemu version 10.0.0 fails to build with clang-21 (current trunk)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2971 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2971
new file mode 100644
index 00000000..6706be6f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2971
@@ -0,0 +1,44 @@
+loongarch64 crashes caused by lenient instruction decoding of vldi and xvldi
+Description of problem:
+Lenient instruction decoding of `vldi` and `xvldi` leads to Qemu crashes.
+
+The decoding of `vldi` and `xvldi` instruction allows for instructions with illegal immediates.
+
+`target/loongarch/insns.decode`:
+
+```
+vldi             0111 00111110 00 ............. .....     @v_i13
+xvldi            0111 01111110 00 ............. .....     @v_i13
+```
+
+This is considered in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`:
+
+```C
+    /*
+     * imm bit [11:8] is mode, mode value is 0-12.
+     * other values are invalid.
+     */
+```
+
+However, an assertion error is raised when this condition is violated and qemu crashes:
+
+```
+**
+ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached
+Bail out! ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached
+```
+
+On hardware (Loongson 3A5000), these instructions cause a SIGILL.
+Steps to reproduce:
+1. compile the `test_inv_vldi` test program for loongarch64 (see additional information)
+2. run `qemu-loongarch64-static ./test_inv_vldi`
+Additional information:
+I will post a patch for this issue to the mailing list soon.
+
+`test_inv_vldi` source code:
+
+```C
+int main(int argc, char** argv) {
+    asm volatile(".4byte 0x73e3a000");    
+}
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2972 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2972
new file mode 100644
index 00000000..e92fadc0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2972
@@ -0,0 +1,637 @@
+loongarch64 inconsistencies between hardware and qemu due too lenient decoding of floating point comparisons
+Description of problem:
+(Related to #2971 )
+
+Lenient instruction decoding of floating point comparisons leads to instructions that do not exist on hardware (Loongson 3A5000).
+
+The decoding of floating point compare instruction allows for instructions with illegal fcmp modes.
+
+The following are affected (`target/loongarch/insns.decode`):
+
+```
+vfcmp_cond_s     0000 11000101 ..... ..... ..... .....    @vvv_fcond
+vfcmp_cond_d     0000 11000110 ..... ..... ..... .....    @vvv_fcond
+xvfcmp_cond_s    0000 11001001 ..... ..... ..... .....    @vvv_fcond
+xvfcmp_cond_d    0000 11001010 ..... ..... ..... .....    @vvv_fcond
+fcmp_cond_s     0000 11000001 ..... ..... ..... 00 ...   @cff_fcond
+fcmp_cond_d     0000 11000010 ..... ..... ..... 00 ...   @cff_fcond
+```
+
+The `get_fcmp_flags` function in `target/loongarch/tcg/insn_trans/trans_fcmp.c.inc` allows decoding all possible 4-bit condition values even though some are invalid on hardware (Loongson 3A5000):
+
+<details><summary>qemu-loongarch64-static</summary>
+
+```
+ --- fcond = 0b0 () --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1 () --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b10 (LT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b11 (LT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b100 (EQ) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b101 (EQ) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b110 (LT | EQ) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b111 (LT | EQ) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1000 (UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1001 (UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1010 (LT | UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1011 (LT | UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1100 (EQ | UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1101 (EQ | UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1110 (LT | EQ | UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1111 (LT | EQ | UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b10000 (LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b10001 (LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b10010 (LT | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b10011 (LT | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b10100 (EQ | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b10101 (EQ | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b10110 (LT | EQ | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b10111 (LT | EQ | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b11000 (UN | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b11001 (UN | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b11010 (LT | UN | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b11011 (LT | UN | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b11100 (EQ | UN | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b11101 (EQ | UN | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b11110 (LT | EQ | UN | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b11111 (LT | EQ | UN | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+```
+
+</details>
+
+
+<details><summary>Loongson 3A5000</summary>
+
+```
+ --- fcond = 0b0 () --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1 () --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b10 (LT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b11 (LT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b100 (EQ) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b101 (EQ) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b110 (LT | EQ) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b111 (LT | EQ) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1000 (UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1001 (UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1010 (LT | UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1011 (LT | UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1100 (EQ | UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1101 (EQ | UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1110 (LT | EQ | UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b1111 (LT | EQ | UN) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b10000 (LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b10001 (LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b10010 (LT | LT | GT) --- 
+vfcmp_cond_s  False
+vfcmp_cond_d  False
+xvfcmp_cond_s False
+xvfcmp_cond_d False
+fcmp_cond_s   False
+fcmp_cond_d   False
+
+ --- fcond = 0b10011 (LT | LT | GT) --- 
+vfcmp_cond_s  False
+vfcmp_cond_d  False
+xvfcmp_cond_s False
+xvfcmp_cond_d False
+fcmp_cond_s   False
+fcmp_cond_d   False
+
+ --- fcond = 0b10100 (EQ | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b10101 (EQ | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b10110 (LT | EQ | LT | GT) --- 
+vfcmp_cond_s  False
+vfcmp_cond_d  False
+xvfcmp_cond_s False
+xvfcmp_cond_d False
+fcmp_cond_s   False
+fcmp_cond_d   False
+
+ --- fcond = 0b10111 (LT | EQ | LT | GT) --- 
+vfcmp_cond_s  False
+vfcmp_cond_d  False
+xvfcmp_cond_s False
+xvfcmp_cond_d False
+fcmp_cond_s   False
+fcmp_cond_d   False
+
+ --- fcond = 0b11000 (UN | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b11001 (UN | LT | GT) --- 
+vfcmp_cond_s  True
+vfcmp_cond_d  True
+xvfcmp_cond_s True
+xvfcmp_cond_d True
+fcmp_cond_s   True
+fcmp_cond_d   True
+
+ --- fcond = 0b11010 (LT | UN | LT | GT) --- 
+vfcmp_cond_s  False
+vfcmp_cond_d  False
+xvfcmp_cond_s False
+xvfcmp_cond_d False
+fcmp_cond_s   False
+fcmp_cond_d   False
+
+ --- fcond = 0b11011 (LT | UN | LT | GT) --- 
+vfcmp_cond_s  False
+vfcmp_cond_d  False
+xvfcmp_cond_s False
+xvfcmp_cond_d False
+fcmp_cond_s   False
+fcmp_cond_d   False
+
+ --- fcond = 0b11100 (EQ | UN | LT | GT) --- 
+vfcmp_cond_s  False
+vfcmp_cond_d  False
+xvfcmp_cond_s False
+xvfcmp_cond_d False
+fcmp_cond_s   False
+fcmp_cond_d   False
+
+ --- fcond = 0b11101 (EQ | UN | LT | GT) --- 
+vfcmp_cond_s  False
+vfcmp_cond_d  False
+xvfcmp_cond_s False
+xvfcmp_cond_d False
+fcmp_cond_s   False
+fcmp_cond_d   False
+
+ --- fcond = 0b11110 (LT | EQ | UN | LT | GT) --- 
+vfcmp_cond_s  False
+vfcmp_cond_d  False
+xvfcmp_cond_s False
+xvfcmp_cond_d False
+fcmp_cond_s   False
+fcmp_cond_d   False
+
+ --- fcond = 0b11111 (LT | EQ | UN | LT | GT) --- 
+vfcmp_cond_s  False
+vfcmp_cond_d  False
+xvfcmp_cond_s False
+xvfcmp_cond_d False
+fcmp_cond_s   False
+fcmp_cond_d   False
+```
+
+</details>
+Steps to reproduce:
+1. compile the `test_instr_valid` test program for loongarch64 (see additional information).
+2. run the `check_defined.py` python script to print out information about defined instructions.
+3. All tested fcmp instructions are defined when run using qemu, but some are invalid (SIGILL) on actual hardware.
+Additional information:
+I will post a patch for this issue to the mailing list soon.
+
+`test_instr_valid` source code:
+
+```C
+#include <signal.h>
+#include <errno.h>
+#include <stdio.h>
+#include <stddef.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <sys/mman.h>
+
+#define PAGE_SIZE 0x4000
+
+#define ret 0x4c000020
+
+typedef void (*instr_fun)(void);
+
+static __attribute__((aligned(PAGE_SIZE))) uint32_t code[PAGE_SIZE / sizeof(uint32_t)];
+
+void handler(int signo, siginfo_t *info, void *context) {
+    printf("False");
+    exit(0);
+}
+
+int main(int argc, char** argv) {
+    struct sigaction act = { 0 };
+    act.sa_flags = SA_SIGINFO | SA_ONSTACK;
+    act.sa_sigaction = &handler;
+    sigaction(SIGILL, &act, NULL);
+    uint32_t instr = (uint32_t)strtoull(argv[1], NULL, 0);
+    code[0] = instr;
+    code[1] = ret;
+    mprotect(code, sizeof(code), PROT_READ | PROT_EXEC);
+    instr_fun f = (instr_fun)(void*)code;
+    f();
+    printf("True");
+    exit(0);
+}
+```
+
+`check_defined.py`:
+
+```py
+import subprocess
+
+CMD = ["qemu-loongarch64-static", "./test_instr_valid"] # remove "qemu-loongarch64-static" when running without emulation
+
+def is_defined(instr):
+    try:
+        return eval(subprocess.check_output(CMD + [hex(instr)]).decode())
+    except:
+        return False
+
+bases = [
+    ("vfcmp_cond_s ", 0b00001100010100000000000000000000), # vfcmp_cond_s     0000 11000101 ..... ..... ..... .....    @vvv_fcond
+    ("vfcmp_cond_d ", 0b00001100011000000000000000000000), # vfcmp_cond_d     0000 11000110 ..... ..... ..... .....    @vvv_fcond
+    ("xvfcmp_cond_s", 0b00001100100100000000000000000000), # xvfcmp_cond_s    0000 11001001 ..... ..... ..... .....    @vvv_fcond
+    ("xvfcmp_cond_d", 0b00001100101000000000000000000000), # xvfcmp_cond_d    0000 11001010 ..... ..... ..... .....    @vvv_fcond
+]
+
+bases_2 = [
+    ("fcmp_cond_s  ", 0b00001100000100000000000000000000), # fcmp_cond_s     0000 11000001 ..... ..... ..... 00 ...   @cff_fcond
+    ("fcmp_cond_d  ", 0b00001100001000000000000000000000), # fcmp_cond_d     0000 11000010 ..... ..... ..... 00 ...   @cff_fcond
+]
+
+def format_fcond(val):
+    x = ["LT", "EQ", "UN", "LT | GT"]
+    return " | ".join(x[i] for i in range(4) if (val >> 1) & (1 << i))
+
+fcond_shift = 15
+
+# use r1, r2, r3 for vector instructions
+reg_mask = 0b000110001000001
+
+# use c0, r1, r2 for normal instructions
+reg_mask_2 = 0b000100000100000
+
+for fcond in range(1 << 5):
+    print(f" --- fcond = {bin(fcond)} ({format_fcond(fcond)}) --- ")
+    for name, mask in bases:
+        print(name, is_defined(mask | reg_mask | (fcond << fcond_shift)))
+    for name, mask in bases_2:
+        print(name, is_defined(mask | reg_mask_2 | (fcond << fcond_shift)))
+    print("")
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2974 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2974
new file mode 100644
index 00000000..1fe6ae54
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2974
@@ -0,0 +1 @@
+Remove the "51 Franklin Street, Fifth Floor, Boston" from the QEMU code base
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2975 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2975
new file mode 100644
index 00000000..a4e1a180
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2975
@@ -0,0 +1,68 @@
+qemu-system-x86_64: VFIO_MAP_DMA failed: -22 IVSHMEM
+Description of problem:
+QEMU do not run with looking glass KVMFR and with host model cpu
+It only works when I set cpu to `Snowridge,vmx=on,fma=on,avx=on,f16c=on,hypervisor=on...` (you can see in kvm.sh)
+Steps to reproduce:
+1. I have a script ( search for 'WITH VFIO')
+Additional information:
+UPD
+Some additional debug info from GDB
+
+```
+=== vfio_listener_region_add ===
+Arguments:
+listener = 0x55555a4dd2f0
+section = 0x7fffedb389c0
+
+Section details:
+  section->offset_within_address_space: 0x382000000000
+  Memory region: 0x555558120dd0
+  Memory region name: shmmem-shmem0
+  Memory region size: 0x10000000
+  Memory region addr: 0x382000000000
+Error accessing section details: There is no member named offset.
+
+=== vfio_get_section_iova_range ENTRY ===
+Arguments:
+bcontainer = 0x55555a4dd2c0
+section = 0x7fffedb389c0
+out_iova = 0x7fffedb388b0
+out_end = 0x7fffedb388b8
+out_llend = 0x7fffedb38900
+
+Local variables at entry:
+llend = 140737181354144
+iova = 140737181354432
+
+Thread 4 "CPU 0/KVM" hit Breakpoint -96, 0x0000555555b8511a in vfio_listener_region_add (listener=0x55555a4dd2f0, 
+    section=0x7fffedb389c0) at ../../../hw/vfio/listener.c:467
+467         if (!vfio_get_section_iova_range(bcontainer, section, &iova, &end,
+(gdb) 
+Continuing.
+2025-05-20T22:46:27.819893Z qemu-system-x86_64: vfio_container_dma_map(0x55555a4dd2c0, 0x382000000000, 0x10000000, 0x7fffcffff000) = -22 (Invalid argument)
+qemu: hardware error: vfio: DMA mapping failed, unable to continue
+CPU #0:
+RAX=00000000e0000000 RBX=00000000e0608004 RCX=0000000000608004 RDX=0000000000000003
+RSI=0000000000000003 RDI=0000000000000000 RBP=000000007ef6b640 RSP=000000007ef6b5f0
+R8 =0000000000000000 R9 =000000007ef6b70f R10=0000000000000000 R11=0000000000000004
+R12=000000007ef6b800 R13=0000000000000003 R14=0000000000000000 R15=000000007ef6b7fe
+RIP=000000007e1fe2eb RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
+
+```
+
+Tested with latest QEMU 2af4a82ab2cce3412ffc92cd4c96bd870e33bc8e same error
+```
+sudo dnf builddep qemu
+../../../configure --enable-debug
+```
+
+[ERROR-QEMU-GIT-2af4a82ab2cce3412ffc92cd4c96bd870e33bc8e.txt](/uploads/060b26f091f0391f0491ea91dbe78f6d/ERROR-QEMU-GIT-2af4a82ab2cce3412ffc92cd4c96bd870e33bc8e.txt)
+
+[ERROR-trace-iova-values.txt](/uploads/22cacf4a5cb2c91ff6375c792a25dde1/ERROR-trace-iova-values.txt)
+
+[WORKINg-trace-iova-values.txt](/uploads/d4d53c2e743cf5f2d5bf810d61b9f1e6/WORKINg-trace-iova-values.txt)
+
+
+[kvm.log.txt](/uploads/ac31eebf6e63aa6abe2498d1a4064bef/kvm.log.txt)
+
+[kvm.sh](/uploads/7f656f7cf0d623a240309ee61b024dc9/kvm.sh)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2976 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2976
new file mode 100644
index 00000000..0473acdf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2976
@@ -0,0 +1,25 @@
+attach-ns doesn't work correctly in SR-IOV, cannot attach NS to VF if it is attached to a PF
+Description of problem:
+We can't attach namespace to a VF (Secondary controller) unless it is not attached to a primary controller first
+
+Lately in the commit https://github.com/qemu/qemu/commit/6ccca4b6bb9f994cc04e71004e1767a3476d2b23 the file qemu/hw/nvme/ctrl.c got changed -\> in function "nvme_ns_attachment" -\> line 6819 (At the time I'm writing the bug) which is the condation in attach ns to check if the namespace is attached "`if (nvme_ns(n, nsid)) {`"
+
+This change will always result in checking the namespace attach to the PF even if we are trying to attach it to the VF.
+Steps to reproduce:
+1. Enable a VF:
+
+```
+echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset
+sleep 1
+
+echo 2 > /sys/bus/pci/devices/0000:01:00.0/sriov_numvfs
+sleep 1
+
+nvme virt-mgmt /dev/nvme0 -c 1 -r 1 -a 8 -n 1
+nvme virt-mgmt /dev/nvme0 -c 1 -r 0 -a 8 -n 2
+nvme virt-mgmt /dev/nvme0 -c 1 -a 9
+sleep 1
+```
+
+2. attach namespace 1 to the PF (e.g. `vme attach-ns /dev/nvme0 -n1 -c0` )
+3. try to attach it using the nvme_cli command from the PF (e.g. `nvme attach-ns /dev/nvme0 -n1 -c1`)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2977 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2977
new file mode 100644
index 00000000..63545e09
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2977
@@ -0,0 +1,11 @@
+QEMU SVM VMCB exit_code is uint32_t when AMD spec requires uint64_t
+Description of problem:
+QEMU's SVM implementation incorrectly uses a 32-bit parameter for the exit code in the `cpu_vmexit` function, despite the AMD SVM specification requiring a 64-bit exit code field in the VMCB (Virtual Machine Control Block).
+
+I think the issue is in `target/i386/svm.c` in the `cpu_vmexit` function.
+
+The `exit_code` parameter is declared as `uint32_t` but should be `uint64_t` according to the AMD SVM specification. This causes exit codes to be truncated to 32 bits, resulting in values like 0xffff_ffff instead of the expected 0xffff_ffff_ffff_ffff.
+Steps to reproduce:
+
+Additional information:
+[this](https://stackoverflow.com/questions/79632531/qemu-svm-vmcb-exit-code-is-uint32-t-when-amd-spec-requires-uint64-t?noredirect=1#comment140448815_79632531) question I posted on stack overflow
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2978 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2978
new file mode 100644
index 00000000..d9f9aa71
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2978
@@ -0,0 +1,23 @@
+Qemu assertion issue
+Description of problem:
+This issue is **not caused by my OS**, as it runs perfectly under VMware and other emulators.
+
+However, when using QEMU, the emulator sometimes randomly **crashes or aborts** during boot or early execution. The crash is **inconsistent** — sometimes it runs, sometimes it fails immediately.
+
+QEMU fails with an **assertion failure** in `qemu_mutex_lock_iothread_impl`
+Steps to reproduce:
+Unfortunately, I do not know exactly what causes this issue. It may be specific to my system or configuration.
+
+1. 
+2.
+Additional information:
+Qemu stdout:
+
+```
+ERROR:system/cpus.c:504:qemu_mutex_lock_iothread_impl: assertion failed: (!qemu_mutex_iothread_locked()) Bail out! ERROR:system/cpus.c:504:qemu_mutex_lock_iothread_impl: assertion failed: (!qemu_mutex_iothread_locked()) ./run: line 3: 3544 Aborted (core dumped)
+```
+
+Command line:
+```
+ qemu-system-x86_64 -debugcon file:OxizeOS.log -drive file=output/OxizeOS.hdd,format=raw -serial stdio
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/298 b/gitlab/issues_text/target_missing/host_missing/accel_missing/298
new file mode 100644
index 00000000..fa9e80d4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/298
@@ -0,0 +1 @@
+OpenGL, Virtio-VGA, Virtio-GPU-PCI, GTK
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2980 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2980
new file mode 100644
index 00000000..2ad3f471
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2980
@@ -0,0 +1,264 @@
+QEMU Crashes During Snapshot: bdrv_co_write_req_prepare Assertion child->perm & BLK_PERM_WRITE Failed
+Description of problem:
+After taking a external snapshot (w/ memory state) with libvirt, the QEMU process crashed with an assertion
+
+```
+qemu-system-x86_64: ../block/io.c:2052: bdrv_co_write_req_prepare: Assertion `child->perm & BLK_PERM_WRITE` failed.
+```
+Steps to reproduce:
+1. Start the qemu process
+2. Take an external (w/ memory) snapshot by libvirt Python API
+    
+    ```python
+    domain.snapshotCreateXML(<xml_string>, 
+      libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_ATOMIC |
+      libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_REUSE_EXT |
+      libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_LIVE)
+    ```
+    
+3. The qemu process crashed by hitting the assertion
+Additional information:
+Libvirt domain XML
+```xml
+<domain type='kvm'>
+  <name>1a3dabc5-c33b-4308-acc5-2245f3b64163</name>
+  <uuid>1a3dabc5-c33b-4308-acc5-2245f3b64163</uuid>
+  <metadata xmlns:qvs="http://www.qnap.com/schemas/qvs/1.0">
+  </metadata>
+  <memory unit='KiB'>16777216</memory>
+  <currentMemory unit='KiB'>16777216</currentMemory>
+  <memoryBacking>
+    <nosharepages/>
+  </memoryBacking>
+  <vcpu placement='static' cpuset='0-23'>5</vcpu>
+  <sysinfo type='smbios'>
+    <system>
+      <entry name='manufacturer'>qemu</entry>
+      <entry name='product'>qemu</entry>
+    </system>
+  </sysinfo>
+  <os>
+    <type arch='x86_64' machine='pc-i440fx-7.0'>hvm</type>
+    <boot dev='cdrom'/>
+    <boot dev='hd'/>
+    <bootmenu enable='no'/>
+    <smbios mode='sysinfo'/>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+    <pae/>
+  </features>
+  <cpu mode='host-passthrough' check='none' migratable='on'>
+    <topology sockets='1' dies='1' cores='5' threads='1'/>
+    <numa>
+      <cell id='0' cpus='0-4' memory='16777216' unit='KiB' memAccess='private'/>
+    </numa>
+  </cpu>
+  <clock offset='localtime'/>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>restart</on_crash>
+  <pm>
+    <suspend-to-mem enabled='no'/>
+    <suspend-to-disk enabled='no'/>
+  </pm>
+  <devices>
+    <emulator>/QVS/usr/bin/qemu-system-x86_64</emulator>
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2' cache='writeback'/>
+      <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747803601' startupPolicy='optional'/>
+      <backingStore type='file'>
+        <format type='qcow2'/>
+        <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747630800'/>
+        <backingStore type='file'>
+          <format type='qcow2'/>
+          <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747371601'/>
+          <backingStore type='file'>
+            <format type='qcow2'/>
+            <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747198801'/>
+            <backingStore type='file'>
+              <format type='qcow2'/>
+              <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747026001'/>
+              <backingStore type='file'>
+                <format type='qcow2'/>
+                <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1746594001'/>
+                <backingStore type='file'>
+                  <format type='qcow2'/>
+                  <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1746421201'/>
+                  <backingStore type='file'>
+                    <format type='qcow2'/>
+                    <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1745557200'/>
+                    <backingStore type='file'>
+                      <format type='qcow2'/>
+                      <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1745211600'/>
+                      <backingStore type='file'>
+                        <format type='qcow2'/>
+                        <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1744174801'/>
+                        <backingStore type='file'>
+                          <format type='qcow2'/>
+                          <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1743570001'/>
+                          <backingStore type='file'>
+                            <format type='qcow2'/>
+                            <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1743138001'/>
+                            <backingStore type='file'>
+                              <format type='qcow2'/>
+                              <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1742965201'/>
+                              <backingStore type='file'>
+                                <format type='qcow2'/>
+                                <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1742360400'/>
+                                <backingStore type='file'>
+                                  <format type='qcow2'/>
+                                  <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1742187600'/>
+                                  <backingStore type='file'>
+                                    <format type='qcow2'/>
+                                    <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1741928400'/>
+                                    <backingStore type='file'>
+                                      <format type='qcow2'/>
+                                      <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1741755601'/>
+                                      <backingStore type='file'>
+                                        <format type='qcow2'/>
+                                        <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1741323600'/>
+                                        <backingStore type='file'>
+                                          <format type='qcow2'/>
+                                          <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740718800'/>
+                                          <backingStore type='file'>
+                                            <format type='qcow2'/>
+                                            <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740546000'/>
+                                            <backingStore type='file'>
+                                              <format type='qcow2'/>
+                                              <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740373200'/>
+                                              <backingStore type='file'>
+                                                <format type='qcow2'/>
+                                                <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740114000'/>
+                                                <backingStore type='file'>
+                                                  <format type='qcow2'/>
+                                                  <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739941201'/>
+                                                  <backingStore type='file'>
+                                                    <format type='qcow2'/>
+                                                    <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739768400'/>
+                                                    <backingStore type='file'>
+                                                      <format type='qcow2'/>
+                                                      <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739509200'/>
+                                                      <backingStore type='file'>
+                                                        <format type='qcow2'/>
+                                                        <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739336400'/>
+                                                        <backingStore type='file'>
+                                                          <format type='qcow2'/>
+                                                          <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739163600'/>
+                                                          <backingStore type='file'>
+                                                            <format type='qcow2'/>
+                                                            <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1738904400'/>
+                                                            <backingStore type='file'>
+                                                              <format type='qcow2'/>
+                                                              <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1738558801'/>
+                                                              <backingStore type='file'>
+                                                                <format type='qcow2'/>
+                                                                <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1724816945'/>
+                                                                <backingStore type='file'>
+                                                                  <format type='qcow2'/>
+                                                                  <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1724045214_1'/>
+                                                                  <backingStore type='file'>
+                                                                    <format type='qcow2'/>
+                                                                    <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1721622169'/>
+                                                                    <backingStore type='file'>
+                                                                      <format type='qcow2'/>
+                                                                      <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.img'/>
+                                                                      <backingStore/>
+                                                                    </backingStore>
+                                                                  </backingStore>
+                                                                </backingStore>
+                                                              </backingStore>
+                                                            </backingStore>
+                                                          </backingStore>
+                                                        </backingStore>
+                                                      </backingStore>
+                                                    </backingStore>
+                                                  </backingStore>
+                                                </backingStore>
+                                              </backingStore>
+                                            </backingStore>
+                                          </backingStore>
+                                        </backingStore>
+                                      </backingStore>
+                                    </backingStore>
+                                  </backingStore>
+                                </backingStore>
+                              </backingStore>
+                            </backingStore>
+                          </backingStore>
+                        </backingStore>
+                      </backingStore>
+                    </backingStore>
+                  </backingStore>
+                </backingStore>
+              </backingStore>
+            </backingStore>
+          </backingStore>
+        </backingStore>
+      </backingStore>
+      <target dev='vdb' bus='virtio'/>
+      <serial>1a3dabc5c33b4308ac01</serial>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
+    </disk>
+    <disk type='file' device='cdrom'>
+      <driver name='qemu' type='raw'/>
+      <source startupPolicy='optional'/>
+      <target dev='hda' bus='ide'/>
+      <readonly/>
+      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+    </disk>
+    <controller type='ide' index='0'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
+    </controller>
+    <controller type='usb' index='0' model='nec-xhci' ports='6'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
+    </controller>
+    <controller type='pci' index='0' model='pci-root'/>
+    <controller type='virtio-serial' index='0'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
+    </controller>
+    <interface type='bridge'>
+      <mac address='52:54:00:a2:a4:e3'/>
+      <source bridge='qvs0'/>
+      <model type='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+    </interface>
+    <channel type='unix'>
+      <source mode='bind' path='/QVS/var/lib/libvirt/qemu/1a3dabc5-c33b-4308-acc5-2245f3b64163.agent'/>
+      <target type='virtio' name='org.qemu.guest_agent.0'/>
+      <address type='virtio-serial' controller='0' bus='0' port='1'/>
+    </channel>
+    <input type='tablet' bus='usb'>
+      <address type='usb' bus='0' port='1'/>
+    </input>
+    <input type='mouse' bus='ps2'/>
+    <input type='keyboard' bus='ps2'/>
+    <tpm model='tpm-tis'>
+      <backend type='emulator' version='2.0'/>
+    </tpm>
+    <graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1' keymap='en-us'>
+      <listen type='address' address='127.0.0.1'/>
+    </graphics>
+    <graphics type='spice' autoport='yes' listen='127.0.0.1' keymap='en-us'>
+      <listen type='address' address='127.0.0.1'/>
+      <image compression='off'/>
+      <jpeg compression='never'/>
+      <zlib compression='never'/>
+      <playback compression='off'/>
+      <streaming mode='all'/>
+    </graphics>
+    <sound model='ich6'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
+    </sound>
+    <audio id='1' type='spice'/>
+    <video>
+      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+    </video>
+    <memballoon model='virtio'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
+    </memballoon>
+  </devices>
+</domain>
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2981 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2981
new file mode 100644
index 00000000..58401522
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2981
@@ -0,0 +1,25 @@
+Assert error with accel=hvf:tcg when hvf is unavailable
+Description of problem:
+Trying to start qemu with `-machine virt,accel=hvf:tcg` in a Mac OS guest under Mac OS host, both arm64. I expect it to try hvf (unavailable - nested virtualization not supported) and fallback to tcg. Documentation for accel option says "If there is more than one accelerator specified, the next one is used if the previous one fails to initialize." This works fine with kvm, but for hvf it crashes in some auxiliary function when trying it:
+
+```
+% qemu-system-aarch64 -machine virt,accel=hvf:tcg
+qemu-system-aarch64: Error: ret = HV_UNSUPPORTED (0xfae9400f, at ../target/arm/hvf/hvf.c:949)
+```
+
+Stack trace
+```
+  * frame #0: 0x0000000193a18388 libsystem_kernel.dylib`__pthread_kill + 8
+    frame #1: 0x0000000193a5188c libsystem_pthread.dylib`pthread_kill + 296
+    frame #2: 0x000000019395ac60 libsystem_c.dylib`abort + 124
+    frame #3: 0x00000001005ee7f4 qemu-system-aarch64`assert_hvf_ok_impl + 92
+    frame #4: 0x000000010032a550 qemu-system-aarch64`hvf_arm_get_max_ipa_bit_size + 64
+    frame #5: 0x0000000100334928 qemu-system-aarch64`virt_hvf_get_physical_address_range + 68
+    frame #6: 0x00000001005ee9b8 qemu-system-aarch64`hvf_accel_init + 68
+    frame #7: 0x00000001002ef8e4 qemu-system-aarch64`accel_init_machine + 92
+    frame #8: 0x00000001002a6640 qemu-system-aarch64`do_configure_accelerator + 208
+    frame #9: 0x0000000100782bdc qemu-system-aarch64`qemu_opts_foreach + 112
+    frame #10: 0x00000001002a3180 qemu-system-aarch64`qemu_init + 11344
+    frame #11: 0x00000001006ea76c qemu-system-aarch64`main + 36
+    frame #12: 0x00000001936b2b4c dyld`start + 6000
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2983 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2983
new file mode 100644
index 00000000..4070f202
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2983
@@ -0,0 +1,115 @@
+qemu-system-riscv64 randomly  turns MPP bits to 0 in the mstatus word.
+Description of problem:
+ToyOs runs the kernel in machine mode and user programs in user mode.  This is specific choice on my part to make sure the kernel code runs with machine address and user code runs with virtual addresses.  This is different than Linux, NetBSD or other OSes I know that run the kernel in supervisor mode. When running in machine mode and running kernel code, I get a a trap.  My error message looks like this:
+
+PANIC: Unexpected trap from machine mode!
+  mepc = 0x800002a8, mcause = 2, mtval=0xe78023 mstatus=0xa00000080
+
+Notice, the mstatus bits show the trap was due to a privileged instruction being run by a "user" mode instruction.   In the "assignment version" used for the above, no user code was run.  It was just multiple threads running in machine mode.   Also, the trap function is run with the MPP bits of 0, so even trying to recover from this trap can't be done as trying to manipulate the mstatus will generate yet again another trap to the same place and still running in "user" mode.
+
+This change does not happen on every run.  It happens more consistently recently when trying to debug the kernel with gdb.  This must be a race condition somewhere.
+
+The kernel is written in C++ with C libraries.
+Steps to reproduce:
+1.  You will need to have access to my kernel and possibly my code base.  This is a code base that I want to stay at WWU (Western Washington University).
+2.  Give the command "bmake run".  It often completes with no problems, but if you run it often enough it will generate this trap from "machine mode".   The example above had four good runs with no errors and on the fifth run it blew up.  There is not guaranteed way to get this to have a problem.   (This is why I haven't reported it before, I kept trying to get a minimal code set that had the problem, but I couldn't do it.)
+Additional information:
+This is a bug has been a problem for several years.  It didn't strike very often on some versions of qemu.  I think one of the 7.x.x versions happened not too often.  But with newer, faster machines and a different version of Linux, this bug has become a big problem for me and my students.
+
+Here is a sample bad run:  (All compilation has been done before so this just makes sure everything is up-to-date and then runs qemu-system-riscv64.  In this assignment, no user mode code is being run.  Threads are all running in machine mode for the entire time.  I am getting clock interrupts on the CPU, but that does not appear to be the problem.)
+
+$ bmake run
+if ! [ -e toolbin ] ; then mkdir toolbin ; fi;
+(cd tools; bmake install)
+(cd toy_fs; bmake)
+`toyfs' is up to date.
+(cd mkdep; bmake)
+`mkdep' is up to date.
+(cd toy_fs; bmake install)
+(cd mkdep; bmake install)
+Making in /home/phil/447/csci447_s25/lib
+Making in /home/phil/447/csci447_s25/kernel
+`DISK' is up to date.
+qemu-system-riscv64 -machine virt -bios none -m 1G -smp 1 -nographic -global virtio-mmio.force-legacy=false -drive file=DISK,if=none,format=raw,id=x0 -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 -kernel kernel/kernel -gdb tcp::27277
+Initializing scheduler ...
+Initializing frame set... 
+Initializing thread set ...
+Initializing process set ...
+Initializing fcb set ...
+Initializing OpenFile set ...
+Initializing pipe set ...
+Initializing vertio ...
+Initializing filesystem ...
+Starting os_main ...
+PANIC: Unexpected trap from machine mode!
+  mepc = 0x800002a8, mcause = 2, mtval=0xe78023 mstatus=0xa00000080
+attach with gdb!
+QEMU: Terminated
+
+$ riscv64-unknown-elf-addr2line -e kernel/kernel 0x800002a8
+/home/phil/447/csci447_s25/kernel/runtime.S:350
+
+And that instruction turns out to be "mret", the return from the clock interrupt.
+
+The following is a error free run of this.
+
+$ bmake run
+if ! [ -e toolbin ] ; then mkdir toolbin ; fi;
+(cd tools; bmake install)
+(cd toy_fs; bmake)
+`toyfs' is up to date.
+(cd mkdep; bmake)
+`mkdep' is up to date.
+(cd toy_fs; bmake install)
+(cd mkdep; bmake install)
+Making in /home/phil/447/csci447_s25/lib
+Making in /home/phil/447/csci447_s25/kernel
+`DISK' is up to date.
+qemu-system-riscv64 -machine virt -bios none -m 1G -smp 1 -nographic -global virtio-mmio.force-legacy=false -drive file=DISK,if=none,format=raw,id=x0 -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 -kernel kernel/kernel -gdb tcp::27277
+Initializing scheduler ...
+Initializing frame set... 
+Initializing thread set ...
+Initializing process set ...
+Initializing fcb set ...
+Initializing OpenFile set ...
+Initializing pipe set ...
+Initializing vertio ...
+Initializing filesystem ...
+Starting os_main ...
+
+Welcome to Toy OS, hartid = 0
+Assignment 3 ...
+
+********** Frame Tester **********
+1.3.2.4.5.6.7.8.9.10.12.11.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50.51.52.53.54.55.56.57.58.59.60.61.62.63.64.65.66.67.68.69.70.71.72.73.74.75.76.77.78.79.80.81.82.83.85.84.87.86.88.89.91.92.90.93.94.95.96.97.98.99.100.101.102.103.104.105.106.107.108.109.110.111.113.112.114.115.116.117.119.118.120.121.122.123.124.125.126.127.128.129.130.131.132.133.134.135.136.137.138.139.140.161.162.163.164.166.165.167.168.169.170.171.172.173.174.175.177.178.176.179.180.181.182.183.184.185.186.187.188.189.190.191.194.193.192.195.197.196.198.200.199.201.202.203.204.206.205.207.209.208.210.211.212.214.213.215.216.217.218.219.220.221.222.223.224.225.226.227.228.230.231.229.232.233.234.235.236.237.238.239.240.241.242.243.244.245.246.247.248.249.250.252.253.251.254.255.256.257.258.259.260.261.262.263.264.265.266.267.268.269.270.271.273.272.274.275.276.277.278.279.280.281.282.283.284.285.286.287.288.289.290.291.292.293.294.295.296.297.298.299.300.301.302.303.304.305.306.308.307.309.310.311.312.313.314.315.316.317.318.319.320.341.342.343.344.345.346.347.348.349.350.351.353.352.354.356.355.357.358.359.360.361.362.363.364.365.366.367.368.369.370.371.372.373.374.375.376.377.378.379.380.382.381.383.384.385.386.387.388.389.390.391.392.394.395.393.396.397.398.399.400.401.402.403.404.405.406.407.409.408.410.411.412.413.414.415.416.417.418.420.419.421.422.423.425.426.424.427.428.429.430.432.431.433.434.435.436.437.438.439.440.441.442.443.444.445.446.447.448.449.450.451.452.453.455.454.457.456.458.459.460.461.462.463.464.465.466.467.468.469.470.471.472.473.474.475.476.477.478.479.480.481.482.483.484.485.486.487.488.489.490.491.492.493.494.495.496.497.498.499.500.521.523.522.524.525.526.528.527.529.530.531.532.533.534.535.536.537.538.539.540.542.544.543.541.545.546.548.547.549.551.550.553.552.555.554.557.556.559.558.560.561.562.563.564.565.566.567.568.569.570.571.572.573.574.575.576.577.578.579.580.581.582.583.584.585.586.587.588.589.590.591.592.593.594.595.596.597.598.599.600.601.602.603.604.605.606.607.608.609.610.611.612.613.614.615.616.617.618.619.620.621.622.623.624.625.626.627.628.629.630.631.632.633.634.635.636.637.638.639.640.641.642.643.644.645.646.647.648.649.650.651.652.653.654.655.656.657.658.659.660.661.662.663.664.665.666.667.668.669.670.671.672.673.675.674.676.677.678.679.680.701.702.704.703.705.706.707.708.709.711.710.712.713.714.715.716.717.718.719.720.723.722.721.724.725.727.726.728.729.730.731.732.733.734.735.737.736.738.739.741.740.742.744.743.746.747.745.748.749.750.751.752.753.754.756.755.757.758.759.761.760.762.763.764.765.766.767.768.769.770.771.772.773.774.775.776.777.778.780.779.781.782.783.784.785.786.787.788.789.790.791.792.793.794.795.797.796.798.799.800.801.802.803.804.805.806.807.808.809.810.811.812.813.814.815.816.817.818.819.820.821.822.823.825.824.826.827.828.829.830.831.832.833.834.835.836.837.838.839.840.841.842.843.844.845.846.847.848.849.850.851.852.853.854.855.856.857.858.859.860.882.881.884.883.885.886.888.887.890.889.891.892.893.894.895.896.897.898.899.901.900.902.903.904.905.906.907.908.909.910.911.913.912.914.915.916.917.918.919.920.921.922.923.924.925.926.928.927.929.930.931.932.933.934.935.936.937.939.938.940.941.942.943.944.945.946.947.948.949.950.951.952.953.954.955.956.957.958.959.961.960.962.963.964.965.966.967.968.969.970.971.972.973.974.975.976.977.978.979.980.981.982.983.984.985.986.987.988.989.990.991.992.993.994.995.996.997.998.999.1000.1001.1002.1003.1004.1005.1006.1008.1007.1009.1010.1011.1012.1014.1013.1015.1016.1017.1018.1019.1020.1021.1022.1023.1024.1025.1026.1027.1028.1029.1030.1031.1032.1033.1034.1035.1036.1037.1038.1039.1040.1061.1062.1063.1065.1064.1066.1069.1067.1068.1070.1071.1072.1073.1074.1075.1076.1077.1078.1079.1080.1082.1081.1084.1083.1085.1086.1087.1088.1089.1090.1091.1093.1092.1094.1095.1097.1096.1098.1099.1100.1101.1102.1103.1104.1105.1106.1107.1109.1108.1110.1111.1112.1113.1114.1115.1117.1116.1118.1119.1120.1121.1122.1123.1124.1125.1126.1127.1128.1129.1130.1131.1132.1133.1134.1135.1136.1137.1138.1139.1140.1141.1142.1143.1144.1145.1146.1147.1148.1149.1150.1151.1152.1153.1154.1155.1156.1157.1158.1159.1160.1161.1162.1163.1164.1165.1166.1167.1168.1169.1170.1172.1171.1173.1174.1175.1176.1177.1178.1179.1180.1181.1182.1183.1184.1185.1186.1187.1188.1189.1190.1191.1192.1193.1194.1195.1196.1197.1198.1199.1201.1200.1202.1203.1204.1205.1207.1206.1208.1209.1210.1211.1212.1213.1214.1215.1216.1217.1218.1219.1220.1241.1242.1244.1243.1245.1246.1247.1248.1249.1251.1250.1252.1253.1254.1255.1256.1257.1258.1259.1260.1261.1262.1263.1264.1265.1266.1267.1269.1268.1270.1272.1271.1274.1273.1275.1276.1277.1278.1279.1280.1281.1283.1282.1284.1285.1287.1286.1288.1290.1289.1291.1292.1293.1294.1295.1296.1297.1299.1298.1300.1301.1302.1303.1304.1305.1306.1307.1308.1309.1310.1311.1312.1313.1315.1314.1316.1317.1318.1319.1320.1321.1322.1323.1324.1325.1326.1327.1328.1329.1330.1331.1332.1333.1335.1334.1336.1337.1338.1339.1340.1341.1342.1343.1344.1345.1346.1347.1348.1349.1350.1351.1352.1353.1354.1355.1356.1357.1358.1360.1361.1359.1362.1364.1363.1365.1366.1367.1370.1369.1368.1371.1372.1373.1375.1374.1376.1377.1378.1379.1380.1381.1382.1383.1384.1385.1386.1387.1388.1389.1390.1391.1392.1393.1394.1395.1396.1397.1398.1400.1401.1419.1422.1423.1424.1426.1425.1427.1428.1429.1431.1430.1432.1434.1435.1433.1437.1436.1438.1440.1439.1441.1447.1442.1443.1444.1445.1446.1448.1449.1450.1452.1453.1451.1454.1455.1456.1457.1459.1458.1461.1460.1462.1463.1464.1465.1466.1467.1468.1469.1470.1471.1472.1473.1474.1475.1476.1477.1478.1479.1480.1481.1482.1483.1484.1486.1485.1487.1488.1489.1490.1491.1492.1493.1494.1495.1496.1498.1497.1499.1500.1501.1502.1503.1504.1505.1506.1507.1508.1509.1510.1511.1512.1513.1514.1515.1516.1517.1519.1518.1520.1521.1522.1523.1524.1525.1526.1527.1528.1529.1530.1531.1532.1533.1534.1535.1536.1537.1538.1539.1540.1541.1542.1543.1544.1545.1547.1546.1548.1549.1550.1551.1553.1552.1554.1555.1556.1557.1558.1559.1560.1561.1562.1563.1564.1565.1566.1567.1568.1569.1570.1571.1572.1573.1574.1575.1576.1577.1578.1579.1581.1600.1602.1603.1604.1605.1607.1606.1608.1609.1610.1612.1611.1613.1614.1616.1615.1617.1618.1619.1622.1621.1620.1623.1624.1625.1626.1627.1628.1629.1630.1631.1632.1633.1635.1634.1636.1637.1638.1639.1640.1641.1642.1643.1644.1646.1645.1647.1648.1650.1649.1652.1651.1653.1654.1655.1656.1657.1658.1659.1660.1661.1663.1662.1664.1665.1666.1667.1668.1669.1670.1671.1672.1673.1674.1675.1676.1677.1678.1679.1680.1681.1682.1683.1685.1684.1686.1687.1688.1689.1691.1690.1692.1693.1694.1695.1696.1698.1697.1699.1700.1701.1702.1703.1704.1705.1706.1707.1708.1709.1710.1711.1713.1712.1714.1715.1717.1716.1718.1719.1720.1721.1722.1723.1724.1725.1726.1727.1728.1729.1730.1731.1732.1733.1734.1735.1736.1737.1738.1739.1740.1741.1742.1743.1744.1745.1746.1747.1748.1749.1751.1750.1752.1753.1754.1755.1756.1757.1758.1759.1762.1780.1781.1784.1785.1783.1787.1788.1786.1789.1790.1791.1792.1794.1793.1795.1796.1799.1797.1800.1798.
+Frame  0, used 0x  Frame  1, used 0x  Frame  2, used 0x  
+Frame  3, used 438x  Frame  4, used 435x  Frame  5, used 429x  
+Frame  6, used 420x  Frame  7, used 414x  Frame  8, used 407x  
+Frame  9, used 396x  Frame 10, used 391x  Frame 11, used 386x  
+Frame 12, used 374x  Frame 13, used 372x  Frame 14, used 367x  
+Frame 15, used 361x  Frame 16, used 353x  Frame 17, used 345x  
+Frame 18, used 342x  Frame 19, used 335x  Frame 20, used 330x  
+Frame 21, used 329x  Frame 22, used 325x  Frame 23, used 319x  
+Frame 24, used 271x  Frame 25, used 262x  Frame 26, used 255x  
+Frame 27, used 141x  Frame 28, used 108x  Frame 29, used 95x  
+**********  Test Done   **********
+
+********** Thread Tester **********
+3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.2.22.20.30.31.24.21.23.25.26.32.27.33.39.40.41.28.29.35.34.36.42.44.48.49.50.37.51.38.45.46.52.55.57.43.58.60.53.61.62.56.63.65.67.68.47.70.71.64.72.73.74.69.54.77.78.59.81.82.75.83.76.85.79.86.89.91.92.84.93.66.87.80.94.96.98.101.102.103.95.88.104.97.99.105.108.110.111.112.113.100.114.107.115.109.117.119.120.122.106.116.124.125.90.126.129.130.131.132.133.127.134.135.128.136.138.139.141.142.143.144.123.145.140.146.148.149.151.153.152.154.118.147.156.121.159.160.161.162.163.157.164.150.137.166.169.170.171.172.158.174.167.175.155.176.178.173.181.182.168.183.184.179.185.165.187.177.188.189.186.180.190.192.191.193.195.196.197.194.198.199.200.201.
+**********   Test Done   **********
+
+********** Process Tester **********
+5.6.7.8.9.10.2.3.11.4.23.22.24.19.21.12.13.14.25.26.29.28.15.16.17.30.18.20.34.35.38.39.32.40.31.27.41.33.43.44.48.49.50.42.36.51.37.45.52.54.56.58.59.60.61.46.47.53.62.57.67.68.69.70.71.55.63.64.65.73.76.78.79.72.81.66.74.82.75.83.86.88.90.91.77.84.92.85.93.80.95.97.99.101.87.102.94.89.103.96.98.100.108.112.104.113.105.114.106.107.109.115.110.122.123.124.116.111.117.118.119.125.120.132.134.121.126.127.135.130.128.136.129.139.133.131.145.138.137.142.140.143.146.141.155.147.148.144.149.152.150.151.153.156.157.158.154.162.159.160.161.163.166.164.167.165.168.172.170.169.180.173.176.171.174.181.175.177.178.179.188.189.182.185.183.190.186.184.187.191.193.194.192.195.196.197.198.199.200.201.
+**********   Test Done    **********
+
+********** OpenFile Tester **********
+3.4.5.2.8.6.9.7.11.10.13.12.14.16.15.17.18.19.21.20.22.23.24.26.25.27.28.29.31.30.32.33.34.36.35.37.39.38.40.41.42.43.45.44.47.46.49.48.50.52.51.53.55.54.56.58.57.59.60.62.61.63.65.66.64.67.69.68.70.71.72.74.73.76.77.75.78.80.79.81.82.83.85.84.86.87.88.90.89.91.92.94.95.93.97.96.98.99.100.102.101.103.105.104.106.108.107.109.111.110.113.112.115.114.116.117.118.119.120.121.122.123.124.125.126.127.128.129.130.131.132.133.134.135.136.138.137.139.140.141.142.143.144.145.146.147.148.149.150.152.151.153.154.155.156.157.158.159.160.161.162.163.164.166.165.167.168.169.170.172.171.173.174.176.175.177.178.180.179.181.183.182.185.184.186.187.188.189.190.191.192.194.193.195.197.196.198.199.200.201.
+**********   Test Done   **********
+
+********** FileControlBlock Tester **********
+2.3.4.5.6.7.8.9.10.2!W1.3!W2.5!W3.4!W4.6!W5.7!W6.8!W7.9!W8.10!F12.2!12.3!W1.12.5!W2.12.W3.12.12.12.12.12.10!4!W4.6!W5.7!9!W6.W7.8!W8.F12.12.12.20.12.12.12.20.12.12.12.20.20.20.20.20.20.20.
+**********   Test Done   **********
+
+All Assignment 3 tests done.
+
+I call this a "heisenbug" as I never know when it will strike and stop ToyOS from running.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2984 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2984
new file mode 100644
index 00000000..b5180a69
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2984
@@ -0,0 +1,53 @@
+CPU hotplug crashed the guest when using virt-type as qemu!
+Description of problem:
+Guest is getting crashing and getting into shutoff state when I am trying to hotplug much more cpus than present in the host! This is happening only when i give virt-type as qemu.
+Additional information:
+Tried reproducing while attaching gdb shows below backtrace which happened after hotplugging 249 CPUs in TCG mode:
+
+```
+Thread 261 "CPU 249/TCG" received signal SIGABRT, Aborted.
+[Switching to Thread 0x7ff97c00ea20 (LWP 51567)]
+0x00007fff84cac3e8 in __pthread_kill_implementation () from target:/lib64/glibc-hwcaps/power10/libc.so.6
+(gdb) bt
+#0  0x00007fff84cac3e8 in __pthread_kill_implementation () from target:/lib64/glibc-hwcaps/power10/libc.so.6
+#1  0x00007fff84c46ba0 in raise () from target:/lib64/glibc-hwcaps/power10/libc.so.6
+#2  0x00007fff84c29354 in abort () from target:/lib64/glibc-hwcaps/power10/libc.so.6
+#3  0x00007fff850f1e30 in g_assertion_message () from target:/lib64/libglib-2.0.so.0
+#4  0x00007fff850f1ebc in g_assertion_message_expr () from target:/lib64/libglib-2.0.so.0
+#5  0x00000001376c6f00 in tcg_region_initial_alloc__locked (s=0x7fff7c000f30) at ../tcg/region.c:396
+#6  0x00000001376c6fa8 in tcg_region_initial_alloc (s=0x7fff7c000f30) at ../tcg/region.c:402
+#7  0x00000001376dae08 in tcg_register_thread () at ../tcg/tcg.c:1011
+#8  0x000000013768b7e4 in mttcg_cpu_thread_fn (arg=0x143e884f0) at ../accel/tcg/tcg-accel-ops-mttcg.c:77
+#9  0x0000000137bbb2d0 in qemu_thread_start (args=0x143b4aff0) at ../util/qemu-thread-posix.c:542
+#10 0x00007fff84ca9be0 in start_thread () from target:/lib64/glibc-hwcaps/power10/libc.so.6
+#11 0x00007fff84d4ef3c in __clone3 () from target:/lib64/glibc-hwcaps/power10/libc.so.6
+(gdb) 
+```
+
+which points to below code:
+
+```
+/*
+ * Perform a context's first region allocation.
+ * This function does _not_ increment region.agg_size_full.
+ */
+static void tcg_region_initial_alloc__locked(TCGContext *s)
+{
+    bool err = tcg_region_alloc__locked(s);
+    g_assert(!err);
+}
+```
+
+Here, tcg_region_alloc__locked returns true on failure when max region allocation is reached and therefore intentionally asserted as TCG can't proceed without it.
+
+```
+static bool tcg_region_alloc__locked(TCGContext *s)
+{
+    if (region.current == region.n) {
+        return true;
+    }
+    tcg_region_assign(s, region.current);
+    region.current++;
+    return false;
+}
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2985 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2985
new file mode 100644
index 00000000..844eb959
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2985
@@ -0,0 +1,8 @@
+throttle group limit feature request for discard
+Additional information:
+- Need to add particular options in [ThrottleGroupProperties](https://qemu-project.gitlab.io/qemu/interop/qemu-qmp-ref.html#object-QMP-block-core.ThrottleGroupProperties) which like this
+```txt
+x-discard-iops-total
+x-discard-iops-total-max
+....
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2986 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2986
new file mode 100644
index 00000000..cc8340b2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2986
@@ -0,0 +1 @@
+ARM register DBGDTR_EL0 incorrectly causes undefined exception
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2988 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2988
new file mode 100644
index 00000000..49598abd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2988
@@ -0,0 +1,7 @@
+Absolute mouse mode is broken in SDL2
+Description of problem:
+Absolute mouse mode is broken in SDL2. Bisected at 30aa105640b0a2a541744b6584d57c9a4b86debd.
+
+Relative mouse mode has never worked in stretched SDL2 Display for display controllers that passed through cursor data and have positions warped by HOST UI backend. It looks like 30aa105640b0a2a541744b6584d57c9a4b86debd tried to fix this but it didn't work out. Scaling **"relative motions"** isn't straight-forward as what the commit had expected.
+
+Absolute mouse mode mode has always worked in stretched SDL2 Display. 30aa105640b0a2a541744b6584d57c9a4b86debd broke it without fixing anything.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/300 b/gitlab/issues_text/target_missing/host_missing/accel_missing/300
new file mode 100644
index 00000000..86861247
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/300
@@ -0,0 +1 @@
+qemu-system-i386 virtio-vga: Assertion in address_space_stw_le_cached failed again
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/301 b/gitlab/issues_text/target_missing/host_missing/accel_missing/301
new file mode 100644
index 00000000..f229c74f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/301
@@ -0,0 +1 @@
+Assertion `addr < cache->len && 2 <= cache->len - addr' in virtio-blk
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/302 b/gitlab/issues_text/target_missing/host_missing/accel_missing/302
new file mode 100644
index 00000000..9237e468
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/302
@@ -0,0 +1 @@
+[Fuzz] qemu-system-i386 virtio-mouse: Assertion in address_space_lduw_le_cached failed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/303 b/gitlab/issues_text/target_missing/host_missing/accel_missing/303
new file mode 100644
index 00000000..1fe2e797
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/303
@@ -0,0 +1 @@
+assert issue locates in hw/usb/core.c:727: usb_ep_get: Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/304 b/gitlab/issues_text/target_missing/host_missing/accel_missing/304
new file mode 100644
index 00000000..f3faeb78
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/304
@@ -0,0 +1 @@
+assertion failure in mptsas1068 emulator
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/305 b/gitlab/issues_text/target_missing/host_missing/accel_missing/305
new file mode 100644
index 00000000..0856bcf5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/305
@@ -0,0 +1 @@
+assertion failure in lsi53c810 emulator
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/306 b/gitlab/issues_text/target_missing/host_missing/accel_missing/306
new file mode 100644
index 00000000..c9c23af0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/306
@@ -0,0 +1 @@
+Option to constrain linux-user exec() to emulated CPU only
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/307 b/gitlab/issues_text/target_missing/host_missing/accel_missing/307
new file mode 100644
index 00000000..b0363161
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/307
@@ -0,0 +1 @@
+qemu may freeze during drive-mirroring on fragmented FS
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/308 b/gitlab/issues_text/target_missing/host_missing/accel_missing/308
new file mode 100644
index 00000000..4fdc7c95
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/308
@@ -0,0 +1 @@
+QEMU: net: vmxnet: integer overflow may crash guest
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/309 b/gitlab/issues_text/target_missing/host_missing/accel_missing/309
new file mode 100644
index 00000000..52162979
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/309
@@ -0,0 +1 @@
+assert issue locates in hw/net/vmxnet3.c:1793:vmxnet3_io_bar1_write: code should not be reach
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/310 b/gitlab/issues_text/target_missing/host_missing/accel_missing/310
new file mode 100644
index 00000000..e7664005
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/310
@@ -0,0 +1 @@
+unable to migrate non shared storage when TLS is used
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/311 b/gitlab/issues_text/target_missing/host_missing/accel_missing/311
new file mode 100644
index 00000000..c0496864
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/311
@@ -0,0 +1 @@
+qemu user mode: rt signals not implemented for sparc guests
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/313 b/gitlab/issues_text/target_missing/host_missing/accel_missing/313
new file mode 100644
index 00000000..1531161e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/313
@@ -0,0 +1 @@
+-daemonize not working on macOS
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/315 b/gitlab/issues_text/target_missing/host_missing/accel_missing/315
new file mode 100644
index 00000000..49e2d2ea
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/315
@@ -0,0 +1 @@
+3d accel does not take care of 1280x960 setting
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/316 b/gitlab/issues_text/target_missing/host_missing/accel_missing/316
new file mode 100644
index 00000000..ecdca3a8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/316
@@ -0,0 +1 @@
+[feature request] webcam support
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/321 b/gitlab/issues_text/target_missing/host_missing/accel_missing/321
new file mode 100644
index 00000000..b515a6c4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/321
@@ -0,0 +1 @@
+qemu 5.2.0 configure script explodes when in read only directory
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/322 b/gitlab/issues_text/target_missing/host_missing/accel_missing/322
new file mode 100644
index 00000000..d71c62fc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/322
@@ -0,0 +1 @@
+Can't(?) disable default floppy drive any more in qemu 6.0
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/323 b/gitlab/issues_text/target_missing/host_missing/accel_missing/323
new file mode 100644
index 00000000..821a2843
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/323
@@ -0,0 +1 @@
+qemu 5.2.0: Add reconnect option support for netdev socket
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/324 b/gitlab/issues_text/target_missing/host_missing/accel_missing/324
new file mode 100644
index 00000000..ccd57dfa
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/324
@@ -0,0 +1 @@
+chrome based apps can not be run under qemu user mode
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/327 b/gitlab/issues_text/target_missing/host_missing/accel_missing/327
new file mode 100644
index 00000000..69c44608
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/327
@@ -0,0 +1 @@
+Storage | Two decimal digits precision
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/328 b/gitlab/issues_text/target_missing/host_missing/accel_missing/328
new file mode 100644
index 00000000..45180a8b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/328
@@ -0,0 +1 @@
+numerical keypad disabled by default in the guest
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/332 b/gitlab/issues_text/target_missing/host_missing/accel_missing/332
new file mode 100644
index 00000000..2d9d673e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/332
@@ -0,0 +1 @@
+VirtIO drivers don't work on Windows: "GLib: Too many handles to wait for!" crash
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/334 b/gitlab/issues_text/target_missing/host_missing/accel_missing/334
new file mode 100644
index 00000000..447ad007
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/334
@@ -0,0 +1 @@
+macOS App Nap feature gradually freezes QEMU process
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/335 b/gitlab/issues_text/target_missing/host_missing/accel_missing/335
new file mode 100644
index 00000000..e9fce88d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/335
@@ -0,0 +1 @@
+Broken tap networking on macOS host
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/336 b/gitlab/issues_text/target_missing/host_missing/accel_missing/336
new file mode 100644
index 00000000..e70bf173
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/336
@@ -0,0 +1 @@
+Built-in DHCP server: SiAddr
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/338 b/gitlab/issues_text/target_missing/host_missing/accel_missing/338
new file mode 100644
index 00000000..8c131dc8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/338
@@ -0,0 +1 @@
+QEMU: Null Pointer Failure in fdctrl_read() in hw/block/fdc.c
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/341 b/gitlab/issues_text/target_missing/host_missing/accel_missing/341
new file mode 100644
index 00000000..2488fcc2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/341
@@ -0,0 +1 @@
+Null-ptr dereference on AHCICmdHdr in ahci_pio_transfer
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/342 b/gitlab/issues_text/target_missing/host_missing/accel_missing/342
new file mode 100644
index 00000000..bcca3139
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/342
@@ -0,0 +1 @@
+Assertion `child->perm & BLK_PERM_WRITE' failed in bdrv_co_write_req_prepare through atapi
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/344 b/gitlab/issues_text/target_missing/host_missing/accel_missing/344
new file mode 100644
index 00000000..f09d798d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/344
@@ -0,0 +1 @@
+Option "-loadvm"  cannot load VM snapshot, created from QMP API
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/345 b/gitlab/issues_text/target_missing/host_missing/accel_missing/345
new file mode 100644
index 00000000..2b60167e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/345
@@ -0,0 +1 @@
+Sector translation bug in scsi_unmap_complete_noio
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/347 b/gitlab/issues_text/target_missing/host_missing/accel_missing/347
new file mode 100644
index 00000000..7d4b2182
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/347
@@ -0,0 +1 @@
+Forward host UNIX socket to guest TCP port
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/348 b/gitlab/issues_text/target_missing/host_missing/accel_missing/348
new file mode 100644
index 00000000..76e34489
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/348
@@ -0,0 +1 @@
+qemu-user fails to run container using systemd-networkd: "Could not create manager: Protocol not supported"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/349 b/gitlab/issues_text/target_missing/host_missing/accel_missing/349
new file mode 100644
index 00000000..d1e969c8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/349
@@ -0,0 +1 @@
+USB folder sharing causing segment fault
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/350 b/gitlab/issues_text/target_missing/host_missing/accel_missing/350
new file mode 100644
index 00000000..7b757be4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/350
@@ -0,0 +1 @@
+lsisas1068 not supported (for VMDK manipulation)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/351 b/gitlab/issues_text/target_missing/host_missing/accel_missing/351
new file mode 100644
index 00000000..3ffe774c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/351
@@ -0,0 +1 @@
+German keyboard vnc issue
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/354 b/gitlab/issues_text/target_missing/host_missing/accel_missing/354
new file mode 100644
index 00000000..0f14f4c2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/354
@@ -0,0 +1 @@
+Emulation error when calling the SIOCGIFNETMASK ioctl through qemu-user
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/355 b/gitlab/issues_text/target_missing/host_missing/accel_missing/355
new file mode 100644
index 00000000..78053cf4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/355
@@ -0,0 +1 @@
+A possible divide by zero bug in get_whole_cluster
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/357 b/gitlab/issues_text/target_missing/host_missing/accel_missing/357
new file mode 100644
index 00000000..a3a3797d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/357
@@ -0,0 +1 @@
+race condition in hw/input/pckbd.c causes wrong data to be read on interrupts
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/359 b/gitlab/issues_text/target_missing/host_missing/accel_missing/359
new file mode 100644
index 00000000..ce7dbaa8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/359
@@ -0,0 +1 @@
+In the "tests/qtests/meson.build" line 92 need dbus-vmstate1.h and dbus-vmstate1.c files, but in "tests/qtests/" not include this files.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/362 b/gitlab/issues_text/target_missing/host_missing/accel_missing/362
new file mode 100644
index 00000000..c86fa33c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/362
@@ -0,0 +1 @@
+check of PMR capability is missing for PMRCTL register write
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/365 b/gitlab/issues_text/target_missing/host_missing/accel_missing/365
new file mode 100644
index 00000000..ac5b0c2b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/365
@@ -0,0 +1 @@
+virtiofsd: Directory for PID file hardcoded
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/366 b/gitlab/issues_text/target_missing/host_missing/accel_missing/366
new file mode 100644
index 00000000..d4968d28
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/366
@@ -0,0 +1 @@
+How to make OVMF
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/369 b/gitlab/issues_text/target_missing/host_missing/accel_missing/369
new file mode 100644
index 00000000..eb61187e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/369
@@ -0,0 +1 @@
+Remove leading underscores from #defines
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/370 b/gitlab/issues_text/target_missing/host_missing/accel_missing/370
new file mode 100644
index 00000000..29f077bd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/370
@@ -0,0 +1 @@
+Indentation should be done with spaces, not with TABs, in the UI, graphics, audio and USB subsystem
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/371 b/gitlab/issues_text/target_missing/host_missing/accel_missing/371
new file mode 100644
index 00000000..7ed23dfd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/371
@@ -0,0 +1 @@
+Indentation should be done with spaces, not with TABs, in the block subsystem
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/377 b/gitlab/issues_text/target_missing/host_missing/accel_missing/377
new file mode 100644
index 00000000..0e4dc88a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/377
@@ -0,0 +1 @@
+Indentation should be done with spaces, not with TABs, in the net subsystem
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/378 b/gitlab/issues_text/target_missing/host_missing/accel_missing/378
new file mode 100644
index 00000000..5c6da66e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/378
@@ -0,0 +1 @@
+Indentation should be done with spaces, not with TABs
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/379 b/gitlab/issues_text/target_missing/host_missing/accel_missing/379
new file mode 100644
index 00000000..f1cf1b26
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/379
@@ -0,0 +1 @@
+Update the FSF address to their current location
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/383 b/gitlab/issues_text/target_missing/host_missing/accel_missing/383
new file mode 100644
index 00000000..a2fab8ab
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/383
@@ -0,0 +1 @@
+virtio-gpu: heap-buffer-overflow in virtio_gpu_disable_scanout
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/384 b/gitlab/issues_text/target_missing/host_missing/accel_missing/384
new file mode 100644
index 00000000..f284de94
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/384
@@ -0,0 +1 @@
+qemu-monitor-event command gets stuck randomly
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/388 b/gitlab/issues_text/target_missing/host_missing/accel_missing/388
new file mode 100644
index 00000000..56520091
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/388
@@ -0,0 +1 @@
+Can not pass hw device names as alsa input and output devices
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/392 b/gitlab/issues_text/target_missing/host_missing/accel_missing/392
new file mode 100644
index 00000000..f3927ae3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/392
@@ -0,0 +1 @@
+`-hda` and `-drive` differ with respect to path handling
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/393 b/gitlab/issues_text/target_missing/host_missing/accel_missing/393
new file mode 100644
index 00000000..51c5e1b5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/393
@@ -0,0 +1 @@
+tests/vm: Warn when cross-build VM is run with TCG accelerator
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/395 b/gitlab/issues_text/target_missing/host_missing/accel_missing/395
new file mode 100644
index 00000000..393b3077
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/395
@@ -0,0 +1 @@
+Write a python style guide document
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/396 b/gitlab/issues_text/target_missing/host_missing/accel_missing/396
new file mode 100644
index 00000000..1b602555
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/396
@@ -0,0 +1 @@
+Investigate moving other packages in ./scripts to ./python
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/397 b/gitlab/issues_text/target_missing/host_missing/accel_missing/397
new file mode 100644
index 00000000..ec7b93eb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/397
@@ -0,0 +1 @@
+Cannot run qemu at all
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/398 b/gitlab/issues_text/target_missing/host_missing/accel_missing/398
new file mode 100644
index 00000000..071c6a2b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/398
@@ -0,0 +1 @@
+qemu-system-aarch64  could not open 'ubuntu-16.04-server-cloudimg-arm64-uefi1.img' qemu6.0 on windows 10
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/399 b/gitlab/issues_text/target_missing/host_missing/accel_missing/399
new file mode 100644
index 00000000..ddcbd9c6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/399
@@ -0,0 +1 @@
+drive-backup job hangs in a 'paused' state after unsuccessful first attempt
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/400 b/gitlab/issues_text/target_missing/host_missing/accel_missing/400
new file mode 100644
index 00000000..ff9830c4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/400
@@ -0,0 +1 @@
+Build error -Werror=stringop-overflow in util/qemu-thread-posix.c
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/401 b/gitlab/issues_text/target_missing/host_missing/accel_missing/401
new file mode 100644
index 00000000..e1848f51
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/401
@@ -0,0 +1 @@
+Wishlist: nvme-ns: allow specifying eui-64
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/402 b/gitlab/issues_text/target_missing/host_missing/accel_missing/402
new file mode 100644
index 00000000..0158b436
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/402
@@ -0,0 +1 @@
+e1000 / e1000e randomly stop sending packets to VM with DPDK app in VM
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/405 b/gitlab/issues_text/target_missing/host_missing/accel_missing/405
new file mode 100644
index 00000000..a3b3af79
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/405
@@ -0,0 +1 @@
+Assertion failure in e1000e_intrmgr_on_throttling_timer
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/406 b/gitlab/issues_text/target_missing/host_missing/accel_missing/406
new file mode 100644
index 00000000..a4a19191
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/406
@@ -0,0 +1 @@
+vhost-user net device sends SET_VRING_ENABLE before feature negotiation
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/407 b/gitlab/issues_text/target_missing/host_missing/accel_missing/407
new file mode 100644
index 00000000..b48e15f4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/407
@@ -0,0 +1 @@
+migration: Build failure on MacOS with Homebrew (gnutls/gnutls.h not found)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/408 b/gitlab/issues_text/target_missing/host_missing/accel_missing/408
new file mode 100644
index 00000000..3ba91f60
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/408
@@ -0,0 +1 @@
+DLLs not installing on 32bit version
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/409 b/gitlab/issues_text/target_missing/host_missing/accel_missing/409
new file mode 100644
index 00000000..e8a3f5e0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/409
@@ -0,0 +1 @@
+tar can only read 4096 bytes from some files on 9p
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/413 b/gitlab/issues_text/target_missing/host_missing/accel_missing/413
new file mode 100644
index 00000000..df3ed1e4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/413
@@ -0,0 +1 @@
+Error handling: Audit callers of load_image_targphys, get_image_size, event_notifier_init, msix_init
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/414 b/gitlab/issues_text/target_missing/host_missing/accel_missing/414
new file mode 100644
index 00000000..0fa409d6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/414
@@ -0,0 +1 @@
+Error handling: Use &error_abort instead of NULL for errp parameters for may-not-fail invocations
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/415 b/gitlab/issues_text/target_missing/host_missing/accel_missing/415
new file mode 100644
index 00000000..72903db5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/415
@@ -0,0 +1 @@
+Error handling: Use TFR() macro where applicable
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/416 b/gitlab/issues_text/target_missing/host_missing/accel_missing/416
new file mode 100644
index 00000000..52d33d6b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/416
@@ -0,0 +1 @@
+Error handling: Audit unsafe usages of strerror()
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/417 b/gitlab/issues_text/target_missing/host_missing/accel_missing/417
new file mode 100644
index 00000000..0db7dfb9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/417
@@ -0,0 +1 @@
+allow qemu_thread_create to return with error
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/418 b/gitlab/issues_text/target_missing/host_missing/accel_missing/418
new file mode 100644
index 00000000..76aa13d5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/418
@@ -0,0 +1 @@
+qemu-img commit on Windows 10 fails
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/419 b/gitlab/issues_text/target_missing/host_missing/accel_missing/419
new file mode 100644
index 00000000..22a93085
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/419
@@ -0,0 +1 @@
+bsd-user dumps core for all binaries emulated
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/423 b/gitlab/issues_text/target_missing/host_missing/accel_missing/423
new file mode 100644
index 00000000..71a750c1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/423
@@ -0,0 +1 @@
+NVME disk cannot be hotplugged after removal
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/424 b/gitlab/issues_text/target_missing/host_missing/accel_missing/424
new file mode 100644
index 00000000..166c5422
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/424
@@ -0,0 +1 @@
+the option for vdagent communication needed for qxl scren resizing is not documented
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/425 b/gitlab/issues_text/target_missing/host_missing/accel_missing/425
new file mode 100644
index 00000000..fc53354e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/425
@@ -0,0 +1 @@
+QEMU prepends pathnames to command lines of Multiboot kernels and modules, contrary to the specification
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/428 b/gitlab/issues_text/target_missing/host_missing/accel_missing/428
new file mode 100644
index 00000000..a81b09e5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/428
@@ -0,0 +1 @@
+Windows: Very low network throughput with tap-netdev & virtio-serial
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/429 b/gitlab/issues_text/target_missing/host_missing/accel_missing/429
new file mode 100644
index 00000000..02a02c08
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/429
@@ -0,0 +1 @@
+Build failure on MacOS with Homebrew after upgrade
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/431 b/gitlab/issues_text/target_missing/host_missing/accel_missing/431
new file mode 100644
index 00000000..98e9e085
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/431
@@ -0,0 +1 @@
+USB passthrough in Windows Host non functional
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/432 b/gitlab/issues_text/target_missing/host_missing/accel_missing/432
new file mode 100644
index 00000000..d3d9d649
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/432
@@ -0,0 +1 @@
+QAPI: Avoid generating empty source files
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/433 b/gitlab/issues_text/target_missing/host_missing/accel_missing/433
new file mode 100644
index 00000000..53e94bbd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/433
@@ -0,0 +1 @@
+chardev: Windows stdio eats characters
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/434 b/gitlab/issues_text/target_missing/host_missing/accel_missing/434
new file mode 100644
index 00000000..5e0f5da1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/434
@@ -0,0 +1 @@
+Mouse pointer disappears when it is over console window
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/436 b/gitlab/issues_text/target_missing/host_missing/accel_missing/436
new file mode 100644
index 00000000..ad8d15b9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/436
@@ -0,0 +1 @@
+window 8 stuck during boot on Qemu
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/437 b/gitlab/issues_text/target_missing/host_missing/accel_missing/437
new file mode 100644
index 00000000..d8b52e19
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/437
@@ -0,0 +1 @@
+[AHCI] crash when running a GNU/Hurd guest
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/440 b/gitlab/issues_text/target_missing/host_missing/accel_missing/440
new file mode 100644
index 00000000..3950273c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/440
@@ -0,0 +1 @@
+/usr/share/applications/qemu.desktop should have an "Exec=" key.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/441 b/gitlab/issues_text/target_missing/host_missing/accel_missing/441
new file mode 100644
index 00000000..9e9e2510
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/441
@@ -0,0 +1 @@
+qemu-img: "Could not open backing image to determine size" when backing image is encrypted
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/445 b/gitlab/issues_text/target_missing/host_missing/accel_missing/445
new file mode 100644
index 00000000..84c4e8f6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/445
@@ -0,0 +1 @@
+QEMU + DOS keyboard behavior
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/446 b/gitlab/issues_text/target_missing/host_missing/accel_missing/446
new file mode 100644
index 00000000..261a6594
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/446
@@ -0,0 +1 @@
+usb-audio does not work with Mac OS
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/450 b/gitlab/issues_text/target_missing/host_missing/accel_missing/450
new file mode 100644
index 00000000..fa56e5c5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/450
@@ -0,0 +1 @@
+sdhci: Assertion wpnum < sd->wpgrps_size failed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/451 b/gitlab/issues_text/target_missing/host_missing/accel_missing/451
new file mode 100644
index 00000000..7b0d5278
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/451
@@ -0,0 +1 @@
+sdhci: Heap-buffer-overflow in sdhci_read_dataport
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/453 b/gitlab/issues_text/target_missing/host_missing/accel_missing/453
new file mode 100644
index 00000000..50527147
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/453
@@ -0,0 +1,3 @@
+tests/acceptance: Allow to overwrite smp and memory values set by `avocado_qemu.LinuxTest`
+Additional information:
+Refer to the discussion in https://lore.kernel.org/qemu-devel/20210621080824.789274-1-eric.auger@redhat.com/
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/455 b/gitlab/issues_text/target_missing/host_missing/accel_missing/455
new file mode 100644
index 00000000..4651c717
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/455
@@ -0,0 +1,34 @@
+Pressing special keys (specially ctrl) sticks the key or makes it repeat the next key until ESC or Ctrl is pressed.
+Description of problem:
+Well, I'm using it in a daily basis, since it is my VM to isolate the environment for work.
+
+It was compiled from source for _jack_ support, the only thing that I cared about. I'll be honest : I don't remember the special parameters, nothing unusual though. I'm not in the need for _rt_ kernels.
+
+When I press `Ctrl` and sometimes when I press other special keys, one of the three options occur :
+1. It repeats all the keys pressed next, like if I was pressing it for a long time.
+    - Example : `a` turns into `aaaaaaaaaaaaaaa...`(continues)
+    - It repeats until I press `Esc` or `Ctrl` again.
+1. `Ctrl` continues as pressed and everything I type occurs with `Ctrl`.
+    - Example : `a` turns into `Ctrl-A`
+    - Probably caused by the previous option.
+1. It does what is expected, like `Ctrl-C`
+Steps to reproduce:
+1. Run the specified config.
+1. Test `Ctrl-C` + `Ctrl-V` using text editors.
+    - I think that using a graphical one is faster to see it happening.
+    - Examples
+        - Atom
+        - Eclipse
+        - Kate
+        - VsCode
+    - It also occurred using a _pty_ but since I generally use the _middle-mouse-button_ with _ptys_.
+        - I'm not aware of the frequency that it happens.
+    - It also occurs with the mouse (`Ctrl-mouseclick`).
+        - For example: instead of going to a _Firefox_'s tab, it selects it.
+
+I don't know any other step here, the use case is trivial coding.
+Additional information:
+- I have already tried to disable "keyboard repeat" in config.
+    - At first it seems to work but the `Ctrl` key can get stuck like in the description and then I'm unable to get out of it (everything is sent as if it was with `Ctrl`) without pressing `Ctrl`+`ESC`. I have no idea of why.
+    - The problem seems to occur less frequently.
+- It also happened before setting up `qemu-guest-agent`.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/456 b/gitlab/issues_text/target_missing/host_missing/accel_missing/456
new file mode 100644
index 00000000..484667fe
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/456
@@ -0,0 +1,29 @@
+Qemu User (x86_64) Hangs after futex function not implemented error
+Description of problem:
+Qemu User hangs on futex call with the following last strace
+```
+futex(0x0000004001a01654,FUTEX_PRIVATE_FLAG|FUTEX_UNLOCK_PI,0,NULL,NULL,0) = -1 errno=38 (Function not implemented)
+```
+This is the last call until giving a SIGINT with CTRL + C where the following strace is output
+```
+futex(0x00000040b0085180,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,2,NULL,NULL,0) = -1 errno=4 (Interrupted system call)
+--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL, si_pid=0, si_uid=0} ---
+
+```
+Steps to reproduce:
+1. Install steamcmd https://developer.valvesoftware.com/wiki/SteamCMD
+2. In the steamcmd shell install Valheim dedicated server with `app_update 896660`
+3. Navigate to the downloaded app `cd ~/Steam/steamapps/common/Valheim\ dedicated\ server/`
+4. Run `qemu-x86_64 valheim_server.x86_64`
+5. The process hangs as per description.
+Additional information:
+The issue was originally encountered on a raspberry pi ARM64 host using the ubuntu 5.2.0 version of qemu. Installed cross libararies:
+* libc6-amd64-cross
+* libgcc-s1-amd64-cross
+
+It was then replicated on the x86 host fedora with a build of the qemu master branch.
+The full qemu -strace output is provided below
+[qemu_strace_output.log](/uploads/96e0e31b1e63191a94d73f05023c5173/qemu_strace_output.log)
+
+The expected output found when running `strace ./valheim_server.x86_64` without qemu on the x86_64 host is attached below
+[expected_output.log](/uploads/b3b25618103de8a3b9c0ef227bbffc9c/expected_output.log)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/458 b/gitlab/issues_text/target_missing/host_missing/accel_missing/458
new file mode 100644
index 00000000..730e3135
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/458
@@ -0,0 +1 @@
+Xfer:features:read truncating xml sent to gdb frontends
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/46 b/gitlab/issues_text/target_missing/host_missing/accel_missing/46
new file mode 100644
index 00000000..0b5054d2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/46
@@ -0,0 +1 @@
+Investigate suitibility of GitLab Issue Tracker for QEMU
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/460 b/gitlab/issues_text/target_missing/host_missing/accel_missing/460
new file mode 100644
index 00000000..52c311eb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/460
@@ -0,0 +1 @@
+vmxnet3: Assertion failure in eth_setup_ip4_fragmentation
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/462 b/gitlab/issues_text/target_missing/host_missing/accel_missing/462
new file mode 100644
index 00000000..b03cf0a1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/462
@@ -0,0 +1,43 @@
+mirror: the block-job-cancel command can put qemu to the endless error loop
+Description of problem:
+If the destination VM will crash (or network is down) right before the completion of the block device mirroring job (`block-job-cancel`), then there will be a possibility to put QEMU in the error loop.
+Steps to reproduce:
+1. Run both QEMU VMs: source + target.
+2. On the target side prepare NBD server for blockdev mirroring process by using QMP commands similar to the one below:
+```
+{"execute": "nbd-server-start", "arguments": { "addr": { "data": { "host": "::", "port": "49153" }, "type": "inet" } } }
+{ "execute": "nbd-server-add", "arguments": { "device": "drive_main01", "writable": true } }
+```
+3. On the source side, prepare VM for the migration and start driver mirror job:
+```
+{"execute":"migrate-set-capabilities","arguments":{"capabilities":[{"capability":"pause-before-switchover","state":true}]}}
+{ "execute": "drive-mirror", "arguments": { "device": "drive_main01", "mode": "existing", "job-id": "job0", "target": "nbd:127.0.0.1:49153:exportname=drive_main01", "sync": "top", "on-source-error": "stop", "on-target-error": "stop", "format": "raw", "speed": 0 } }
+```
+4. On the source side wait for the `BLOCK_JOB_READY` event:
+```
+{"timestamp": {"seconds": 1625586327, "microseconds": 833805}, "event": "BLOCK_JOB_READY", "data": {"device": "job0", "len": 21474836480, "offset": 21474836480, "speed": 0, "type": "mirror"}}
+```
+5. Start migration on the source side:
+```
+{ "execute": "migrate", "arguments": { "uri": "tcp:127.0.0.1:8091" } }
+```
+6. Wait for the `pre-switchover` state of the migration:
+```
+{ "execute": "query-migrate" }
+{"return": {"expected-downtime": 300, "status": "pre-switchover", "setup-time": 3, "total-time": 11343, "ram": {"total": 8725020672, "postcopy-requests": 0, "dirty-sync-count": 2, "multifd-bytes": 0, "pages-per-second": 39550, "page-size": 4096, "remaining": 2871296, "mbps": 1073.7734399999999, "transferred": 963647065, "duplicate": 1899491, "dirty-pages-rate": 84, "skipped": 0, "normal-bytes": 944705536, "normal": 230641}}}
+```
+7. Kill target QEMU to reproduce an issue.
+8. Cancel the job on the source side:
+```
+{ "execute": "block-job-cancel", "arguments": { "device": "job0" } }
+```
+
+Got the endless errror loop:
+```
+...
+{"timestamp": {"seconds": 1625586487, "microseconds": 413847}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}}
+{"timestamp": {"seconds": 1625586487, "microseconds": 413865}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}}
+{"timestamp": {"seconds": 1625586487, "microseconds": 413885}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}}
+...
+```
+Source qemu could be stopped only by using SIGKILL.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/463 b/gitlab/issues_text/target_missing/host_missing/accel_missing/463
new file mode 100644
index 00000000..e91a06a3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/463
@@ -0,0 +1,25 @@
+[Build][git]Build process stop in libqemuutil.a.p/qobject_json-streamer.c.o
+Description of problem:
+Hello.
+
+I tried qemu to get build with revision 9aef0954195cc592e86846dbbe7f3c2c5603690a but it stops really quick at task 238/9335.
+
+Here is the beginning of the error log:
+
+```
+[238/9335] Compiling C object libqemuutil.a.p/qobject_json-streamer.c.o
+FAILED: libqemuutil.a.p/qobject_json-streamer.c.o 
+cc -Ilibqemuutil.a.p -I. -I.. -Isubprojects/libvhost-user -I../subprojects/libvhost-user -Itrace -Iqapi -Iui -Iui/shader -I/usr/include/p11-kit-1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -I/usr/include/pixman-1 -fdiagnostics-color=auto -pipe -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /build/qemu-git/src/qemu/linux-headers -isystem linux-headers -iquote . -iquote /build/qemu-git/src/qemu -iquote /build/qemu-git/src/qemu/include -iquote /build/qemu-git/src/qemu/disas/libvixl -iquote /build/qemu-git/src/qemu/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -m64 -mcx16 -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 -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fPIC -MD -MQ libqemuutil.a.p/qobject_json-streamer.c.o -MF libqemuutil.a.p/qobject_json-streamer.c.o.d -o libqemuutil.a.p/qobject_json-streamer.c.o -c ../qobject/json-streamer.c
+In file included from ../qobject/json-streamer.c:14:
+/build/qemu-git/src/qemu/include/qemu/osdep.h:259:58: error: operator '&&' has no right operand
+  259 | #if defined(HAVE_BROKEN_SIZE_MAX) && HAVE_BROKEN_SIZE_MAX
+      |   
+```
+Steps to reproduce:
+1. Grab qemu-git code at commit 9aef0954195cc592e86846dbbe7f3c2c5603690a
+2. use these configure options: --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror --enable-vhost-user --enable-slirp=system --enable-xfsctl --audio-drv-list="pa alsa sdl"
+3. run building process.
+Additional information:
+Attaching full build log.
+
+I'm using gcc 11.1.0. My last complete build was based on commit 9bef7ea9
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/464 b/gitlab/issues_text/target_missing/host_missing/accel_missing/464
new file mode 100644
index 00000000..2803cae6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/464
@@ -0,0 +1 @@
+The virtio disk shows offline when try to install windows version v6.0.5
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/465 b/gitlab/issues_text/target_missing/host_missing/accel_missing/465
new file mode 100644
index 00000000..ea8e837e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/465
@@ -0,0 +1,7 @@
+Support network virtualization for Macos Big Sur+
+Additional information:
+The following implementation are already submitted as a patch and they seem to work well on my mbp 2019 Big Sur. The only prob is that the qemu-system command should be run as root.
+
+[https://patchwork.kernel.org/project/qemu-devel/list/?series=502533](https://patchwork.kernel.org/project/qemu-devel/list/?series=502533)
+
+[https://patchwork.kernel.org/project/qemu-devel/patch/20210708054451.9374-1-akihiko.odaki@gmail.com/](https://patchwork.kernel.org/project/qemu-devel/patch/20210708054451.9374-1-akihiko.odaki@gmail.com/)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/469 b/gitlab/issues_text/target_missing/host_missing/accel_missing/469
new file mode 100644
index 00000000..11313a5e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/469
@@ -0,0 +1 @@
+SB16 audio playback freezes emulation in Windows 95 guest
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/471 b/gitlab/issues_text/target_missing/host_missing/accel_missing/471
new file mode 100644
index 00000000..55f186f9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/471
@@ -0,0 +1,64 @@
+Clipboard sharing with `qemu_vdagent` does not work with SDL backend
+Description of problem:
+Clipboard sharing doesn't work: qemu does not send clipboard-grab messages when selecting on the host, nor does it respond to clipboard-grab messages from the guest.
+Steps to reproduce:
+1. Start QEMU with `qemu_vdagent` and `-display sdl`
+2. Try to copy on the host or the guest
+3. Observe that the clipboard is not shared
+Additional information:
+It appears as though `vdagent_clipboard_notify` function is not called.
+
+Logs: 
+
+With SDL:
+```
+vdagent_open 
+vdagent_recv_chunk size 28
+vdagent_recv_msg msg announce-capabilities, size 8
+vdagent_peer_cap cap mouse-state
+vdagent_peer_cap cap monitors-config
+vdagent_peer_cap cap reply
+vdagent_peer_cap cap clipboard-by-demand
+vdagent_peer_cap cap clipboard-selection
+vdagent_peer_cap cap sparse-monitors-config
+vdagent_peer_cap cap guest-lineend-lf
+vdagent_peer_cap cap max-clipboard
+vdagent_peer_cap cap audio-volume-sync
+vdagent_send msg announce-capabilities
+# tried to copy on host -- nothing happens here.
+# trying to copy on guest:
+vdagent_recv_chunk size 28
+vdagent_recv_msg msg clipboard-grab, size 8
+vdagent_cb_grab_selection selection clipboard
+vdagent_cb_grab_type type text
+# no response sent
+```
+With GTK:
+```
+vdagent_open 
+vdagent_recv_chunk size 28
+vdagent_recv_msg msg announce-capabilities, size 8
+vdagent_peer_cap cap mouse-state
+vdagent_peer_cap cap monitors-config
+vdagent_peer_cap cap reply
+vdagent_peer_cap cap clipboard-by-demand
+vdagent_peer_cap cap clipboard-selection
+vdagent_peer_cap cap sparse-monitors-config
+vdagent_peer_cap cap guest-lineend-lf
+vdagent_peer_cap cap max-clipboard
+vdagent_peer_cap cap audio-volume-sync
+vdagent_send msg announce-capabilities
+# trying to copy on host:
+vdagent_send msg clipboard-grab
+vdagent_recv_chunk size 28
+vdagent_recv_msg msg clipboard-request, size 8
+vdagent_send msg clipboard
+vdagent_recv_chunk size 28
+# trying to copy on guest:
+vdagent_recv_msg msg clipboard-grab, size 8
+vdagent_cb_grab_selection selection clipboard
+vdagent_cb_grab_type type text
+vdagent_send msg clipboard-request
+vdagent_recv_chunk size 29
+vdagent_recv_msg msg clipboard, size 9
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/473 b/gitlab/issues_text/target_missing/host_missing/accel_missing/473
new file mode 100644
index 00000000..eebf94a5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/473
@@ -0,0 +1 @@
+QEMU 6.0.0 - NSIS installer script issues
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/474 b/gitlab/issues_text/target_missing/host_missing/accel_missing/474
new file mode 100644
index 00000000..71be4a68
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/474
@@ -0,0 +1,30 @@
+[build][git]Build process stops while linking qemu-aarch64_be in util/async.c:426
+Description of problem:
+Looks like this is a followup of bug #463. Even if this bug is fixed, build process breaks later.
+
+This time, build process is stop while processing linking qemu-aarch64_be, really late at step 6492/9511.
+
+Error log start with:
+
+```
+[6492/9511] Linking target qemu-aarch64_be
+FAILED: qemu-aarch64_be 
+```
+
+And later I can read:
+
+```
+/usr/bin/ld: libqemuutil.a(util_async.c.o): in function `aio_setup_linux_io_uring':
+/build/qemu-git/src/qemu/build-full/../util/async.c:421: undefined reference to `luring_init'
+/usr/bin/ld: /build/qemu-git/src/qemu/build-full/../util/async.c:426: undefined reference to `luring_attach_aio_context'
+/usr/bin/ld: libqemuutil.a(util_async.c.o): in function `aio_ctx_finalize':
+/build/qemu-git/src/qemu/build-full/../util/async.c:334: undefined reference to `luring_detach_aio_context'
+/usr/bin/ld: /build/qemu-git/src/qemu/build-full/../util/async.c:335: undefined reference to `luring_cleanup'
+collect2: error: ld returned 1 exit status
+```
+Steps to reproduce:
+1. Grab source code at commit bd38ae2
+2. use these configure options: --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror --enable-vhost-user --enable-slirp=system --enable-xfsctl --audio-drv-list="pa alsa sdl"
+3. Launch build process.
+Additional information:
+Adding building process log.[qemu-git-13_6.0.0.r2577.gbd38ae26ce-1-x86_64-build.log](/uploads/419d2323799aad3a0f4a7719ce123f35/qemu-git-13_6.0.0.r2577.gbd38ae26ce-1-x86_64-build.log)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/476 b/gitlab/issues_text/target_missing/host_missing/accel_missing/476
new file mode 100644
index 00000000..411933c0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/476
@@ -0,0 +1 @@
+QEMU with x86-64 EFI disk image and 'nographic' option crashes WSL2 window
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/479 b/gitlab/issues_text/target_missing/host_missing/accel_missing/479
new file mode 100644
index 00000000..c6564eb5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/479
@@ -0,0 +1,12 @@
+qemu-6.0.0:  Assertion 'p_rcu_reader->depth != 0' failed
+Description of problem:
+assertion failure:
+```
+qemu-system-aarch64: /home/aileen/Downloads/qemu-6.0.0/include/qemu/rcu.h:93: rcu_read_unlock: Assertion `p_rcu_reader->depth != 0' failed.
+```
+Steps to reproduce:
+1. You cannot
+2.   unless I give
+3.   you the ELF file.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/48 b/gitlab/issues_text/target_missing/host_missing/accel_missing/48
new file mode 100644
index 00000000..52fafa18
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/48
@@ -0,0 +1 @@
+Hover effect color for "Full list of releases" button is low contrast
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/480 b/gitlab/issues_text/target_missing/host_missing/accel_missing/480
new file mode 100644
index 00000000..2c4dbec2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/480
@@ -0,0 +1 @@
+Supported ARMv8.? Opcodes
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/483 b/gitlab/issues_text/target_missing/host_missing/accel_missing/483
new file mode 100644
index 00000000..1b3cf7ae
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/483
@@ -0,0 +1,25 @@
+qemu doesn't process -object secret when read from a config file
+Description of problem:
+Qemu doesn't process -object secret lines when read from a config file.  This results in the new spice password-secret option failing with error: No secret with id '\<theid\>'
+Steps to reproduce:
+1. Create a password file
+```
+printf "password" > passfile.pw
+```
+2. Start qemu with command line options and also write to a config file
+```
+qemu-system-x86_64 \
+  -object secret,id=spicepwd,format=raw,file=passfile.pw \
+  -spice port=5901,password-secret=spicepwd \
+  -writeconfig qemu.cfg
+```
+3. Optional: Connect using spice client and password: "password"
+4. Exit qemu and cat qemu.cfg and verify it looks okay with equivalent options to what was specified on the command line
+5. Now attempt to start qemu and read the options using the config file
+```
+qemu-system-x86_64 -readconfig qemu.cfg
+```
+6. This fails with an error:
+```
+qemu-system-x86_64: No secret with id 'spicepwd'
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/484 b/gitlab/issues_text/target_missing/host_missing/accel_missing/484
new file mode 100644
index 00000000..64adaac5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/484
@@ -0,0 +1 @@
+6.1 Regression: machine pflash parsing
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/486 b/gitlab/issues_text/target_missing/host_missing/accel_missing/486
new file mode 100644
index 00000000..41042bd3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/486
@@ -0,0 +1 @@
+/dev/input/mouse0: is not an evdev device
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/487 b/gitlab/issues_text/target_missing/host_missing/accel_missing/487
new file mode 100644
index 00000000..3e3e0e14
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/487
@@ -0,0 +1 @@
+sdhci: out of bounds read on sd->sd_status
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/488 b/gitlab/issues_text/target_missing/host_missing/accel_missing/488
new file mode 100644
index 00000000..bd17cb17
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/488
@@ -0,0 +1,30 @@
+[git]Virt-Manager cannot start any previously created virtual machine with Qemu commit bd306cfe: 'spicevmc' is not a valid char driver name
+Description of problem:
+With qemu built on commit bd306cfe, I'm unable to start a previously created VM. 
+
+Because of both bug #463 and #474 I was blocked from building qemu from git for something like a week or so. My last built and working Qemu is based on commit 9bef7ea9d9.
+
+Doing a git bissect won't be an easy task :(
+Steps to reproduce:
+1. Build qemu using commit bd306cfe
+2. Launch Virt-Manager
+3. Try to launch a previously created VM or try to boot a new one.
+Additional information:
+Every single time I tried to launch a VM, I get a dialog box with this error message:
+
+```
+Error starting domain: internal error: qemu unexpectedly closed the monitor: 2021-07-18T07:56:50.116480Z qemu-system-x86_64: -chardev spicevmc,id=charchannel1,name=vdagent: 'spicevmc' is not a valid char driver name
+
+Traceback (most recent call last):
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
+    callback(asyncjob, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb
+    callback(*args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
+    ret = fn(self, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in startup
+    self._backend.create()
+  File "/usr/lib/python3.9/site-packages/libvirt.py", line 1353, in create
+    raise libvirtError('virDomainCreate() failed')
+libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: 2021-07-18T07:56:50.116480Z qemu-system-x86_64: -chardev spicevmc,id=charchannel1,name=vdagent: 'spicevmc' is not a valid char driver name
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/49 b/gitlab/issues_text/target_missing/host_missing/accel_missing/49
new file mode 100644
index 00000000..37b31187
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/49
@@ -0,0 +1 @@
+[Feature request] MDIO bus
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/490 b/gitlab/issues_text/target_missing/host_missing/accel_missing/490
new file mode 100644
index 00000000..b93e97e9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/490
@@ -0,0 +1,829 @@
+Compilation FAILED: libblock.fa.p/block_vpc.c.o
+Description of problem:
+Compilation failed
+Steps to reproduce:
+```
+git checkout v5.2.0
+./configure --target-list=riscv64-softmmu 
+make 
+```
+Additional information:
+```
+changing dir to build for make ""...
+make[1]: Entering directory '/home/peterlin/Labs/riscv64-linux/qemu/build'
+/usr/bin/ninja  build.ninja && touch build.ninja.stamp
+ninja: no work to do.
+/usr/bin/meson introspect --targets --tests --benchmarks | /usr/bin/python3 -B scripts/mtest2make.py > Makefile.mtest
+  AS      multiboot.o
+  AS      linuxboot.o
+  CC      linuxboot_dma.o
+  AS      pvh.o
+  AS      kvmvapic.o
+  BUILD   linuxboot.img
+  BUILD   kvmvapic.img
+  CC      pvh_main.o
+  BUILD   multiboot.img
+  BUILD   linuxboot_dma.img
+ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?)
+make[2]: *** [Makefile:57: kvmvapic.img] Error 1
+make[2]: *** Waiting for unfinished jobs....
+ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?)
+make[2]: *** [Makefile:57: linuxboot.img] Error 1
+ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?)
+ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?)
+make[2]: *** [Makefile:57: multiboot.img] Error 1
+make[2]: *** [Makefile:57: linuxboot_dma.img] Error 1
+make[1]: *** [Makefile:206: pc-bios/optionrom/all] Error 2
+make[1]: *** Waiting for unfinished jobs....
+[1/2124] Compiling C object libcapstone.a.p/capstone_MCInstrDesc.c.o
+[2/2124] Compiling C object libcapstone.a.p/capstone_MCRegisterInfo.c.o
+[3/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86Module.c.o
+[4/2124] Compiling C object libcapstone.a.p/capstone_SStream.c.o
+[5/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86InstPrinterCommon.c.o
+[6/2124] Compiling C object libcapstone.a.p/capstone_utils.c.o
+[7/2124] Compiling C object libcapstone.a.p/capstone_MCInst.c.o
+[8/2124] Compiling C object libcapstone.a.p/capstone_cs.c.o
+[9/2124] Generating qemu-version.h with a custom command (wrapped by meson to capture output)
+[10/2124] Generating hmp-commands.h with a custom command (wrapped by meson to capture output)
+[11/2124] Generating qemu-img-cmds.h with a custom command (wrapped by meson to capture output)
+[12/2124] Generating hmp-commands-info.h with a custom command (wrapped by meson to capture output)
+[13/2124] Generating qemu-options.def with a custom command (wrapped by meson to capture output)
+[14/2124] Compiling C object contrib/libvhost-user/libvhost-user.a.p/libvhost-user-glib.c.o
+[15/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86Disassembler.c.o
+[16/2124] Generating trace-hw_audio.h with a custom command (wrapped by meson to capture output)
+[17/2124] Generating trace-hw_9pfs.h with a custom command (wrapped by meson to capture output)
+[18/2124] Generating trace-hw_audio.c with a custom command (wrapped by meson to capture output)
+[19/2124] Generating trace-hw_block_dataplane.h with a custom command (wrapped by meson to capture output)
+[20/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86ATTInstPrinter.c.o
+[21/2124] Generating trace-hw_block.c with a custom command (wrapped by meson to capture output)
+[22/2124] Generating trace-hw_block.h with a custom command (wrapped by meson to capture output)
+[23/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86IntelInstPrinter.c.o
+[24/2124] Generating trace-hw_arm.h with a custom command (wrapped by meson to capture output)
+[25/2124] Generating trace-hw_alpha.c with a custom command (wrapped by meson to capture output)
+[26/2124] Generating trace-hw_arm.c with a custom command (wrapped by meson to capture output)
+[27/2124] Compiling C object contrib/libvhost-user/libvhost-user.a.p/libvhost-user.c.o
+[28/2124] Linking static target contrib/libvhost-user/libvhost-user.a
+[29/2124] Generating trace-hw_char.c with a custom command (wrapped by meson to capture output)
+[30/2124] Generating trace-hw_9pfs.c with a custom command (wrapped by meson to capture output)
+[31/2124] Generating trace-hw_block_dataplane.c with a custom command (wrapped by meson to capture output)
+[32/2124] Generating trace-hw_char.h with a custom command (wrapped by meson to capture output)
+[33/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86Mapping.c.o
+[34/2124] Generating trace-hw_alpha.h with a custom command (wrapped by meson to capture output)
+[35/2124] Generating trace-hw_acpi.c with a custom command (wrapped by meson to capture output)
+[36/2124] Generating trace-hw_acpi.h with a custom command (wrapped by meson to capture output)
+[37/2124] Generating trace-accel_kvm.h with a custom command (wrapped by meson to capture output)
+[38/2124] Generating trace-root.c with a custom command (wrapped by meson to capture output)
+[39/2124] Generating trace-accel_tcg.h with a custom command (wrapped by meson to capture output)
+[40/2124] Generating trace-accel_kvm.c with a custom command (wrapped by meson to capture output)
+[41/2124] Generating trace-crypto.h with a custom command (wrapped by meson to capture output)
+[42/2124] Generating trace-accel_tcg.c with a custom command (wrapped by meson to capture output)
+[43/2124] Generating trace-crypto.c with a custom command (wrapped by meson to capture output)
+[44/2124] Generating trace-authz.c with a custom command (wrapped by meson to capture output)
+[45/2124] Generating trace-authz.h with a custom command (wrapped by meson to capture output)
+[46/2124] Generating trace-monitor.h with a custom command (wrapped by meson to capture output)
+[47/2124] Generating trace-monitor.c with a custom command (wrapped by meson to capture output)
+[48/2124] Compiling C object libcapstone.a.p/capstone_arch_X86_X86DisassemblerDecoder.c.o
+[49/2124] Linking static target libcapstone.a
+[50/2124] Generating trace-root.h with a custom command (wrapped by meson to capture output)
+[51/2124] Generating trace-block.h with a custom command (wrapped by meson to capture output)
+[52/2124] Generating trace-hw_watchdog.h with a custom command (wrapped by meson to capture output)
+[53/2124] Generating trace-hw_virtio.c with a custom command (wrapped by meson to capture output)
+[54/2124] Generating trace-hw_watchdog.c with a custom command (wrapped by meson to capture output)
+[55/2124] Generating trace-block.c with a custom command (wrapped by meson to capture output)
+[56/2124] Generating trace-io.c with a custom command (wrapped by meson to capture output)
+[57/2124] Generating trace-nbd.h with a custom command (wrapped by meson to capture output)
+[58/2124] Generating trace-nbd.c with a custom command (wrapped by meson to capture output)
+[59/2124] Generating trace-io.h with a custom command (wrapped by meson to capture output)
+[60/2124] Generating trace-scsi.h with a custom command (wrapped by meson to capture output)
+[61/2124] Generating trace-scsi.c with a custom command (wrapped by meson to capture output)
+[62/2124] Generating trace-audio.h with a custom command (wrapped by meson to capture output)
+[63/2124] Generating trace-backends.h with a custom command (wrapped by meson to capture output)
+[64/2124] Generating trace-backends.c with a custom command (wrapped by meson to capture output)
+[65/2124] Generating trace-audio.c with a custom command (wrapped by meson to capture output)
+[66/2124] Generating trace-backends_tpm.h with a custom command (wrapped by meson to capture output)
+[67/2124] Generating trace-backends_tpm.c with a custom command (wrapped by meson to capture output)
+[68/2124] Generating shared QAPI source files with a custom command
+[69/2124] Generating trace-chardev.h with a custom command (wrapped by meson to capture output)
+[70/2124] Generating trace-chardev.c with a custom command (wrapped by meson to capture output)
+[71/2124] Generating trace-hw_display.h with a custom command (wrapped by meson to capture output)
+[72/2124] Generating trace-hw_display.c with a custom command (wrapped by meson to capture output)
+[73/2124] Generating trace-hw_dma.h with a custom command (wrapped by meson to capture output)
+[74/2124] Generating trace-hw_dma.c with a custom command (wrapped by meson to capture output)
+[75/2124] Generating trace-hw_hppa.h with a custom command (wrapped by meson to capture output)
+[76/2124] Generating trace-hw_hppa.c with a custom command (wrapped by meson to capture output)
+[77/2124] Generating trace-hw_hyperv.h with a custom command (wrapped by meson to capture output)
+[78/2124] Generating trace-hw_hyperv.c with a custom command (wrapped by meson to capture output)
+[79/2124] Generating trace-hw_i2c.h with a custom command (wrapped by meson to capture output)
+[80/2124] Generating trace-hw_i386_xen.c with a custom command (wrapped by meson to capture output)
+[81/2124] Generating trace-hw_i386.h with a custom command (wrapped by meson to capture output)
+[82/2124] Generating trace-hw_i386.c with a custom command (wrapped by meson to capture output)
+[83/2124] Generating trace-hw_i2c.c with a custom command (wrapped by meson to capture output)
+[84/2124] Generating trace-hw_i386_xen.h with a custom command (wrapped by meson to capture output)
+[85/2124] Generating trace-hw_ide.c with a custom command (wrapped by meson to capture output)
+[86/2124] Generating trace-hw_ide.h with a custom command (wrapped by meson to capture output)
+[87/2124] Generating trace-hw_input.h with a custom command (wrapped by meson to capture output)
+[88/2124] Generating trace-hw_input.c with a custom command (wrapped by meson to capture output)
+[89/2124] Generating trace-hw_isa.h with a custom command (wrapped by meson to capture output)
+[90/2124] Generating trace-hw_intc.h with a custom command (wrapped by meson to capture output)
+[91/2124] Generating trace-hw_intc.c with a custom command (wrapped by meson to capture output)
+[92/2124] Generating trace-hw_mem.h with a custom command (wrapped by meson to capture output)
+[93/2124] Generating trace-hw_mem.c with a custom command (wrapped by meson to capture output)
+[94/2124] Generating trace-hw_isa.c with a custom command (wrapped by meson to capture output)
+[95/2124] Generating trace-hw_misc.h with a custom command (wrapped by meson to capture output)
+[96/2124] Generating trace-hw_mips.h with a custom command (wrapped by meson to capture output)
+[97/2124] Generating trace-hw_mips.c with a custom command (wrapped by meson to capture output)
+[98/2124] Generating trace-hw_misc.c with a custom command (wrapped by meson to capture output)
+[99/2124] Generating trace-hw_misc_macio.c with a custom command (wrapped by meson to capture output)
+[100/2124] Generating trace-hw_misc_macio.h with a custom command (wrapped by meson to capture output)
+[101/2124] Generating trace-hw_net.h with a custom command (wrapped by meson to capture output)
+[102/2124] Generating trace-hw_nvram.h with a custom command (wrapped by meson to capture output)
+[103/2124] Generating trace-hw_net.c with a custom command (wrapped by meson to capture output)
+[104/2124] Generating trace-hw_pci.h with a custom command (wrapped by meson to capture output)
+[105/2124] Generating trace-hw_nvram.c with a custom command (wrapped by meson to capture output)
+[106/2124] Generating trace-hw_pci_host.h with a custom command (wrapped by meson to capture output)
+[107/2124] Generating trace-hw_pci.c with a custom command (wrapped by meson to capture output)
+[108/2124] Generating trace-hw_pci_host.c with a custom command (wrapped by meson to capture output)
+[109/2124] Generating trace-hw_ppc.h with a custom command (wrapped by meson to capture output)
+[110/2124] Generating trace-hw_ppc.c with a custom command (wrapped by meson to capture output)
+[111/2124] Generating trace-hw_rdma.c with a custom command (wrapped by meson to capture output)
+[112/2124] Generating trace-hw_rdma_vmw.c with a custom command (wrapped by meson to capture output)
+[113/2124] Generating trace-hw_rdma_vmw.h with a custom command (wrapped by meson to capture output)
+[114/2124] Generating trace-hw_rdma.h with a custom command (wrapped by meson to capture output)
+[115/2124] Generating trace-hw_rtc.h with a custom command (wrapped by meson to capture output)
+[116/2124] Generating trace-hw_rtc.c with a custom command (wrapped by meson to capture output)
+[117/2124] Generating trace-hw_s390x.c with a custom command (wrapped by meson to capture output)
+[118/2124] Generating trace-hw_s390x.h with a custom command (wrapped by meson to capture output)
+[119/2124] Generating trace-hw_scsi.c with a custom command (wrapped by meson to capture output)
+[120/2124] Generating trace-hw_scsi.h with a custom command (wrapped by meson to capture output)
+[121/2124] Generating trace-hw_sd.h with a custom command (wrapped by meson to capture output)
+[122/2124] Generating trace-hw_sd.c with a custom command (wrapped by meson to capture output)
+[123/2124] Generating trace-hw_sparc.h with a custom command (wrapped by meson to capture output)
+[124/2124] Generating trace-hw_sparc64.c with a custom command (wrapped by meson to capture output)
+[125/2124] Generating trace-hw_sparc.c with a custom command (wrapped by meson to capture output)
+[126/2124] Generating trace-hw_sparc64.h with a custom command (wrapped by meson to capture output)
+[127/2124] Generating trace-hw_ssi.h with a custom command (wrapped by meson to capture output)
+[128/2124] Generating trace-hw_ssi.c with a custom command (wrapped by meson to capture output)
+[129/2124] Generating trace-hw_timer.h with a custom command (wrapped by meson to capture output)
+[130/2124] Generating trace-hw_timer.c with a custom command (wrapped by meson to capture output)
+[131/2124] Generating trace-hw_tpm.h with a custom command (wrapped by meson to capture output)
+[132/2124] Generating trace-hw_usb.h with a custom command (wrapped by meson to capture output)
+[133/2124] Generating trace-hw_tpm.c with a custom command (wrapped by meson to capture output)
+[134/2124] Generating trace-hw_usb.c with a custom command (wrapped by meson to capture output)
+[135/2124] Generating trace-hw_vfio.c with a custom command (wrapped by meson to capture output)
+[136/2124] Generating trace-hw_vfio.h with a custom command (wrapped by meson to capture output)
+[137/2124] Generating trace-hw_xen.h with a custom command (wrapped by meson to capture output)
+[138/2124] Generating trace-hw_virtio.h with a custom command (wrapped by meson to capture output)
+[139/2124] Generating trace-hw_xen.c with a custom command (wrapped by meson to capture output)
+[140/2124] Generating trace-hw_gpio.h with a custom command (wrapped by meson to capture output)
+[141/2124] Generating trace-hw_gpio.c with a custom command (wrapped by meson to capture output)
+[142/2124] Generating trace-migration.h with a custom command (wrapped by meson to capture output)
+[143/2124] Generating trace-net.c with a custom command (wrapped by meson to capture output)
+[144/2124] Generating trace-migration.c with a custom command (wrapped by meson to capture output)
+[145/2124] Generating trace-softmmu.h with a custom command (wrapped by meson to capture output)
+[146/2124] Generating trace-net.h with a custom command (wrapped by meson to capture output)
+[147/2124] Generating trace-softmmu.c with a custom command (wrapped by meson to capture output)
+[148/2124] Generating trace-ui.h with a custom command (wrapped by meson to capture output)
+[149/2124] Generating trace-ui.c with a custom command (wrapped by meson to capture output)
+[150/2124] Generating trace-hw_core.c with a custom command (wrapped by meson to capture output)
+[151/2124] Generating trace-hw_core.h with a custom command (wrapped by meson to capture output)
+[152/2124] Generating trace-qapi.h with a custom command (wrapped by meson to capture output)
+[153/2124] Generating trace-qom.h with a custom command (wrapped by meson to capture output)
+[154/2124] Generating trace-qapi.c with a custom command (wrapped by meson to capture output)
+[155/2124] Generating trace-qom.c with a custom command (wrapped by meson to capture output)
+[156/2124] Generating trace-target_arm.h with a custom command (wrapped by meson to capture output)
+[157/2124] Generating trace-target_arm.c with a custom command (wrapped by meson to capture output)
+[158/2124] Generating trace-target_hppa.h with a custom command (wrapped by meson to capture output)
+[159/2124] Generating trace-target_hppa.c with a custom command (wrapped by meson to capture output)
+[160/2124] Generating trace-target_i386.h with a custom command (wrapped by meson to capture output)
+[161/2124] Generating trace-target_i386.c with a custom command (wrapped by meson to capture output)
+[162/2124] Generating trace-target_mips.h with a custom command (wrapped by meson to capture output)
+[163/2124] Generating trace-target_ppc.h with a custom command (wrapped by meson to capture output)
+[164/2124] Generating trace-target_mips.c with a custom command (wrapped by meson to capture output)
+[165/2124] Generating trace-target_ppc.c with a custom command (wrapped by meson to capture output)
+[166/2124] Generating trace-target_riscv.h with a custom command (wrapped by meson to capture output)
+[167/2124] Generating trace-target_riscv.c with a custom command (wrapped by meson to capture output)
+[168/2124] Generating trace-target_s390x.h with a custom command (wrapped by meson to capture output)
+[169/2124] Generating trace-target_s390x.c with a custom command (wrapped by meson to capture output)
+[170/2124] Generating trace-target_sparc.h with a custom command (wrapped by meson to capture output)
+[171/2124] Generating trace-util.h with a custom command (wrapped by meson to capture output)
+[172/2124] Generating trace-target_sparc.c with a custom command (wrapped by meson to capture output)
+[173/2124] Generating trace-util.c with a custom command (wrapped by meson to capture output)
+[174/2124] Generating generated-helpers.c with a custom command (wrapped by meson to capture output)
+[175/2124] Generating generated-tcg-tracers.h with a custom command (wrapped by meson to capture output)
+[176/2124] Generating generated-helpers.h with a custom command (wrapped by meson to capture output)
+[177/2124] Generating trace-events-all with a custom command (wrapped by meson to capture output)
+[178/2124] Generating generated-helpers-wrappers.h with a custom command (wrapped by meson to capture output)
+[179/2124] Generating input-keymap-linux-to-qcode.c.inc with a custom command (wrapped by meson to capture output)
+[180/2124] Generating input-keymap-qcode-to-atset1.c.inc with a custom command (wrapped by meson to capture output)
+[181/2124] Generating input-keymap-qcode-to-atset2.c.inc with a custom command (wrapped by meson to capture output)
+[182/2124] Generating input-keymap-atset1-to-qcode.c.inc with a custom command (wrapped by meson to capture output)
+[183/2124] Generating input-keymap-qcode-to-linux.c.inc with a custom command (wrapped by meson to capture output)
+[184/2124] Generating input-keymap-qcode-to-qnum.c.inc with a custom command (wrapped by meson to capture output)
+[185/2124] Generating input-keymap-qcode-to-atset3.c.inc with a custom command (wrapped by meson to capture output)
+[186/2124] Generating input-keymap-qcode-to-sun.c.inc with a custom command (wrapped by meson to capture output)
+[187/2124] Generating input-keymap-qnum-to-qcode.c.inc with a custom command (wrapped by meson to capture output)
+[188/2124] Generating input-keymap-win32-to-qcode.c.inc with a custom command (wrapped by meson to capture output)
+[189/2124] Generating input-keymap-usb-to-qcode.c.inc with a custom command (wrapped by meson to capture output)
+[190/2124] Generating module_block.h with a custom command
+[191/2124] Generating block-gen.c with a custom command
+[192/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128_lt_quiet.c.o
+[193/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128_isSignalingNaN.c.o
+[194/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128M_to_i64.c.o
+[195/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128M_to_ui32.c.o
+[196/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128M_to_ui64.c.o
+[197/2124] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_f128M_to_i32.c.o
+[198/2124] Generating 'libqemu-riscv64-softmmu.fa.p/decode-insn16.c.inc'.
+[199/2124] Generating input-keymap-xorgevdev-to-qcode.c.inc with a custom command (wrapped by meson to capture output)
+[200/2124] Generating input-keymap-xorgxwin-to-qcode.c.inc with a custom command (wrapped by meson to capture output)
+[201/2124] Generating texture-blit-frag.h with a custom command (wrapped by meson to capture output)
+[202/2124] Generating texture-blit-vert.h with a custom command (wrapped by meson to capture output)
+[203/2124] Generating input-keymap-xorgxquartz-to-qcode.c.inc with a custom command (wrapped by meson to capture output)
+[204/2124] Generating input-keymap-xorgkbd-to-qcode.c.inc with a custom command (wrapped by meson to capture output)
+[205/2124] Generating 'libqemu-riscv64-softmmu.fa.p/decode-insn32.c.inc'.
+[206/2124] Generating input-keymap-x11-to-qcode.c.inc with a custom command (wrapped by meson to capture output)
+[207/2124] Generating QGA QAPI files with a custom command
+[208/2124] Generating bepo with a custom command
+[209/2124] Generating input-keymap-osx-to-qcode.c.inc with a custom command (wrapped by meson to capture output)
+[210/2124] Generating ar with a custom command
+[211/2124] Generating cz with a custom command
+[212/2124] Generating texture-blit-flip-vert.h with a custom command (wrapped by meson to capture output)
+[213/2124] Generating de with a custom command
+[214/2124] Generating da with a custom command
+[215/2124] Compiling C object contrib/elf2dmp/elf2dmp.p/download.c.o
+[216/2124] Compiling C object contrib/elf2dmp/elf2dmp.p/addrspace.c.o
+[217/2124] Compiling C object contrib/elf2dmp/elf2dmp.p/qemu_elf.c.o
+[218/2124] Compiling C object contrib/ivshmem-client/ivshmem-client.p/main.c.o
+[219/2124] Compiling C object contrib/elf2dmp/elf2dmp.p/pdb.c.o
+[220/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-qdev.c.o
+[221/2124] Compiling C object libqemuutil.a.p/stubs_ram-block.c.o
+[222/2124] Generating riscv64-softmmu-gdbstub-xml.c with a custom command (wrapped by meson to capture output)
+[223/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-acpi.c.o
+[224/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-acpi.c.o
+[225/2124] Compiling C object contrib/ivshmem-client/ivshmem-client.p/ivshmem-client.c.o
+[226/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-acpi.c.o
+[227/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-acpi.c.o
+[228/2124] Compiling C object contrib/elf2dmp/elf2dmp.p/main.c.o
+[229/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-authz.c.o
+[230/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-builtin-types.c.o
+[231/2124] Generating QAPI files for qemu-storage-daemon with a custom command
+[232/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-audio.c.o
+[233/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_mips.c.o
+[234/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-builtin-visit.c.o
+[235/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-audio.c.o
+[236/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-authz.c.o
+[237/2124] Compiling C object libblock.fa.p/block_qed-check.c.o
+[238/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-audio.c.o
+[239/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-authz.c.o
+[240/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-misc.c.o
+[241/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_vhost-user-input-pci.c.o
+[242/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-audio.c.o
+[243/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-block.c.o
+[244/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_vhost-vsock-common.c.o
+[245/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-block.c.o
+[246/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-authz.c.o
+[247/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_virtio-input-host-pci.c.o
+[248/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-block.c.o
+[249/2124] Compiling C object libblock.fa.p/block_qed-cluster.c.o
+[250/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-authz.c.o
+[251/2124] Compiling C object libblock.fa.p/block_qed-l2-cache.c.o
+[252/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-block.c.o
+[253/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-block-export.c.o
+[254/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-misc.c.o
+[255/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-block.c.o
+[256/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-block-export.c.o
+[257/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_virtio-rng-pci.c.o
+[258/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-char.c.o
+[259/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-char.c.o
+[260/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-block-core.c.o
+[261/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-block-export.c.o
+[262/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-block-export.c.o
+[263/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-common.c.o
+[264/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-common.c.o
+[265/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-common.c.o
+[266/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-common.c.o
+[267/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-char.c.o
+[268/2124] Compiling C object libqemuutil.a.p/util_getauxval.c.o
+[269/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-char.c.o
+[270/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-control.c.o
+[271/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-block-core.c.o
+[272/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-control.c.o
+[273/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-control.c.o
+[274/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-block-core.c.o
+[275/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-control.c.o
+[276/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_vhost-user-vsock-pci.c.o
+[277/2124] Compiling C object libqemuutil.a.p/util_uuid.c.o
+[278/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_vhost-user-blk-pci.c.o
+[279/2124] Compiling C object libqemuutil.a.p/util_rcu.c.o
+[280/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-crypto.c.o
+[281/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-crypto.c.o
+[282/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-crypto.c.o
+[283/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-dump.c.o
+[284/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-error.c.o
+[285/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-dump.c.o
+[286/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-dump.c.o
+[287/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-error.c.o
+[288/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-dump.c.o
+[289/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-error.c.o
+[290/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-error.c.o
+[291/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-introspect.c.o
+[292/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-introspect.c.o
+[293/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-introspect.c.o
+[294/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-crypto.c.o
+[295/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-job.c.o
+[296/2124] Compiling C object libqemuutil.a.p/stubs_cpu-get-clock.c.o
+[297/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-job.c.o
+[298/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-job.c.o
+[299/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-job.c.o
+[300/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-machine.c.o
+[301/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-misc.c.o
+[302/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-migration.c.o
+[303/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-introspect.c.o
+[304/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-migration.c.o
+[305/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-machine.c.o
+[306/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_virtio-balloon-pci.c.o
+[307/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-crypto.c.o
+[308/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-machine.c.o
+[309/2124] Compiling C object libqemuutil.a.p/util_crc32c.c.o
+[310/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-monitor.c.o
+[311/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_virtio-9p-pci.c.o
+[312/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-migration.c.o
+[313/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-migration.c.o
+[314/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-pragma.c.o
+[315/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_vhost-scsi-pci.c.o
+[316/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-net.c.o
+[317/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-pragma.c.o
+[318/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-net.c.o
+[319/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-net.c.o
+[320/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-pragma.c.o
+[321/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-pragma.c.o
+[322/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-misc.c.o
+[323/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-qdev.c.o
+[324/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-qdev.c.o
+[325/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-qom.c.o
+[326/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-pci.c.o
+[327/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-qdev.c.o
+[328/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-net.c.o
+[329/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-qom.c.o
+[330/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-pci.c.o
+[331/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-pci.c.o
+[332/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-machine.c.o
+[333/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-rdma.c.o
+[334/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-rocker.c.o
+[335/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-rdma.c.o
+[336/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-rdma.c.o
+[337/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-qom.c.o
+[338/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-pci.c.o
+[339/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-qom.c.o
+[340/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-rdma.c.o
+[341/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-replay.c.o
+[342/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-replay.c.o
+[343/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-replay.c.o
+[344/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-replay.c.o
+[345/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-rocker.c.o
+[346/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-rocker.c.o
+[347/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-run-state.c.o
+[348/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-rocker.c.o
+[349/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-run-state.c.o
+[350/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-sockets.c.o
+[351/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-sockets.c.o
+[352/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-sockets.c.o
+[353/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-run-state.c.o
+[354/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-tpm.c.o
+[355/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-tpm.c.o
+[356/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-run-state.c.o
+[357/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-trace.c.o
+[358/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-trace.c.o
+[359/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-tpm.c.o
+[360/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-sockets.c.o
+[361/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-trace.c.o
+[362/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-tpm.c.o
+[363/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-transaction.c.o
+[364/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-trace.c.o
+[365/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-transaction.c.o
+[366/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-events-ui.c.o
+[367/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-transaction.c.o
+[368/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-types-ui.c.o
+[369/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-root.c.o
+[370/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-accel_kvm.c.o
+[371/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-transaction.c.o
+[372/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-ui.c.o
+[373/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-accel_tcg.c.o
+[374/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-nbd.c.o
+[375/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-audio.c.o
+[376/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-io.c.o
+[377/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-scsi.c.o
+[378/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-backends.c.o
+[379/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-chardev.c.o
+[380/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-backends_tpm.c.o
+[381/2124] Compiling C object libblock.fa.p/block_dmg-bz2.c.o
+[382/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_9pfs.c.o
+[383/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_acpi.c.o
+[384/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_alpha.c.o
+[385/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_audio.c.o
+[386/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_block_dataplane.c.o
+[387/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_arm.c.o
+[388/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_char.c.o
+[389/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_block.c.o
+[390/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_hyperv.c.o
+[391/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_dma.c.o
+[392/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_display.c.o
+[393/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_i2c.c.o
+[394/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-ui.c.o
+[395/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_hppa.c.o
+[396/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_ide.c.o
+[397/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_i386_xen.c.o
+[398/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_i386.c.o
+[399/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_input.c.o
+[400/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_mem.c.o
+[401/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_isa.c.o
+[402/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_nvram.c.o
+[403/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_intc.c.o
+[404/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_misc_macio.c.o
+[405/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_misc.c.o
+[406/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_pci_host.c.o
+[407/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_pci.c.o
+[408/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_ppc.c.o
+[409/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_rdma.c.o
+[410/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_rdma_vmw.c.o
+[411/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_net.c.o
+[412/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_s390x.c.o
+[413/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_rtc.c.o
+[414/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_sparc.c.o
+[415/2124] Compiling C object libqemuutil.a.p/meson-generated_.._qapi_qapi-visit-block-core.c.o
+[416/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_sd.c.o
+[417/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_timer.c.o
+[418/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_sparc64.c.o
+[419/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_scsi.c.o
+[420/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_tpm.c.o
+[421/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_ssi.c.o
+[422/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_virtio.c.o
+[423/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_xen.c.o
+[424/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_vfio.c.o
+[425/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_usb.c.o
+[426/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_watchdog.c.o
+[427/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_gpio.c.o
+[428/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-ui.c.o
+[429/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-qapi.c.o
+[430/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-net.c.o
+[431/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-softmmu.c.o
+[432/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-hw_core.c.o
+[433/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-migration.c.o
+[434/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-qom.c.o
+[435/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_arm.c.o
+[436/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_hppa.c.o
+[437/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_mips.c.o
+[438/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_i386.c.o
+[439/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_riscv.c.o
+[440/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_ppc.c.o
+[441/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-util.c.o
+[442/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_s390x.c.o
+[443/2124] Compiling C object libqemuutil.a.p/meson-generated_.._trace_trace-target_sparc.c.o
+[444/2124] Compiling C object libqemuutil.a.p/qapi_qapi-dealloc-visitor.c.o
+[445/2124] Compiling C object libqemuutil.a.p/qapi_qapi-util.c.o
+[446/2124] Compiling C object libqemuutil.a.p/qapi_qapi-clone-visitor.c.o
+[447/2124] Compiling C object libqemuutil.a.p/qapi_qmp-event.c.o
+[448/2124] Compiling C object libqemuutil.a.p/qapi_opts-visitor.c.o
+[449/2124] Compiling C object libqemuutil.a.p/qapi_qmp-dispatch.c.o
+[450/2124] Compiling C object libqemuutil.a.p/qobject_qnull.c.o
+[451/2124] Compiling C object libqemuutil.a.p/qapi_qobject-output-visitor.c.o
+[452/2124] Compiling C object libqemuutil.a.p/qapi_qmp-registry.c.o
+[453/2124] Compiling C object libqemuutil.a.p/qapi_string-input-visitor.c.o
+[454/2124] Compiling C object libqemuutil.a.p/qobject_qstring.c.o
+[455/2124] Compiling C object libqemuutil.a.p/qobject_qnum.c.o
+[456/2124] Compiling C object libqemuutil.a.p/qapi_string-output-visitor.c.o
+[457/2124] Compiling C object libqemuutil.a.p/qobject_qobject.c.o
+[458/2124] Compiling C object libqemuutil.a.p/qobject_qbool.c.o
+[459/2124] Compiling C object libqemuutil.a.p/qapi_qapi-visit-core.c.o
+[460/2124] Compiling C object libqemuutil.a.p/qobject_qlist.c.o
+[461/2124] Compiling C object libqemuutil.a.p/qapi_qobject-input-visitor.c.o
+[462/2124] Compiling C object libqemuutil.a.p/qobject_qlit.c.o
+[463/2124] Compiling C object libqemuutil.a.p/qobject_json-lexer.c.o
+[464/2124] Compiling C object libqemuutil.a.p/qobject_qdict.c.o
+[465/2124] Compiling C object libqemuutil.a.p/qobject_qjson.c.o
+[466/2124] Compiling C object libqemuutil.a.p/util_unicode.c.o
+[467/2124] Compiling C object libqemuutil.a.p/qobject_json-streamer.c.o
+[468/2124] Compiling C object libqemuutil.a.p/util_qemu-timer-common.c.o
+[469/2124] Compiling C object libqemuutil.a.p/util_fdmon-poll.c.o
+[470/2124] Compiling C object libqemuutil.a.p/qobject_json-parser.c.o
+[471/2124] Compiling C object libqemuutil.a.p/util_compatfd.c.o
+[472/2124] Compiling C object libqemuutil.a.p/util_event_notifier-posix.c.o
+[473/2124] Compiling C object libqemuutil.a.p/util_fdmon-epoll.c.o
+[474/2124] Compiling C object libqemuutil.a.p/util_qemu-openpty.c.o
+[475/2124] Compiling C object libqemuutil.a.p/qobject_block-qdict.c.o
+[476/2124] Compiling C object libqemuutil.a.p/util_mmap-alloc.c.o
+[477/2124] Compiling C object libqemuutil.a.p/util_fdmon-io_uring.c.o
+[478/2124] Compiling C object libqemuutil.a.p/util_osdep.c.o
+[479/2124] Compiling C object libqemuutil.a.p/util_module.c.o
+[480/2124] Compiling C object libqemuutil.a.p/util_cutils.c.o
+[481/2124] Compiling C object libqemuutil.a.p/util_host-utils.c.o
+[482/2124] Compiling C object libqemuutil.a.p/util_memfd.c.o
+[483/2124] Compiling C object libqemuutil.a.p/util_envlist.c.o
+[484/2124] Compiling C object libqemuutil.a.p/util_path.c.o
+[485/2124] Compiling C object libqemuutil.a.p/util_aio-posix.c.o
+[486/2124] Compiling C object libqemuutil.a.p/util_fifo8.c.o
+[487/2124] Compiling C object libqemuutil.a.p/util_bitops.c.o
+[488/2124] Compiling C object libqemuutil.a.p/util_cacheinfo.c.o
+[489/2124] Compiling C object libqemuutil.a.p/util_qemu-thread-posix.c.o
+[490/2124] Compiling C object libqemuutil.a.p/util_id.c.o
+[491/2124] Compiling C object libqemuutil.a.p/util_qemu-print.c.o
+[492/2124] Compiling C object libqemuutil.a.p/util_oslib-posix.c.o
+[493/2124] Compiling C object libqemuutil.a.p/util_error.c.o
+[494/2124] Compiling C object libqemuutil.a.p/util_notify.c.o
+[495/2124] Compiling C object libqemuutil.a.p/util_qemu-progress.c.o
+[496/2124] Compiling C object libqemuutil.a.p/util_bitmap.c.o
+[497/2124] Compiling C object libqemuutil.a.p/util_qemu-error.c.o
+[498/2124] Compiling C object libqemuutil.a.p/util_keyval.c.o
+[499/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/hw_virtio_virtio-input-pci.c.o
+[500/2124] Compiling C object libqemuutil.a.p/util_qemu-config.c.o
+[501/2124] Compiling C object libqemuutil.a.p/util_pagesize.c.o
+[502/2124] Compiling C object libqemuutil.a.p/util_log.c.o
+[503/2124] Compiling C object libqemuutil.a.p/util_range.c.o
+[504/2124] Compiling C object libqemuutil.a.p/util_drm.c.o
+[505/2124] Compiling C object libqemuutil.a.p/util_stats64.c.o
+[506/2124] Compiling C object libqemuutil.a.p/util_qdist.c.o
+[507/2124] Compiling C object libqemuutil.a.p/util_systemd.c.o
+[508/2124] Compiling C object libqemuutil.a.p/util_aiocb.c.o
+[509/2124] Compiling C object libblock.fa.p/block_dmg.c.o
+[510/2124] Compiling C object libqemuutil.a.p/util_guest-random.c.o
+[511/2124] Compiling C object libqemuutil.a.p/util_base64.c.o
+[512/2124] Compiling C object libqemuutil.a.p/util_qht.c.o
+[513/2124] Compiling C object libqemuutil.a.p/util_aio-wait.c.o
+[514/2124] Compiling C object libqemuutil.a.p/util_async.c.o
+[515/2124] Compiling C object libqemuutil.a.p/util_qemu-option.c.o
+[516/2124] Compiling C object libqemuutil.a.p/util_dbus.c.o
+[517/2124] Compiling C object libqemuutil.a.p/util_qsp.c.o
+[518/2124] Compiling C object libqemuutil.a.p/util_hexdump.c.o
+[519/2124] Compiling C object libblock.fa.p/block_curl.c.o
+[520/2124] Compiling C object libqemuutil.a.p/util_coroutine-ucontext.c.o
+[521/2124] Compiling C object libqemuutil.a.p/util_buffer.c.o
+[522/2124] Compiling C object libqemuutil.a.p/util_iova-tree.c.o
+[523/2124] Compiling C object libqemuutil.a.p/util_main-loop.c.o
+[524/2124] Compiling C object libqemuutil.a.p/util_qemu-coroutine-io.c.o
+[525/2124] Compiling C object libqemuutil.a.p/util_lockcnt.c.o
+[526/2124] Compiling C object libqemuutil.a.p/util_nvdimm-utils.c.o
+[527/2124] Compiling C object libqemuutil.a.p/util_qemu-coroutine.c.o
+[528/2124] Compiling C object libqemuutil.a.p/util_iov.c.o
+[529/2124] Compiling C object libqemuutil.a.p/util_hbitmap.c.o
+[530/2124] Compiling C object libqemuutil.a.p/util_qemu-coroutine-sleep.c.o
+[531/2124] Compiling C object libqemuutil.a.p/util_bufferiszero.c.o
+[532/2124] Compiling C object libqemuutil.a.p/util_qemu-coroutine-lock.c.o
+[533/2124] Compiling C object libqemuutil.a.p/util_block-helpers.c.o
+[534/2124] Compiling C object libqemuutil.a.p/util_qemu-co-shared-resource.c.o
+[535/2124] Compiling C object libqemuutil.a.p/util_vhost-user-server.c.o
+[536/2124] Compiling C object libqemuutil.a.p/util_qemu-sockets.c.o
+[537/2124] Compiling C object libqemuutil.a.p/util_timed-average.c.o
+[538/2124] Compiling C object libqemuutil.a.p/crypto_random-gnutls.c.o
+[539/2124] Compiling C object libqemuutil.a.p/crypto_init.c.o
+[540/2124] Compiling C object libqemuutil.a.p/util_filemonitor-inotify.c.o
+[541/2124] Compiling C object libqemuutil.a.p/util_readline.c.o
+[542/2124] Compiling C object libqemuutil.a.p/util_thread-pool.c.o
+[543/2124] Compiling C object libqemuutil.a.p/stubs_arch_type.c.o
+[544/2124] Compiling C object libqemuutil.a.p/util_qemu-timer.c.o
+[545/2124] Compiling C object libqemuutil.a.p/crypto_aes.c.o
+[546/2124] Compiling C object libqemuutil.a.p/trace_qmp.c.o
+[547/2124] Compiling C object libqemuutil.a.p/util_throttle.c.o
+[548/2124] Compiling C object libqemuutil.a.p/util_uri.c.o
+[549/2124] Compiling C object libqemuutil.a.p/stubs_blockdev-close-all-bdrv-states.c.o
+[550/2124] Compiling C object libqemuutil.a.p/stubs_bdrv-next-monitor-owned.c.o
+[551/2124] Compiling C object libqemuutil.a.p/stubs_blk-exp-close-all.c.o
+[552/2124] Compiling C object libqemuutil.a.p/stubs_change-state-handler.c.o
+[553/2124] Compiling C object libqemuutil.a.p/stubs_blk-commit-all.c.o
+[554/2124] Compiling C object libqemuutil.a.p/stubs_cpus-get-virtual-clock.c.o
+[555/2124] Compiling C object libqemuutil.a.p/stubs_cmos.c.o
+[556/2124] Compiling C object libqemuutil.a.p/stubs_qemu-timer-notify-cb.c.o
+[557/2124] Compiling C object libqemuutil.a.p/stubs_dump.c.o
+[558/2124] Compiling C object libqemuutil.a.p/trace_control.c.o
+[559/2124] Compiling C object libqemuutil.a.p/util_vfio-helpers.c.o
+[560/2124] Compiling C object libqemuutil.a.p/stubs_error-printf.c.o
+[561/2124] Compiling C object libqemuutil.a.p/stubs_gdbstub.c.o
+[562/2124] Compiling C object libqemuutil.a.p/stubs_icount.c.o
+[563/2124] Compiling C object libqemuutil.a.p/stubs_io_uring.c.o
+[564/2124] Compiling C object libqemuutil.a.p/stubs_iothread.c.o
+[565/2124] Compiling C object libqemuutil.a.p/stubs_get-vm-name.c.o
+[566/2124] Compiling C object libqemuutil.a.p/stubs_fw_cfg.c.o
+[567/2124] Compiling C object libqemuutil.a.p/stubs_is-daemonized.c.o
+[568/2124] Compiling C object libqemuutil.a.p/stubs_iothread-lock.c.o
+[569/2124] Compiling C object libqemuutil.a.p/stubs_fdset.c.o
+[570/2124] Compiling C object libqemuutil.a.p/stubs_machine-init-done.c.o
+[571/2124] Compiling C object libqemuutil.a.p/stubs_migr-blocker.c.o
+[572/2124] Compiling C object libqemuutil.a.p/stubs_linux-aio.c.o
+[573/2124] Compiling C object libqemuutil.a.p/stubs_isa-bus.c.o
+[574/2124] Compiling C object libqemuutil.a.p/stubs_runstate-check.c.o
+[575/2124] Compiling C object libqemuutil.a.p/stubs_qtest.c.o
+[576/2124] Compiling C object libqemuutil.a.p/stubs_monitor.c.o
+[577/2124] Compiling C object libqemuutil.a.p/stubs_ramfb.c.o
+[578/2124] Compiling C object libqemuutil.a.p/stubs_pci-bus.c.o
+[579/2124] Compiling C object libqemuutil.a.p/stubs_qmp_memory_device.c.o
+[580/2124] Compiling C object libqemuutil.a.p/stubs_monitor-core.c.o
+[581/2124] Compiling C object libqemuutil.a.p/stubs_sysbus.c.o
+[582/2124] Compiling C object libqemuutil.a.p/stubs_pci-host-piix.c.o
+[583/2124] Compiling C object libqemuutil.a.p/stubs_replay.c.o
+[584/2124] Compiling C object libqemuutil.a.p/stubs_target-monitor-defs.c.o
+[585/2124] Compiling C object libqemuutil.a.p/stubs_set-fd-handler.c.o
+[586/2124] Compiling C object libqemuutil.a.p/stubs_target-get-monitor-def.c.o
+[587/2124] Compiling C object libqemuutil.a.p/stubs_tpm.c.o
+[588/2124] Compiling C object libqemuutil.a.p/stubs_trace-control.c.o
+[589/2124] Compiling C object libqemuutil.a.p/stubs_uuid.c.o
+[590/2124] Compiling C object libqemuutil.a.p/stubs_vmstate.c.o
+[591/2124] Compiling C object libqemuutil.a.p/stubs_vm-stop.c.o
+[592/2124] Compiling C object libqemuutil.a.p/stubs_win32-kbd-hook.c.o
+[593/2124] Compiling C object libcommon.fa.p/hw_net_rocker_rocker_of_dpa.c.o
+[594/2124] Compiling C object libqemuutil.a.p/stubs_vmgenid.c.o
+[595/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_cpu.c.o
+[596/2124] Compiling C object libqemuutil.a.p/stubs_cpu-synchronize-state.c.o
+[597/2124] Compiling C object libqemuutil.a.p/stubs_replay-tools.c.o
+[598/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_fpu_helper.c.o
+[599/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_csr.c.o
+[600/2124] Compiling C object libqemuutil.a.p/stubs_semihost.c.o
+[601/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/qos_external.c.o
+[602/2124] Compiling C object fsdev/virtfs-proxy-helper.p/9p-marshal.c.o
+[603/2124] Compiling C object libqemuutil.a.p/stubs_xen-hw-stub.c.o
+[604/2124] Compiling C object fsdev/virtfs-proxy-helper.p/9p-iov-marshal.c.o
+[605/2124] Compiling C object fsdev/virtfs-proxy-helper.p/virtfs-proxy-helper.c.o
+[606/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/malloc-spapr.c.o
+[607/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/libqos.c.o
+[608/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/malloc.c.o
+[609/2124] Linking static target libqemuutil.a
+[610/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/rtas.c.o
+[611/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/fw_cfg.c.o
+[612/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/libqos-spapr.c.o
+[613/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/qgraph.c.o
+[614/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/pci.c.o
+[615/2124] Linking target fsdev/virtfs-proxy-helper
+[616/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/pci-spapr.c.o
+[617/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/malloc-pc.c.o
+[618/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/libqos-pc.c.o
+[619/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/usb.c.o
+[620/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/pci-pc.c.o
+[621/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/e1000e.c.o
+[622/2124] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_cpu_helper.c.o
+[623/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/i2c.c.o
+[624/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/i2c-omap.c.o
+[625/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/i2c-imx.c.o
+[626/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/tpci200.c.o
+[627/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/.._libqtest.c.o
+[628/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-balloon.c.o
+[629/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-9p.c.o
+[630/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-blk.c.o
+[631/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/sdhci.c.o
+[632/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-mmio.c.o
+[633/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-rng.c.o
+[634/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/aarch64-xlnx-zcu102-machine.c.o
+[635/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-imx25-pdk-machine.c.o
+[636/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-net.c.o
+[637/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-scsi.c.o
+[638/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-n800-machine.c.o
+[639/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio.c.o
+[640/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-serial.c.o
+[641/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-pci-modern.c.o
+[642/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-smdkc210-machine.c.o
+[643/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-raspi2-machine.c.o
+[644/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-sabrelite-machine.c.o
+[645/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-xilinx-zynq-a9-machine.c.o
+[646/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/virtio-pci.c.o
+[647/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/ppc64_pseries-machine.c.o
+[648/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/arm-virt-machine.c.o
+[649/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/x86_64_pc-machine.c.o
+[650/2124] Compiling C object tests/qtest/libqos/libqos.fa.p/ahci.c.o
+[651/2124] Compiling C object libqom.fa.p/qom_container.c.o
+[652/2124] Compiling C object libauthz.fa.p/authz_base.c.o
+[653/2124] Linking static target tests/qtest/libqos/libqos.fa
+[654/2124] Compiling C object libqom.fa.p/qom_qom-qobject.c.o
+[655/2124] Compiling C object libqom.fa.p/hw_nvram_fw_cfg-interface.c.o
+[656/2124] Generating block.syms with a custom command (wrapped by meson to capture output)
+[657/2124] Compiling C object libauthz.fa.p/authz_simple.c.o
+[658/2124] Compiling C object libqom.fa.p/qom_object_interfaces.c.o
+[659/2124] Compiling C object libauthz.fa.p/authz_list.c.o
+[660/2124] Generating qemu.syms with a custom command (wrapped by meson to capture output)
+[661/2124] Compiling C object libauthz.fa.p/authz_listfile.c.o
+[662/2124] Compiling C object libauthz.fa.p/authz_pamacct.c.o
+[663/2124] Linking static target libauthz.fa
+[664/2124] Compiling C object libcrypto.fa.p/crypto_afsplit.c.o
+[665/2124] Compiling C object libcrypto.fa.p/crypto_block-qcow.c.o
+[666/2124] Compiling C object libcrypto.fa.p/crypto_hash.c.o
+[667/2124] Compiling C object libcrypto.fa.p/crypto_ivgen-plain64.c.o
+[668/2124] Compiling C object libcrypto.fa.p/crypto_block.c.o
+[669/2124] Compiling C object libcrypto.fa.p/crypto_ivgen-essiv.c.o
+[670/2124] Compiling C object libcrypto.fa.p/crypto_hmac.c.o
+[671/2124] Compiling C object libcrypto.fa.p/crypto_ivgen-plain.c.o
+[672/2124] Compiling C object libcrypto.fa.p/crypto_desrfb.c.o
+[673/2124] Compiling C object libcrypto.fa.p/crypto_ivgen.c.o
+[674/2124] Compiling C object libcrypto.fa.p/crypto_pbkdf.c.o
+[675/2124] Compiling C object libcrypto.fa.p/crypto_secret.c.o
+[676/2124] Compiling C object libcrypto.fa.p/crypto_tlscreds.c.o
+[677/2124] Compiling C object libcrypto.fa.p/crypto_secret_common.c.o
+[678/2124] Compiling C object libcrypto.fa.p/crypto_tlscredsanon.c.o
+[679/2124] Compiling C object libcrypto.fa.p/crypto_hash-nettle.c.o
+[680/2124] Compiling C object libcrypto.fa.p/crypto_tlscredspsk.c.o
+[681/2124] Compiling C object libcrypto.fa.p/crypto_block-luks.c.o
+[682/2124] Compiling C object libcrypto.fa.p/crypto_pbkdf-nettle.c.o
+[683/2124] Compiling C object libcrypto.fa.p/crypto_secret_keyring.c.o
+[684/2124] Compiling C object libcrypto.fa.p/crypto_tlscredsx509.c.o
+[685/2124] Compiling C object libcrypto.fa.p/crypto_hmac-nettle.c.o
+[686/2124] Compiling C object libio.fa.p/io_channel-command.c.o
+[687/2124] Compiling C object libcrypto.fa.p/crypto_tlssession.c.o
+[688/2124] Compiling C object libcrypto.fa.p/crypto_cipher.c.o
+[689/2124] Compiling C object libcrypto.fa.p/crypto_tls-cipher-suites.c.o
+[690/2124] Compiling C object libio.fa.p/io_channel-buffer.c.o
+[691/2124] Compiling C object libmigration.fa.p/migration_page_cache.c.o
+[692/2124] Compiling C object libio.fa.p/io_channel-util.c.o
+[693/2124] Linking static target libcrypto.fa
+[694/2124] Compiling C object libio.fa.p/io_channel-file.c.o
+[695/2124] Compiling C object libio.fa.p/io_channel-watch.c.o
+[696/2124] Compiling C object libqom.fa.p/qom_object.c.o
+[697/2124] Compiling C object libio.fa.p/io_channel-tls.c.o
+[698/2124] Linking static target libqom.fa
+[699/2124] Compiling C object libio.fa.p/io_dns-resolver.c.o
+[700/2124] Compiling C object libmigration.fa.p/migration_xbzrle.c.o
+[701/2124] Compiling C object libio.fa.p/io_channel.c.o
+[702/2124] Compiling C object libio.fa.p/io_task.c.o
+[703/2124] Compiling C object libio.fa.p/io_channel-socket.c.o
+[704/2124] Compiling C object libmigration.fa.p/migration_qemu-file-channel.c.o
+[705/2124] Compiling C object libmigration.fa.p/migration_qjson.c.o
+[706/2124] Compiling C object libio.fa.p/io_net-listener.c.o
+[707/2124] Compiling C object libio.fa.p/io_channel-websock.c.o
+[708/2124] Linking static target libio.fa
+[709/2124] Compiling C object libblock.fa.p/replication.c.o
+[710/2124] Compiling C object libmigration.fa.p/migration_vmstate.c.o
+[711/2124] Compiling C object libmigration.fa.p/migration_vmstate-types.c.o
+[712/2124] Compiling C object libblock.fa.p/meson-generated_.._block_block-gen.c.o
+[713/2124] Compiling C object libmigration.fa.p/migration_qemu-file.c.o
+[714/2124] Compiling C object libblock.fa.p/blockjob.c.o
+[715/2124] Linking static target libmigration.fa
+[716/2124] Compiling C object libblock.fa.p/nbd_common.c.o
+[717/2124] Compiling C object libblock.fa.p/scsi_utils.c.o
+[718/2124] Compiling C object libblock.fa.p/scsi_pr-manager.c.o
+[719/2124] Compiling C object libblock.fa.p/block_aio_task.c.o
+[720/2124] Compiling C object libblock.fa.p/block_nfs.c.o
+[721/2124] Compiling C object libblock.fa.p/job.c.o
+[722/2124] Compiling C object libblock.fa.p/block_amend.c.o
+[723/2124] Compiling C object libblock.fa.p/scsi_pr-manager-helper.c.o
+[724/2124] Compiling C object libblock.fa.p/block_accounting.c.o
+[725/2124] Compiling C object libblock.fa.p/block_blklogwrites.c.o
+[726/2124] Compiling C object libblock.fa.p/block_backup-top.c.o
+[727/2124] Compiling C object libblock.fa.p/block_blkverify.c.o
+[728/2124] Compiling C object libblock.fa.p/qemu-io-cmds.c.o
+[729/2124] Compiling C object libblock.fa.p/block_backup.c.o
+[730/2124] Compiling C object libblock.fa.p/block_commit.c.o
+[731/2124] Compiling C object libblock.fa.p/nbd_client.c.o
+[732/2124] Compiling C object libblock.fa.p/block_blkdebug.c.o
+[733/2124] Compiling C object libblock.fa.p/block_create.c.o
+[734/2124] Compiling C object libblock.fa.p/block_copy-on-read.c.o
+[735/2124] Compiling C object libblock.fa.p/block_dirty-bitmap.c.o
+[736/2124] Compiling C object libblock.fa.p/block_block-copy.c.o
+[737/2124] Compiling C object libblock.fa.p/block_null.c.o
+[738/2124] Compiling C object libblock.fa.p/block_filter-compress.c.o
+[739/2124] Compiling C object libblock.fa.p/block_crypto.c.o
+[740/2124] Compiling C object libblock.fa.p/block_qapi.c.o
+[741/2124] Compiling C object libblock.fa.p/block_block-backend.c.o
+[742/2124] Compiling C object libblock.fa.p/block_raw-format.c.o
+[743/2124] Compiling C object libblock.fa.p/block_mirror.c.o
+[744/2124] Compiling C object libblock.fa.p/block_snapshot.c.o
+[745/2124] Compiling C object libblock.fa.p/block_qcow2-cache.c.o
+[746/2124] Compiling C object libblock.fa.p/block_quorum.c.o
+[747/2124] Compiling C object libblock.fa.p/block_nbd.c.o
+[748/2124] Compiling C object libblock.fa.p/block_qcow2-bitmap.c.o
+[749/2124] Compiling C object libblock.fa.p/block_throttle-groups.c.o
+[750/2124] Compiling C object libblock.fa.p/block_qcow2-threads.c.o
+[751/2124] Compiling C object libblock.fa.p/block_qcow2-snapshot.c.o
+[752/2124] Compiling C object libblock.fa.p/block_cloop.c.o
+[753/2124] Compiling C object libblock.fa.p/block_bochs.c.o
+[754/2124] Compiling C object libblock.fa.p/block_vpc.c.o
+FAILED: libblock.fa.p/block_vpc.c.o 
+cc -Ilibblock.fa.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -Iblock -I/usr/include/libxml2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu99 -O2 -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -m64 -mcx16 -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 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -isystem /home/peterlin/Labs/riscv64-linux/qemu/linux-headers -isystem linux-headers -iquote /home/peterlin/Labs/riscv64-linux/qemu/tcg/i386 -iquote . -iquote /home/peterlin/Labs/riscv64-linux/qemu -iquote /home/peterlin/Labs/riscv64-linux/qemu/accel/tcg -iquote /home/peterlin/Labs/riscv64-linux/qemu/include -iquote /home/peterlin/Labs/riscv64-linux/qemu/disas/libvixl -pthread -fPIE -DHAVE_LIBSSH_0_8 -MD -MQ libblock.fa.p/block_vpc.c.o -MF libblock.fa.p/block_vpc.c.o.d -o libblock.fa.p/block_vpc.c.o -c ../block/vpc.c
+../block/vpc.c: In function ‘vpc_open’:
+../block/vpc.c:358:51: error: array subscript ‘VHDDynDiskHeader {aka struct vhd_dyndisk_header}[0]’ is partly outside array bounds of ‘uint8_t[512]’ {aka ‘unsigned char[512]’} [-Werror=array-bounds]
+  358 |         s->block_size = be32_to_cpu(dyndisk_header->block_size);
+      |                                                   ^~
+../block/vpc.c:223:13: note: while referencing ‘buf’
+  223 |     uint8_t buf[HEADER_SIZE];
+      |             ^~~
+../block/vpc.c:366:58: error: array subscript ‘VHDDynDiskHeader {aka struct vhd_dyndisk_header}[0]’ is partly outside array bounds of ‘uint8_t[512]’ {aka ‘unsigned char[512]’} [-Werror=array-bounds]
+  366 |         s->max_table_entries = be32_to_cpu(dyndisk_header->max_table_entries);
+      |                                                          ^~
+../block/vpc.c:223:13: note: while referencing ‘buf’
+  223 |     uint8_t buf[HEADER_SIZE];
+      |             ^~~
+../block/vpc.c:398:51: error: array subscript ‘VHDDynDiskHeader {aka struct vhd_dyndisk_header}[0]’ is partly outside array bounds of ‘uint8_t[512]’ {aka ‘unsigned char[512]’} [-Werror=array-bounds]
+  398 |         s->bat_offset = be64_to_cpu(dyndisk_header->table_offset);
+      |                                                   ^~
+../block/vpc.c:223:13: note: while referencing ‘buf’
+  223 |     uint8_t buf[HEADER_SIZE];
+      |             ^~~
+cc1: all warnings being treated as errors
+[755/2124] Compiling C object libblock.fa.p/block.c.o
+[756/2124] Compiling C object libblock.fa.p/block_vhdx.c.o
+[757/2124] Compiling C object libblock.fa.p/block_throttle.c.o
+[758/2124] Compiling C object libblock.fa.p/block_vhdx-endian.c.o
+[759/2124] Compiling C object libblock.fa.p/block_io.c.o
+[760/2124] Compiling C object libblock.fa.p/block_qcow2-refcount.c.o
+[761/2124] Compiling C object libblock.fa.p/block_qed-table.c.o
+[762/2124] Compiling C object libblock.fa.p/block_qcow2-cluster.c.o
+[763/2124] Compiling C object libblock.fa.p/block_vmdk.c.o
+[764/2124] Compiling C object libblock.fa.p/block_qcow2.c.o
+[765/2124] Compiling C object libblock.fa.p/block_vvfat.c.o
+ninja: build stopped: subcommand failed.
+make[1]: *** [Makefile:171: run-ninja] Error 1
+make[1]: Leaving directory '/home/peterlin/Labs/riscv64-linux/qemu/build'
+make: *** [GNUmakefile:11: all] Error 2
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/491 b/gitlab/issues_text/target_missing/host_missing/accel_missing/491
new file mode 100644
index 00000000..4d4e02fc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/491
@@ -0,0 +1 @@
+There is a code error here
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/492 b/gitlab/issues_text/target_missing/host_missing/accel_missing/492
new file mode 100644
index 00000000..78fc8460
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/492
@@ -0,0 +1,27 @@
+[git] "qemu-system-x86_64: Parameter 'drive' is missing" when I tried to launch an existing VM in Virt-Manager.
+Description of problem:
+This bug is related in some way to bug #488.
+
+I cannot start an existing virtual machine using qemu-git.
+Additional information:
+```
+internal error: process exited while connecting to monitor: 2021-07-19T19:24:27.044654Z qemu-system-x86_64: Parameter 'drive' is missing
+
+Traceback (most recent call last):
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
+    callback(asyncjob, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb
+    callback(*args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
+    ret = fn(self, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in startup
+    self._backend.create()
+  File "/usr/lib/python3.9/site-packages/libvirt.py", line 1353, in create
+    raise libvirtError('virDomainCreate() failed')
+libvirt.libvirtError: internal error: process exited while connecting to monitor: 2021-07-19T19:24:27.044654Z qemu-system-x86_64: Parameter 'drive' is missing
+
+```
+
+My last working build was made using commit 9bef7ea9. Using Peter Maydell commits as milestone, I noticed commit 9aef0954 was the first showing the bug.
+
+I'll try to do bisect between these two commits and report asap. There is about 40 commits to verify.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/495 b/gitlab/issues_text/target_missing/host_missing/accel_missing/495
new file mode 100644
index 00000000..4a9ada74
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/495
@@ -0,0 +1 @@
+sdhci: Another way to trigger Assertion wpnum < sd->wpgrps_size failed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/497 b/gitlab/issues_text/target_missing/host_missing/accel_missing/497
new file mode 100644
index 00000000..f5ef9574
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/497
@@ -0,0 +1,19 @@
+GVT-g + -spice error since qemu 6
+Description of problem:
+It doesn't work:
+```
+qemu-system-x86_64: The console requires display DMABUF support.
+```
+
+If I add `gl=on` to `-spice`, it reports:
+```
+can't register two opengl displays (spice-egl, egl-headless)
+```
+Steps to reproduce:
+1. Setup an Intel GVT-g vGPU
+2. Run the command
+3. See the error
+Additional information:
+Before 6.0.0 it worked.
+
+Using VNC instead of SPICE works.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/498 b/gitlab/issues_text/target_missing/host_missing/accel_missing/498
new file mode 100644
index 00000000..5b24594b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/498
@@ -0,0 +1,42 @@
+Cannot focus QEMU window on macOS Big Sur (11.4)
+Description of problem:
+I'm not sure when the problem has been started, but I recently noticed that key inputs to QEMU window are not processed and the input goes other focused windows (e.g. terminal). QEMU window itself is shown but it looks like they are not focused. Also, the Dock icon for QEMU is also disappeared (it was displayed before).
+Steps to reproduce:
+1. build & install the latest qemu with `./configure --target-list=x86_64-softmmu` 
+    - (`a146af86c8247f41b641783428b95ee71eb0e43f` was the revision I used)
+2. run　`qemu-system-x86_64` from terminal
+3. click the QEMU window.
+    - Expected behavior: menu bar title will be switched to "QEMU", key inputs are handled by QEMU, Dock icon will be shown.
+    - Actual behavior: menu bar shows different app name that were focused before clicking the qemu, key inputs went to other app that was focused, dock icon is not showing up.
+Additional information:
+I tried to see if the events are delivered to QemuCocoaView by putting `NSLog(@"handleEventLocked: %@\n", event);` at the beginning of `handleEventLocked` @ `ui/cocoa.m`. It looks like the mouse events are delivered but not NSEventTypeKeyDown.
+
+(logs after clicked the QEMU window and type some 'a')
+```
+$ qemu-system-x86_64 
+2021-07-24 16:58:00.767 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682409.7 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=4 data1=1144258560 data2=1138098176
+2021-07-24 16:58:00.768 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,228) time=682409.7 flags=0 win=0x7fe2b5fb0ee0 winNum=10356 ctxt=0x0 subtype=4 data1=1137180672 data2=1130627072
+2021-07-24 16:58:06.462 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=9 data1=1129 data2=0
+2021-07-24 16:58:06.462 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseDown loc=(591.031,166.896) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0![スクリーンショット_2021-07-24_16.51.53](/uploads/7e9b0987b70a776976541d5320f66a0d/スクリーンショット_2021-07-24_16.51.53.png)x0 evNum=6096 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0
+2021-07-24 16:58:06.462 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,0) time=0.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=1 data1=1129 data2=0
+2021-07-24 16:58:06.487 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=22 data1=0 data2=0
+2021-07-24 16:58:06.487 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=23 data1=0 data2=0
+2021-07-24 16:58:06.565 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseUp loc=(591.031,166.896) time=682415.5 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6096 click=1 buttonNumber=0 pressure=0 deviceID:0x0 subtype=0
+2021-07-24 16:58:12.997 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(174.184,408.859) time=682421.9 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0
+2021-07-24 16:58:13.013 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(152.704,428.804) time=682422.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0
+2021-07-24 16:58:24.181 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682433.1 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=9 data1=1131 data2=0
+2021-07-24 16:58:24.181 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseDown loc=(268.333,208.222) time=682433.1 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6098 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0
+2021-07-24 16:58:24.262 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseUp loc=(268.333,208.222) time=682433.2 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6098 click=1 buttonNumber=0 pressure=0 deviceID:0x0 subtype=0
+2021-07-24 16:58:24.877 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(3.83252,400.359) time=682433.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0
+2021-07-24 16:58:25.053 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(7.08813,408.091) time=682434.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe295c0f090 userData=0x1
+2021-07-24 16:58:25.054 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(7.08813,408.091) time=682434.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e80e30 userData=0x0
+2021-07-24 16:58:25.302 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseDown loc=(10.917,420.558) time=682434.2 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6099 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0
+2021-07-24 16:58:25.365 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseUp loc=(10.917,420.558) time=682434.3 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6099 click=1 buttonNumber=0 pressure=0 deviceID:0x0 subtype=0
+2021-07-24 16:58:25.845 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(11.9221,422.759) time=682434.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe295c0f090 userData=0x1
+2021-07-24 16:58:25.846 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(11.9221,422.759) time=682434.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e80e30 userData=0x0
+2021-07-24 16:58:25.855 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(14.2417,428.558) time=682434.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0
+
+```
+
+Possibly related discussion on Apple Developer Forums:
+- https://developer.apple.com/forums/thread/667004
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/50 b/gitlab/issues_text/target_missing/host_missing/accel_missing/50
new file mode 100644
index 00000000..aa4e1789
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/50
@@ -0,0 +1 @@
+Create PyPI installable package for the Python library
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/500 b/gitlab/issues_text/target_missing/host_missing/accel_missing/500
new file mode 100644
index 00000000..cdb65628
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/500
@@ -0,0 +1 @@
+6.1.0-rc0 Regression: Parameter 'audiodev' is missing
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/501 b/gitlab/issues_text/target_missing/host_missing/accel_missing/501
new file mode 100644
index 00000000..8ba77f6b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/501
@@ -0,0 +1 @@
+6.1.0-rc0 Regression: No keyboard input possible
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/502 b/gitlab/issues_text/target_missing/host_missing/accel_missing/502
new file mode 100644
index 00000000..e1f9dace
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/502
@@ -0,0 +1 @@
+6.1.0-rc0 Regression: No mouse input possible
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/506 b/gitlab/issues_text/target_missing/host_missing/accel_missing/506
new file mode 100644
index 00000000..a12bcc0a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/506
@@ -0,0 +1 @@
+ga: auto-discover virtio port using sysfs
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/511 b/gitlab/issues_text/target_missing/host_missing/accel_missing/511
new file mode 100644
index 00000000..8a4252c0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/511
@@ -0,0 +1 @@
+usbredirparser: bulk transfer length exceeds limits (can't use any USB storage)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/515 b/gitlab/issues_text/target_missing/host_missing/accel_missing/515
new file mode 100644
index 00000000..53f5977b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/515
@@ -0,0 +1,31 @@
+qemu-system-x86_64 fails to run with regular user after following arch wiki article
+Description of problem:
+When `qemu-system-x86_64` binary is run with a regular user, it fails with no output. No matter if it's run with `--help`, `--version` or any other parameter. By checking the resulting error code (`echo $?`) it is possible to see that it finished with error code 1.
+
+After seeing this [post](https://www.reddit.com/r/archlinux/comments/b9emxp/qemusystemx86_64_does_not_execute_how_can_i/ek47btb/) on reddit, it became clear that the reason was that my `/etc` directory had a subdirectory qemu, in which my regular user did not have access to. That is, qemu binary looks for `/etc/qemu/qemu.conf` and if it can't determine if the file is there or not, it fails.
+
+Here goes the logic:
+strace showed the permission error (even though there was no output to indicate that).
+
+```
+$ strace /usr/bin/qemu-system-x86_64
+…
+mmap(NULL, 4928, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_POPULATE, 3, 0) = 0x7f4d01e6e000
+mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_POPULATE, 3, 0x10000000) = 0x7f4d01e6c000
+eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)   = 4
+sysinfo({uptime=92539, loads=[109952, 80640, 118144], totalram=16643309568, freeram=5314445312, sharedram=2590158848, bufferram=1301561344, totalswap=20479733760, freeswap=19551150080, procs=1202, totalhigh=0, freehigh=0, mem_unit=1}) = 0
+rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f4d01ad7960}, NULL, 8) = 0
+openat(AT_FDCWD, "/etc/qemu/qemu.conf", O_RDONLY) = -1 EACCES (Permission denied)
+exit_group(1)                           = ?
++++ exited with 1 +++
+```
+
+The thing was that initially that folder did not exist, and I created it to make the qemu bridges work, like indicated in this arch wiki [article](https://wiki.archlinux.org/title/QEMU#Bridged_networking_using_qemu-bridge-helper). I will be suggesting modifications to that article.
+
+When the directory did not exit, qemu noticed that the folder didn't exist and moved on, once it was created, in case the regular user had no access to it, it fails with no warning.
+
+I just gave access to the folder ant it worked again (if you delete the folder it works too).
+
+If you use libvirt, by using virsh for example, you may not notice this issue as it may be running as system (by setting the following system variable `export LIBVIRT_DEFAULT_URI='qemu:///system'`) 
+
+So, to fix this issue, in my opinion a warning should be printed out to the stderr. Otherwise, qemu could move on if it doens't have access to `/etc/qemu/qemu.conf`.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/516 b/gitlab/issues_text/target_missing/host_missing/accel_missing/516
new file mode 100644
index 00000000..e282e7b4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/516
@@ -0,0 +1,42 @@
+Configure option `--enable-plugins` makes modules in shared library not loadable on macOS
+Description of problem:
+The title mentions `--enable-plugins` option, however as it's enabled by default, not providing `--disable-plugins` would also cause this to happen.
+
+If TCG plugin support is enabled, symbols in `qemu-system-*` binaries will be missing, and module libraries would fail to load as they expect those symbols to exist in the main binary.
+
+Configure options used: `STRIP="strip -x" ./configure --enable-user --enable-tools --enable-parallels --enable-libxml2 --enable-spice --enable-hvf --enable-cocoa --enable-guest-agent --enable-curses --enable-plugins --enable-modules --objcc=gcc --enable-libusb --enable-usb-redir`
+
+After inspecting the compiler command line, I've found the linker option `-Wl,-exported_symbols_list,qemu-plugins-ld64.symbols` is causing this to happen: only symbols listed in `qemu-plugins-ld64.symbols` would be kept in `qemu-system-*` binaries and all other symbols will be hidden.
+
+Note that this is not caused by stripping (although I had to use custom strip command line on macOS to successfully compile qemu); the option `-exported_symbols_list` works by only exposing the provided symbols and treating all other symbols as `visibility=hidden`.
+
+Replacing `--enable-plugins` to `--disable-plugins` in the above configure command line would "fix" it, although it means TCG plugins will not be supported.
+Steps to reproduce:
+1. Build QEMU on macOS with plugin support enabled
+2. Try to use modules in shared library like qxl
+Additional information:
+Some examples:
+
+```
+$ qemu-system-x86_64 -device qxl
+Failed to open module: dlopen(/usr/local/bin/../lib/qemu/ui-spice-core.dylib, 10): Symbol not found: __TRACE_QEMU_SPICE_ADD_MEMSLOT_DSTATE
+  Referenced from: /usr/local/bin/../lib/qemu/ui-spice-core.dylib
+  Expected in: flat namespace
+ in /usr/local/bin/../lib/qemu/ui-spice-core.dylib
+Failed to open module: dlopen(/usr/local/bin/../lib/qemu/hw-display-qxl.dylib, 2): Symbol not found: __TRACE_QXL_CLIENT_MONITORS_CONFIG_CAPPED_DSTATE
+  Referenced from: /usr/local/bin/../lib/qemu/hw-display-qxl.dylib
+  Expected in: flat namespace
+ in /usr/local/bin/../lib/qemu/hw-display-qxl.dylib
+qemu-system-x86_64: -device qxl: 'qxl' is not a valid device model name
+```
+
+```
+$ qemu-system-x86_64 -spice port=5901
+Failed to open module: dlopen(/usr/local/bin/../lib/qemu/ui-spice-core.dylib, 10): Symbol not found: __TRACE_QEMU_SPICE_ADD_MEMSLOT_DSTATE
+  Referenced from: /usr/local/bin/../lib/qemu/ui-spice-core.dylib
+  Expected in: flat namespace
+ in /usr/local/bin/../lib/qemu/ui-spice-core.dylib
+qemu-system-x86_64: -spice port=5901: spice support is disabled
+```
+
+After disabling plugin support I could run virtual machines locally through libvirt with full spice and qxl video support.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/517 b/gitlab/issues_text/target_missing/host_missing/accel_missing/517
new file mode 100644
index 00000000..764c25b7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/517
@@ -0,0 +1 @@
+Abort in vmxnet3_setup_tx_offloads
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/520 b/gitlab/issues_text/target_missing/host_missing/accel_missing/520
new file mode 100644
index 00000000..1d63a7ce
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/520
@@ -0,0 +1,33 @@
+qemu-ga fsfreeze crashes the kernel
+Description of problem:
+Hello,
+
+Still required your attention, duplicate from:
+https://bugs.launchpad.net/bugs/1807073
+https://bugs.launchpad.net/bugs/1813045
+
+We use mainly Cloudlinux, Debian and Centos.
+We experienced many crashes on our qemu instances based on Cloudlinux during a snapshot.
+The issue is not related to CloudLinux directly, but to Qemu agent, which does not freeze the file system(s) correctly. What is actually happening:
+
+When VM backup is invoked, Qemu agent freezes the file systems, so no single change will be made during the backup. But Qemu agent does not respect the loop* devices in freezing order (we have checked its sources), which leads to the next situation:
+1) freeze loopback fs
+              ---> send async reqs to loopback thread
+2) freeze main fs
+3) loopback thread wakes up and trying to write data to the main fs, which is still frozen, and this finally leads to the hung task and kernel crash.
+
+Moreover, a lot of Proxmox users are complaining about the issue as well:
+https://forum.proxmox.com/threads/error-vm-100-qmp-command-guest-fsfreeze-thaw-failed-got-timeout.68082/
+https://forum.proxmox.com/threads/problem-with-fsfreeze-freeze-and-qemu-guest-agent.65707/
+Steps to reproduce:
+1. Manually start backup for the VM with qemu-agent enabled.
+2. The backup process stuck at "INFO: issuing guest-agent 'fs-freeze' command"
+3. The VM become unavailable, you can only unlock it and force reset.
+Additional information:
+/var/log/messages logs:  
+Aug  6 21:54:00 cpanel qemu-ga: info: guest-ping called  
+Aug  6 21:54:01 cpanel qemu-ga: info: guest-fsfreeze called  
+Aug  6 21:54:01 cpanel qemu-ga: info: executing fsfreeze hook with arg 'freeze'  
+
+
+after this the VM becomes completely unavailable.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/521 b/gitlab/issues_text/target_missing/host_missing/accel_missing/521
new file mode 100644
index 00000000..b9591880
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/521
@@ -0,0 +1 @@
+Assert mr != NULL through megaraid
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/522 b/gitlab/issues_text/target_missing/host_missing/accel_missing/522
new file mode 100644
index 00000000..48b18068
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/522
@@ -0,0 +1,54 @@
+qemu gets SIGSEGV when starting with vhost-user-blk-pci device
+Description of problem:
+as subject
+Steps to reproduce:
+1. Prepare an qemu-storage-daemon process for vhost-user
+```
+qemu-img create /tmp/test 100M
+```
+```
+/usr/bin/qemu-storage-daemon --blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/test.img","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' --blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"raw","file":"libvirt-1-storage"}' --export vhost-user-blk,id=vhost-user-blk0,node-name=libvirt-1-format,addr.type=unix,addr.path=/tmp/vhost.sock,writable=on --chardev stdio,mux=on,id=char0
+```
+2. Run the qemu cmdline above. Then SIGSEGV.
+And the error of qemu-storage-daemon:`qemu-storage-daemon: vu_panic: Invalid queue index: 1`
+Additional information:
+Backtrace:
+```
+#0  0x0000557105198937 in vhost_user_read_cb (source=0x55710677be90, condition=<optimized out>, opaque=0x7ffe8b208ee0) at ../hw/virtio/vhost-user.c:313
+#1  0x00007f7e7ec422af in g_main_dispatch (context=0x557107b02070) at ../glib/gmain.c:3344
+#2  g_main_context_dispatch (context=0x557107b02070) at ../glib/gmain.c:4062
+#3  0x00007f7e7ec96df8 in g_main_context_iterate.constprop.0 (context=0x557107b02070, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4138
+#4  0x00007f7e7ec41873 in g_main_loop_run (loop=0x557107b02570) at ../glib/gmain.c:4336
+#5  0x000055710519770a in vhost_user_read (dev=dev@entry=0x7f7df46443f8, msg=msg@entry=0x7ffe8b208f50) at ../hw/virtio/vhost-user.c:402
+#6  0x000055710519808f in vhost_user_get_config (dev=0x7f7df46443f8, config=0x7f7df46443ac "", config_len=60) at ../hw/virtio/vhost-user.c:2133
+#7  0x0000557105152af1 in vhost_user_blk_device_realize (dev=0x7f7df46441b0, errp=<optimized out>) at ../hw/block/vhost-user-blk.c:503
+#8  0x000055710518cb9c in virtio_device_realize (dev=0x7f7df46441b0, errp=0x7ffe8b2092e0) at ../hw/virtio/virtio.c:3660
+#9  0x00005571051d7abd in device_set_realized (obj=<optimized out>, value=<optimized out>, errp=0x7ffe8b209360) at ../hw/core/qdev.c:761
+#10 0x00005571051da62a in property_set_bool (obj=0x7f7df46441b0, v=<optimized out>, name=<optimized out>, opaque=0x55710653c150, errp=0x7ffe8b209360) at ../qom/object.c:2257
+#11 0x00005571051dd3ac in object_property_set (obj=obj@entry=0x7f7df46441b0, name=name@entry=0x55710541bab9 "realized", v=v@entry=0x557107afbc80, errp=errp@entry=0x7ffe8b209470)
+    at ../qom/object.c:1402
+#12 0x00005571051e08f4 in object_property_set_qobject
+    (obj=obj@entry=0x7f7df46441b0, name=name@entry=0x55710541bab9 "realized", value=value@entry=0x557107afbbc0, errp=errp@entry=0x7ffe8b209470) at ../qom/qom-qobject.c:28
+#13 0x00005571051dd9c9 in object_property_set_bool (obj=0x7f7df46441b0, name=0x55710541bab9 "realized", value=<optimized out>, errp=0x7ffe8b209470) at ../qom/object.c:1472
+#14 0x0000557104fe813c in pci_qdev_realize (qdev=<optimized out>, errp=<optimized out>) at ../hw/pci/pci.c:2117
+#15 0x00005571051d7abd in device_set_realized (obj=<optimized out>, value=<optimized out>, errp=0x7ffe8b209590) at ../hw/core/qdev.c:761
+#16 0x00005571051da62a in property_set_bool (obj=0x7f7df463c010, v=<optimized out>, name=<optimized out>, opaque=0x55710653c150, errp=0x7ffe8b209590) at ../qom/object.c:2257
+#17 0x00005571051dd3ac in object_property_set (obj=obj@entry=0x7f7df463c010, name=name@entry=0x55710541bab9 "realized", v=v@entry=
+    0x557107af5e80, errp=errp@entry=0x5571057e2db0 <error_fatal>) at ../qom/object.c:1402
+#18 0x00005571051e08f4 in object_property_set_qobject
+    (obj=obj@entry=0x7f7df463c010, name=name@entry=0x55710541bab9 "realized", value=value@entry=0x557107af5e40, errp=errp@entry=0x5571057e2db0 <error_fatal>) at ../qom/qom-qobject.c:28
+#19 0x00005571051dd9c9 in object_property_set_bool (obj=0x7f7df463c010, name=name@entry=0x55710541bab9 "realized", value=value@entry=true, errp=errp@entry=0x5571057e2db0 <error_fatal>)
+    at ../qom/object.c:1472
+#20 0x00005571051d8052 in qdev_realize (dev=<optimized out>, bus=bus@entry=0x5571073ffeb0, errp=errp@entry=0x5571057e2db0 <error_fatal>) at ../hw/core/qdev.c:389
+#21 0x0000557104ec5e28 in qdev_device_add (opts=0x557106534000, errp=errp@entry=0x5571057e2db0 <error_fatal>) at ../softmmu/qdev-monitor.c:674
+#22 0x00005571050f4bf3 in device_init_func (opaque=<optimized out>, opts=<optimized out>, errp=0x5571057e2db0 <error_fatal>) at ../softmmu/vl.c:1212
+#23 0x0000557105302282 in qemu_opts_foreach (list=<optimized out>, func=func@entry=0x5571050f4be0 <device_init_func>, opaque=opaque@entry=0x0, errp=errp@entry=0x5571057e2db0 <error_fatal>)
+    at ../util/qemu-option.c:1168
+#24 0x00005571050f7532 in qemu_create_cli_devices () at ../softmmu/vl.c:2587
+#25 qmp_x_exit_preconfig (errp=<optimized out>) at ../softmmu/vl.c:2635
+#26 0x00005571050fb5ac in qmp_x_exit_preconfig (errp=<optimized out>) at ../softmmu/vl.c:2629
+#27 qemu_init (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/vl.c:3669
+#28 0x0000557104e87b1d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:49
+```
+
+Get full threads backtrace on the attachment [gdb.zip](/uploads/3cbc168cad60a1472e9e3f323207de9d/gdb.zip)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/523 b/gitlab/issues_text/target_missing/host_missing/accel_missing/523
new file mode 100644
index 00000000..cf0ec97f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/523
@@ -0,0 +1,126 @@
+Some iotests failing with --enable-block-drv-whitelist-in-tools
+Description of problem:
+Building latest RC with Fedora, some of the iotests now report fail. We could track it down to the --enable-block-drv-whitelist-in-tools option.
+Steps to reproduce:
+1. ```configure --enable-block-drv-whitelist-in-tools```
+2. ```make```
+3. ```make check```
+Additional information:
+```
+...
+  TEST   iotest-qcow2: 049 [fail]
+QEMU          -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-system-x86_64" -nodefaults -display none -accel qtest
+QEMU_IMG      -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-img" 
+QEMU_IO       -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-io" --cache writeback --aio threads -f qcow2
+QEMU_NBD      -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-nbd" 
+IMGFMT        -- qcow2
+IMGPROTO      -- file
+PLATFORM      -- Linux/x86_64 buildvm-x86-11.iad2.fedoraproject.org 5.12.13-300.fc34.x86_64
+TEST_DIR      -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch
+SOCK_DIR      -- /tmp/tmpr6u1m61s
+SOCKET_SCM_HELPER -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/socket_scm_helper
+--- /builddir/build/BUILD/qemu-6.1.0-rc3/tests/qemu-iotests/049.out
++++ 049.out.bad
+@@ -199,6 +199,8 @@
+ qemu-img create -f qcow2 --object secret,id=sec0,data=123456 -o encryption=on,encrypt.key-secret=sec0 TEST_DIR/t.qcow2 64M
+ Formatting 'TEST_DIR/t.qcow2', fmt=qcow2 encryption=on encrypt.key-secret=sec0 cluster_size=65536 extended_l2=off compression_type=zlib size=67108864 lazy_refcounts=off refcount_bits=16
++qemu-img: TEST_DIR/t.qcow2: Use of AES-CBC encrypted qcow2 images is no longer supported in system emulators
++You can use 'qemu-img convert' to convert your image to an alternative supported format, such as unencrypted qcow2, or raw with the LUKS format instead.
+ == Check lazy_refcounts option (only with v3) ==
+...
+  TEST   iotest-qcow2: 134 [fail]
+QEMU          -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-system-x86_64" -nodefaults -display none -accel qtest
+QEMU_IMG      -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-img" 
+QEMU_IO       -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-io" --cache writeback --aio threads -f qcow2
+QEMU_NBD      -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-nbd" 
+IMGFMT        -- qcow2
+IMGPROTO      -- file
+PLATFORM      -- Linux/x86_64 buildvm-x86-11.iad2.fedoraproject.org 5.12.13-300.fc34.x86_64
+TEST_DIR      -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch
+SOCK_DIR      -- /tmp/tmpr6u1m61s
+SOCKET_SCM_HELPER -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/socket_scm_helper
+--- /builddir/build/BUILD/qemu-6.1.0-rc3/tests/qemu-iotests/134.out
++++ 134.out.bad
+@@ -1,30 +1,24 @@
+ QA output created by 134
+ Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 encryption=on
++qemu-img: TEST_DIR/t.IMGFMT: Use of AES-CBC encrypted IMGFMT images is no longer supported in system emulators
++You can use 'qemu-img convert' to convert your image to an alternative supported format, such as unencrypted IMGFMT, or raw with the LUKS format instead.
+ == reading whole image ==
+-read 134217728/134217728 bytes at offset 0
+-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory
+ == rewriting cluster part ==
+-wrote 512/512 bytes at offset 512
+-512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory
+ == verify pattern ==
+-read 512/512 bytes at offset 0
+-512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+-read 512/512 bytes at offset 512
+-512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory
++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory
+ == rewriting whole image ==
+-wrote 134217728/134217728 bytes at offset 0
+-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory
+ == verify pattern ==
+-read 134217728/134217728 bytes at offset 0
+-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory
+ == verify pattern failure with wrong password ==
+-Pattern verification failed at offset 0, 134217728 bytes
+-read 134217728/134217728 bytes at offset 0
+-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory
+ *** done
+...
+  TEST   iotest-qcow2: 158 [fail]
+QEMU          -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-system-x86_64" -nodefaults -display none -accel qtest
+QEMU_IMG      -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-img" 
+QEMU_IO       -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-io" --cache writeback --aio threads -f qcow2
+QEMU_NBD      -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-nbd" 
+IMGFMT        -- qcow2
+IMGPROTO      -- file
+PLATFORM      -- Linux/x86_64 buildvm-x86-11.iad2.fedoraproject.org 5.12.13-300.fc34.x86_64
+TEST_DIR      -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch
+SOCK_DIR      -- /tmp/tmpr6u1m61s
+SOCKET_SCM_HELPER -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/socket_scm_helper
+--- /builddir/build/BUILD/qemu-6.1.0-rc3/tests/qemu-iotests/158.out
++++ 158.out.bad
+@@ -1,26 +1,25 @@
+ QA output created by 158
+ == create base ==
+ Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=134217728 encryption=on
++qemu-img: TEST_DIR/t.IMGFMT.base: Use of AES-CBC encrypted IMGFMT images is no longer supported in system emulators
++You can use 'qemu-img convert' to convert your image to an alternative supported format, such as unencrypted IMGFMT, or raw with the LUKS format instead.
+ == writing whole image ==
+-wrote 134217728/134217728 bytes at offset 0
+-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2.base': No such file or directory
+ == verify pattern ==
+-read 134217728/134217728 bytes at offset 0
+-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2.base': No such file or directory
+ == create overlay ==
+ Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 backing_file=TEST_DIR/t.IMGFMT.base backing_fmt=IMGFMT encryption=on
++qemu-img: TEST_DIR/t.IMGFMT: Use of AES-CBC encrypted IMGFMT images is no longer supported in system emulators
++You can use 'qemu-img convert' to convert your image to an alternative supported format, such as unencrypted IMGFMT, or raw with the LUKS format instead.
+ == writing part of a cluster ==
+-wrote 1024/1024 bytes at offset 0
+-1 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory
+ == verify pattern ==
+-read 1024/1024 bytes at offset 0
+-1 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory
+ == verify pattern ==
+-read 64512/64512 bytes at offset 1024
+-63 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory
+ *** done
+...
+Failures: 049 134 158
+Failed 3 of 122 iotests
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/524 b/gitlab/issues_text/target_missing/host_missing/accel_missing/524
new file mode 100644
index 00000000..d2cd09ad
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/524
@@ -0,0 +1 @@
+Giving -smp option a negative argument makes QEMU dump core
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/526 b/gitlab/issues_text/target_missing/host_missing/accel_missing/526
new file mode 100644
index 00000000..eba13155
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/526
@@ -0,0 +1,15 @@
+MacBook German Keyboard <> and ^° Key not working
+Description of problem:
+Using a German keyboard on my 2018 MacBook Pro I can't type the <> Key or the ^ Key. 
+When pressing the <> Key it gets interpreted as the ^ Key, the ^ Key is dead.
+
+Problem is not caused by the guest system, Ubuntu VMs also can't type <>. (Ubuntu VMs ran inside UTM, which internally uses QEMU. https://mac.getutm.app/ )
+
+VirtualBox maps the <> Key and ^ Key correctly.
+Steps to reproduce:
+0. Use a MacBook with a German Keyboard
+1. Install TempleOS
+2. Install German Keyboard Layout from https://github.com/Rion96/GKey (mount the ISO as a CD Drive)
+3. Every key works except for <> and ^.
+Additional information:
+Doing the same steps in VirtualBox results in <> and ^ working, so it must be a QEMU error.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/527 b/gitlab/issues_text/target_missing/host_missing/accel_missing/527
new file mode 100644
index 00000000..8556234c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/527
@@ -0,0 +1 @@
+Plain text files in docs/ should be converted to rst
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/531 b/gitlab/issues_text/target_missing/host_missing/accel_missing/531
new file mode 100644
index 00000000..68c334cc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/531
@@ -0,0 +1 @@
+Replace DMA processing in I/O handlers by asynchronous BH
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/532 b/gitlab/issues_text/target_missing/host_missing/accel_missing/532
new file mode 100644
index 00000000..24db93b4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/532
@@ -0,0 +1 @@
+USB-EHCI: Replace DMA processing in I/O handlers by asynchronous BH
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/533 b/gitlab/issues_text/target_missing/host_missing/accel_missing/533
new file mode 100644
index 00000000..c2d86a5b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/533
@@ -0,0 +1 @@
+Assertion failure in vmxnet3_get_next_body_rx_descr: d->btype == VMXNET3_RXD_BTYPE_BODY
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/534 b/gitlab/issues_text/target_missing/host_missing/accel_missing/534
new file mode 100644
index 00000000..1bad520c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/534
@@ -0,0 +1 @@
+Memcpy param-overlap through e1000e_write_to_rx_buffers
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/535 b/gitlab/issues_text/target_missing/host_missing/accel_missing/535
new file mode 100644
index 00000000..13f281aa
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/535
@@ -0,0 +1 @@
+Assertion failure in iov_from_buf_full through the e1000e
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/537 b/gitlab/issues_text/target_missing/host_missing/accel_missing/537
new file mode 100644
index 00000000..90ab1f56
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/537
@@ -0,0 +1 @@
+Assertion failure in e1000e_write_to_rx_buffers
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/539 b/gitlab/issues_text/target_missing/host_missing/accel_missing/539
new file mode 100644
index 00000000..398cadcc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/539
@@ -0,0 +1 @@
+Abort in vmxnet3_validate_interrupt_idx
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/540 b/gitlab/issues_text/target_missing/host_missing/accel_missing/540
new file mode 100644
index 00000000..ab123218
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/540
@@ -0,0 +1 @@
+Heap-use-after-free in usb_packet_unmap through xhci
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/541 b/gitlab/issues_text/target_missing/host_missing/accel_missing/541
new file mode 100644
index 00000000..d23bf0c5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/541
@@ -0,0 +1 @@
+Heap-use-after-free through ehci_flush_qh
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/542 b/gitlab/issues_text/target_missing/host_missing/accel_missing/542
new file mode 100644
index 00000000..aa3c41f1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/542
@@ -0,0 +1 @@
+Stack-overflow in ldl_le_dma through intel-hda (CVE-2021-3611)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/543 b/gitlab/issues_text/target_missing/host_missing/accel_missing/543
new file mode 100644
index 00000000..700d5da8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/543
@@ -0,0 +1 @@
+virtio-blk: ASSERT: !s->dataplane_started
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/544 b/gitlab/issues_text/target_missing/host_missing/accel_missing/544
new file mode 100644
index 00000000..d9d7c5f9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/544
@@ -0,0 +1 @@
+Assert xfer->packet.status != USB_RET_NAK in xhci
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/545 b/gitlab/issues_text/target_missing/host_missing/accel_missing/545
new file mode 100644
index 00000000..663a9ee7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/545
@@ -0,0 +1 @@
+Abort in ohci_frame_boundary
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/546 b/gitlab/issues_text/target_missing/host_missing/accel_missing/546
new file mode 100644
index 00000000..4003cb23
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/546
@@ -0,0 +1 @@
+Global-buffer-overflow in mode_sense_page
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/547 b/gitlab/issues_text/target_missing/host_missing/accel_missing/547
new file mode 100644
index 00000000..389aa167
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/547
@@ -0,0 +1 @@
+e1000: Loop blocking QEMU with high CPU usage
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/548 b/gitlab/issues_text/target_missing/host_missing/accel_missing/548
new file mode 100644
index 00000000..9098ca7e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/548
@@ -0,0 +1 @@
+Null-ptr dereference in megasas_finish_dcmd
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/55 b/gitlab/issues_text/target_missing/host_missing/accel_missing/55
new file mode 100644
index 00000000..d5227695
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/55
@@ -0,0 +1 @@
+Can't install Windows 7 with q35 (SATA)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/551 b/gitlab/issues_text/target_missing/host_missing/accel_missing/551
new file mode 100644
index 00000000..1d3fd5ee
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/551
@@ -0,0 +1 @@
+Null-ptr dereference in megasas_command_complete
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/552 b/gitlab/issues_text/target_missing/host_missing/accel_missing/552
new file mode 100644
index 00000000..be9c9c97
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/552
@@ -0,0 +1 @@
+assert issue locates in hw/scsi/lsi53c895a.c:624: lsi_do_dma: Assertion `s->current' failed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/553 b/gitlab/issues_text/target_missing/host_missing/accel_missing/553
new file mode 100644
index 00000000..82a64f19
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/553
@@ -0,0 +1,25 @@
+Virtio-vga with blobs on fails, when qemu compiled with enabled modules
+Description of problem:
+When using qemu configured with `--enabled-modules` and starting qemu with command line above, qemu crashes with following output:
+```
+qemu-system-x86_64: -device virtio-vga,blob=on: cannot enable blob resources without udmabuf
+```
+While qemu configured without `--enabled-modules` runs this command successfully.
+Steps to reproduce:
+1. Get latest qemu source code
+2. Build qemu `mkdir build && cd build && ../configure && ninja`
+3. Check if following command runs without errors and show sdl qemu window
+ ```
+ sudo ./qemu-system-x86_64  \
+      -object memory-backend-memfd,id=mem1,size=512M \
+      -machine memory-backend=mem1 \
+      -display sdl \
+      -device virtio-vga,blob=on
+
+ ```
+4. Then try to build with modules enabled  `mkdir build && cd build && ../configure --enable-modules && ninja`
+5. Try to do step 3 again
+Additional information:
+I tried to debug this bug, and found that problem is with function `virtio_gpu_have_udmabuf`: when qemu is build without modules this function is from `hw/display/virtio-gpu-udmabuf.c` (which is correct), but when qemu compiled with modules this function comes from `stubs/virtio-gpu-udmabuf.c` and when `hw-display-virtio-gpu.so` is loaded, `virtio_gpu_have_udmabuf` is not replaced, and remains function from stub (which always return 0) and command fails.
+
+I think I will submit patch that fix it tomorrow
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/556 b/gitlab/issues_text/target_missing/host_missing/accel_missing/556
new file mode 100644
index 00000000..a8914e21
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/556
@@ -0,0 +1,19 @@
+Fix DMA MMIO reentrancy issues
+Additional information:
+List of `DMA reentrancy` issues (usually found by [fuzzer](https://gitlab.com/qemu-project/qemu/-/issues?label_name[]=Fuzzer)):
+- #62 (AHCI)
+- #84, #305, #552 (SCSI)
+- #451, #1282 (SDHCI)
+- #540 (xHCI)
+- #541 (EHCI)
+- #542 (HDA)
+- #557 (pcnet)
+- #782 (NVMe)
+- [eepro100](https://lore.kernel.org/qemu-devel/20210218140629.373646-1-ppandit@redhat.com/)
+- #827 (virtio-blk)
+- #1171 (tulip)
+- #1543 (e1000e)
+- #1563 (lsi53c895a)
+
+
+Usually coredump backtrace includes multiple calls to `access_with_adjusted_size()` from the Memory API.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/557 b/gitlab/issues_text/target_missing/host_missing/accel_missing/557
new file mode 100644
index 00000000..8ba506c6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/557
@@ -0,0 +1 @@
+Stack-overflow through pcnet_tmd_load
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/558 b/gitlab/issues_text/target_missing/host_missing/accel_missing/558
new file mode 100644
index 00000000..2d6178e4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/558
@@ -0,0 +1,57 @@
+gtk UI interprets double/triple click as button release
+Description of problem:
+When using the GTK interface clicking rapidly in a down-up-down pattern, the final "down" event is erroneously followed by an immediate "up" event and the mouse device in the guest reports the pressed button as no longer being held.
+Steps to reproduce:
+1. Start a VM using the GTK interface.
+2. Open a tool to examine guest mouse input events, such as `xev` or `yutani-test`
+3. Click twice with any button, without releasing on the second click.
+4. Observe erroneous 'up' event in guest.
+5. Move the mouse while keeping the button pressed.
+6. Observe the guest reports the button is not held.
+Additional information:
+GTK 3 sends an additional `GDK_2BUTTON_PRESS` event after the initial `GDK_BUTTON_PRESS` event, which QEMU is misinterpreting as a release event. I confirmed this with the addition of some logging of `button->type` in `gd_button_event`:
+
+```
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4 # = PRESS
+button = 1, type = 5 # = 2BUTTON_PRESS
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 5
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 5
+button = 1, type = 7
+```
+
+```diff
+diff --git a/ui/gtk.c b/ui/gtk.c
+index cfb0728d1f..b9979f0e11 100644
+--- a/ui/gtk.c
++++ b/ui/gtk.c
+@@ -925,6 +925,13 @@ static gboolean gd_button_event(GtkWidget *widget, GdkEventButton *button,
+         return TRUE;
+     }
+ 
++    /* ignore additional events for double- and triple- press, as they are
++     * sent to us after a regular press event; otherwise we will misinterpret
++     * these as release events and eat the button! */
++    if (button->type == GDK_2BUTTON_PRESS || button->type == GDK_3BUTTON_PRESS) {
++        return TRUE;
++    }
++
+     qemu_input_queue_btn(vc->gfx.dcl.con, btn,
+                          button->type == GDK_BUTTON_PRESS);
+     qemu_input_event_sync();
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/559 b/gitlab/issues_text/target_missing/host_missing/accel_missing/559
new file mode 100644
index 00000000..422ece19
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/559
@@ -0,0 +1 @@
+info does not recognize file format of vpc with subformat=fixed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/56 b/gitlab/issues_text/target_missing/host_missing/accel_missing/56
new file mode 100644
index 00000000..56147c28
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/56
@@ -0,0 +1 @@
+Regression report: Disk subsystem I/O failures/issues surfacing in DOS/early Windows [two separate issues: one bisected, one root-caused]
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/560 b/gitlab/issues_text/target_missing/host_missing/accel_missing/560
new file mode 100644
index 00000000..7ca72966
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/560
@@ -0,0 +1 @@
+User-emu documentation mentions inexistent "runtime" downloads
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/562 b/gitlab/issues_text/target_missing/host_missing/accel_missing/562
new file mode 100644
index 00000000..159304d3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/562
@@ -0,0 +1 @@
+`ShaderTranslator.h` and `ShaderTranslator.cpp` files are missing and are not in ANGLE_ROOT/src/libShaderTranslator
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/563 b/gitlab/issues_text/target_missing/host_missing/accel_missing/563
new file mode 100644
index 00000000..036bd268
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/563
@@ -0,0 +1 @@
+KVM ubuntu 20 VPS on Ryzen 9 5950X
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/564 b/gitlab/issues_text/target_missing/host_missing/accel_missing/564
new file mode 100644
index 00000000..3b929188
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/564
@@ -0,0 +1,13 @@
+Enable opengl virtio-gpu virgl vulkan in windows build
+Additional information:
+```
+PS E:\scoopg\apps\qemu\current> ./qemu-system-x86_64.exe -drive file=E:\groot_02\vdisks\gparted-live.iso,if=virtio  -boot c -m 4096 -machine type=pc,accel=whpx,kernel-irqchip=off -smp 8,sockets=1,cores=8,threads=1 -vga virtio -display sdl,gl=on
+E:\scoopg\apps\qemu\current\qemu-system-x86_64.exe: OpenGL support is disabled
+```
+
+```
+PS E:\scoopg\apps\qemu\current> E:\scoopg\apps\qemu\current\qemu-system-x86_64.exe --version
+QEMU emulator version 6.0.93 (v6.1.0-rc3-11879-ge232c1bc00-dirty)
+Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
+```
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/566 b/gitlab/issues_text/target_missing/host_missing/accel_missing/566
new file mode 100644
index 00000000..c0951630
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/566
@@ -0,0 +1 @@
+Fail to build linux-user on Alpine
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/567 b/gitlab/issues_text/target_missing/host_missing/accel_missing/567
new file mode 100644
index 00000000..63611b1e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/567
@@ -0,0 +1 @@
+qemu 6.1.0 build fail on alpine linux
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/568 b/gitlab/issues_text/target_missing/host_missing/accel_missing/568
new file mode 100644
index 00000000..a94dd3a9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/568
@@ -0,0 +1,26 @@
+video memory option not working with Mac OS or Windows guest
+Description of problem:
+The vgamem_mb option tells the guest how much video memory it has access to. When I used this command '-device VGA,vgamem_mb=128', I expect the guest to report there is 128 MB of video memory. What actually happens is the guest does not seem to know how much video memory is actually available.
+Steps to reproduce:
+**Mac OS guest:**
+1. Run a Mac OS guest with this command: -device VGA,vgamem_mb=128
+2. In Mac OS X open the System Information application -> /Applications/Utilities/System Information. 
+3. Click on "Graphics/Displays".
+4. Look at the 'VRAM (Total)' field.
+The field only shows 3 MB of video ram.
+
+**Windows guest:**
+1. Run a Windows (Windows XP in my case) guest with this command: -device VGA,vgamem_mb=128
+2. Click on Start->Run.
+3. Enter 'dxdiag'.
+4. Push the OK button.
+5. Click on the Display tap in the DirectX Diagnostic Tool.
+6. Look at the Approv. Total Memory field.
+The field should say 128 MB but actually says N/A.
+Additional information:
+**Mac OS 8.5<br>**
+![Mac_OS_10.8](/uploads/b80d67c82ec1236067b3577add10c19c/Mac_OS_10.8.png)<br><br><br>
+**Windows XP<br>**
+![Windows_XP](/uploads/9db71f35faa360dfcebc2b8af84abf06/Windows_XP.png)<br><br><br>
+**Windows 7<br>**
+![Windows_7](/uploads/8645f1424ef1637300056c889df3d7de/Windows_7.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/569 b/gitlab/issues_text/target_missing/host_missing/accel_missing/569
new file mode 100644
index 00000000..b68f03d0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/569
@@ -0,0 +1 @@
+ESP SCSI adapter not working with DOS ASPI drivers
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/57 b/gitlab/issues_text/target_missing/host_missing/accel_missing/57
new file mode 100644
index 00000000..7d9cac89
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/57
@@ -0,0 +1 @@
+IDE short PRDT abort
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/574 b/gitlab/issues_text/target_missing/host_missing/accel_missing/574
new file mode 100644
index 00000000..2cfd7b02
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/574
@@ -0,0 +1 @@
+ui/sdl2: warning: redundant redeclaration of 'direct_waitqueue_init'
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/575 b/gitlab/issues_text/target_missing/host_missing/accel_missing/575
new file mode 100644
index 00000000..bd68a7e4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/575
@@ -0,0 +1 @@
+maybe-uninitialized warning in load_fit()
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/576 b/gitlab/issues_text/target_missing/host_missing/accel_missing/576
new file mode 100644
index 00000000..bd97089c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/576
@@ -0,0 +1 @@
+New Cocoa clipboard support raises minimum macos version to 10.14
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/578 b/gitlab/issues_text/target_missing/host_missing/accel_missing/578
new file mode 100644
index 00000000..a6883007
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/578
@@ -0,0 +1,30 @@
+getdomainname() is not implemented in QEMU user mode on Linux/sparc64
+Description of problem:
+The `getdomainname()` function fails, instead of succeeding.
+Steps to reproduce:
+[foo.c](/uploads/7586c9aab788855b232a5c2f6aaeb4fc/foo.c)
+
+1.
+```
+# apt install g++-10-sparc64-linux-gnu
+# mkdir -p /usr/sparc64-linux-gnu/etc
+# touch /usr/sparc64-linux-gnu/etc/ld.so.cache
+```
+2.
+```
+$ sparc64-linux-gnu-gcc-10 -Wall -static foo.c
+```
+[a.out](/uploads/39d291b95caa182d74b0b622a82667e8/a.out)
+
+3. Transfer the a.out file to a Linux/sparc64 machine; execute it there. It prints
+```
+result: (none)
+```
+4.
+```
+$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-sparc64 ./a.out
+```
+Expected: `result: (none)`
+Actual: `getdomainname: Function not implemented`
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/579 b/gitlab/issues_text/target_missing/host_missing/accel_missing/579
new file mode 100644
index 00000000..efc4639b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/579
@@ -0,0 +1,50 @@
+chown() fails when it should succeed in QEMU user mode on Linux/sparc64
+Description of problem:
+The `chown()` function fails, instead of succeeding, in a particular situation.
+Steps to reproduce:
+[foo.c](/uploads/630d9b83671a071f4ded4da43b6c1b9b/foo.c)
+
+1.
+```
+# apt install g++-10-sparc64-linux-gnu
+# mkdir -p /usr/sparc64-linux-gnu/etc
+# touch /usr/sparc64-linux-gnu/etc/ld.so.cache
+```
+2.
+```
+$ sparc64-linux-gnu-gcc-10 -Wall -static foo.c
+```
+[a.out](/uploads/bbab43a1b78e6d16ee13e0eff5e963a5/a.out)
+
+3. Transfer the a.out file to a Linux/sparc64 machine; execute these commands there:
+```
+$ id
+```
+Verify that you are in 2 or more groups.
+```
+$ touch file
+$ ln -s file link
+$ ln -s link link2
+$ ./a.out; echo $?
+```
+It prints `0`.
+
+4.
+```
+$ id
+```
+Verify that you are in 2 or more groups.
+```
+$ touch file
+$ ln -s file link
+$ ln -s link link2
+$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-sparc64 ./a.out; echo $?
+```
+Expected: `0`
+Actual:
+```
+chown: Operation not permitted
+1
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/58 b/gitlab/issues_text/target_missing/host_missing/accel_missing/58
new file mode 100644
index 00000000..ae6c43d4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/58
@@ -0,0 +1 @@
+Bitmaps with Extra Data cannot be removed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/580 b/gitlab/issues_text/target_missing/host_missing/accel_missing/580
new file mode 100644
index 00000000..3ea5dfe3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/580
@@ -0,0 +1,17 @@
+access internet from guest
+Description of problem:
+I can ssh back to host using ssh 10.0.2.2.
+Also I can login to guest from host using ssh riscv@localhost -p 3333.
+However,
+I could not get internet access from the guest os system, such as:
+```
+[riscv@fedora-riscv ~]$ wget www.google.com
+--2019-12-15 05:53:04--  http://www.google.com/
+Resolving www.google.com (www.google.com)... 216.58.194.164, 2607:f8b0:4005:804::2004
+Connecting to www.google.com (www.google.com)|216.58.194.164|:80... failed: Connection refused.
+Connecting to www.google.com (www.google.com)|2607:f8b0:4005:804::2004|:80... failed: Network is unreachable.
+```
+Therefore, I could not use dnf to install packages.
+Any help will be appreciated.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/581 b/gitlab/issues_text/target_missing/host_missing/accel_missing/581
new file mode 100644
index 00000000..b3251886
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/581
@@ -0,0 +1 @@
+QEMU should warn if the user passes a '-vga something' option and we ignore it
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/582 b/gitlab/issues_text/target_missing/host_missing/accel_missing/582
new file mode 100644
index 00000000..d16a275a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/582
@@ -0,0 +1 @@
+Possible regression in qemu-user-static v5.7 from Fedora 34 Repo?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/583 b/gitlab/issues_text/target_missing/host_missing/accel_missing/583
new file mode 100644
index 00000000..fbd96057
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/583
@@ -0,0 +1 @@
+Last cylinder of CHS disk image is not declared as accessible in image
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/586 b/gitlab/issues_text/target_missing/host_missing/accel_missing/586
new file mode 100644
index 00000000..25a0ffab
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/586
@@ -0,0 +1 @@
+virtio-gpu: qemu 6.1.0 no longer enables virgl when using '-vga virtio'
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/587 b/gitlab/issues_text/target_missing/host_missing/accel_missing/587
new file mode 100644
index 00000000..f4ac6779
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/587
@@ -0,0 +1 @@
+qemu show no error but the virtual machine stuck in boot (GPU passthrough)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/589 b/gitlab/issues_text/target_missing/host_missing/accel_missing/589
new file mode 100644
index 00000000..7225b9c0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/589
@@ -0,0 +1 @@
+Error installing QGA file under virtual machine of windows system
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/59 b/gitlab/issues_text/target_missing/host_missing/accel_missing/59
new file mode 100644
index 00000000..dec48bf8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/59
@@ -0,0 +1 @@
+ide/core.c ATA Major Version reporting incorrect
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/590 b/gitlab/issues_text/target_missing/host_missing/accel_missing/590
new file mode 100644
index 00000000..1d556fc6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/590
@@ -0,0 +1 @@
+NSIS Windows installer generator warnings when cross-building on MinGW
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/591 b/gitlab/issues_text/target_missing/host_missing/accel_missing/591
new file mode 100644
index 00000000..47bdee0b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/591
@@ -0,0 +1 @@
+Sphinx documentation jobs fail on fork with no version tag
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/592 b/gitlab/issues_text/target_missing/host_missing/accel_missing/592
new file mode 100644
index 00000000..9e594650
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/592
@@ -0,0 +1,108 @@
+CloudLinux / CageFS - guest-fsfreeze hangs system
+Description of problem:
+Since CloudLinux provides CageFS (virtualized file system), each time guest-fsfreeze for Proxmox backup, the system is hangs up and become unavailable. It's caused by cagefs-skeleton mount points:
+
+```
+sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
+proc on /proc type proc (rw,nosuid,nodev,noexec,relatime,gid=1002,hidepid=2)
+devtmpfs on /dev type devtmpfs (rw,nosuid,size=3993656k,nr_inodes=998414,mode=755)
+securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
+tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
+devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
+tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
+tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
+cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
+pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
+configfs on /sys/kernel/config type configfs (rw,relatime)
+/dev/sda2 on / type ext4 (rw,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=34,pipe_ino=10005,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10005)
+mqueue on /dev/mqueue type mqueue (rw,relatime)
+hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
+debugfs on /sys/kernel/debug type debugfs (rw,relatime)
+fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
+/dev/sda1 on /boot type ext4 (rw,relatime,data=ordered)
+/usr/tmpDSK on /tmp type ext4 (rw,nosuid,noexec,relatime,discard,data=ordered)
+/usr/tmpDSK on /var/tmp type ext4 (rw,nosuid,noexec,relatime,discard,data=ordered)
+cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer)
+cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices)
+cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,relatime,cpuacct,cpu)
+cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset)
+cgroup on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory)
+/dev/sda2 on /usr/share/cagefs-skeleton type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+devpts on /usr/share/cagefs-skeleton/dev/pts type devpts (rw,nosuid,relatime,gid=5,mode=620,ptmxmode=000)
+/dev/sda2 on /usr/share/cagefs-skeleton/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/lib64 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/opt type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/include type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/lib64 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/apache/domlogs type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/lib64 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/perl type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/php type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/share type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/Cpanel type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/Whostmgr type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/base type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/cgi-priv type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/cpaddons type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/hooks type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/htdocs type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/img-sys type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/install type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/lang type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/libexec type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/locale type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/php type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/scripts type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/share type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/shared type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/sys_cpanel/boxtrapper-message type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/var type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/whostmgr type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/whostmgr/docroot/cgi/softaculous type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/l.v.e-manager/cl.nodejs type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/l.v.e-manager/cl.python type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/locale type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/man type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/terminfo type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/vim type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/zoneinfo type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/var/cpanel/ea4 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/var/lib/mysql type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/var/lib/proxyexec/cagefs.sock type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/var/lib/spamassassin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+tmpfs on /usr/share/cagefs-skeleton/run/dbus type tmpfs (rw,nosuid,mode=755)
+tmpfs on /usr/share/cagefs-skeleton/run/nscd type tmpfs (rw,nosuid,mode=755)
+/dev/sda2 on /usr/share/cagefs-skeleton/var/softaculous type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/var/spool/at type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/var/www/cgi-bin type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/var/www/html type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/opt/suphp/sbin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php73/root/usr/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php73/root/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php74/root/usr/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php74/root/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php80/root/usr/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php80/root/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+/dev/sda2 on /usr/share/cagefs-skeleton/var/lve/lveinfo.ver.cagefs type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user)
+proc on /usr/share/cagefs-skeleton/proc type proc (rw,nosuid,relatime,gid=1002,hidepid=2)
+systemd-1 on /usr/share/cagefs-skeleton/proc/sys/fs/binfmt_misc type autofs (rw,nosuid,relatime,fd=34,pipe_ino=10005,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10005)
+tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=800880k,mode=700)
+```
+
+Is there anyway qemu-guest-agent can handle this? I saw a lot of users faced this problem since CloudLinux becomes more popular after RHEL halted future CentOS releases.
+
+CloudLinux has an option to umount/mount cagefs-skeleton, maybe it's something can be implemented - https://docs.cloudlinux.com/command-line_tools/
+
+The same issue happens when JailShell is enabled on cPanel servers (OVH reported about) - https://docs.ovh.com/ca/en/vps/cpanel_auto_backup/
+
+Thank you for your time.
+Steps to reproduce:
+1. Manually start backup for the VM with qemu-agent enabled.
+2. The backup process stuck at "INFO: issuing guest-agent 'fs-freeze' command"
+3. The VM become unavailable, you can only unlock it and force reset.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/593 b/gitlab/issues_text/target_missing/host_missing/accel_missing/593
new file mode 100644
index 00000000..888ee3bb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/593
@@ -0,0 +1,7 @@
+USB ECM network device does not work under XHCI
+Description of problem:
+No data is ever received by the USB ECM network device when it is attached to an XHCI controller. (USB 1.0 controllers work OK.)
+Additional information:
+There are some patches it appears were submitted to the GitHub mirror that resolve the problem (I tested them applied to git master, and confirmed they work): https://github.com/qemu/qemu/pull/100
+
+I guess they never were submitted to the mailing list, or somehow got missed?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/595 b/gitlab/issues_text/target_missing/host_missing/accel_missing/595
new file mode 100644
index 00000000..30ab9273
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/595
@@ -0,0 +1,11 @@
+QEMU VNC mouse doesn't move in tablet mode os9
+Description of problem:
+What I am trying to do is have a headless os9 running in QEMU on ubuntu and use the native vnc support in QEMU to access the screen. That is setup and works as expected but the mouse only works in ps/2 mode and that is clearly very undesirable (mouse is never lined up). I set it up in tablet mode and when I am in the QEMU window on the host the mouse works perfect (I added tablet mode to os9 with: https://github.com/kanjitalk755/macos9-usb-tablet). That same tablet mode results in the mouse not moving at all over vnc, if I ctrl+alt 2 and switch the mouse type from tablet mode it starts working again but not lined up at all as expected, cant get to any buttons on edges. Is there anyone in here that ran into this? Am I the only one using QEMU VNC?
+
+Iv thought about running a vnc application on the vm itself but performance was meh at best. Any tips would be worth a lot to me, its a sin to say but I am trying to adapt this into a production environment...
+
+Upon further investigation this seems to be a issue on Linux. I am testing the QEMU on windows and its working as expected over VNC. That is to say if QEMU is running on a windows host, it just works over vnc with tablet mode. So what could be causing Linux version to not work? I did compile it from source, are there any configure flags I am missing? I am trying to run it on Ubuntu server 21.04
+Steps to reproduce:
+1.add vnc option to parameters
+2.enable tablet mode and install driver in os9
+3.connect to vnc and mouse doesn't move
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/598 b/gitlab/issues_text/target_missing/host_missing/accel_missing/598
new file mode 100644
index 00000000..c24c0609
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/598
@@ -0,0 +1 @@
+QEMU boot kernel for ppc e300c3 problem
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/599 b/gitlab/issues_text/target_missing/host_missing/accel_missing/599
new file mode 100644
index 00000000..e4d8a747
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/599
@@ -0,0 +1,11 @@
+Q35: Windows BSOD running on 6.1.0
+Description of problem:
+Starting with QEMU 6.1.0, Windows no longer boots with Q35 (including `pc-q35-6.0` as well). When booting an existing Windows 7 installation, BSOD appears during boot (0x0000007B). If you try to install Windows from an ISO, the follow error appears when you try to start setup.
+
+![Screen_Shot_2021-09-05_at_1.58.05_PM](/uploads/cfa04f25e9a8dc5ca8f201c87794b6c7/Screen_Shot_2021-09-05_at_1.58.05_PM.png)
+
+Other people also reported similar issues booting Windows 10, as well as during use of Windows XP.
+Steps to reproduce:
+Enter commands from above.
+Additional information:
+This was not an issue in QEMU 6.0.0. I can reproduce it at `master`.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/600 b/gitlab/issues_text/target_missing/host_missing/accel_missing/600
new file mode 100644
index 00000000..132cf76c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/600
@@ -0,0 +1 @@
+Have 'info mtree' accept an (optional) 'name' parameter to pick a specific address space
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/603 b/gitlab/issues_text/target_missing/host_missing/accel_missing/603
new file mode 100644
index 00000000..91ec0d63
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/603
@@ -0,0 +1 @@
+Unable to use mps2-an386 machine with qemu-6.0.0 version code
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/604 b/gitlab/issues_text/target_missing/host_missing/accel_missing/604
new file mode 100644
index 00000000..6ff8faec
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/604
@@ -0,0 +1 @@
+QEMU crashes with "-global driver=isa-fdc"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/605 b/gitlab/issues_text/target_missing/host_missing/accel_missing/605
new file mode 100644
index 00000000..43b84900
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/605
@@ -0,0 +1,15 @@
+QEMU crashes when receiving network connection on NetBSD
+Description of problem:
+After booting the VM, connecting to the TCP port 2222 of the host immediately crashes the VM and qemu prints:
+
+**
+Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0)
+Bail out! Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0)
+Steps to reproduce:
+1. start VM as indicated
+2. telnet localhost 2222
+3. crash
+Additional information:
+**
+Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0)
+Bail out! Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/606 b/gitlab/issues_text/target_missing/host_missing/accel_missing/606
new file mode 100644
index 00000000..c534ac3e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/606
@@ -0,0 +1 @@
+Gtk: gtk_clipboard_set_with_data: assertion 'targets != NULL' failed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/607 b/gitlab/issues_text/target_missing/host_missing/accel_missing/607
new file mode 100644
index 00000000..7b9ea684
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/607
@@ -0,0 +1,59 @@
+socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.
+Description of problem:
+
+Steps to reproduce:
+1. Run Qemu command line 
+2. Start console in virt-manager
+Additional information:
+_/var/log/libvirt/qemu_
+
+```
+2021-09-08 13:08:22.003+0000: starting up libvirt version: 7.6.0, qemu version: 6.1.0, kernel: 5.4.143-1-MANJARO, hostname: pjehrsohmehj
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \
+HOME=/var/lib/libvirt/qemu/domain-81-Vagrant_default \
+XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-81-Vagrant_default/.local/share \
+XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-81-Vagrant_default/.cache \
+XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-81-Vagrant_default/.config \
+/usr/bin/qemu-system-x86_64 \
+-name guest=Vagrant_default,debug-threads=on \
+-S \
+-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-81-Vagrant_default/master-key.aes"}' \
+-machine pc-i440fx-6.1,accel=kvm,usb=off,dump-guest-core=off,memory-backend=pc.ram \
+-cpu Snowridge,ss=on,vmx=on,hypervisor=on,tsc-adjust=on,mpx=on,rdpid=on,md-clear=on,stibp=on,xsaves=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,rdctl-no=on,ibrs-all=on,skip-l1dfl-vmentry=on,mds-no=on,pschange-mc-no=on,clwb=off,gfni=off,cldemote=off,movdiri=off,movdir64b=off,core-capability=off,split-lock-detect=off \
+-m 512 \
+-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":536870912}' \
+-overcommit mem-lock=off \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid cde944bb-cfc2-473b-b605-580382c3f944 \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=32,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/Zelec-VAGRANTSLASH-manjarolinux_vagrant_box_image_20210901.1551100290_box.img","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-2-format","read-only":true,"driver":"qcow2","file":"libvirt-2-storage","backing":null}' \
+-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/Vagrant_default.img","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"}' \
+-device virtio-blk-pci,bus=pci.0,addr=0x3,drive=libvirt-1-format,id=virtio-disk0,bootindex=1 \
+-netdev tap,fd=34,id=hostnet0,vhost=on,vhostfd=35 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:cf:27:78,bus=pci.0,addr=0x5 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-audiodev id=audio1,driver=none \
+-vnc 127.0.0.1:0,audiodev=audio1 \
+-k en-us \
+-device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
+char device redirected to /dev/pts/0 (label charserial0)
+2021-09-08T13:08:22.188784Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12]
+2021-09-08T13:08:22.188905Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13]
+qemu-system-x86_64: ../qemu-6.1.0/util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.
+2021-09-08 13:08:28.059+0000: shutting down, reason=crashed
+2
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/608 b/gitlab/issues_text/target_missing/host_missing/accel_missing/608
new file mode 100644
index 00000000..1e42c7f2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/608
@@ -0,0 +1 @@
+incremental_live_backup:  Error prompt info when do incremental backup with an invalid "bitmap-mode"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/609 b/gitlab/issues_text/target_missing/host_missing/accel_missing/609
new file mode 100644
index 00000000..41bd5327
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/609
@@ -0,0 +1,9 @@
+Can't build system emulation with static on qemu 6.1
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/610 b/gitlab/issues_text/target_missing/host_missing/accel_missing/610
new file mode 100644
index 00000000..ee7537a7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/610
@@ -0,0 +1,31 @@
+after upgrade to 6.1.0, snapshot creation fails with "pre-save failed: qxl"
+Description of problem:
+When trying to create a snapshot using `virsh --connect qemu:///system snapshot-create-as <domain-name> <snapshot-name>` or virt-manager GUI, I get the following error:
+
+```
+Error: Error while writing VM state: Unknown error -1
+
+
+Traceback (most recent call last):
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
+    callback(asyncjob, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/details/snapshots.py", line 237, in _do_create_snapshot
+    self.vm.create_snapshot(xml)
+  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1124, in create_snapshot
+    self._backend.snapshotCreateXML(xml, flags)
+  File "/usr/lib/python3.9/site-packages/libvirt.py", line 3059, in snapshotCreateXML
+    raise libvirtError('virDomainSnapshotCreateXML() failed')
+libvirt.libvirtError: operation failed: Failed to take snapshot: pre-save failed: qxl
+Error: Error while writing VM state: Unknown error -1
+```
+Additional information:
+I'm using Arch Linux distro packages.
+The issue appeared after upgrading qemu-headless from 6.0.0 to 6.1.0.
+Downgrading back to 6.0.0 fixes the problem (snapshot are created
+successfully and work as expected).
+
+In a reply to my message to libvirt-users describing the issue [1],
+Daniel P. Berrangé confirmed that the error comes from QEMU and
+recommended reporting it here.
+
+[1] https://listman.redhat.com/archives/libvirt-users/2021-September/msg00007.html
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/611 b/gitlab/issues_text/target_missing/host_missing/accel_missing/611
new file mode 100644
index 00000000..bc25d9ed
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/611
@@ -0,0 +1,127 @@
+qemu-system-m68k: hw/scsi/scsi-disk.c  assertion failure
+Description of problem:
+QEMU assertion failure (crash):
+qemu-system-m68k: ../hw/scsi/scsi-disk.c:550: scsi_write_data: Assertion `r->req.aiocb == NULL' failed.
+Steps to reproduce:
+```
+$ xz -d initramfs-stress-ng.cpio.xz vmlinux-5.14-multi.xz
+$ cat rootfs.ext2.xz-part? | xz -dc > rootfs.ext2
+$ qemu-system-m68k -M q800 -m 128M -serial none -serial mon:stdio -g 800x600x4 -rtc base=localtime -drive file=rootfs.ext2,format=raw -kernel vmlinux-5.14-multi -append "console=ttyS0" -initrd initramfs-stress-ng.cpio 
+
+ABCFGHIJK
+[    0.000000] Linux version 5.14.0-multi (fthain@nippy) (m68k-linux-gnu-gcc (btc) 6.4.0, GNU ld (btc) 2.28) #5 Sat Sep 4 16:09:41 AEST 2021
+[    0.000000] Saving 140 bytes of bootinfo
+[    0.000000] Detected Macintosh model: 35
+[    0.000000] Apple Macintosh Quadra 800
+[    0.000000] Zone ranges:
+[    0.000000]   DMA      [mem 0x0000000000000000-0x0000007fffffffff]
+[    0.000000]   Normal   empty
+[    0.000000] Movable zone start for each node
+[    0.000000] Early memory node ranges
+[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000007ffffff]
+[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
+[    0.000000] initrd: 07d3e000 - 07fff600
+[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 32480
+[    0.000000] Kernel command line: console=ttyS0
+[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
+[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
+[    0.000000] Sorting __ex_table...
+[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
+[    0.000000] Memory: 121420K/131072K available (4074K kernel code, 327K rwdata, 752K rodata, 148K init, 117K bss, 9652K reserved, 0K cma-reserved)
+[    0.000000] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
+[    0.000000] NR_IRQS: 200
+[    0.000000] clocksource: via1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 2439823894983 ns
+[    0.000000] Console: colour dummy device 80x25
+[    0.010000] printk: console [ttyS0] enabled
+[    0.020000] Calibrating delay loop... 841.31 BogoMIPS (lpj=4206592)
+[    0.110000] pid_max: default: 32768 minimum: 301
+[    0.110000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
+[    0.110000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
+[    0.150000] devtmpfs: initialized
+[    0.160000] random: get_random_u32 called from bucket_table_alloc.isra.28+0x70/0x1a6 with crng_init=0
+[    0.160000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+[    0.160000] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
+[    0.160000] NET: Registered PF_NETLINK/PF_ROUTE protocol family
+[    0.170000] DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
+[    0.170000] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
+[    0.200000] wait_for_initramfs() called before rootfs_initcalls
+[    0.220000] NuBus: Scanning NuBus slots.
+[    0.220000] Slot 9: Board resource not found!
+[    0.220000] SCSI subsystem initialized
+[    0.240000] clocksource: Switched to clocksource via1
+[    0.260000] NET: Registered PF_INET protocol family
+[    0.260000] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
+[    0.270000] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
+[    0.270000] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
+[    0.270000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
+[    0.270000] TCP: Hash tables configured (established 1024 bind 1024)
+[    0.270000] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
+[    0.270000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
+[    0.270000] NET: Registered PF_UNIX/PF_LOCAL protocol family
+[    0.280000] RPC: Registered named UNIX socket transport module.
+[    0.280000] RPC: Registered udp transport module.
+[    0.280000] RPC: Registered tcp transport module.
+[    0.280000] RPC: Registered tcp NFSv4.1 backchannel transport module.
+[    0.290000] Trying to unpack rootfs image as initramfs...
+[    0.290000] workingset: timestamp_bits=30 max_order=15 bucket_order=0
+[    0.310000] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
+[    0.310000] io scheduler mq-deadline registered
+[    0.310000] macfb: framebuffer at 0xf9001000, mapped to 0x(ptrval), size 234k
+[    0.310000] macfb: mode is 800x600x4, linelength=400
+[    0.330000] Console: switching to colour frame buffer device 100x37
+[    0.350000] fb0: DAFB frame buffer device
+[    0.350000] pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
+[    0.350000] scc.0: ttyS0 at MMIO 0x5000c022 (irq = 4, base_baud = 230400) is a Z85c30 ESCC - Serial port
+[    0.350000] scc.1: ttyS1 at MMIO 0x5000c020 (irq = 4, base_baud = 230400) is a Z85c30 ESCC - Serial port
+[    0.350000] Non-volatile memory driver v1.3
+[    0.390000] brd: module loaded
+[    0.390000] adb: Mac II ADB Driver v1.0 for Unified ADB
+[    0.410000] Detected ADB keyboard, type ANSI.
+[    0.410000] input: ADB keyboard as /devices/virtual/input/input0
+[    0.420000] random: fast init done
+[    0.420000] input: ADB mouse as /devices/virtual/input/input1
+[    0.430000] Freeing initrd memory: 2820K
+[    0.430000] mac_esp: using PDMA for controller 0
+[    0.430000] mac_esp mac_esp.0: esp0: regs[(ptrval):0] irq[19]
+[    0.430000] mac_esp mac_esp.0: esp0: is a ESP236, 16 MHz (ccf=4), SCSI ID 7
+[    3.520000] scsi host0: esp
+[    3.530000] scsi 0:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
+[    3.540000] scsi target0:0:0: Beginning Domain Validation
+[    3.540000] scsi target0:0:0: Domain Validation skipping write tests
+[    3.540000] scsi target0:0:0: Ending Domain Validation
+[    3.550000] scsi 0:0:2:0: CD-ROM            QEMU     QEMU CD-ROM      2.5+ PQ: 0 ANSI: 5
+[    3.550000] scsi target0:0:2: Beginning Domain Validation
+[    3.560000] scsi target0:0:2: Domain Validation skipping write tests
+[    3.560000] scsi target0:0:2: Ending Domain Validation
+[    3.560000] sr 0:0:2:0: Power-on or device reset occurred
+[    3.570000] sr 0:0:2:0: [sr0] scsi3-mmc drive: 16x/50x cd/rw xa/form2 cdda tray
+[    3.570000] cdrom: Uniform CD-ROM driver Revision: 3.20
+[    3.570000] sd 0:0:0:0: Power-on or device reset occurred
+[    3.580000] sd 0:0:0:0: [sda] 322560 512-byte logical blocks: (165 MB/158 MiB)
+[    3.580000] sd 0:0:0:0: [sda] Write Protect is off
+[    3.580000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+[    3.590000] sd 0:0:0:0: Attached scsi generic sg0 type 0
+[    3.590000] sr 0:0:2:0: Attached scsi generic sg1 type 5
+[    3.590000] Onboard/comm-slot SONIC, revision 0x0004, 32 bit DMA, register offset 2
+[    3.590000] SONIC ethernet @50f0a000, MAC 08:00:07:12:34:56, IRQ 3
+[    3.600000] sd 0:0:0:0: [sda] Attached SCSI disk
+[    3.610000] aoe: AoE v85 initialised.
+[    3.610000] mousedev: PS/2 mouse device common for all mice
+[    3.610000] rtc-generic rtc-generic: registered as rtc0
+[    3.620000] NET: Registered PF_PACKET protocol family
+[    3.630000] Freeing unused kernel image (initmem) memory: 148K
+[    3.630000] This architecture does not have kernel memory protection.
+[    3.630000] Run /init as init process
+/init: line 11: ifconfig: not found
+# mount /dev/sda /mnt
+[    9.030000] EXT4-fs (sda): mounting ext2 file system using the ext4 subsystem
+[    9.080000] EXT4-fs (sda): mounted filesystem without journal. Opts: (null). Quota mode: disabled.
+# cd /mnt
+# /root/stress-ng --mmap -1 --mmap-file --mmap-bytes=100%
+stress-ng: info:  [42] defaulting to a 86400 second (1 day, 0.00 secs) run per stressor
+stress-ng: info:  [42] dispatching hogs: 1 mmap
+qemu-system-m68k: ../hw/scsi/scsi-disk.c:550: scsi_write_data: Assertion `r->req.aiocb == NULL' failed.
+Aborted
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/614 b/gitlab/issues_text/target_missing/host_missing/accel_missing/614
new file mode 100644
index 00000000..1d5bf40f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/614
@@ -0,0 +1 @@
+Newly introduced dependency on GCC 7.5.0 should allow any version of GCC 7
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/615 b/gitlab/issues_text/target_missing/host_missing/accel_missing/615
new file mode 100644
index 00000000..d69e499b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/615
@@ -0,0 +1,10 @@
+Not sure if this is a qemu issue but SD card is not correctly read. blk_update_request: I/O error on Manjaro libvirt OS.
+Description of problem:
+
+Steps to reproduce:
+1. Run vagrant command line 
+2. Start console in virt-manager
+3. Add USB SD card reader device with SD card.
+4. Go back to console
+Additional information:
+I've bought a new SD card reader and SD card, tried it on other ports and the problem persists.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/617 b/gitlab/issues_text/target_missing/host_missing/accel_missing/617
new file mode 100644
index 00000000..98d93731
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/617
@@ -0,0 +1,26 @@
+USB passthrough with Conbee 2 failing after upgrade to Fedora 34 / Libvirt 7.0.0
+Description of problem:
+Hi,
+
+I upgraded recently from Fedora 32 to 34.
+
+For a little under a year, I've been running reliably a Home Assistant instance with Deconz add-on in a VM, with a Conbee 2 zigbee gateway in USB passthrough, controlling about 15 devices (door/window sensors, thermometers, leak sensors and push buttons).
+
+It has worked flawlessly but stopped working after upgrading Fedora. The Conbee shows up on the Linux guest but the serial can't be read by the Deconz application and it just does not work, the app can't get past the device connection screen.
+
+This is the state of what works and what doesn't:
+
+- Home Assistant Linux VM: NOK
+- Ubuntu Linux 20.04 VM: NOK
+- Windows 10 VM: NOK
+- Windows 10 physical machine: OK, can connect and pair a door sensor
+
+All running the latest Deconz app.
+
+The fact that the physical Windows machine works excludes a bricked device. I used the physical Windows to upgrade the Conbee 2 firmware with no improvement. 
+
+This does not seem to be an isolated issue: https://old.reddit.com/r/homeassistant/comments/o04sgw/conbee_ii_usb_passthrough_with_libvirt_660/
+
+Apologies if this has already been reported. Let me know what kind of logs you might want.
+
+Thanks!
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/62 b/gitlab/issues_text/target_missing/host_missing/accel_missing/62
new file mode 100644
index 00000000..f6dd0070
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/62
@@ -0,0 +1 @@
+[OSS-Fuzz] ahci: stack overflow in ahci_cond_start_engines
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/621 b/gitlab/issues_text/target_missing/host_missing/accel_missing/621
new file mode 100644
index 00000000..1dd7649e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/621
@@ -0,0 +1 @@
+make after configure not working
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/623 b/gitlab/issues_text/target_missing/host_missing/accel_missing/623
new file mode 100644
index 00000000..6da54906
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/623
@@ -0,0 +1,8 @@
+Allow direct access to windows disks on hyper-V as well as virtiofsd, DAX
+Additional information:
+Depends on, first needs fixing of, Issue #346 / Issue #430 , Essentially accel=whpx is not working/is broken/has regression.
+```
+J:\>E:\scoopg\shims\qemu-system-x86_64.exe --version
+QEMU emulator version 6.1.0 (v6.1.0-11882-g7deea770bf-dirty)
+Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/630 b/gitlab/issues_text/target_missing/host_missing/accel_missing/630
new file mode 100644
index 00000000..1777d5a7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/630
@@ -0,0 +1 @@
+ubuntu-18.04-s390x-all  job timeouts at 1h
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/631 b/gitlab/issues_text/target_missing/host_missing/accel_missing/631
new file mode 100644
index 00000000..6328d70d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/631
@@ -0,0 +1,25 @@
+QEMU locks out user interface after waking from laptop sleep
+Description of problem:
+If qemu is started on laptop from command line and set to full screen, screen activated with mouse click, then put to sleep by closing lid; after waking up by opening lid the user interface locks out, the mouse cursor doesn't show, mouse clicks and keys are unresponsive.
+
+A Ctrl-ALt-Fn terminal must then be used to locate and kill the qemu process. After which the system can recover if it is terminated. The system tends to be affected in other ways such as wifi being disabled and needs to manually enabled after. So it looks like it disrupts the system from fully restoring the awoken state.
+
+The terminal from which QEMU is running is also filled with debug output. The issue looks to be caused by the SDL backend not knowing what to do with a wake up code. The terminal window is filled with the following text: 
+`The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL forums/mailing list <https://discourse.libsdl.org/> X11 KeyCode 151 (143), X11 KeySym 0x1008FF2B (XF86WakeUp).`
+
+I have reduced the steps causing the bug to as little as needed with low dependencies.
+Steps to reproduce:
+1. Using a laptop, start a qemu session in full screen like so:
+  `./qemu-system-ppc -machine mac99,via=pmu -serial stdio -full-screen`
+2. Shut the lid so it sleeps.
+3. Shortly after open the lid.
+Additional information:
+I downloaded the 6.1.0 stable build and compiled it myself.
+
+The SDL issue appears to be low priority. I found some reports here but see no evidence of it being discussed.
+https://discourse.libsdl.org/t/key-not-recognised-by-sdl/24181
+
+
+
+
+![Screenshot_from_2021-09-21_22-56-13](/uploads/e2e7e80adcc3d562235a734aa8bad67b/Screenshot_from_2021-09-21_22-56-13.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/632 b/gitlab/issues_text/target_missing/host_missing/accel_missing/632
new file mode 100644
index 00000000..d119846f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/632
@@ -0,0 +1 @@
+We should document "make install DESTDIR=wherever"
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/634 b/gitlab/issues_text/target_missing/host_missing/accel_missing/634
new file mode 100644
index 00000000..37ae497a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/634
@@ -0,0 +1,81 @@
+usbredir: assertion failure after suspend/resume when stopped
+Description of problem:
+Accessing a USB smart card ([Yubikey 5 NFC](https://www.yubico.com/product/yubikey-5-nfc/)) from the guest after host suspend/resume while the guest is stopped and the device is redirected causes QEMU to crash with "Segmentation fault" (with master) or the assertion failure (with Debian 1:6.1+dfsg-5):
+
+    qemu-system-x86_64: ../../hw/usb/core.c:470: usb_packet_complete_one: Assertion `p->stream || QTAILQ_FIRST(&ep->queue) == p' failed.
+Steps to reproduce:
+1. Run `qemu-system-x86_64` with command line listed above.
+2. Run `remote-viewer spice://localhost:3001` in another terminal.
+3. Redirect the smart card to the guest in remote-viewer.
+4. Run `gpg --card-status` in the guest.
+5. Run `stop` in the QEMU monitor.
+6. Run `rtcwake --mode mem --seconds 1` as root to suspend the host to S3, then resume. (or `ehco mem >/sys/power/state` or `systemctl suspend` then wake manually)
+7. Run `cont` in QEMU monitor to resume the guest.
+8. Stop redirecting the smart card to the guest in remote-viewer.
+9. Start redirecting the smart card to the guest in remote-viewer.
+10. Run `gpg --card-status` in the guest.  Repeat if necessary.
+
+Note that after step 7 the train has left the rails.  Executing `gpg --card-status` in the guest at this point would print:
+
+    gpg: selecting card failed: no such device
+    gpg: OpenPGP card not available: no such device
+
+However, stopping and resuming redirection appears to be necessary to trigger the assertion failure.
+
+Also note that on Windows, it's not necessary to execute any `gpg` commands.  QEMU will hit the assertion failure after step 9.
+Additional information:
+<details>
+<summary>backtrace with version built from 2c3e83f92d</summary>
+
+    Program terminated with signal SIGSEGV, Segmentation fault.
+    #0  0x00005623c09a5754 in usb_handle_packet
+        (dev=0x5623c3592500, p=p@entry=0x7f92e43c81c8) at ../hw/usb/core.c:441
+    #1  0x00005623c09be239 in xhci_submit
+        (epctx=<optimized out>, xfer=<optimized out>, xhci=<optimized out>)
+        at ../hw/usb/hcd-xhci.c:1783
+    #2  xhci_fire_transfer
+        (epctx=<optimized out>, xfer=<optimized out>, xhci=<optimized out>)
+        at ../hw/usb/hcd-xhci.c:1792
+    #3  xhci_kick_epctx (epctx=0x7f92e43c7c30, streamid=0)
+        at ../hw/usb/hcd-xhci.c:1951
+    #4  0x00005623c09bea1b in xhci_kick_ep
+        (xhci=<optimized out>, slotid=<optimized out>, epid=<optimized out>, streamid=<optimized out>) at ../hw/usb/hcd-xhci.c:1817
+    #5  0x00005623c09bebd8 in xhci_doorbell_write
+        (ptr=0x7f92ec137970, reg=1, val=4, size=<optimized out>)
+        at ../hw/usb/hcd-xhci.c:3118
+    #6  0x00005623c0abbc7f in memory_region_write_accessor
+        (mr=mr@entry=0x7f92ec137ed0, addr=4, value=value@entry=0x7f92eda403e8, size=size@entry=4, shift=<optimized out>, mask=mask@entry=4294967295, attrs=...)
+        at ../softmmu/memory.c:492
+    #7  0x00005623c0ab953e in access_with_adjusted_size
+        (addr=addr@entry=4, value=value@entry=0x7f92eda403e8, size=size@entry=4, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=
+        0x5623c0abbc00 <memory_region_write_accessor>, mr=0x7f92ec137ed0, attrs=...) at ../softmmu/memory.c:554
+    #8  0x00005623c0abd650 in memory_region_dispatch_write
+        (mr=mr@entry=0x7f92ec137ed0, addr=4, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../softmmu/memory.c:1511
+    #9  0x00005623c0aad417 in flatview_write_continue
+        (fv=fv@entry=0x7f92e43c7140, addr=addr@entry=4227932164, attrs=attrs@entry=..., ptr=ptr@entry=0x7f92ef17f028, len=len@entry=4, addr1=<optimized out>, l=<optimized out>, mr=0x7f92ec137ed0)
+        at /home/kevin/tmp/qemu/include/qemu/host-utils.h:165
+    #10 0x00005623c0ab09db in flatview_write
+        (len=4, buf=0x7f92ef17f028, attrs=..., addr=4227932164, fv=0x7f92e43c7140)
+        at ../softmmu/physmem.c:2820
+    #11 address_space_write
+        (as=<optimized out>, addr=4227932164, attrs=..., buf=buf@entry=0x7f92ef17f028, len=4) at ../softmmu/physmem.c:2912
+    #12 0x00005623c0ab0a9f in address_space_rw
+        (as=<optimized out>, addr=<optimized out>, attrs=..., 
+        attrs@entry=..., buf=buf@entry=0x7f92ef17f028, len=<optimized out>, is_write=<optimized out>) at ../softmmu/physmem.c:2922
+    #13 0x00005623c0ba2890 in kvm_cpu_exec (cpu=cpu@entry=0x5623c2729bc0)
+        at ../accel/kvm/kvm-all.c:2893
+    #14 0x00005623c0ba3bbd in kvm_vcpu_thread_fn (arg=arg@entry=0x5623c2729bc0)
+        at ../accel/kvm/kvm-accel-ops.c:49
+    #15 0x00005623c0d0a959 in qemu_thread_start (args=0x7f92eda40610)
+        at ../util/qemu-thread-posix.c:557
+    #16 0x00007f92fd431eae in start_thread (arg=0x7f92eda45640)
+        at pthread_create.c:463
+    #17 0x00007f92fca2fa5f in clone ()
+        at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
+
+</details>
+
+Let me know if there are any additional logs or information that would be useful.
+
+Thanks,\
+Kevin
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/637 b/gitlab/issues_text/target_missing/host_missing/accel_missing/637
new file mode 100644
index 00000000..f8264de1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/637
@@ -0,0 +1,4 @@
+qemu drive-mirror live migration sparse copy
+Additional information:
+Please reference this Proxmox post where the developers mention this feature not being available:
+https://forum.proxmox.com/threads/migration-on-lvm-thin.50429/
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/640 b/gitlab/issues_text/target_missing/host_missing/accel_missing/640
new file mode 100644
index 00000000..a0e70319
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/640
@@ -0,0 +1,6 @@
+qemu-system-x86_64 behaving as 32 bits
+Description of problem:
+Qemu is throwing the error ```file '/grub/i386-pc/normal.mod' not found.``` and going into rescue mode while booting my pendrive with a dual boot installation from scratch from [link](https://wiki.archlinux.org/title/Multiboot_USB_drive).
+The files like normal.mod aren't in the i386-pc folder because it's a x86 architecture install. The path it was supposed to see it is ```/grub/x86_64-efi/normal.mod```
+Additional information:
+![image](/uploads/7700f57c0818f6063e4388fe394538ad/image.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/642 b/gitlab/issues_text/target_missing/host_missing/accel_missing/642
new file mode 100644
index 00000000..131e354f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/642
@@ -0,0 +1,4 @@
+Slow QEMU I/O on macOS host
+Description of problem:
+QEMU on macOS host gives very low I/O speed. Tested with fio tool, compared to linux host
+Tested on QEMU v6.1.0, and the recent master
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/643 b/gitlab/issues_text/target_missing/host_missing/accel_missing/643
new file mode 100644
index 00000000..ceaa06cd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/643
@@ -0,0 +1 @@
+how to add include path and library path when building qemu-4.1.1
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/645 b/gitlab/issues_text/target_missing/host_missing/accel_missing/645
new file mode 100644
index 00000000..4837836f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/645
@@ -0,0 +1 @@
+Centos6.8 compiling qeum-2.12.0 failed, Does centos6.8 not support qeum-2.12.0?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/646 b/gitlab/issues_text/target_missing/host_missing/accel_missing/646
new file mode 100644
index 00000000..b462ef18
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/646
@@ -0,0 +1,18 @@
+Infinite loop in xhci_ring_chain_length() in hw/usb/hcd-xhci.c (CVE-2020-14394)
+Description of problem:
+An infinite loop issue was found in the USB xHCI controller emulation of QEMU. Specifically, function `xhci_ring_chain_length()` in hw/usb/hcd-xhci.c may get stuck while fetching empty TRBs from guest memory, since the exit conditions of the loop depend on values that are fully controlled by guest. A privileged guest user may exploit this issue to hang the QEMU process on the host, resulting in a denial of service.
+Steps to reproduce:
+Build and load `xhci.ko` from within the guest:
+
+1) make
+2) insmod xhci.ko
+
+[Makefile](/uploads/98dbf7b4facc9b100817b3c8f63b5cb2/Makefile)
+
+[usb-xhci.h](/uploads/f225524b1553d8cf6c1dfa89369b6edc/usb-xhci.h)
+
+[xhci.c](/uploads/c635f742d12a2bba6ea472ddfe006d56/xhci.c)
+Additional information:
+This issue was reported by Gaoning Pan (Zhejiang University) and Xingwei Li (Ant Security Light-Year Lab).
+
+RH bug: https://bugzilla.redhat.com/show_bug.cgi?id=1908004.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/647 b/gitlab/issues_text/target_missing/host_missing/accel_missing/647
new file mode 100644
index 00000000..c50c0bde
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/647
@@ -0,0 +1,301 @@
+scsi_device_purge_requests() waits infinietly
+Description of problem:
+QEMU hangs typing `system_reset` in the monitor, the monitor becomes unresponsive, as does VNC.
+Steps to reproduce:
+1. In the guest as root: `dd if=/dev/sda ibs=2K obs=1M of=/dev/null`
+2. In the host monitor: `(qemu) system_reset`
+3. Attach with gdb
+4. Press ^C in the unresponsive monitor
+```
+Thread 1 "qemu-system-x86" received signal SIGINT, Interrupt.
+0x00007ffff749796e in ppoll () from /lib64/libc.so.6
+(gdb) bt
+#0  0x00007ffff749796e in ppoll () at /lib64/libc.so.6
+#1  0x00005555570e829a in ppoll ()
+#2  0x0000555559624473 in qemu_poll_ns (fds=0x6060000204e0, nfds=1, timeout=-1) at ../util/qemu-timer.c:336
+#3  0x0000555559651973 in fdmon_poll_wait (ctx=0x61300004d900, ready_list=0x7fffffffb200, timeout=-1) at ../util/fdmon-poll.c:80
+#4  0x00005555595f48f1 in aio_poll (ctx=0x61300004d900, blocking=true) at ../util/aio-posix.c:607
+#5  0x0000555559041dac in bdrv_do_drained_begin (bs=0x62900000a200, recursive=false, parent=0x0, ignore_bds_parents=false, poll=true) at ../block/io.c:473
+#6  0x00005555590414a3 in bdrv_drained_begin (bs=0x62900000a200) at ../block/io.c:479
+#7  0x000055555916f180 in blk_drain (blk=0x618000001080) at ../block/block-backend.c:1732
+#8  0x000055555778f140 in scsi_device_purge_requests (sdev=0x617000004d80, sense=...) at ../hw/scsi/scsi-bus.c:1638
+#9  0x0000555557842df9 in scsi_disk_reset (dev=0x617000004d80) at ../hw/scsi/scsi-disk.c:2248
+#10 0x00005555592a557e in device_transitional_reset (obj=0x617000004d80) at ../hw/core/qdev.c:1028
+#11 0x00005555592a7eb7 in resettable_phase_hold (obj=0x617000004d80, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:182
+#12 0x000055555928a2e8 in bus_reset_child_foreach (obj=0x62d0000268d8, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/bus.c:97
+#13 0x00005555592aaaac in resettable_child_foreach (rc=0x60e000026f40, obj=0x62d0000268d8, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96
+#14 0x00005555592a7b9a in resettable_phase_hold (obj=0x62d0000268d8, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173
+#15 0x00005555592a1c55 in device_reset_child_foreach (obj=0x62d000026680, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/qdev.c:366
+#16 0x00005555592aaaac in resettable_child_foreach (rc=0x60e000040a80, obj=0x62d000026680, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96
+#17 0x00005555592a7b9a in resettable_phase_hold (obj=0x62d000026680, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173
+#18 0x000055555928a2e8 in bus_reset_child_foreach (obj=0x62d0000265f8, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/bus.c:97
+#19 0x00005555592aaaac in resettable_child_foreach (rc=0x60e000026680, obj=0x62d0000265f8, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96
+#20 0x00005555592a7b9a in resettable_phase_hold (obj=0x62d0000265f8, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173
+#21 0x00005555592a1c55 in device_reset_child_foreach (obj=0x62d00001e400, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/qdev.c:366
+#22 0x00005555592aaaac in resettable_child_foreach (rc=0x60e000042300, obj=0x62d00001e400, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96
+#23 0x00005555592a7b9a in resettable_phase_hold (obj=0x62d00001e400, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173
+#24 0x000055555928a2e8 in bus_reset_child_foreach (obj=0x62200005c260, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/bus.c:97
+#25 0x00005555592aaaac in resettable_child_foreach (rc=0x60e00002e2c0, obj=0x62200005c260, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96
+#26 0x00005555592a7b9a in resettable_phase_hold (obj=0x62200005c260, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173
+#27 0x00005555592a1c55 in device_reset_child_foreach (obj=0x62200005b900, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/qdev.c:366
+#28 0x00005555592aaaac in resettable_child_foreach (rc=0x60e000030940, obj=0x62200005b900, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96
+#29 0x00005555592a7b9a in resettable_phase_hold (obj=0x62200005b900, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173
+#30 0x000055555928a2e8 in bus_reset_child_foreach (obj=0x61d00008a280, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/bus.c:97
+#31 0x00005555592aaaac in resettable_child_foreach (rc=0x60e00002e2c0, obj=0x61d00008a280, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96
+#32 0x00005555592a7b9a in resettable_phase_hold (obj=0x61d00008a280, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173
+#33 0x00005555592a1c55 in device_reset_child_foreach (obj=0x62a000006200, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/qdev.c:366
+#34 0x00005555592aaaac in resettable_child_foreach (rc=0x60e000030160, obj=0x62a000006200, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96
+#35 0x00005555592a7b9a in resettable_phase_hold (obj=0x62a000006200, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173
+#36 0x000055555928a2e8 in bus_reset_child_foreach (obj=0x60c000020a40, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/bus.c:97
+#37 0x00005555592aaaac in resettable_child_foreach (rc=0x60e00002fde0, obj=0x60c000020a40, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96
+#38 0x00005555592a7b9a in resettable_phase_hold (obj=0x60c000020a40, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173
+#39 0x00005555592a6e04 in resettable_assert_reset (obj=0x60c000020a40, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:60
+#40 0x00005555592a6cb7 in resettable_reset (obj=0x60c000020a40, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:45
+#41 0x00005555592a9337 in resettable_cold_reset_fn (opaque=0x60c000020a40) at ../hw/core/resettable.c:269
+#42 0x00005555592a6c35 in qemu_devices_reset () at ../hw/core/reset.c:69
+#43 0x00005555582fb4f5 in pc_machine_reset (machine=0x616000000380) at ../hw/i386/pc.c:1764
+#44 0x0000555558a58e56 in qemu_system_reset (reason=SHUTDOWN_CAUSE_HOST_QMP_SYSTEM_RESET) at ../softmmu/runstate.c:443
+#45 0x0000555558a5a746 in main_loop_should_exit () at ../softmmu/runstate.c:688
+#46 0x0000555558a5a57e in qemu_main_loop () at ../softmmu/runstate.c:722
+#47 0x00005555571acaef in main (argc=58, argv=0x7fffffffd8f8, envp=0x7fffffffdad0) at ../softmmu/main.c:50
+(gdb) 
+(gdb) fr 5
+#5  0x0000555559041dac in bdrv_do_drained_begin (bs=0x62900000a200, recursive=false, parent=0x0, ignore_bds_parents=false, poll=true) at ../block/io.c:473
+473             BDRV_POLL_WHILE(bs, bdrv_drain_poll_top_level(bs, recursive, parent));
+(gdb) p *bs
+$1 = {open_flags = 24578, encrypted = false, sg = false, probed = false, force_share = false, implicit = false, drv = 0x55555b0b0c60 <bdrv_qcow2>, opaque = 0x615000015200, aio_context = 0x6130000df080, 
+  aio_notifiers = {lh_first = 0x0}, walking_aio_notifiers = false, filename = "nvme://0000:bc:00.0/1", '\000' <repeats 4074 times>, backing_file = '\000' <repeats 4095 times>, 
+  auto_backing_file = '\000' <repeats 4095 times>, backing_format = '\000' <repeats 15 times>, full_open_options = 0x621002ba2100, exact_filename = "nvme://0000:bc:00.0/1", '\000' <repeats 4074 times>, 
+  backing = 0x0, file = 0x608000002ba0, bl = {request_alignment = 1, max_pdiscard = 0, pdiscard_alignment = 65536, max_pwrite_zeroes = 0, pwrite_zeroes_alignment = 65536, opt_transfer = 0, 
+    max_transfer = 131072, max_hw_transfer = 0, min_mem_alignment = 512, opt_mem_alignment = 4096, max_iov = 1024}, supported_read_flags = 0, supported_write_flags = 0, supported_zero_flags = 260, 
+  supported_truncate_flags = 2, node_name = "drive_nvme1", '\000' <repeats 20 times>, node_list = {tqe_next = 0x0, tqe_circ = {tql_next = 0x0, tql_prev = 0x6290000092d0}}, bs_list = {tqe_next = 0x0, 
+    tqe_circ = {tql_next = 0x0, tql_prev = 0x6290000092e0}}, monitor_list = {tqe_next = 0x0, tqe_circ = {tql_next = 0x0, tql_prev = 0x6290000092f0}}, refcnt = 2, op_blockers = {{
+      lh_first = 0x0} <repeats 16 times>}, inherits_from = 0x0, children = {lh_first = 0x608000002ba0}, parents = {lh_first = 0x608000003620}, options = 0x621000019100, explicit_options = 0x62100001a500, 
+  detect_zeroes = BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF, backing_blocker = 0x0, total_sectors = 41943040, write_threshold_offset = 0, dirty_bitmap_mutex = {lock = {__data = {__lock = 0, __count = 0, __owner = 0, 
+        __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, file = 0x0, line = 0, initialized = true}, 
+  dirty_bitmaps = {lh_first = 0x0}, wr_highest_offset = {value = 17686634496}, copy_on_read = 0, in_flight = 128, serialising_in_flight = 0, io_plugged = 0, enable_write_cache = 0, quiesce_counter = 1, 
+  recursive_quiesce_counter = 0, write_gen = 101, reqs_lock = {locked = 0, ctx = 0x0, from_push = {slh_first = 0x0}, to_pop = {slh_first = 0x0}, handoff = 0, sequence = 0, holder = 0x0}, tracked_requests = {
+    lh_first = 0x7ffc251b48a0}, flush_queue = {entries = {sqh_first = 0x0, sqh_last = 0x62900000e470}}, active_flush_req = false, flushed_gen = 81, never_freeze = false}
+(gdb) fr 4
+#4  0x00005555595f48f1 in aio_poll (ctx=0x61300004d900, blocking=true) at ../util/aio-posix.c:607
+607             ret = ctx->fdmon_ops->wait(ctx, &ready_list, timeout);
+(gdb) p timeout
+$5 = -1
+(gdb) p blocking
+$6 = true
+(gdb) p *ctx
+$3 = {source = {callback_data = 0x0, callback_funcs = 0x0, source_funcs = 0x55555b42d900 <aio_source_funcs>, ref_count = 2, context = 0x60f000000400, priority = 0, flags = 33, source_id = 1, 
+    poll_fds = 0x615000001790 = {0x60d000000860}, prev = 0x0, next = 0x61300004d3c0, name = 0x602000010a10 "aio-context", priv = 0x619000003830}, lock = {m = {lock = {__data = {__lock = 0, __count = 0, 
+          __owner = 0, __nusers = 0, __kind = 1, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 16 times>, "\001", '\000' <repeats 22 times>, __align = 0}, 
+      file = 0x0, line = 0, initialized = true}}, aio_handlers = {lh_first = 0x60d000000860}, deleted_aio_handlers = {lh_first = 0x0}, notify_me = 2, list_lock = {count = 4}, bh_list = {slh_first = 0x0}, 
+  bh_slice_list = {sqh_first = 0x0, sqh_last = 0x61300004d9b8}, notified = false, notifier = {rfd = 7, wfd = 7, initialized = true}, scheduled_coroutines = {slh_first = 0x0}, co_schedule_bh = 0x604000001110, 
+  thread_pool = 0x0, tlg = {tl = {0x60b00000a1d0, 0x60b00000a280, 0x60b00000a330, 0x60b00000a3e0}}, external_disable_cnt = 0, poll_disable_cnt = 0, poll_ns = 0, poll_max_ns = 0, poll_grow = 0, 
+  poll_shrink = 0, aio_max_batch = 0, poll_aio_handlers = {lh_first = 0x60d000000860}, poll_started = false, epollfd = 6, fdmon_ops = 0x55555a4ebbc0 <fdmon_poll_ops>}
+(gdb) p ctx->bh_list
+$8 = {slh_first = 0x0}
+(gdb) p ctx->bh_slice_list
+$9 = {sqh_first = 0x0, sqh_last = 0x61300004d9b8}
+(gdb) p *ctx->bh_slice_list.sqh_last 
+$11 = (struct BHListSlice *) 0x0
+(gdb) p ctx->tlg
+$12 = {tl = {0x60b00000a1d0, 0x60b00000a280, 0x60b00000a330, 0x60b00000a3e0}}
+(gdb) p timerlist_deadline_ns(ctx->tlg.tl[0])
+$14 = -1
+(gdb) p timerlist_deadline_ns(ctx->tlg.tl[1])
+$15 = -1
+(gdb) p timerlist_deadline_ns(ctx->tlg.tl[2])
+$16 = -1
+(gdb) p timerlist_deadline_ns(ctx->tlg.tl[3])
+$17 = -1
+```
+What I see is:
+- timerlistgroup_deadline_ns() -> -1
+- aio_compute_timeout() -> -1
+- aio_poll() -> -1
+
+So scsi_device_purge_requests() waits indefinitively.
+Additional information:
+```
+../configure --enable-trace-backends=log --disable-docs --enable-debug --extra-cflags='-ggdb -fPIE' --disable-user --disable-tools  --target-list=x86_64-softmmu --cc=clang --cxx=clang++ --enable-sanitizers --disable-vhost-user
+qemu 6.1.0
+
+  Directories
+                   Install prefix: /usr/local
+                   BIOS directory: share/qemu
+                    firmware path: /usr/local/share/qemu-firmware
+                 binary directory: bin
+                library directory: lib
+                 module directory: lib/qemu
+                libexec directory: libexec
+                include directory: include
+                 config directory: /usr/local/etc
+            local state directory: /usr/local/var
+                 Manual directory: share/man
+                    Doc directory: /usr/local/share/doc
+                  Build directory: /home/philmd/qemu/build
+                      Source path: /home/philmd/qemu
+                   GIT submodules: ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone slirp
+
+  Host binaries
+                              git: git
+                             make: make
+                           python: /usr/bin/python3 (version: 3.9)
+                     sphinx-build: NO
+                              gdb: /usr/bin/gdb
+                      genisoimage: /usr/bin/mkisofs
+                             smbd: "/usr/sbin/smbd"
+
+  Configurable features
+                    Documentation: NO
+            system-mode emulation: YES
+              user-mode emulation: NO
+                      block layer: YES
+                    Install blobs: YES
+                   module support: NO
+                  fuzzing support: NO
+                    Audio drivers: oss
+                   Trace backends: log
+                    QOM debugging: YES
+             vhost-kernel support: YES
+                vhost-net support: YES
+             vhost-crypto support: NO
+               vhost-scsi support: YES
+              vhost-vsock support: YES
+               vhost-user support: NO
+    vhost-user-blk server support: NO
+            vhost-user-fs support: NO
+               vhost-vdpa support: YES
+                build guest agent: YES
+
+  Compilation
+                         host CPU: x86_64
+                  host endianness: little
+                       C compiler: clang
+                  Host C compiler: clang
+                     C++ compiler: clang++
+                           CFLAGS: -O0 -g
+                         CXXFLAGS: -O0 -g
+                      QEMU_CFLAGS: -fsanitize=undefined -fsanitize=address -m64 -mcx16 -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  -ggdb -fPIE -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong
+                     QEMU_LDFLAGS: -Wl,--warn-common -fsanitize=undefined -fsanitize=address -Wl,-z,relro -Wl,-z,now -m64  -ggdb -fPIE -fstack-protector-strong
+                         profiler: NO
+     link-time optimization (LTO): NO
+                              PIE: YES
+                     static build: NO
+              malloc trim support: YES
+                       membarrier: NO
+                debug stack usage: NO
+                  mutex debugging: YES
+                 memory allocator: system
+                avx2 optimization: NO
+             avx512f optimization: NO
+                    gprof enabled: NO
+                             gcov: NO
+                 thread sanitizer: NO
+                      CFI support: NO
+                   strip binaries: NO
+                           sparse: NO
+                  mingw32 support: NO
+                     x86_64 tests: x86_64-linux-gnu-gcc via debian-amd64-cross
+
+  Targets and accelerators
+                      KVM support: YES
+                      HAX support: NO
+                      HVF support: NO
+                     WHPX support: NO
+                     NVMM support: NO
+                      Xen support: NO
+                      TCG support: YES
+                      TCG backend: native (x86_64)
+                      TCG plugins: YES
+                TCG debug enabled: YES
+                      target list: x86_64-softmmu
+                  default devices: YES
+         out of process emulation: YES
+
+  Block layer support
+                coroutine backend: ucontext
+                   coroutine pool: YES
+             Block whitelist (rw): 
+             Block whitelist (ro): 
+     Use block whitelist in tools: NO
+                   VirtFS support: NO
+            build virtiofs daemon: NO
+             Live block migration: YES
+              replication support: YES
+                    bochs support: YES
+                    cloop support: YES
+                      dmg support: YES
+                  qcow v1 support: YES
+                      vdi support: YES
+                    vvfat support: YES
+                      qed support: YES
+                parallels support: YES
+                     FUSE exports: NO
+
+  Crypto
+                     TLS priority: "NORMAL"
+                   GNUTLS support: YES
+                    GNUTLS crypto: YES
+                        libgcrypt: NO
+                           nettle: NO
+                     crypto afalg: NO
+                         rng-none: NO
+                    Linux keyring: YES
+
+  Dependencies
+                      SDL support: NO
+                SDL image support: NO
+                      GTK support: NO
+                           pixman: YES
+                      VTE support: NO
+                    slirp support: internal
+                         libtasn1: YES
+                              PAM: NO
+                    iconv support: YES
+                   curses support: YES
+                    virgl support: NO
+                     curl support: NO
+                Multipath support: NO
+                      VNC support: YES
+                 VNC SASL support: YES
+                 VNC JPEG support: YES
+                  VNC PNG support: NO
+                   brlapi support: NO
+                      vde support: NO
+                   netmap support: NO
+                Linux AIO support: NO
+           Linux io_uring support: NO
+               ATTR/XATTR support: YES
+                     RDMA support: NO
+                   PVRDMA support: NO
+                      fdt support: internal
+                libcap-ng support: NO
+                      bpf support: NO
+                    spice support: NO
+                      rbd support: NO
+                   xfsctl support: NO
+                smartcard support: NO
+                      U2F support: NO
+                           libusb: NO
+                    usb net redir: NO
+                   OpenGL support: NO
+                              GBM: NO
+                 libiscsi support: NO
+                   libnfs support: NO
+                  seccomp support: NO
+                GlusterFS support: NO
+                      TPM support: YES
+                   libssh support: NO
+                      lzo support: NO
+                   snappy support: NO
+                    bzip2 support: NO
+                    lzfse support: NO
+                     zstd support: NO
+                NUMA host support: NO
+                          libxml2: NO
+                         capstone: internal
+                  libpmem support: NO
+                libdaxctl support: NO
+                          libudev: NO
+                       FUSE lseek: NO
+   ```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/648 b/gitlab/issues_text/target_missing/host_missing/accel_missing/648
new file mode 100644
index 00000000..61b5d36b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/648
@@ -0,0 +1 @@
+util/vfio-helpers: misaligned address for struct vfio_iova_range, which requires 8 byte alignment
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/649 b/gitlab/issues_text/target_missing/host_missing/accel_missing/649
new file mode 100644
index 00000000..029f6fbf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/649
@@ -0,0 +1,8 @@
+qemu-6.1.0 causes I/O errors in VMs leading to data corruption
+Description of problem:
+after upgrading around 10 gentoo hosts from qemu-6.0.0-r53 to 6.1.0 most VMs (around 85 of 100, our VMs with PostgreSQL have 100% chance of hitting this) after some time (few minutes) will have I/O Errors, causing crashes and data corruption.
+The VMs are stored on ZFS volumes.
+Downgrading to qemu-6.0.0-r53 instantly fixes this.
+Happens on completely different hardware (quad core Xeons to 32C Epyc2).
+
+Reproducible: Always
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/65 b/gitlab/issues_text/target_missing/host_missing/accel_missing/65
new file mode 100644
index 00000000..677430a8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/65
@@ -0,0 +1 @@
+Assigning NVMe disk to a domain causes VFIO_MAP_DMA errors
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/650 b/gitlab/issues_text/target_missing/host_missing/accel_missing/650
new file mode 100644
index 00000000..96282cb9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/650
@@ -0,0 +1,24 @@
+Monitor device_add triggers deadlock when calling drain_call_rcu on QEMU >= 6.0.0
+Description of problem:
+It hangs
+Steps to reproduce:
+1. Run the QEMU:
+   ```
+   ./qemu-system-mips64 -nographic
+   ```
+2. Enter into the QEMU monitor: press ctrl-a c
+3. Execute command `device_add` without arguments:
+```
+(qemu) device_add
+```
+4. It hangs so bad that only `kill -9` helps
+Additional information:
+I didn't test versions between 4.2.0 and 6.0.0, but I can confirm that 6.0.0, 6.1.0 and the latest master pull have this bug, while version 4.2.0 doesn't have it.
+
+I've tracked the problem and found this.
+
+1. Command `device_add` calls function `drain_call_rcu`. `drain_call_rcu` waits indefinitely for drain_complete_event.
+2. Function `cpu_exec` in accel/tcg/cpu-exec.c calls `rcu_read_lock` but does not call `rcu_read_unlock()`. `cpu_exec` just spins in its inner loop.
+3. Function `call_rcu_thread` hanged in calling the `synchronize_rcu` which calls `wait_for_readers`.
+
+If I execute `stop` command in QEMU monitor before calling `device_add` command, no hang happen.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/654 b/gitlab/issues_text/target_missing/host_missing/accel_missing/654
new file mode 100644
index 00000000..818a62a5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/654
@@ -0,0 +1,23 @@
+Strace Log Output Mangled
+Description of problem:
+The syscall log entries from the strace logging capability can be interrupted by other log messages before the full syscall line is
+complete.
+This makes parsing the strace syscall lines from the log output difficult.
+Steps to reproduce:
+1. Run the supplied command with a simple dynamically linked binary, or a binary that performs mmaps
+2. Notice that the strace 'mmap' syscall log entries in the trace file are interrupted by the page log output
+Additional information:
+I have attached an example log from a dynamically linked 'hello world' binary, which demonstrates the bug in the mmap syscall strace entries. [output.trace](/uploads/88c83273582d00241fbf95af735dcc61/output.trace)
+
+
+I believe this bug caused by a couple of things:
+Firstly, in the linux-user/syscall.c file: the strace syscall entry is not output atomically, but instead split across two calls:
+The first half is at `print_syscall`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13153
+And the return value (and new line) is printed in `print_syscall_ret`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13160
+
+In the case of the mmap syscall, the function `log_page_dump` is called between these two functions resulting in the mangled log output:
+https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/mmap.c#L633
+There may be other syscalls that behave similarly, but this was noticed due to the mmap behavior.
+
+
+Internally to the `print_syscall` and `print_syscall_ret` functions, `qemu_log` is called multiple times to compose the full log entry, and it seems that it is inside `qemu_log` that the logfile lock is obtained and dropped - so theoretically another thread can output to the log during the printing of a single syscall entry between these `qemu_log` calls. I do not know if this actually happens in practice besides the mmap scenario described above.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/657 b/gitlab/issues_text/target_missing/host_missing/accel_missing/657
new file mode 100644
index 00000000..91a2240b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/657
@@ -0,0 +1 @@
+qemu no valid state has been set by load or init-program Mac OS X Tiger
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/659 b/gitlab/issues_text/target_missing/host_missing/accel_missing/659
new file mode 100644
index 00000000..8e5c77ee
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/659
@@ -0,0 +1,41 @@
+Qemu6 regression causing disabled usb controller upon usbredir device_add
+Description of problem:
+I'm encountering a nagging issue with usbredir and a windows guest, but although I did pinpoint the commit that caused the issue, I have a hard time understanding it.
+
+The issue occurs when two usbredir devices are added to a guest windows vm (any vm installed from the official iso will reproduce the issue). When the second device is added, the UHCI usb controller is disabled by windows with an error code 43 (can be seen with in the usb adapters section of the device manager).
+Steps to reproduce:
+1. take/create an intalled windows image and run it with `qemu-system-x86_64 -M pc -cpu host,hv_time,hv_synic,hv_stimer,hv_vpindex -enable-kvm -m 4096 -device piix3-usb-uhci,id=uhci -qmp tcp:127.0.0.1:4444,server=on,wait=off,ipv4 -drive <disk-parameters> --snapshot` (snapshot not necessary but useful for multiples testing to avoid side effects as the usb status sometime lingers after a shutdown, not sure why)
+2. Open windows device manager
+3. add devices via [this qmp python script](/uploads/5f2f9240dce1b55ceb148b32f3d6073c/qmp-usb-adds.py)
+Additional information:
+The commit causing the issue (everything works well when reverting it) is 7bed89958bfbf40df9ca681cefbdca63abdde39d : device_core: use `drain_call_rcu` in in `qmp_device_add`.
+
+I narrowed the problem to the unlock of the iothread: the minimum `drain_call_rcu` code that still reproduce the issue is:
+
+```c
+void drain_call_rcu(void)
+{
+     bool locked = qemu_mutex_iothread_locked();
+     if (locked) {
+         qemu_mutex_unlock_iothread();
+     }
+     usleep(50000); // time spent draining the rcu on a few slow cases.
+
+     if (locked) {
+         qemu_mutex_lock_iothread();
+     }
+}
+```
+
+About the qemu command line: The hv parameters are needed to trigger the issue I do not know why.
+
+I tried to find what was able to take advantage of the free iothread lock, but the only thing I got so far is that the iothread lock is not taken during the first drain (from the first device add), but is taken many times during the second drain by physmem's IOs (from kvm-accel, but at this point, I'm a bit lost).
+
+I'm looking for pointers as to what could trigger the issue in order to narrow it down, as, so far, I do not understand exactly what causes the regression.
+I am unsure of how this would even transcribe in a linux vm so i didn't try to reproduce the issue with one.
+
+With the attached [reproduction python script](/uploads/5f2f9240dce1b55ceb148b32f3d6073c/qmp-usb-adds.py), the issue triggers nearly 100% of the time.
+
+Note 1: Related to #650 as the commit causing the regression is the same, although the cause is probably different since the rcu is not implied.
+
+Note 2: This is a restranscription of [this ml report](https://lore.kernel.org/qemu-devel/20210930134844.f4kh72vpeknr2vmk@gmail.com/) as i wasn't aware, the correct way to report issue was through gitlab now.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/66 b/gitlab/issues_text/target_missing/host_missing/accel_missing/66
new file mode 100644
index 00000000..961e6dbd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/66
@@ -0,0 +1 @@
+-hda FAT:. limited to 504MBytes
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/660 b/gitlab/issues_text/target_missing/host_missing/accel_missing/660
new file mode 100644
index 00000000..5dc3b4e9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/660
@@ -0,0 +1,9 @@
+User emulation does not use host GPU
+Description of problem:
+
+Steps to reproduce:
+1. Make a Arch Linux chroot (though any Linux system should work) on Linux
+2. run `glxinfo | grep OpenGL
+3. It's using llvmpipe, not whatever GPU/driver that the hosts use
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/662 b/gitlab/issues_text/target_missing/host_missing/accel_missing/662
new file mode 100644
index 00000000..440a78e7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/662
@@ -0,0 +1,11 @@
+Assertion `!s->do_cmd' failed in am53c974 emulator
+Description of problem:
+
+Steps to reproduce:
+```
+1../configure --target-list=i386-softmmu --disable-werror --enable-sanitizers
+2.make -j12
+3.qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img
+```
+Additional information:
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/663 b/gitlab/issues_text/target_missing/host_missing/accel_missing/663
new file mode 100644
index 00000000..335cc259
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/663
@@ -0,0 +1,11 @@
+Assertion `r->req.aiocb == NULL' in am53c974 emulator
+Description of problem:
+
+Steps to reproduce:
+```
+1../configure --target-list=i386-softmmu --disable-werror --enable-sanitizers
+2.make -j12
+3.qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img
+```
+Additional information:
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/665 b/gitlab/issues_text/target_missing/host_missing/accel_missing/665
new file mode 100644
index 00000000..ef5f8d56
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/665
@@ -0,0 +1,52 @@
+Cannot boot from emulated NVMe with seabios
+Description of problem:
+SeaBIOS doesn't boot from NVMe disk.
+
+This is regression compared to version 5.1.0. The exact same SeaBIOS binary that works with QEMU 5.1.0, doesn't detect NVMe with QEMU 6.0.0, nor QEMU 6.1.0. Booting from NVMe via OVMF works on all those versions.
+Steps to reproduce:
+1. Start the above command
+2. Press ESC to open boot menu in SeaBIOS
+3. Observe lack of NVMe entry
+Additional information:
+I've bisected it to this commit:
+```
+7f0f1acedf159d00684d495d7a14d52220c1d16b is the first bad commit
+commit 7f0f1acedf159d00684d495d7a14d52220c1d16b
+Author: Klaus Jensen <k.jensen@samsung.com>
+Date:   Wed Jun 26 08:51:06 2019 +0200
+
+    hw/block/nvme: support multiple namespaces
+
+    This adds support for multiple namespaces by introducing a new 'nvme-ns'
+    device model. The nvme device creates a bus named from the device name
+    ('id'). The nvme-ns devices then connect to this and registers
+    themselves with the nvme device.
+
+    This changes how an nvme device is created. Example with two namespaces:
+
+      -drive file=nvme0n1.img,if=none,id=disk1
+      -drive file=nvme0n2.img,if=none,id=disk2
+      -device nvme,serial=deadbeef,id=nvme0
+      -device nvme-ns,drive=disk1,bus=nvme0,nsid=1
+      -device nvme-ns,drive=disk2,bus=nvme0,nsid=2
+
+    The drive property is kept on the nvme device to keep the change
+    backward compatible, but the property is now optional. Specifying a
+    drive for the nvme device will always create the namespace with nsid 1.
+
+    Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
+    Reviewed-by: Keith Busch <kbusch@kernel.org>
+    Reviewed-by: Minwoo Im <minwoo.im.dev@gmail.com>
+
+ hw/block/meson.build  |   2 +-
+ hw/block/nvme-ns.c    | 167 ++++++++++++++++++++++++++++++++++
+ hw/block/nvme-ns.h    |  74 +++++++++++++++
+ hw/block/nvme.c       | 245 ++++++++++++++++++++++++++++++++------------------
+ hw/block/nvme.h       |  46 +++++-----
+ hw/block/trace-events |   6 +-
+ 6 files changed, 426 insertions(+), 114 deletions(-)
+ create mode 100644 hw/block/nvme-ns.c
+ create mode 100644 hw/block/nvme-ns.h
+```
+
+Using `-device nvme-ns` as shown above doesn't help either.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/666 b/gitlab/issues_text/target_missing/host_missing/accel_missing/666
new file mode 100644
index 00000000..5a03d6d1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/666
@@ -0,0 +1,7 @@
+ivshmem-plain cannot be used on non-Linux hosts
+Additional information:
+I would like to propose this patch as-is on the mailing list (the trivial one?) as soon as I figure patch submission out fully:
+
+https://github.com/fredldotme/qemu/commit/e929b8db8078aede6df7b02d8c0b71d1e2d6afcb
+
+It's just `#ifdef`ing out doorbell support on non-Linux builds which seems to be enough for basic functionality.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/667 b/gitlab/issues_text/target_missing/host_missing/accel_missing/667
new file mode 100644
index 00000000..00ec3cd0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/667
@@ -0,0 +1 @@
+Wacom EMR pen pressure support
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/668 b/gitlab/issues_text/target_missing/host_missing/accel_missing/668
new file mode 100644
index 00000000..61055b2a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/668
@@ -0,0 +1,21 @@
+No trace verbs
+Description of problem:
+I am trying to follow [this tutorial](https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver) to get my sound working again, but I am stuck at the step where I have to analyse the verbs, because I get none. They say I should get things similar to this:
+```
+CORB[1] = 0xf0000 (caddr:0x0 nid:0x0 control:0xf00 param:0x0)
+CORB[2] = 0xf0002 (caddr:0x0 nid:0x0 control:0xf00 param:0x2)
+CORB[3] = 0xf0004 (caddr:0x0 nid:0x0 control:0xf00 param:0x4)
+RIRBWP advance to 3, last WP 0
+CORB caddr:0x0 nid:0x0 control:0xf00 param:0x0 response:0x10ec0245 (ex 0x0)
+CORB caddr:0x0 nid:0x0 control:0xf00 param:0x2 response:0x100001 (ex 0x0)
+CORB caddr:0x0 nid:0x0 control:0xf00 param:0x4 response:0x10001 (ex 0x0)
+```
+in the `qemu-output.txt` file, but instead I am getting [this](https://github.com/ryanprescott/realtek-verb-tools/files/7331986/qemu-output.txt) in the console.
+
+How do I get verbs in the first format ?
+
+I tried compiling qemu from source with this: `./configure --enable-trace-backends=log --target-list=x86_64-softmmu`, but that produced the same result as using the `qemu-system-x86_64` command that I got by installing qemu with my package manager.
+Steps to reproduce:
+https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver
+Additional information:
+I don't know, as me if I am missing something
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/669 b/gitlab/issues_text/target_missing/host_missing/accel_missing/669
new file mode 100644
index 00000000..8d0d824c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/669
@@ -0,0 +1,23 @@
+QEMU Segmentation fault - UnRaid 9.3.2 when passing nvidia k620 GPU inserted into Lenovo x3550 M5 server
+Description of problem:
+When I pass the following GPU to any Virtual Machine:
+IOMMU group 33:[10de:13bb] 81:00.0 VGA compatible controller: NVIDIA Corporation GM107GL [Quadro K620] (rev a2)
+I receive this error as soon as i try to boot the VM (any OS).
+
+Oct 13 03:06:12 MyUnraid-1U kernel: vfio-pci 0000:81:00.0: enabling device (0140 -> 0141)
+Oct 13 03:06:12 MyUnraid-1U kernel: vfio-pci 0000:81:00.0: vfio_ecap_init: hiding ecap 0x1e@0x258
+Oct 13 03:06:12 MyUnraid-1U kernel: vfio-pci 0000:81:00.0: vfio_ecap_init: hiding ecap 0x19@0x900
+**Oct 13 03:06:12 MyUnraid-1U kernel: qemu-system-x86[6080]: segfault at a8 ip 00005618620c812a sp 00007ffc610531b0 error 4 in qemu-system-x86_64[561861fbb000+51d000]
+Oct 13 03:06:12 MyUnraid-1U kernel: Code: ef ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 55 53 48 89 fb 48 83 ec 08 48 8b 6f 58 e8 4e de ff ff 48 89 df e8 16 e9 ff ff <48> 8b 85 a8 00 00 00 48 85 c0 74 52 8b 93 a0 00 00 00 eb 0e 66 90**
+Oct 13 03:06:13 MyUnraid-1U avahi-daemon[3536]: Interface vnet0.IPv6 no longer relevant for mDNS.
+
+This is one example of W10 VM:
+In attach my VM template
+
+[VM_example.txt](/uploads/428ca5a10ef3338d5d408583fc552b25/VM_example.txt)
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/670 b/gitlab/issues_text/target_missing/host_missing/accel_missing/670
new file mode 100644
index 00000000..a86f9947
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/670
@@ -0,0 +1,10 @@
+qemu x86_64 for microsoft windows hangs when booting a Debian Live 11.1 iso file
+Description of problem:
+qemu displays the boot screen from the live linux iso and starts the boot, but no more display is performed even when waiting for approximately 30 minutes
+Steps to reproduce:
+1. Get hold of a Live Linux iso from Debian 11.1
+2. Set up the Microsoft Windows version of qemu from https://qemu.weilnetz.de/
+3. Attempt to boot the Live Linux iso
+Additional information:
+I also tested older versions of QEMU from the Weilnetz web site. 6.0.0 and 5.2.0 are bad; 5.1.0 and older are good. I then tested the same command line ( no acceleration ) under Linux Tumbleweed 20211014 with qemu 6.1.0 and the iso booted successfully. I have not tried with isos from distributions other than Debian 11.1 . So there is a bug with the Microsoft Windows-specific code in qemu.
+If you need the specific Live Linux that I was using, let me know and I will get it to you somehow. It is several GB in size so I cannot upload it anywhere conveniently.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/671 b/gitlab/issues_text/target_missing/host_missing/accel_missing/671
new file mode 100644
index 00000000..86678878
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/671
@@ -0,0 +1,18 @@
+gtk with virtio and opengl black screen
+Description of problem:
+Running the provided command line, the screen is black, and the vm still starts.
+I can confirm that turning off gl (with gl=off), everything works.
+
+These are line outputs printed out by QEMU:
+```
+gl_version 45 - core profile enabled
+vrend_renderer_fill_caps: Entering with stale GL error: 1280
+GLSL feature level 430
+virtio_input_hid_handle_status: unknown type 20
+virtio_input_hid_handle_status: unknown type 20
+```
+Steps to reproduce:
+1. Execute the provided command
+2. Wait
+Additional information:
+The bug was opened on launchpad by Ethan (ethannij). However, after the migration to github issues, the bug expired and no one reported here. This is the full launchpad discussion: https://bugs.launchpad.net/qemu/+bug/1898490
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/675 b/gitlab/issues_text/target_missing/host_missing/accel_missing/675
new file mode 100644
index 00000000..d8634c49
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/675
@@ -0,0 +1,10 @@
+Attaching WinDbg to a Windows guest on Windows host causes hang
+Description of problem:
+Attempting to attach WinDbg to a Windows guest on a Windows host causes qemu to lockup while using real serial ports. This has been an issue for some time (years if I'm remembering correctly) I just haven't reported it.
+Steps to reproduce:
+1. Enable debug in Windows guest
+2. Create a DB9 between 2 COM ports
+3. Power guest
+4. Attach WinDbg to 2nd COM port not in use by the guest
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/677 b/gitlab/issues_text/target_missing/host_missing/accel_missing/677
new file mode 100644
index 00000000..c1e336f1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/677
@@ -0,0 +1 @@
+Qemu crashes when trying to load kernel inside of WSL2
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/678 b/gitlab/issues_text/target_missing/host_missing/accel_missing/678
new file mode 100644
index 00000000..bb79e4ed
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/678
@@ -0,0 +1,47 @@
+eject (monitor command) not work for blockdev cdrom
+Description of problem:
+cdrom1 device work fine, all files reads, but when i whant to eject CD-ROM disk from device by telnet monitor, it not work.
+Steps to reproduce:
+1. Connect to monitor with
+```
+telnet 127.0.0.1 9100
+(QEMU 5.2.0 monitor - type 'help' for more information)
+```
+
+2. Show block devices
+```
+info block
+cdrom1-format: /mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso (raw, read-only)
+    Attached to:      cdrom1
+    Removable device: not locked, tray closed
+    Cache mode:       writeback
+```
+
+3. Send eject commands
+```
+eject cdrom1
+Error: Device 'cdrom1' not found
+eject cdrom1-format
+Error: Device 'cdrom1-format' not found
+eject cdrom1-storage
+Error: Device 'cdrom1-storage' not found
+```
+Additional information:
+When i run qemu with next lines (replace -blockdev to -drive):
+```
+-device ide-cd,bus=ide.1,drive=cdrom1,id=idecd1,bootindex=2
+-drive if=none,id=cdrom1,media=cdrom,readonly=on,file="/mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso"
+```
+
+eject cdrom1 command work fine
+
+```
+info block
+cdrom1 (#block133): /mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso (raw, read-only)
+    Attached to:      idecd1
+    Removable device: not locked, tray closed
+    Cache mode:       writeback
+eject cdrom1
+```
+
+Also i found a similar bug description on this link https://bugs.launchpad.net/qemu/+bug/1799766
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/68 b/gitlab/issues_text/target_missing/host_missing/accel_missing/68
new file mode 100644
index 00000000..d5c64b0f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/68
@@ -0,0 +1 @@
+Solaris can't be powered off with ACPI shutdown/poweroff
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/680 b/gitlab/issues_text/target_missing/host_missing/accel_missing/680
new file mode 100644
index 00000000..f0f069e7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/680
@@ -0,0 +1 @@
+multi-threaded qemu instance and pci bar
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/681 b/gitlab/issues_text/target_missing/host_missing/accel_missing/681
new file mode 100644
index 00000000..62094a42
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/681
@@ -0,0 +1,25 @@
+Error saving memory to disk
+Description of problem:
+When trying to save the state of the machine using virt-manager (3.2.0) it fails with this error:
+
+Error saving domain: operation failed: domain save job: unexpectedly failed
+```bash
+Traceback (most recent call last):
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
+    callback(asyncjob, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/vmmenu.py", line 182, in cb
+    vm.save(meter=asyncjob.get_meter())
+  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
+    ret = fn(self, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1377, in save
+    self._backend.managedSave(0)
+  File "/usr/lib/python3.9/site-packages/libvirt.py", line 1780, in managedSave
+    raise libvirtError('virDomainManagedSave() failed')
+libvirt.libvirtError: operation failed: domain save job: unexpectedly failed
+```
+Steps to reproduce:
+1. setup a virtual machine
+2. setup a linux distro
+3. try to save the memory to disk
+Additional information:
+Will be provided when needed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/684 b/gitlab/issues_text/target_missing/host_missing/accel_missing/684
new file mode 100644
index 00000000..105e6970
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/684
@@ -0,0 +1 @@
+xHCI Port Status Change Event at port powered
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/686 b/gitlab/issues_text/target_missing/host_missing/accel_missing/686
new file mode 100644
index 00000000..ff0e5614
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/686
@@ -0,0 +1,39 @@
+Qemu crashes if it is paused and migrated twice
+Description of problem:
+If the vm is in PAUSED state (in Openstack parlance) (I think libvirt calls that paused as well but uses the command `virsh suspend`), and live-migrated twice, the second time the Qemu process terminates.
+
+This is perfectly repeatable.
+
+If the VM is unpaused and re-paused after the first migration, then the problem does not occur on the next migration.
+Steps to reproduce:
+See also the referenced bug report to openstack, above.
+1. `$ openstack stack create ....`
+2. `$ openstack server pause <UUID>`
+(wait until done)
+3. `$ openstack server migrate --live-migration <UUID>`
+(wait until done)
+4. `$ openstack server migrate --live-migration <UUID>`
+
+The VM is now in ERROR state because it has disappeared: `libvirt.libvirtError: Domain not found: no domain with matching uuid '<UUID>'`
+Additional information:
+The last few lines from the instance-00000ba2.log seem pertinent (this is from the receiving Qemu instance):
+```
+2021-10-22 15:32:53.829+0000: initiating migration
+qemu-system-x86_64: /build/qemu-lb4V37/qemu-4.2/block.c:5523: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed.
+2021-10-22 15:32:59.122+0000: shutting down, reason=crashed
+```
+This is logged by libvirt (also on the receiving side):
+```
+Oct 22 15:29:04 ybk140931 ovs-vsctl[20174]: ovs|00001|vsctl|INFO|Called as ovs-vsctl --timeout=5 -- --if-exists del-port tap3a71aa63-6a
+Oct 22 15:31:31 ybk140931 ovs-vsctl[21412]: ovs|00001|vsctl|INFO|Called as ovs-vsctl --timeout=5 -- --if-exists del-port tap3a71aa63-6a -- add-port br-int tap3a71aa63-6a -- set Interface tap3a71aa63-6a "external-ids:attached-mac=\"fa:16:3e:da:03:56\"" -- set Interface tap3a71aa63-6a "external-ids:iface-id=\"3a71aa63-6a39-41d8-9602-04b84834db9e\"" -- set Interface tap3a71aa63-6a "external-ids:vm-id=\"de2b27d2-345c-45fc-8f37-2fa0ed1a1151\"" -- set Interface tap3a71aa63-6a external-ids:iface-status=active
+Oct 22 15:32:58 ybk140931 libvirtd[3237]: Unable to read from monitor: Connection reset by peer
+Oct 22 15:32:59 ybk140931 ovs-vsctl[22001]: ovs|00001|vsctl|INFO|Called as ovs-vsctl --timeout=5 -- --if-exists del-port tap3a71aa63-6a
+Oct 22 15:32:59 ybk140931 libvirtd[3237]: operation failed: domain is not running
+Oct 22 15:32:59 ybk140931 libvirtd[3237]: internal error: qemu unexpectedly closed the monitor: 2021-10-22T15:32:58.845667Z qemu-system-x86_64: Failed to load virtio_pci/modern_queue_state:used
+                                          2021-10-22T15:32:58.845687Z qemu-system-x86_64: Failed to load virtio_pci/modern_state:vqs
+                                          2021-10-22T15:32:58.845690Z qemu-system-x86_64: Failed to load virtio/extra_state:extra_state
+                                          2021-10-22T15:32:58.845692Z qemu-system-x86_64: Failed to load virtio-rng:virtio
+                                          2021-10-22T15:32:58.845695Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:06.0/virtio-rng'
+                                          2021-10-22T15:32:58.847860Z qemu-system-x86_64: load of migration failed: Input/output error
+Oct 22 15:32:59 ybk140931 libvirtd[3237]: operation failed: domain 'instance-00000ba2' is not running
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/687 b/gitlab/issues_text/target_missing/host_missing/accel_missing/687
new file mode 100644
index 00000000..e615c820
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/687
@@ -0,0 +1 @@
+what is the DMAR?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/688 b/gitlab/issues_text/target_missing/host_missing/accel_missing/688
new file mode 100644
index 00000000..0203ec61
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/688
@@ -0,0 +1,47 @@
+Shrinking an image with qemu-img  does not reduce image file size
+Description of problem:
+I have a macOS 10.9 VM using a qcow2 image that was 151GB. The image was originally converted from a VMware image with:
+```
+qemu-img convert macOS-10.9.vmdk -O qcow2 -o preallocation=falloc macOS-10.9.qcow2
+```
+This resulted in `macOS-10.9.qcow2` being 151GB big:
+```
+$ du -h macOS-10.9.qcow2 
+151G     macOS-10.9.qcow2
+```
+After reducing the filesystem size from within macOS to 25GB with DiskUtil, I shut down the VM and resized the image to 30GB with:
+```
+qemu-img resize -f qcow2 --shrink macOS-10.9.qcow2 30G
+```
+This succeeded. However, the file still consumes 151GB of space:
+```
+$ du -h macOS-10.9.qcow2 
+151G     macOS-10.9.qcow2
+```
+Even though `qemu-img info` shows:
+```
+$ qemu-img info macOS-10.9.qcow2 
+image: macOS-10.9.qcow2
+file format: qcow2
+virtual size: 30 GiB (32212254720 bytes)
+disk size: 30 GiB
+cluster_size: 65536
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: false
+    refcount bits: 16
+    corrupt: false
+    extended l2: false
+```
+The size inside the VM is also reported as being 30GB.
+
+The whole point of resizing that image was to free up disk space on the host. But this doesn't seem to be happening.
+
+My filesystem is ext4.
+Steps to reproduce:
+1. Create a vmdk image with `qemu-img create -f vmdk test.vmdk 5G`
+2. Convert the vmdk image to qcow2 with `qemu-img convert test.vmdk -O qcow2 -o preallocation=falloc test.qcow2`
+3. Shrink the new image with `qemu-img resize -f qcow2 --shrink test.qcow2 3G`
+
+The resulting `test.qcow2` file should be 3GB, but it's not. It's 5GB.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/69 b/gitlab/issues_text/target_missing/host_missing/accel_missing/69
new file mode 100644
index 00000000..1663daf8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/69
@@ -0,0 +1 @@
+ALSA underruns occurr when using QEMU
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/691 b/gitlab/issues_text/target_missing/host_missing/accel_missing/691
new file mode 100644
index 00000000..329a20f2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/691
@@ -0,0 +1,6 @@
+`-nic model=help` on qemu-system-riscv64 doesn't output supported models
+Description of problem:
+`-nic model=help` doesn't list out the supported NIC models and instead launches QEMU with warnings.
+![image](/uploads/6b0ea448ee8757a5b14081bb19dd6060/image.png)
+Steps to reproduce:
+1. run `qemu-system-riscv64 -machine virt -nic model=help`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/692 b/gitlab/issues_text/target_missing/host_missing/accel_missing/692
new file mode 100644
index 00000000..08a21c79
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/692
@@ -0,0 +1 @@
+remove_fd_in_watch does not call g_source_unref
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/696 b/gitlab/issues_text/target_missing/host_missing/accel_missing/696
new file mode 100644
index 00000000..588b5d11
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/696
@@ -0,0 +1,9 @@
+EDID does not reflected to window size when added through the commandline
+Description of problem:
+It seems some odd behavior on the guest screen. it shows me the size of default window (640x480) instead of override the value to 1740x720. This size (640x480) is first initialized on ui/console.c => QemuConsole *graphic_console_init and I did noticed that in hw/display/virtio-gpu-base.c=> static int virtio_gpu_ui_info the override value is not taking place instead it just took the value from ui/console.c (640x480). May I know, how do I achieved the right override edid value from the current provided interface.
+
+##Additional information
+I did noticed that the edid flag is always true (running this command) It is contradiction from the doc.
+Steps to reproduce:
+1. Run the qemu with the command mentioned
+2. Check the resolution of guest OS
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/697 b/gitlab/issues_text/target_missing/host_missing/accel_missing/697
new file mode 100644
index 00000000..1bc175fa
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/697
@@ -0,0 +1 @@
+linux-user create default CPU type before parsing the ELF header for specific CPU type
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/698 b/gitlab/issues_text/target_missing/host_missing/accel_missing/698
new file mode 100644
index 00000000..a11a7840
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/698
@@ -0,0 +1,358 @@
+linux-user: emulated process reading /proc/self/mem doesn't see guest view of memory map
+Description of problem:
+QEMU user-mode emulation of a 32-bit guest on a 64-bit host doesn't seem to emulate `/proc/self/mem` (or `/proc/$pid/mem`) correctly. Based on the contents of `/proc/self/maps`, there seems to be some sort of address translation happening that `/proc/self/mem` doesn't honor.
+
+The following source file:
+
+```c
+#include <fcntl.h>
+#include <inttypes.h>
+#include <stdbool.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <sys/wait.h>
+
+static const char string[] = "Hello, world!\n";
+
+static bool copy_to_stdout(const char *path)
+{
+	bool success = false;
+
+	int fd = open(path, O_RDONLY);
+	if (fd < 0) {
+		perror("open");
+		return false;
+	}
+
+	char buf[16 * 1024];
+	while (true) {
+		ssize_t bytes_read = read(fd, buf, sizeof(buf));
+		if (bytes_read == 0) {
+			success = true;
+			goto out;
+		} else if (bytes_read < 0) {
+			perror("read");
+			goto out;
+		}
+		ssize_t bytes_written = 0;
+		while (bytes_written < bytes_read) {
+			ssize_t ret = write(STDOUT_FILENO, buf + bytes_written,
+					    bytes_read - bytes_written);
+			if (ret < 0) {
+				perror("write");
+				goto out;
+			}
+			bytes_written += ret;
+		}
+	}
+
+out:
+	close(fd);
+	return success;
+}
+
+static bool dump_maps(void)
+{
+	printf("Maps read by self:\n");
+	fflush(stdout);
+	if (!copy_to_stdout("/proc/self/maps"))
+		return false;
+
+	printf("\nMaps read by child process:\n");
+	fflush(stdout);
+	pid_t pid = fork();
+	if (pid < 0) {
+		perror("fork");
+		return false;
+	}
+	if (pid == 0) {
+		char parent_maps[32];
+		sprintf(parent_maps, "/proc/%u/maps", (unsigned int)getppid());
+		if (copy_to_stdout(parent_maps))
+			_exit(EXIT_SUCCESS);
+		else
+			_exit(EXIT_FAILURE);
+	}
+	int wstatus;
+	if (waitpid(pid, &wstatus, 0) < 0 ||
+	    !WIFEXITED(wstatus) || WEXITSTATUS(wstatus) != EXIT_SUCCESS)
+		return false;
+
+	printf("\n");
+	return true;
+}
+
+int main(void)
+{
+	if (!dump_maps())
+		return EXIT_FAILURE;
+
+	int fd = open("/proc/self/mem", O_RDONLY);
+	if (fd < 0) {
+		perror("open: /proc/self/mem");
+		return EXIT_FAILURE;
+	}
+
+	char buf[sizeof(string)];
+	printf("Reading %zu bytes from %p (%" PRIuPTR ") to %p of PID %u\n",
+	       sizeof(buf), string, (uintptr_t)string, buf,
+	       (unsigned int)getpid());
+	fflush(stdout);
+
+	if (pread(fd, buf, sizeof(buf), (uintptr_t)string) < 0) {
+		perror("pread: /proc/self/mem");
+		return EXIT_FAILURE;
+	}
+
+	if (memcmp(buf, string, sizeof(buf)) != 0) {
+		fprintf(stderr, "buffer doesn't match\n");
+		return EXIT_FAILURE;
+	}
+
+	return EXIT_SUCCESS;
+}
+```
+
+when compiled for 32-bit ARM produces the following output:
+
+```
+Maps read by self:
+10000-7c000 r-xp 00000000 00:19 8275924                                  /home/osandov/repro
+7c000-8b000 ---p 00000000 00:00 0                                        
+8b000-8c000 r--p 0006b000 00:19 8275924                                  /home/osandov/repro
+8c000-8d000 rw-p 0006c000 00:19 8275924                                  /home/osandov/repro
+8d000-b0000 rw-p 00000000 00:00 0                                        
+3ffff000-40000000 r-xp 00000000 00:00 0                                  
+40000000-40001000 ---p 00000000 00:00 0                                  
+40001000-40801000 rw-p 00000000 00:00 0                                  [stack]
+
+Maps read by child process:
+00010000-00020000 ---p 00000000 00:00 0 
+00020000-0008c000 r--p 00000000 00:19 8275924                            /home/osandov/repro
+0008c000-0009b000 ---p 00000000 00:00 0 
+0009b000-0009c000 r--p 0006b000 00:19 8275924                            /home/osandov/repro
+0009c000-0009d000 rw-p 0006c000 00:19 8275924                            /home/osandov/repro
+0009d000-000c0000 rw-p 00000000 00:00 0 
+000c0000-4000f000 ---p 00000000 00:00 0 
+4000f000-40010000 r--p 00000000 00:00 0 
+40010000-40011000 ---p 00000000 00:00 0 
+40011000-40811000 rw-p 00000000 00:00 0 
+40811000-100000000 ---p 00000000 00:00 0 
+100000000-100001000 r--p 00000000 00:00 0 
+5636dd7a2000-5636dd8a4000 r--p 00000000 00:19 8270028                    /home/osandov/repos/qemu/build/qemu-arm
+5636dd8a4000-5636ddb13000 r-xp 00102000 00:19 8270028                    /home/osandov/repos/qemu/build/qemu-arm
+5636ddb13000-5636ddf69000 r--p 00371000 00:19 8270028                    /home/osandov/repos/qemu/build/qemu-arm
+5636ddf6a000-5636ddfe7000 r--p 007c7000 00:19 8270028                    /home/osandov/repos/qemu/build/qemu-arm
+5636ddfe7000-5636ddff3000 rw-p 00844000 00:19 8270028                    /home/osandov/repos/qemu/build/qemu-arm
+5636ddff3000-5636de010000 rw-p 00000000 00:00 0 
+5636df67b000-5636df80c000 rw-p 00000000 00:00 0                          [heap]
+7f3008000000-7f300ffff000 rwxp 00000000 00:00 0 
+7f300ffff000-7f3010000000 ---p 00000000 00:00 0 
+7f3010000000-7f3010021000 rw-p 00000000 00:00 0 
+7f3010021000-7f3014000000 ---p 00000000 00:00 0 
+7f3017119000-7f301719a000 rw-p 00000000 00:00 0 
+7f301719a000-7f301719b000 ---p 00000000 00:00 0 
+7f301719b000-7f30179a1000 rw-p 00000000 00:00 0 
+7f30179a1000-7f30179a3000 r--p 00000000 00:19 3660771                    /usr/lib/libffi.so.8.1.0
+7f30179a3000-7f30179a9000 r-xp 00002000 00:19 3660771                    /usr/lib/libffi.so.8.1.0
+7f30179a9000-7f30179ab000 r--p 00008000 00:19 3660771                    /usr/lib/libffi.so.8.1.0
+7f30179ab000-7f30179ac000 r--p 00009000 00:19 3660771                    /usr/lib/libffi.so.8.1.0
+7f30179ac000-7f30179ad000 rw-p 0000a000 00:19 3660771                    /usr/lib/libffi.so.8.1.0
+7f30179ad000-7f30179be000 r--p 00000000 00:19 1476709                    /usr/lib/libgmp.so.10.4.1
+7f30179be000-7f3017a32000 r-xp 00011000 00:19 1476709                    /usr/lib/libgmp.so.10.4.1
+7f3017a32000-7f3017a49000 r--p 00085000 00:19 1476709                    /usr/lib/libgmp.so.10.4.1
+7f3017a49000-7f3017a4a000 ---p 0009c000 00:19 1476709                    /usr/lib/libgmp.so.10.4.1
+7f3017a4a000-7f3017a4c000 r--p 0009c000 00:19 1476709                    /usr/lib/libgmp.so.10.4.1
+7f3017a4c000-7f3017a4d000 rw-p 0009e000 00:19 1476709                    /usr/lib/libgmp.so.10.4.1
+7f3017a4d000-7f3017a56000 r--p 00000000 00:19 2871144                    /usr/lib/libhogweed.so.6.4
+7f3017a56000-7f3017a69000 r-xp 00009000 00:19 2871144                    /usr/lib/libhogweed.so.6.4
+7f3017a69000-7f3017a93000 r--p 0001c000 00:19 2871144                    /usr/lib/libhogweed.so.6.4
+7f3017a93000-7f3017a95000 r--p 00045000 00:19 2871144                    /usr/lib/libhogweed.so.6.4
+7f3017a95000-7f3017a96000 rw-p 00047000 00:19 2871144                    /usr/lib/libhogweed.so.6.4
+7f3017a96000-7f3017a98000 rw-p 00000000 00:00 0 
+7f3017a98000-7f3017aa4000 r--p 00000000 00:19 2871147                    /usr/lib/libnettle.so.8.4
+7f3017aa4000-7f3017ac5000 r-xp 0000c000 00:19 2871147                    /usr/lib/libnettle.so.8.4
+7f3017ac5000-7f3017adb000 r--p 0002d000 00:19 2871147                    /usr/lib/libnettle.so.8.4
+7f3017adb000-7f3017adc000 ---p 00043000 00:19 2871147                    /usr/lib/libnettle.so.8.4
+7f3017adc000-7f3017ade000 r--p 00043000 00:19 2871147                    /usr/lib/libnettle.so.8.4
+7f3017ade000-7f3017adf000 rw-p 00045000 00:19 2871147                    /usr/lib/libnettle.so.8.4
+7f3017adf000-7f3017ae2000 r--p 00000000 00:19 2550729                    /usr/lib/libtasn1.so.6.6.1
+7f3017ae2000-7f3017aee000 r-xp 00003000 00:19 2550729                    /usr/lib/libtasn1.so.6.6.1
+7f3017aee000-7f3017af2000 r--p 0000f000 00:19 2550729                    /usr/lib/libtasn1.so.6.6.1
+7f3017af2000-7f3017af3000 ---p 00013000 00:19 2550729                    /usr/lib/libtasn1.so.6.6.1
+7f3017af3000-7f3017af4000 r--p 00013000 00:19 2550729                    /usr/lib/libtasn1.so.6.6.1
+7f3017af4000-7f3017af5000 rw-p 00014000 00:19 2550729                    /usr/lib/libtasn1.so.6.6.1
+7f3017af5000-7f3017b06000 r--p 00000000 00:19 937656                     /usr/lib/libunistring.so.2.1.0
+7f3017b06000-7f3017b3b000 r-xp 00011000 00:19 937656                     /usr/lib/libunistring.so.2.1.0
+7f3017b3b000-7f3017c72000 r--p 00046000 00:19 937656                     /usr/lib/libunistring.so.2.1.0
+7f3017c72000-7f3017c76000 r--p 0017c000 00:19 937656                     /usr/lib/libunistring.so.2.1.0
+7f3017c76000-7f3017c77000 rw-p 00180000 00:19 937656                     /usr/lib/libunistring.so.2.1.0
+7f3017c77000-7f3017c79000 r--p 00000000 00:19 3212638                    /usr/lib/libidn2.so.0.3.7
+7f3017c79000-7f3017c7d000 r-xp 00002000 00:19 3212638                    /usr/lib/libidn2.so.0.3.7
+7f3017c7d000-7f3017c97000 r--p 00006000 00:19 3212638                    /usr/lib/libidn2.so.0.3.7
+7f3017c97000-7f3017c98000 r--p 0001f000 00:19 3212638                    /usr/lib/libidn2.so.0.3.7
+7f3017c98000-7f3017c99000 rw-p 00020000 00:19 3212638                    /usr/lib/libidn2.so.0.3.7
+7f3017c99000-7f3017cc2000 r--p 00000000 00:19 3663986                    /usr/lib/libp11-kit.so.0.3.0
+7f3017cc2000-7f3017d60000 r-xp 00029000 00:19 3663986                    /usr/lib/libp11-kit.so.0.3.0
+7f3017d60000-7f3017dba000 r--p 000c7000 00:19 3663986                    /usr/lib/libp11-kit.so.0.3.0
+7f3017dba000-7f3017dc4000 r--p 00120000 00:19 3663986                    /usr/lib/libp11-kit.so.0.3.0
+7f3017dc4000-7f3017dce000 rw-p 0012a000 00:19 3663986                    /usr/lib/libp11-kit.so.0.3.0
+7f3017dce000-7f3017dd0000 r--p 00000000 00:19 2549813                    /usr/lib/libdl-2.33.so
+7f3017dd0000-7f3017dd2000 r-xp 00002000 00:19 2549813                    /usr/lib/libdl-2.33.so
+7f3017dd2000-7f3017dd3000 r--p 00004000 00:19 2549813                    /usr/lib/libdl-2.33.so
+7f3017dd3000-7f3017dd4000 r--p 00004000 00:19 2549813                    /usr/lib/libdl-2.33.so
+7f3017dd4000-7f3017dd5000 rw-p 00005000 00:19 2549813                    /usr/lib/libdl-2.33.so
+7f3017dd5000-7f3017dd7000 rw-p 00000000 00:00 0 
+7f3017dd7000-7f3017dd9000 r--p 00000000 00:19 3020974                    /usr/lib/libpcre.so.1.2.13
+7f3017dd9000-7f3017e2f000 r-xp 00002000 00:19 3020974                    /usr/lib/libpcre.so.1.2.13
+7f3017e2f000-7f3017e4c000 r--p 00058000 00:19 3020974                    /usr/lib/libpcre.so.1.2.13
+7f3017e4c000-7f3017e4d000 r--p 00074000 00:19 3020974                    /usr/lib/libpcre.so.1.2.13
+7f3017e4d000-7f3017e4e000 rw-p 00075000 00:19 3020974                    /usr/lib/libpcre.so.1.2.13
+7f3017e4e000-7f3017e74000 r--p 00000000 00:19 2549806                    /usr/lib/libc-2.33.so
+7f3017e74000-7f3017fbf000 r-xp 00026000 00:19 2549806                    /usr/lib/libc-2.33.so
+7f3017fbf000-7f301800b000 r--p 00171000 00:19 2549806                    /usr/lib/libc-2.33.so
+7f301800b000-7f301800e000 r--p 001bc000 00:19 2549806                    /usr/lib/libc-2.33.so
+7f301800e000-7f3018011000 rw-p 001bf000 00:19 2549806                    /usr/lib/libc-2.33.so
+7f3018011000-7f301801a000 rw-p 00000000 00:00 0 
+7f301801a000-7f3018021000 r--p 00000000 00:19 2549847                    /usr/lib/libpthread-2.33.so
+7f3018021000-7f3018030000 r-xp 00007000 00:19 2549847                    /usr/lib/libpthread-2.33.so
+7f3018030000-7f3018034000 r--p 00016000 00:19 2549847                    /usr/lib/libpthread-2.33.so
+7f3018034000-7f3018035000 ---p 0001a000 00:19 2549847                    /usr/lib/libpthread-2.33.so
+7f3018035000-7f3018036000 r--p 0001a000 00:19 2549847                    /usr/lib/libpthread-2.33.so
+7f3018036000-7f3018037000 rw-p 0001b000 00:19 2549847                    /usr/lib/libpthread-2.33.so
+7f3018037000-7f301803b000 rw-p 00000000 00:00 0 
+7f301803b000-7f301803e000 r--p 00000000 00:19 2550528                    /usr/lib/libgcc_s.so.1
+7f301803e000-7f3018050000 r-xp 00003000 00:19 2550528                    /usr/lib/libgcc_s.so.1
+7f3018050000-7f3018053000 r--p 00015000 00:19 2550528                    /usr/lib/libgcc_s.so.1
+7f3018053000-7f3018054000 ---p 00018000 00:19 2550528                    /usr/lib/libgcc_s.so.1
+7f3018054000-7f3018055000 r--p 00018000 00:19 2550528                    /usr/lib/libgcc_s.so.1
+7f3018055000-7f3018056000 rw-p 00019000 00:19 2550528                    /usr/lib/libgcc_s.so.1
+7f3018056000-7f3018065000 r--p 00000000 00:19 2549819                    /usr/lib/libm-2.33.so
+7f3018065000-7f30180ff000 r-xp 0000f000 00:19 2549819                    /usr/lib/libm-2.33.so
+7f30180ff000-7f3018197000 r--p 000a9000 00:19 2549819                    /usr/lib/libm-2.33.so
+7f3018197000-7f3018198000 ---p 00141000 00:19 2549819                    /usr/lib/libm-2.33.so
+7f3018198000-7f3018199000 r--p 00141000 00:19 2549819                    /usr/lib/libm-2.33.so
+7f3018199000-7f301819a000 rw-p 00142000 00:19 2549819                    /usr/lib/libm-2.33.so
+7f301819a000-7f3018233000 r--p 00000000 00:19 2550558                    /usr/lib/libstdc++.so.6.0.29
+7f3018233000-7f3018333000 r-xp 00099000 00:19 2550558                    /usr/lib/libstdc++.so.6.0.29
+7f3018333000-7f301839f000 r--p 00199000 00:19 2550558                    /usr/lib/libstdc++.so.6.0.29
+7f301839f000-7f30183ac000 r--p 00204000 00:19 2550558                    /usr/lib/libstdc++.so.6.0.29
+7f30183ac000-7f30183ad000 rw-p 00211000 00:19 2550558                    /usr/lib/libstdc++.so.6.0.29
+7f30183ad000-7f30183b2000 rw-p 00000000 00:00 0 
+7f30183b2000-7f30183e6000 r--p 00000000 00:19 2907924                    /usr/lib/libgnutls.so.30.30.0
+7f30183e6000-7f3018508000 r-xp 00034000 00:19 2907924                    /usr/lib/libgnutls.so.30.30.0
+7f3018508000-7f301859d000 r--p 00156000 00:19 2907924                    /usr/lib/libgnutls.so.30.30.0
+7f301859d000-7f301859e000 ---p 001eb000 00:19 2907924                    /usr/lib/libgnutls.so.30.30.0
+7f301859e000-7f30185af000 r--p 001eb000 00:19 2907924                    /usr/lib/libgnutls.so.30.30.0
+7f30185af000-7f30185b1000 rw-p 001fc000 00:19 2907924                    /usr/lib/libgnutls.so.30.30.0
+7f30185b1000-7f30185b3000 rw-p 00000000 00:00 0 
+7f30185b3000-7f30185b5000 r--p 00000000 00:19 3662215                    /usr/lib/libgmodule-2.0.so.0.7000.0
+7f30185b5000-7f30185b7000 r-xp 00002000 00:19 3662215                    /usr/lib/libgmodule-2.0.so.0.7000.0
+7f30185b7000-7f30185b8000 r--p 00004000 00:19 3662215                    /usr/lib/libgmodule-2.0.so.0.7000.0
+7f30185b8000-7f30185b9000 r--p 00004000 00:19 3662215                    /usr/lib/libgmodule-2.0.so.0.7000.0
+7f30185b9000-7f30185ba000 rw-p 00005000 00:19 3662215                    /usr/lib/libgmodule-2.0.so.0.7000.0
+7f30185ba000-7f30185d7000 r--p 00000000 00:19 3662212                    /usr/lib/libglib-2.0.so.0.7000.0
+7f30185d7000-7f3018664000 r-xp 0001d000 00:19 3662212                    /usr/lib/libglib-2.0.so.0.7000.0
+7f3018664000-7f30186ec000 r--p 000aa000 00:19 3662212                    /usr/lib/libglib-2.0.so.0.7000.0
+7f30186ec000-7f30186ed000 ---p 00132000 00:19 3662212                    /usr/lib/libglib-2.0.so.0.7000.0
+7f30186ed000-7f30186ee000 r--p 00132000 00:19 3662212                    /usr/lib/libglib-2.0.so.0.7000.0
+7f30186ee000-7f30186ef000 rw-p 00133000 00:19 3662212                    /usr/lib/libglib-2.0.so.0.7000.0
+7f30186ef000-7f30186f0000 rw-p 00000000 00:00 0 
+7f30186f0000-7f30186f2000 r--p 00000000 00:19 3440204                    /usr/lib/liburing.so.2.1.0
+7f30186f2000-7f30186f4000 r-xp 00002000 00:19 3440204                    /usr/lib/liburing.so.2.1.0
+7f30186f4000-7f30186f5000 r--p 00004000 00:19 3440204                    /usr/lib/liburing.so.2.1.0
+7f30186f5000-7f30186f6000 r--p 00004000 00:19 3440204                    /usr/lib/liburing.so.2.1.0
+7f30186f6000-7f30186f7000 rw-p 00005000 00:19 3440204                    /usr/lib/liburing.so.2.1.0
+7f30186f7000-7f30186fa000 r--p 00000000 00:19 2549855                    /usr/lib/librt-2.33.so
+7f30186fa000-7f30186fe000 r-xp 00003000 00:19 2549855                    /usr/lib/librt-2.33.so
+7f30186fe000-7f3018700000 r--p 00007000 00:19 2549855                    /usr/lib/librt-2.33.so
+7f3018700000-7f3018701000 r--p 00008000 00:19 2549855                    /usr/lib/librt-2.33.so
+7f3018701000-7f3018702000 rw-p 00009000 00:19 2549855                    /usr/lib/librt-2.33.so
+7f3018702000-7f3018705000 r--p 00000000 00:19 15838                      /usr/lib/libz.so.1.2.11
+7f3018705000-7f3018713000 r-xp 00003000 00:19 15838                      /usr/lib/libz.so.1.2.11
+7f3018713000-7f3018719000 r--p 00011000 00:19 15838                      /usr/lib/libz.so.1.2.11
+7f3018719000-7f301871a000 ---p 00017000 00:19 15838                      /usr/lib/libz.so.1.2.11
+7f301871a000-7f301871b000 r--p 00017000 00:19 15838                      /usr/lib/libz.so.1.2.11
+7f301871b000-7f301871c000 rw-p 00018000 00:19 15838                      /usr/lib/libz.so.1.2.11
+7f301871c000-7f301871e000 rw-p 00000000 00:00 0 
+7f301871e000-7f301871f000 r--p 00000000 00:19 2549795                    /usr/lib/ld-2.33.so
+7f301871f000-7f3018743000 r-xp 00001000 00:19 2549795                    /usr/lib/ld-2.33.so
+7f3018743000-7f301874c000 r--p 00025000 00:19 2549795                    /usr/lib/ld-2.33.so
+7f301874c000-7f301874e000 r--p 0002d000 00:19 2549795                    /usr/lib/ld-2.33.so
+7f301874e000-7f3018750000 rw-p 0002f000 00:19 2549795                    /usr/lib/ld-2.33.so
+7ffc5c8f6000-7ffc5c917000 rw-p 00000000 00:00 0                          [stack]
+7ffc5c935000-7ffc5c939000 r--p 00000000 00:00 0                          [vvar]
+7ffc5c939000-7ffc5c93b000 r-xp 00000000 00:00 0                          [vdso]
+ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]
+
+Reading 15 bytes from 0x6377c (407420) to 0x40800638 of PID 278331
+buffer doesn't match
+```
+
+The program is trying to read from 0x6377c, which according to the emulated maps is in this mapping:
+
+```
+10000-7c000 r-xp 00000000 00:19 8275924                                  /home/osandov/repro
+```
+
+but on the host, it's mapped differently:
+
+```
+00020000-0008c000 r--p 00000000 00:19 8275924                            /home/osandov/repro
+```
+
+When using `qemu-arm-static` (version `6.1.0 (Debian 1:6.1+dfsg-6)`) via `binfmt_misc`, I also saw a case where the address isn't mapped in the host at all:
+
+```
+Maps read by self:
+10000-7c000 r-xp 00000000 00:19 8275924                                  /home/osandov/repro
+7c000-8b000 ---p 00000000 00:00 0                                        
+8b000-8c000 r--p 0006b000 00:19 8275924                                  /home/osandov/repro
+8c000-8d000 rw-p 0006c000 00:19 8275924                                  /home/osandov/repro
+8d000-b0000 rw-p 00000000 00:00 0                                        
+40000000-40001000 ---p 00000000 00:00 0                                  
+40001000-40801000 rw-p 00000000 00:00 0                                  [stack]
+
+Maps read by child process:
+00400000-00401000 r--p 00000000 00:19 297                                /usr/bin/qemu-arm-static
+00401000-00769000 r-xp 00001000 00:19 297                                /usr/bin/qemu-arm-static
+00769000-00abe000 r--p 00369000 00:19 297                                /usr/bin/qemu-arm-static
+00abe000-00c58000 r--p 006bd000 00:19 297                                /usr/bin/qemu-arm-static
+00c58000-00cd3000 rw-p 00857000 00:19 297                                /usr/bin/qemu-arm-static
+00cd3000-00cf7000 rw-p 00000000 00:00 0 
+0253c000-0268e000 rw-p 00000000 00:00 0                                  [heap]
+42645000-42655000 ---p 00000000 00:00 0 
+42655000-426c1000 r--p 00000000 00:19 8275924                            /home/osandov/repro
+426c1000-426d0000 ---p 00000000 00:00 0 
+426d0000-426d1000 r--p 0006b000 00:19 8275924                            /home/osandov/repro
+426d1000-426d2000 rw-p 0006c000 00:19 8275924                            /home/osandov/repro
+426d2000-426f5000 rw-p 00000000 00:00 0 
+426f5000-82645000 ---p 00000000 00:00 0 
+82645000-82646000 ---p 00000000 00:00 0 
+82646000-82e46000 rw-p 00000000 00:00 0 
+82e46000-142635000 ---p 00000000 00:00 0 
+142635000-142636000 r--p 00000000 00:00 0 
+7f5584000000-7f558bfff000 rwxp 00000000 00:00 0 
+7f558bfff000-7f558c000000 ---p 00000000 00:00 0 
+7f558c000000-7f558c021000 rw-p 00000000 00:00 0 
+7f558c021000-7f5590000000 ---p 00000000 00:00 0 
+7f55929b5000-7f5592a36000 rw-p 00000000 00:00 0 
+7f5592a36000-7f5592a37000 ---p 00000000 00:00 0 
+7f5592a37000-7f5593237000 rw-p 00000000 00:00 0 
+7ffc4971a000-7ffc4973b000 rw-p 00000000 00:00 0                          [stack]
+7ffc497fa000-7ffc497fe000 r--p 00000000 00:00 0                          [vvar]
+7ffc497fe000-7ffc49800000 r-xp 00000000 00:00 0                          [vdso]
+ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]
+
+Reading 15 bytes from 0x6377c (407420) to 0x40800648 of PID 278443
+pread: /proc/self/mem: Input/output error
+```
+Steps to reproduce:
+1. Download statically-linked ARM [reproducer](/uploads/5563ad67d01f0ec4a10f27d1967216c4/repro).
+2. Run `qemu-arm ./repro`.
+Additional information:
+I encountered this when trying out a CI system that uses QEMU user-mode emulation for 32-bit ARM builds. My project is a debugger that uses `/proc/self/mem`, and a test case tripped over this. See https://github.com/osandov/drgn/pull/126.
+
+This also seems to happen with a i386 guest, but not with an aarch64 guest, so I'm assuming that it's a 32-bit guest issue.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/699 b/gitlab/issues_text/target_missing/host_missing/accel_missing/699
new file mode 100644
index 00000000..82a3d26e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/699
@@ -0,0 +1 @@
+SGX QEMU release
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/70 b/gitlab/issues_text/target_missing/host_missing/accel_missing/70
new file mode 100644
index 00000000..d8dd4e8b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/70
@@ -0,0 +1 @@
+hda sound capture broken with VNC
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/700 b/gitlab/issues_text/target_missing/host_missing/accel_missing/700
new file mode 100644
index 00000000..da0634da
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/700
@@ -0,0 +1 @@
+GTK display refresh rate is throttled
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/701 b/gitlab/issues_text/target_missing/host_missing/accel_missing/701
new file mode 100644
index 00000000..6879aa16
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/701
@@ -0,0 +1 @@
+Setup a gitlab shared runner for linux-user testing
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/702 b/gitlab/issues_text/target_missing/host_missing/accel_missing/702
new file mode 100644
index 00000000..60f10fa7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/702
@@ -0,0 +1 @@
+Setup a gitlab shared runner for bsd-user testing
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/703 b/gitlab/issues_text/target_missing/host_missing/accel_missing/703
new file mode 100644
index 00000000..71ab9026
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/703
@@ -0,0 +1,17 @@
+Resizable BAR (ReBAR) support on VFIO
+Additional information:
+Currently `vfio_add_ext_cap()` doesn't pass ReBAR support option to VFIO.
+
+There was a report that removing the line you see below makes it boot, but the system is not stable.
+Needs investigation.
+
+[https://github.com/qemu/qemu/blob/2255564fd21059960966b47212def9069cb56077/hw/vfio/pci.c#L2089](https://github.com/qemu/qemu/blob/2255564fd21059960966b47212def9069cb56077/hw/vfio/pci.c#L2089)
+```        switch (cap_id) {
+        case 0: /* kernel masked capability */
+        case PCI_EXT_CAP_ID_SRIOV: /* Read-only VF BARs confuse OVMF */
+        case PCI_EXT_CAP_ID_ARI: /* XXX Needs next function virtualization */
+        case PCI_EXT_CAP_ID_REBAR: /* Can't expose read-only */
+            trace_vfio_add_ext_cap_dropped(vdev->vbasedev.name, cap_id, next);
+```
+
+[Discussion link](https://forum.level1techs.com/t/smart-access-memory-vs-qemu-kvm/169447)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/704 b/gitlab/issues_text/target_missing/host_missing/accel_missing/704
new file mode 100644
index 00000000..c90992a0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/704
@@ -0,0 +1 @@
+linux-user: misaligned address for type 'struct linux_dirent64'
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/707 b/gitlab/issues_text/target_missing/host_missing/accel_missing/707
new file mode 100644
index 00000000..dd3cb3f5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/707
@@ -0,0 +1,62 @@
+The QEMU emulator incorrectly interprets the contents of the SLIC table. See attached image.
+Description of problem:
+The QEMU emulator incorrectly interprets the contents of the SLIC table.
+
+The SLIC table read on pure hardware and in a virtual machine in the fedora 34 and 35:
+
+![windows_slic_read](/uploads/0dd986ab8345db8826c3d1f0655f65be/windows_slic_read.png)
+Steps to reproduce:
+Steps to Reproduce:
+
+1. Install Fedora 34
+
+2. Install virtualization group:
+ 
+      dnf group install virtualization
+
+4. Place SLIC binary image(slic.bin) into the direcrory /var/lib/libvirt/images
+
+3. Create Virtual Machine with Virtual Machine Manager.
+
+4. Modify xml description of virtual machine:
+   `...
+   <os>
+      ...
+      <acpi>
+         <table type='slic'>/var/lib/libvirt/images/slic.bin</table>
+      </acpi>
+   </os>
+   ...`
+
+5. Install Microsoft Windows 7 64-bit into Virtual machine.
+
+6. Place sertificate into Windows 7.
+
+7. Run with admin rights:
+
+       slmgr.vbs /ilc <sertificate>
+       slmgr.vbs /ipk <key>
+
+8. Windows 7 will be activated !
+
+9. Save Virtual Machine Image and it's xml description anywere.
+
+10. Install Fedora 35
+
+11. Install virtualization group.
+
+12. Place saved Virtual Machine Image and slic.bin into the directory /var/lib/libvirt/images/
+
+13. Register virtual machine:
+
+        virsh -c qemu:///system define <xml_file>
+
+15. Run virtual machine - Windows 7 will lose it activation.
+Additional information:
+Fedora 34 has:
+    kernel-5.14.15-200.fc34.x86_64, qemu-system-x86-5.2.0-8.fc34.x86_64
+
+Fedora 35 has:
+    kernel-5.14.15-300.fc35.x86_64, qemu-system-x86-6.1.0-9.fc35.x86_64
+
+Slick Binary Image: [slic.bin](/uploads/da94a96516c3dbe52803fb84738f434c/slic.bin)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/708 b/gitlab/issues_text/target_missing/host_missing/accel_missing/708
new file mode 100644
index 00000000..da665aec
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/708
@@ -0,0 +1,10 @@
+some TPM related files are missing in sysfs when enable passthrough TPM
+Description of problem:
+When enable passthrough TPM, there are some files in sysfs are missing, like description, uid file.
+under the host linux, we have those file in it:
+root@intel-x86-64:/sys/class/tpm/tpm0/device/firmware_node# cat description 
+TPM 2.0 Device
+root@intel-x86-64:/sys/class/tpm/tpm0/device/firmware_node# cat uid 
+1
+Steps to reproduce:
+after boot into system, check sysfs, there is no description and uid file in /sys/class/tpm/tpm0/device/firmware_node
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/709 b/gitlab/issues_text/target_missing/host_missing/accel_missing/709
new file mode 100644
index 00000000..90badcf8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/709
@@ -0,0 +1 @@
+make command fail
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/71 b/gitlab/issues_text/target_missing/host_missing/accel_missing/71
new file mode 100644
index 00000000..91510a0f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/71
@@ -0,0 +1 @@
+AC97 can allocate ~500MB of host RAM
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/711 b/gitlab/issues_text/target_missing/host_missing/accel_missing/711
new file mode 100644
index 00000000..4df5ca10
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/711
@@ -0,0 +1 @@
+ATI Rage video card emulation
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/712 b/gitlab/issues_text/target_missing/host_missing/accel_missing/712
new file mode 100644
index 00000000..a1a0fd43
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/712
@@ -0,0 +1,14 @@
+Build fails if build directory name includes a comma
+Description of problem:
+Builds fail if the build directory name contains a comma.
+Steps to reproduce:
+1. `mkdir build,demo && cd build,demo`
+2. `../configure && make`
+
+The linker fails because it uses a wrong build path (comma and trailing part of directory name is missing):
+
+```
+ld: can't read -exported_symbols_list file: /Users/stefan/src/gitlab/qemu-project/qemu/build
+clang: error: linker command failed with exit code 1 (use -v to see invocation)
+ninja: build stopped: subcommand failed.
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/713 b/gitlab/issues_text/target_missing/host_missing/accel_missing/713
new file mode 100644
index 00000000..9ef53322
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/713
@@ -0,0 +1 @@
+Missing safe-syscall.inc.S for mips
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/716 b/gitlab/issues_text/target_missing/host_missing/accel_missing/716
new file mode 100644
index 00000000..8a26baf1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/716
@@ -0,0 +1,3 @@
+using "-device scsi-cd" option on arm64 platform
+Description of problem:
+When using OpenStack to create a virtual machine instance, I need to configure the password of the root user through cloud-init. I use the ConfigDriver method, in which OpenStack will mount a virtual disk in iso9660 format to the virtual machine instance. The command line generated by OpenStack is shown above. You can see that this ConfigDrive virtual disk is mounted via "--device scsi-cd". But when I entered the virtual machine instance and used lsblk, blkid and searched in /dev/disk/by-label, I did not find the virtual disk that should be mounted. In addition, I don't have more debugging messages or error messages. I want to know if the "scsi-cd" is not fully adapted to arm64 platform.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/718 b/gitlab/issues_text/target_missing/host_missing/accel_missing/718
new file mode 100644
index 00000000..2a98037a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/718
@@ -0,0 +1,6 @@
+option to take screenshot with screendump as PNG
+Additional information:
+Libvirt already have preparation for PNG MIME type: https://github.com/libvirt/libvirt/blob/master/tools/virsh-domain.c#L5526
+
+
+Thanks
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/719 b/gitlab/issues_text/target_missing/host_missing/accel_missing/719
new file mode 100644
index 00000000..66c48c6a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/719
@@ -0,0 +1,19 @@
+live migration's performance with compression enabled is much worse than compression disabled
+Description of problem:
+
+Steps to reproduce:
+1. Run QEMU the Guests with 1Gpbs network on source host and destination host with QEMU command line
+2. Run some memory work loads on Guest, for example, ./memtester 1G 1
+3. Set migration parameters in QEMU monitor. On source and destination, 
+   execute: #migrate_set_capability compress on
+   Other compression parameters are all default. 
+4. Run migrate command, # migrate -d tcp:10.156.208.154:4000
+5. The results: 
+   - without compression：  total time:  197366 ms   throughput:   937.81 mbps  transferred Ram: 22593703 kbytes 
+   - with compression: total time:  281711 ms   throughput:  90.24 mbps    transferred Ram: 3102898 kbytes  
+
+When compression is enabled, the compression transferred ram is reduced a lot. But the throughput is down badly.
+The total time of live migration with compression is longer than without compression. 
+I tried with 100G network bandwidth, it also has the same problem.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/72 b/gitlab/issues_text/target_missing/host_missing/accel_missing/72
new file mode 100644
index 00000000..8afb1d3d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/72
@@ -0,0 +1 @@
+mouse offset or invisible wall 2.11.0-3
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/721 b/gitlab/issues_text/target_missing/host_missing/accel_missing/721
new file mode 100644
index 00000000..b7347372
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/721
@@ -0,0 +1,30 @@
+Build failed at libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o
+Steps to reproduce:
+1. Download and build from source
+
+```
+wget https://download.qemu.org/qemu-6.1.0.tar.xz
+tar xvJf qemu-6.1.0.tar.xz
+cd qemu-6.1.0
+./configure
+make
+```
+Additional information:
+```
+[2150/9644] Compiling C object libqemu-alpha-softmmu.fa.p/migration_dirtyrate.c.o
+[2151/9644] Compiling C object libqemu-alpha-softmmu.fa.p/migration_ram.c.o
+[2152/9644] Compiling C object libqemu-alpha-softmmu.fa.p/target_alpha_fpu_helper.c.o
+[2153/9644] Compiling C object libqemu-aarch64-softmmu.fa.p/accel_tcg_translate-all.c.o
+[2154/9644] Compiling C object libqemu-alpha-softmmu.fa.p/migration_target.c.o
+[2155/9644] Compiling C object libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o
+FAILED: libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o
+gcc -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -I../dtc/libfdt -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/valgrind -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/intel/Sources/qemu-6.1.0/linux-headers -isystem linux-headers -iquote . -iquote /home/intel/Sources/qemu-6.1.0 -iquote /home/intel/Sources/qemu-6.1.0/include -iquote /home/intel/Sources/qemu-6.1.0/disas/libvixl -iquote /home/intel/Sources/qemu-6.1.0/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -m64 -mcx16 -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 -g -O3 -feliminate-unused-debug-types -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -Wformat -Wformat-security -m64 -fasynchronous-unwind-tables -Wp,-D_REENTRANT -ftree-loop-distribute-patterns -Wl,-z -Wl,now -Wl,-z -Wl,relro -fno-semantic-interposition -ffat-lto-objects -fno-trapping-math -Wl,-sort-common -Wl,--enable-new-dtags -mtune=skylake -fPIE -isystem../linux-headers -isystemlinux-headers -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_cputlb.c.o -MF libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o.d -o libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o -c ../accel/tcg/cputlb.c
+during GIMPLE pass: fab
+In file included from /home/intel/Sources/qemu-6.1.0/include/qemu/osdep.h:37,
+                 from ../accel/tcg/cputlb.c:20:
+../accel/tcg/atomic_common.c.inc: In function ‘helper_atomic_fetch_andb’:
+/home/intel/Sources/qemu-6.1.0/include/exec/helper-head.h:21:27: internal compiler error: in optimize_atomic_bit_test_and, at tree-ssa-ccp.c:3245
+   21 | #define HELPER(name) glue(helper_, name)
+      |                           ^~~~~~~
+/home/intel/Sources/qemu-6.1.0/include/qemu/compiler.h:35:21: note: in definition of macro ‘xglue’
+   35 | #define xglue(x, y) x
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/722 b/gitlab/issues_text/target_missing/host_missing/accel_missing/722
new file mode 100644
index 00000000..011ccd9c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/722
@@ -0,0 +1,12 @@
+Qemu slirp connectivity lost when host enters vpn(openvpn or wireguard)
+Description of problem:
+No connectivity after host enters a vpn, tested with valid openvpn
+and wireguard.
+Steps to reproduce:
+1. Open the vpn.
+2. Open a virtual machine using slirp
+3. Ping 8.8.8.8(if you can...)
+Additional information:
+The bug is independent on the order of execution, if you start the vm
+to see it works, and run the vpn script, the connectivity in the vm
+will drop, and come back when the tunneled connection is over.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/723 b/gitlab/issues_text/target_missing/host_missing/accel_missing/723
new file mode 100644
index 00000000..1b939140
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/723
@@ -0,0 +1,31 @@
+multiple displays VGA + qxl forces Spice mouse-mode=server and breaks usb-tablet/seamless mode
+Description of problem:
+qxl causes a totally unexpected mouse conflict with the default VGA in OSX Catalina and newer guests using AppleVirtualGraphics.kext 
+
+usb-tablet is unusable - only clicks are received
+usb-mouse works but grabs focus
+Steps to reproduce:
+1. install and run OSX guest
+2. connect to Spice port 
+3. can't move mouse if usb-tablet is used. usb-mouse pointer but is grabbed 
+4. removing qxl fixed the issue for me. Mouse is seamless/not grabbed now 
+5. added -spice agent-mouse=on just in case
+Additional information:
+qmp from broken shows mouse-mode server.  Working guests show mouse-mode client
+
+```
+{ "execute": "query-spice" }
+... "mouse-mode": "server"}}
+```
+- spice works with multiple displays in OSX if both are VGA but I had the same focus problem, will need to recheck because Qemu 6.1 seems stuck on mouse-mode=server.
+
+
+Working VGA 
+```
+/usr/bin/qemu-system-x86_64 -name macos-big-sur,process=macos-big-sur -pidfile macos-big-sur/macos-big-sur.pid -enable-kvm -machine q35,smm=off,vmport=off -device isa-applesmc,osk=ourhardworkbythesewordsguardedpleasedontsteal\(c\)AppleComputerInc -no-hpet -global kvm-pit.lost_tick_policy=discard -cpu host,kvm=on,vendor=GenuineIntel,+hypervisor,+invtsc,+kvm_pv_eoi,+kvm_pv_unhalt -smp cores=2,threads=1,sockets=1 -m 8G -device virtio-balloon -smbios type=2,manufacturer="Wimpys World",product=Quickemu,version=2.3.1,serial=jvzclfjbeyq.pbz,location=wimpysworld.com,asset=macos-big-sur -device VGA,vgamem_mb=128 -display none -device usb-ehci,id=input -device usb-kbd,bus=input.0 -device usb-tablet,bus=input.0 -rtc base=localtime,clock=host,driftfix=slew -spice disable-ticketing=on,agent-mouse=on,port=5930 -device virtio-serial-pci -chardev socket,id=agent0,path=macos-big-sur/macos-big-sur-agent.sock,server=on,wait=off -device virtserialport,chardev=agent0,name=org.qemu.guest_agent.0 -device virtio-rng-pci,rng=rng0 -object rng-random,id=rng0,filename=/dev/urandom -chardev socket,id=monitor0,path=macos-big-sur/macos-big-sur-monitor.sock,server=on,wait=off -mon chardev=monitor0,id=monitor,mode=control -monitor none -serial mon:stdio -audiodev spice,id=audio0 -device ich9-intel-hda -device hda-duplex,audiodev=audio0 -device virtio-net,netdev=nic -netdev user,hostname=macos-big-sur,hostfwd=tcp::22220-:22,id=nic -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,unit=0,file=macos-big-sur/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=macos-big-sur/OVMF_VARS-1024x768.fd -device ahci,id=ahci -device ide-hd,bus=ahci.0,drive=BootLoader,bootindex=0 -drive id=BootLoader,if=none,format=qcow2,file=macos-big-sur/OpenCore.qcow2 -device virtio-blk-pci,drive=SystemDisk -drive id=SystemDisk,if=none,format=qcow2,file=macos-big-sur/disk.qcow2 -device qemu-xhci,id=spicepass -chardev spicevmc,id=usbredirchardev1,name=usbredir -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1 -chardev spicevmc,id=usbredirchardev2,name=usbredir -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2 -chardev spicevmc,id=usbredirchardev3,name=usbredir -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3 -device usb-ccid -chardev spicevmc,id=ccid,name=smartcard -device ccid-card-passthru,chardev=ccid -device virtio-serial-pci -chardev spiceport,id=webdav0,name=org.spice-space.webdav.0 -device virtserialport,chardev=webdav0,name=org.spice-space.webdav.0 -fsdev local,id=fsdev0,path=/home/jmorrison/Public,security_model=mapped-xattr -device virtio-9p-pci,fsdev=fsdev0,mount_tag=Public-jmorrison
+```
+
+Broken usb-tablet qxl
+```
+/usr/bin/qemu-system-x86_64 -name macos-big-sur,process=macos-big-sur -pidfile macos-big-sur/macos-big-sur.pid -enable-kvm -machine q35,smm=off,vmport=off -device isa-applesmc,osk=ourhardworkbythesewordsguardedpleasedontsteal\(c\)AppleComputerInc -no-hpet -global kvm-pit.lost_tick_policy=discard -cpu host,kvm=on,vendor=GenuineIntel,+hypervisor,+invtsc,+kvm_pv_eoi,+kvm_pv_unhalt -smp cores=2,threads=1,sockets=1 -m 8G -device virtio-balloon -smbios type=2,manufacturer="Wimpys World",product=Quickemu,version=2.3.1,serial=jvzclfjbeyq.pbz,location=wimpysworld.com,asset=macos-big-sur -device qxl -display none -device usb-ehci,id=input -device usb-kbd,bus=input.0 -device usb-tablet,bus=input.0 -rtc base=localtime,clock=host,driftfix=slew -spice disable-ticketing=on,port=5930 -device virtio-serial-pci -chardev socket,id=agent0,path=macos-big-sur/macos-big-sur-agent.sock,server=on,wait=off -device virtserialport,chardev=agent0,name=org.qemu.guest_agent.0 -device virtio-rng-pci,rng=rng0 -object rng-random,id=rng0,filename=/dev/urandom -chardev socket,id=monitor0,path=macos-big-sur/macos-big-sur-monitor.sock,server=on,wait=off -mon chardev=monitor0,id=monitor,mode=control -monitor none -serial mon:stdio -audiodev spice,id=audio0 -device ich9-intel-hda -device hda-duplex,audiodev=audio0 -device virtio-net,netdev=nic -netdev user,hostname=macos-big-sur,hostfwd=tcp::22220-:22,id=nic -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,unit=0,file=macos-big-sur/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=macos-big-sur/OVMF_VARS-1024x768.fd -device ahci,id=ahci -device ide-hd,bus=ahci.0,drive=BootLoader,bootindex=0 -drive id=BootLoader,if=none,format=qcow2,file=macos-big-sur/OpenCore.qcow2 -device virtio-blk-pci,drive=SystemDisk -drive id=SystemDisk,if=none,format=qcow2,file=macos-big-sur/disk.qcow2 -device qemu-xhci,id=spicepass -chardev spicevmc,id=usbredirchardev1,name=usbredir -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1 -chardev spicevmc,id=usbredirchardev2,name=usbredir -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2 -chardev spicevmc,id=usbredirchardev3,name=usbredir -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3 -device usb-ccid -chardev spicevmc,id=ccid,name=smartcard -device ccid-card-passthru,chardev=ccid -device virtio-serial-pci -chardev spiceport,id=webdav0,name=org.spice-space.webdav.0 -device virtserialport,chardev=webdav0,name=org.spice-space.webdav.0 -fsdev local,id=fsdev0,path=/home/jmorrison/Public,security_model=mapped-xattr -device virtio-9p-pci,fsdev=fsdev0,mount_tag=Public-jmorrison
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/724 b/gitlab/issues_text/target_missing/host_missing/accel_missing/724
new file mode 100644
index 00000000..c6bbe4d5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/724
@@ -0,0 +1 @@
+esp: heap-buffer-overflow in esp_fifo_pop_buf
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/726 b/gitlab/issues_text/target_missing/host_missing/accel_missing/726
new file mode 100644
index 00000000..0740ba5a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/726
@@ -0,0 +1 @@
+Missing 6.2.0-rc0 tarball on https://download.qemu.org/
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/727 b/gitlab/issues_text/target_missing/host_missing/accel_missing/727
new file mode 100644
index 00000000..2ed6bc8e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/727
@@ -0,0 +1,156 @@
+VHDX is corrupted on expansion
+Description of problem:
+Fresh VHDX corrupts with data loss upon copying data into it.
+Steps to reproduce:
+1. Create new dynamic vhdx file of about 93Gib (unexpanded, starting size is small ~205Mib, freshly created and NTFS formatted in windows.) 
+2. Connect drive using qemu-nbd to /dev/nbd0
+3. Ensure partition using gdisk
+4. format partition with ntfs/ExFAT volume
+5. mount volume
+6. copy/rsync data of about 85Gib of data into the mounted volume
+7. unmount volume
+8. disconnect /dev/nbd0
+9. reconnect /dev/nbd0
+10. attempt mount, sometimes mount may fail if corrupted
+11. If mount succeeds, verify data/all-files using some method like sha256sum. Some data is likely to fail
+
+Given the amount of data I am rsync-ing into the volume, there is very high chance of corruption. 
+
+The corruption is not apparent until **disconnection and reconnection** of virtual-disk. Simply unmounting and remounting without disconnecting is unlikely to cause one to suspect corruption. 
+
+If the expanded corrupted volume is again disconnected, reconnected, reformatted and data is again re-copied onto it, then the volume is less likely to experience a corruption, perhaps because new block allocation is not required.
+
+Errors vary and include:
+- sometimes mount fails
+- sometimes ls -l output is garbled
+- sometimes one cannot cd into a directory
+- several consecutive errors in shasum256 start midway through the file-list processing. Error is shown as if rsync failed and files do not exist.
+  ```
+  sha256sum: ./201207/IMG_2406.JPG: No such file or directory
+  ./201207/IMG_2406.JPG: FAILED open or read
+  ```
+- Doing chdsk on windows may just create FOUND.000/FILE0000.CHK files.
+Additional information:
+See comment https://gitlab.com/qemu-project/qemu/-/issues/136#note_731044761 from where this all began. Some summary included here.
+
+```
+[root@sirius a16]# uname -a
+Linux sirius 5.15.0-60.fc35.x86_64 #1 SMP Tue Nov 2 15:38:03 IST 2021 x86_64 x86_64 x86_64 GNU/Linux
+
+[root@sirius ~]# qemu-system-x86_64 --version
+QEMU emulator version 6.1.0 (qemu-6.1.0-10.fc35)
+Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
+
+[root@sirius ~]# cat /etc/mtab | grep -E "a16|a17" | grep ntfs3
+/dev/sda16 /mnt/a16 ExFAT rw,relatime,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro 0 0
+/dev/sda17 /mnt/a17 ntfs3 rw,relatime,uid=0,gid=0,iocharset=utf8 0 0
+
+[root@sirius ~]# uname -a # self-built rpmbuild kernel from fedora rawhide kernel-src rpm 
+Linux sirius 5.15.0-60.fc35.x86_64 #1 SMP Tue Nov 2 15:38:03 IST 2021 x86_64 x86_64 x86_64 GNU/Linux
+```
+
+Test/Activity being done: About 85Gib of data is copied onto a size 93Gib VHDX on host-FS ntfs3 with guest-FS ntfs3. 
+```
+Prefer windows method: Inside windows-10, using powershell command New-VHD, one may a 93Gib VHDX
+  New-VHD -Path I:\gkpics01.vhdx -SizeBytes 99723771904 -Dynamic
+  Then attach disk and format volume inside to ntfs.
+or Alternatively, Linux method (less preferred)
+  qemu-img create -f qcow2 /mnt/a16/gkpics01.qcow2 99723771904
+  qemu-img create -f vhdx -o subformat=dynamic /mnt/a16/gkpics01.vhdx 99723771904
+:
+sync ; sleep 1 ; qemu-nbd -c /dev/nbd0 /mnt/a16/gkpics01.vhdx
+:
+create appropriate partitions on /dev/nbd0 if not already partitioned
+gdisk /dev/nbd0 
+:
+format volume with filesystem ntfs, or ext4 etc if not already formatted
+mkfs -t ntfs -Q -L fs_gkpics01 /dev/nbd0p2 
+:
+mount partition
+sync ; sleep 1 ; mount -t ntfs3 /dev/nbd0p2 /mnt/t1
+:
+do copy/rsync etc
+( fl="photos001" ; src="/mnt/c13" ; dst="/mnt/t1" ; cd "$src" ;rsync -avH "$fl" "$dst" ; sudo -u gana DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0.0 -- notify-send "$src/$fl" "rsync $src/$fl" )
+:
+sync ; sleep 1 ; umount /mnt/t1
+:
+sync ; sleep 1 ; blockdev --flushbufs /dev/nbd0 ; sleep 2 ; qemu-nbd -d /dev/nbd0 ; sleep 1 ; sync
+:
+sync ; sleep 1 ; qemu-nbd -c /dev/nbd0 /mnt/a16/gkpics01.vhdx
+:
+sync ; sleep 1 ; mount -t ntfs3 /dev/nbd0p2 /mnt/t1
+:
+do ls-l/verify/sha256sum-c etc
+( fl="photos001" ; rtpt="/mnt/t1" ; cd "${rtpt}/${fl}" ; sdate=`date` ; echo "$sdate" ; sha256sum -c "$rtpt/$fl/find.CHECKSUM" --quiet ; echo "$sdate" ; date ; sudo -u gana DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0.0 -- notify-send "$src/$fl" "checksum $src/$fl" )
+```
+
+In the below list detailing under what circumstance corruption occurs
+
+- Format:  kernel-version/ disk-attaching-sw/ hostFS/ VDISK/ guestFS with any parameters in parenthesis.
+- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ntfs3/VHDX/ntfs3
+- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ntfs3/VHDX/ext4
+- Corruption does happen with kernel-5.15.0-60/guestfish-1.46.0(backend=direct)/ntfs3/VHDX/ntfs3
+- Corruption does happen with kernel-5.15.0-60/guestfish-1.46.0(backend=libvirt-7.6.0-3)/ntfs3/VHDX/ntfs3
+- Corruption does happen on host-FS **ExFAT too** with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX/ntfs3
+- Corruption does happen with kernel-5.15.0-60/qemu-6.0.0-10/ExFAT/VHDX/ntfs3
+- Corruption does happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/VHDX/ntfs3g-fuseblk
+- Corruption does happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/VHDX(created by qemu-img)/ntfs3g-fuseblk
+  ``` Failed to mount '/dev/nbd0p2': Input/output error NTFS is either inconsistent, or there is a hardware fault,```
+- Corruption does **not** happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/qcow2/ext4
+- Corruption does **not** happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/qcow2/ntfs3g-fuseblk
+- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX(cache=none,aio=threads)/ntfs3
+- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX(cache=none,aio=io_uring)/ntfs3
+- VHDX fixed disk grows in size. Filed as different bug: https://gitlab.com/qemu-project/qemu/-/issues/806 
+  - Corruption **does happen** with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX(fixed)/ntfs3
+    A fixed vhdx disk should not grow in size. It is as if the blocks are added to a vhdx-journal instead of overwriting preallocated blocks.
+- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ext4/VHDX/ntfs3
+- Corruption does happen with kernel-5.15.2-200/**qemu-6.2.0-rc1**/ExFAT/VHDX/ntfs3
+- Corruption does **not** happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/**VMDK**(v4,monolithicSparse)/ntfs3
+- Corruption does not happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/VMDK(compat6,monolithicSparse)/ntfs3
+- Corruption does **not** happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/**VDI**/ntfs3
+- Corruption does **not** happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/**VPC**(dynamic)/ntfs3
+- Corruption does happen with kernel-5.15.2-200/**qemu-5.2.0-8**/ExFAT/VHDX/ntfs3
+- Corruption does happen with kernel-5.15.2-200/**qemu-4.2.1-1**/ExFAT/VHDX/ntfs3
+- Corruption does happen with vhdx-file is on 2Tb NTFS 1Tb partition of **external USB HDD** 2Tb,  with kernel-5.15.2-200/qemu-6.2.0-rc1/ntfs3/VHDX/ntfs3
+- Corruption does happen when using src is on ntfs3 partition on external USB drive, which is **generated synthetic data (sgdata)** sgdata/kernel-5.15.2-200/qemu-6.2.0-rc1/ExFat/VHDX/ntfs3
+- Corruption does happen when starting with qemu-img created vhdx image with sgdata/kernel-5.15.2-200/qemu-6.2.0-rc1/ExFat/VHDX(created by qemu-img)/ext4 superblock mount fail
+- Corruption does happen older fc34-kernel on Fedora-35, sgdata/kernel-5.13.19-200/qemu-6.2.0-rc2/ExFAT/VHDX/ntfs3g-fuseblk , different, fewer files 3 small files affected
+- Corruption does happen with older fc32-kernel on Fedora-35, sgdata/kernel-5.11.22-100/qemu-6.2.0-rc2/ExFAT/VHDX/ntfs3g-fuseblk , fewer files, different, but same as above  3 small files affected, 
+- Corruption does happen with older fc32-kernel on Fedora-35, sgdata/kernel-5.11.22-100/qemu-6.2.0-rc2/ExFAT/VHDX/ext4  
+- Corruption does happen with self-built 5.10 LTS kernel on Fedora-35, sgdata/kernel-5.10.90-200/qemu-6.2.0-1/ExFAT/VHDX/ext4 (sgdata accessed using ntfs-fuseblk)  
+- As the host kernel invoking qemu-nbd, these kernels showed less errors than if they were run inside a VM as a guest. If run as a guest VM, These kernels, 5.15.4 and above, may also have kernel bugs https://bugzilla.kernel.org/show_bug.cgi?id=215460 or https://bugzilla.kernel.org/show_bug.cgi?id=215563 resulting in additional compounded errors in the failure test results, even in raw-img and qcow2(fixed).
+  - Corruption does happen with sgdata/kernel-5.15.4-201/qemu-6.2.0-rc1/ExFAT/VHDX(created by qemu-img)/ext4
+  - Corruption does happen with sgdata/kernel-5.15.4-201/**qemu-6.2.0-rc2**/ExFAT/VHDX(created by qemu-img)/ext4
+  - Corruption does not happen with synthetic-data sgdata/kernel-5.15.4-201/qemu-6.2.0-rc2/ExFAT/VMDK(created by qemu-img)/ext4
+  - Corruption does happen with sgdata/kernel-5.15.5-200/qemu-6.2.0-rc2/ExFAT/VHDX(created by qemu-img)/ext4
+  - Corruption does not happen with sgdata/kernel-5.15.4-201/nbdkit-1.28.2-nbdplugin-qemu-6.2.0-0.rc2/ExFAT/vmdk/ntfs3
+  - Corruption does not happen with sgdata/kernel-5.15.4-201/nbdkit-1.28.2-nbdplugin/ExFAT/vmdk-nbd-vddkplugin/ntfs3
+  - Corruption does happen with sgdata/kernel-5.15.4-201/nbdkit-1.28.2-nbdplugin-qemu-6.2.0-0.rc2/ExFAT/VHDX/ntfs3
+  - Corruption does happen with sgdata/kernel-5.15.6-200 to kernel-5.15.13-200 /qemu-6.2.0-0.rc2/ExFAT/VHDX/ntfs3
+- On Windows-10, these tests may possibly be different bug. Also causes system-wide DiskIO stuck in addition to corruption https://github.com/cloudbase/wnbd/issues/63
+  - Corruption does happen with sgdata/**WIN10**-21H2-19044-1415/**WNBD**-0.2.2-4-g10c1fbe/qemu-6.2.0-rc4/ExFAT/VHDX/NTFS
+  - Corruption **does happen** with sgdata/**WIN10**-21H2-19044-1415/**WNBD**-0.2.2-4-g10c1fbe/qemu-6.2.0-rc4/ExFAT/**qcow2**/NTFS 
+- Possibly different bug, on Windows-10, corruption of virtual-disk from inside VM, no nbd . Maybe https://bugzilla.kernel.org/show_bug.cgi?id=215460 or https://bugzilla.kernel.org/show_bug.cgi?id=215563
+  - Win10-21H2-19044-1415/WHPX/ExFAT/qemu-6.2.0-rc4/alpine-linux-3.15/kernel-5.15.4/VHDX/ntfs3
+  - Win10-21H2-19044-1415/WHPX/ExFAT/qemu-6.2.0-rc4/alpine-linux-3.15/kernel-5.15.4/**qcow2**/ext4
+- Corruption does **not** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/**qcow2(dyn)**/ntfs3 data-src: VHDX(dyn)/ntfs3/sgdata
+- Corruption does **not** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/qcow2(dyn)/ntfs3 data-src: VHDX(dyn)/**ntfs-fuseblk**/sgdata
+- Corruption **does** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/**VHDX**/ntfs3 data-src: VHDX(dyn)/ntfs3/sgdata
+- Corruption **does** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/VHDX/ext4 data-src: VHDX(dyn)/**ntfs-fuseblk**/sgdata
+- Corruption **does** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/**Rocky-8.5-Workstation-20211114.iso**/**kernel-4.18.0-348.el8.0.2.x86_64**/ExFAT/VHDX/ext4 data-src: VHDX(dyn)/**ntfs-fuseblk**/sgdata
+
+ExFAT filesystem was considered because it does not have concept of sparse files eliminating that factor from troubleshooting. Furthermore, it may be incorrect to suspect NTFS3, ExFAT or NTFS3g-fuseblk only because they are new/recently mainstreamed filesystems, as there aren't any intense/complex filesystem operations. The filesystem is experiencing only though-put and files are simply copied into it without further operations. Furthermore, ext4 also experiences corruption if on VHDX.
+
+It just seems to me the VHDX support implementation has bugs, corrupts and hence is not reliable.
+
+The qemu test-suite needs test-cases added for testing for vhdx-stress and vhdx-throughput .
+
+More troubleshooting test results are summarized in https://gitlab.com/qemu-project/qemu/-/issues/727#note_745711084
+
+Chief suspect files
+- ~~kernel: nbd: [drivers/block/nbd.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/block/nbd.c)~~ can be made to happen via VM
+- ~~kernel: ntfs3~~ no ntfs3 partition required
+- ~~kernel 5.x series~~ bug exists in 4.18.0.348
+- ~~qemu: block~~ doesn't happen to other virtual-disk formats (raw,qcow2) 
+- qemu/VM : seems to happen only when using qemu-nbd or inside qemu-VM
+- qemu: [block/vhdx.c](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx.c) , [block/vhdx_log.c](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx-log.c) , [block/vhdx-endian.c](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx-endian.c) , [block/vhdx.h](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx.h),
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/728 b/gitlab/issues_text/target_missing/host_missing/accel_missing/728
new file mode 100644
index 00000000..97762077
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/728
@@ -0,0 +1,16 @@
+Catch up to latest VHDX v2(=0x01) rev-7.0 specification
+Additional information:
+Below issues need to be addressed before or during the tackling of this issue.
+- ~#727 VHDX is corrupted on expansion.~
+- #136 windows qemu-img create vpc/vhdx error due to sparse files
+- #1605 On windows, 2nd kind vhdx-dyn bug, crash on Unexpected error in bdrv_check_qiov_request() in io.c 
+- #806 Fixed VHDX inflates beyond its fixed size when data is copied onto it and also corrupts
+- 
+This VHDX support applies to qemu build on any architecture, not just the windows-build.
+
+It is very likely, that the native hypervisor on windows WHPX will be the main hypervisor displacing haxm/vbox etc. VHDX, if it works, seems to be the virtual-disk format that is ideal 
+- for Linux/windows dual-boot machines, 
+- for clusters with Linux/windows servers sharing images from a network-storage  
+- for WSL2/Hyper-V
+
+Following a similar line of thought, NTFS/ExFat may be ideal for sharing data/images between Linux and Windows. So the storing, modification and drive attachment of VHDX files on these filesystems need to be just as well-tested as native Linux filesystems. As their driver are internal-kernel-drivers and not fuse/dokan-drivers, on both operating-systems, they are also performant.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/731 b/gitlab/issues_text/target_missing/host_missing/accel_missing/731
new file mode 100644
index 00000000..32acc7bf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/731
@@ -0,0 +1,21 @@
+Display resolution fixed by 800x600 with latest VirtIO drivers and guest additions
+Description of problem:
+Display resolution can't be changed to anything else than 800x600.
+Steps to reproduce:
+1. Install qemu/kvm
+2. Create virtual machine
+3. Setup Windows 10
+4. Install VirtIO-Drivers
+5. Install guest-agent
+6. Install qxl-drivers
+
+Steps 5 and 6 enable use of QXL-Display, but do not lead to allow for higher display resolutions than before.
+Additional information:
+![Screenshot_w10_2021-11-16_17_18_07](/uploads/0b9bcd234c917a4730b41c4c063d867c/Screenshot_w10_2021-11-16_17_18_07.png)
+![Screenshot_w10_2021-11-16_17_18_38](/uploads/1f4a1099b2274d61f4dec117cba4d06c/Screenshot_w10_2021-11-16_17_18_38.png)
+![Screenshot_w10_2021-11-16_17_26_17](/uploads/2d48b8f35673a144e1c961387aa2b433/Screenshot_w10_2021-11-16_17_26_17.png)
+Screen resolution is fixed by 800x600.
+Driver is installed, but seems to have a problem (Attention sign. Warning, Error: digital signatur could not be checked -- at least there is no how to to make the existing signature work).
+Latest available VirtIO-drivers where used as available from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso 
+
+Older available drivers did not work too as expected. Same problem. Could not check older Windows 10 versions, because of lack of older install media.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/732 b/gitlab/issues_text/target_missing/host_missing/accel_missing/732
new file mode 100644
index 00000000..0bcc01b4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/732
@@ -0,0 +1 @@
+Can not use --enable-fuzzing on Ubuntu 20.04 Aarch64
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/733 b/gitlab/issues_text/target_missing/host_missing/accel_missing/733
new file mode 100644
index 00000000..e711bc35
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/733
@@ -0,0 +1,33 @@
+Qemu Adventcalendar 2020 ELKS fails to run with error "qemu-system-x86_64: at most one isa-vga device is permitted"
+Description of problem:
+Running ELKS from Qemu Advent calendar results in:
+qemu-system-x86_64: at most one isa-vga device is permitted
+Steps to reproduce:
+(with ELKS)
+1. Untar https://download.qemu.org/qemu-6.2.0-rc0.tar.xz
+1. Build qemu-system-x86_64
+2. Download https://www.qemu-advent-calendar.org/2020/download/day23.tar.gz
+3. Execute ELKS as described in run.sh
+Additional information:
+A git bisect was performed to identify the culprit commit:
+```
+qemu$ git bisect good
+binäre Suche: danach noch 1 Commit zum Testen übrig (ungefähr 1 Schritt)
+[2b3a98255c90d8d2f9f87a73eb33371961508517] hw/display/xlnx_dp: fix an out-of-bounds read in xlnx_dp_read
+
+qemu$ ./configure --target-list=x86_64-softmmu --disable-linux-user && make -j2
+
+qemu$ build/qemu-system-x86_64 -machine isapc -vga std
+qemu-system-x86_64: at most one isa-vga device is permitted
+
+qemu$ git bisect bad
+binäre Suche: danach noch 0 Commits zum Testen übrig (ungefähr 0 Schritte)
+[7852a77f598635a67a222b6c1463c8b46098aed2] vga: don't abort when adding a duplicate isa-vga device
+
+qemu$ cat .git/refs/bisect/bad
+2b3a98255c90d8d2f9f87a73eb33371961508517
+
+qemu$ git status
+HEAD losgelöst bei 7852a77f59
+
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/739 b/gitlab/issues_text/target_missing/host_missing/accel_missing/739
new file mode 100644
index 00000000..1e96c74f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/739
@@ -0,0 +1,17 @@
+qemu option -snapshot not work for blockdev disk
+Description of problem:
+If disk image configured with a -blockdev option, option -snapshot not work: all changes write to disk image instead of temporary files.
+Steps to reproduce:
+1. Run qemu guest with -blockdev disk image file and -snapshot options
+2. Create file test.txt on guest disk
+3. Power off guest
+4. Run qemu guest again
+5. File test.txt present on guest disk
+Additional information:
+When i replace -blockdev options to legacy -drive option
+```
+-snapshot
+-drive if=none,id=ssd1-format,media=disk,cache=none,aio=native,discard=unmap,detect-zeroes=unmap,format=qcow2,file=images/windows21h2.qcow2
+-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=ssd1-format,id=scsi0-0-0-0,write-cache=on,bootindex=1
+```
+-snapshot option work fine
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/74 b/gitlab/issues_text/target_missing/host_missing/accel_missing/74
new file mode 100644
index 00000000..767454b6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/74
@@ -0,0 +1 @@
+AUD_set_volume_out takes SWVoiceOut as parameter, but controls HWVoiceOut
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/741 b/gitlab/issues_text/target_missing/host_missing/accel_missing/741
new file mode 100644
index 00000000..b5d772e3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/741
@@ -0,0 +1 @@
+Document "net/net.h" API
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/746 b/gitlab/issues_text/target_missing/host_missing/accel_missing/746
new file mode 100644
index 00000000..d4226b1c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/746
@@ -0,0 +1 @@
+Current file VERSION of tag 6.2.0-rc2 contains 6.2.92, not 6.1.92
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/749 b/gitlab/issues_text/target_missing/host_missing/accel_missing/749
new file mode 100644
index 00000000..2765381c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/749
@@ -0,0 +1 @@
+Enhance QEMU live patching
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/75 b/gitlab/issues_text/target_missing/host_missing/accel_missing/75
new file mode 100644
index 00000000..98325b53
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/75
@@ -0,0 +1 @@
+Add -display SDL grab-on-hover option
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/750 b/gitlab/issues_text/target_missing/host_missing/accel_missing/750
new file mode 100644
index 00000000..db373a7a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/750
@@ -0,0 +1,33 @@
+/proc/cpuinfo doesn't present guest cpuinfo for most architectures (including M1 Macs)
+Description of problem:
+I tried to start Blender inside an amd docker container, emulated on M1 Mac, running noVNC to access the the GUI via Chrome.
+From Blender versions 2.8 and higher I get the following error message:
+
+```
+ ArchError: Could not find 'cpu MHz' in /proc/cpuinfo
+  Function: Arch_InitTickTimer
+      File: /home/sybren/buildbot-builder/linux_glibc217_x86_64_cmake/build_deps/deps/build/usd/src/external_usd/pxr/base/arch/timing.cpp
+      Line: 133
+qemu: uncaught target signal 6 (Aborted) - core dumped
+Aborted
+```
+
+I posted the problem to Blender [here](https://developer.blender.org/T92956) as well as to docker [here](https://github.com/docker/for-mac/issues/6047).
+Steps to reproduce:
+You need:
+- ✅ M1 Mac
+- ✅ Docker Desktop 4.1.1 (69879)
+
+Setup the Container:
+
+1. Unzip the attached file
+2. In a terminal go to the unzipped folder
+3. run `source build-and-launch.sh` to build the image and spin up a container
+4. open a browser and go to [http://localhost:6901](http://localhost:6901)
+5. login using password `pass`
+6. see the README.txt on the Desktop you just logged into
+7. == Follow the README instructions ==
+
+
+
+[blender-bug-report-202111091146.zip](/uploads/340ada45a9ee0585cfc0cdfcc1932fb4/blender-bug-report-202111091146.zip)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/751 b/gitlab/issues_text/target_missing/host_missing/accel_missing/751
new file mode 100644
index 00000000..a5866c07
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/751
@@ -0,0 +1 @@
+Default set of CI tasks is quite broad for forks of non-developer respositories
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/753 b/gitlab/issues_text/target_missing/host_missing/accel_missing/753
new file mode 100644
index 00000000..75d1d156
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/753
@@ -0,0 +1 @@
+qemu unable to convert file above 2 TB
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/757 b/gitlab/issues_text/target_missing/host_missing/accel_missing/757
new file mode 100644
index 00000000..03411df3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/757
@@ -0,0 +1 @@
+intel-hda: stream reset bits are broken
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/759 b/gitlab/issues_text/target_missing/host_missing/accel_missing/759
new file mode 100644
index 00000000..72b934fb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/759
@@ -0,0 +1,12 @@
+Copy&Paste does not work on VNC
+Description of problem:
+Cannot copy&paste between host and guest when vnc is used (gtk works fine).
+Steps to reproduce:
+1. Build qemu 6.2-rc2 using the following `./configure` options:
+```
+--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-fuse --enable-fuse-lseek
+```
+2. Run the above qemu command using vnc server. Connect to the VM desktop using `vncviewer :5900` where vncviewer is downloaded from [here](https://www.realvnc.com/en/connect/download/viewer/).
+3. Try to copy and paste something in the terminal between host and guest. It doesn't work.
+Additional information:
+I'm following [this article](https://www.kraxel.org/blog/2021/05/qemu-cut-paste/) which says copy&paste is supported on vnc.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/76 b/gitlab/issues_text/target_missing/host_missing/accel_missing/76
new file mode 100644
index 00000000..999c8319
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/76
@@ -0,0 +1 @@
+Mouse cursor sometimes can't pass the invisible border on the right side of the screen
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/760 b/gitlab/issues_text/target_missing/host_missing/accel_missing/760
new file mode 100644
index 00000000..7b4bcf9c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/760
@@ -0,0 +1,3 @@
+Feature request: QEMU can report its building option
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/761 b/gitlab/issues_text/target_missing/host_missing/accel_missing/761
new file mode 100644
index 00000000..48243548
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/761
@@ -0,0 +1,12 @@
+With -display gtk,gl=on, the position of mouse does not show correctly
+Description of problem:
+With `-display gtk,gl=on`, the cursor of the mouse does not show correctly. So, it's very hard to use mouse on guest OS desktop to, say, open an application or to close it. The displayed mouse cursor is about 300x300 away from the actual mouse position.
+Steps to reproduce:
+1. Build qemu 6.2.0-rc2 using the following `./configure` options:
+```
+--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-fuse --enable-fuse-lseek
+```
+2. Run the above QEMU command with `-display gtk,gl=on`.
+3. Try to open an application by clicking its icon on desktop and to close it by clicking the "X" icon.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/762 b/gitlab/issues_text/target_missing/host_missing/accel_missing/762
new file mode 100644
index 00000000..5481f6d3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/762
@@ -0,0 +1 @@
+Assertion failure in iov_from_buf_full `offset == 0' failed through virtio-net
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/764 b/gitlab/issues_text/target_missing/host_missing/accel_missing/764
new file mode 100644
index 00000000..fce22751
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/764
@@ -0,0 +1,45 @@
+qemu-system-x86 crash (reason: use after free in socket_reconnect_timeout when reconnecting vhost-user dev)
+Description of problem:
+(gdb) bt<br/>
+#0  0x00007f205976b78b in raise () from /usr/lib64/libc.so.6<br/>
+#1  0x00007f205976cab1 in abort () from /usr/lib64/libc.so.6<br/>
+#2  0x00007f205976404a in ?? () from /usr/lib64/libc.so.6<br/>
+#3  0x00007f20597640c2 in __assert_fail () from /usr/lib64/libc.so.6<br/>
+#4  0x00007f20594ea556 in **qemu_mutex_lock_impl**(mutex=<optimized out>, file=<optimized out>, line=<optimized out>)<br/>
+#5  0x00007f205957a4ef in **socket_reconnect_timeout** (opaque=<optimized out>)<br/>
+#6  0x00007f205993b68d in ?? () from /usr/lib64/libglib-2.0.so.0<br/>
+#7  0x00007f205993aba4 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0<br/>
+#8  0x00007f20594e5d49 in glib_pollfds_poll () at /usr/src/debug/qemu-4.1.0-666.x86_64/util/main-loop.c:218<br/>
+#9  0x00007f20594e5dc2 in os_host_main_loop_wait (timeout=<optimized out>)<br/>
+#10 0x00007f20594e5f5d in main_loop_wait (nonblocking=nonblocking@entry=0)<br/>
+... ...<br/>
+#14 0x0000560919e13180 in main (argc=80, argv=0x7ffebc1d0598, envp=0x7ffebc1d0820)<br/>
+
+at the moment, chr had be free by hot unplug vhost-user dev<br/>
+
+I think the bug cause reason as following:<br/>
+1. when vhost-user dev is connecting state, io-task-worker thread will try call tcp_chr_connect_client_async <br/>
+ again and again to reconnect.<br/>
+2. if reconnect fail, io-task-worker thread will switch to main-thread to handle error, and main-thread will <br/> 
+call qemu_chr_socket_restart_timer again to reconnect again. <br/>
+
+3. But, if a hot unplug operation insert to main-thread before io-task-worker switch to main-thread,<br/>
+   the qemu_chr_socket_restart_timer->socket_reconnect_timeout process will use the released chardev and <br/>
+   trigger qemu crash
+
+in short, the primary cause of this bug is io-task-worker reconnect process and <br/>
+main-thread hot unplug vhost-user-dev process in a race.<br/>
+Steps to reproduce:
+1. in qio_task_thread_worker func, add sleep in the following position: <br/>
+      &emsp;task->thread->completion = g_idle_source_new(); <br/>
+      &emsp;g_source_set_callback(task->thread->completion,<br/>
+                          qio_task_thread_result, task, NULL);<br/>
+      &emsp;**sleep(8);**<br/>
+      &emsp;g_source_attach(task->thread->completion,<br/>
+                    task->thread->context);<br/>
+      &emsp;g_source_unref(task->thread->completion);  <br/>
+2. kill spdk proces or dpdk process, qemu will reconnect to the disconnected vhost-user dev of spdk or dpdk <br/>
+3. hot unplug the disconnected vhost-user dev when reconnect logic goto upper sleep position <br/>
+4. qemu_chr_socket_restart_timer will use the chr after free, and trigger qemu crash
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/765 b/gitlab/issues_text/target_missing/host_missing/accel_missing/765
new file mode 100644
index 00000000..57be47ea
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/765
@@ -0,0 +1,65 @@
+Issue with Docker on M1 Mac
+Description of problem:
+I'm trying to run a docker container using the following command:
+
+```
+docker run  --platform=linux/amd64 --rm uphold/litecoin-core \     
+  -printtoconsole \
+  -regtest=1 \
+  -rpcallowip=172.17.0.0/16 \
+  -rpcauth='foo:1e72f95158becf7170f3bac8d9224$957a46166672d61d3218c167a223ed5290389e9990cc57397d24c979b4853f8e'
+```
+
+It should run the docker container, instead it throws the following error:
+```
+/entrypoint.sh: assuming arguments for litecoind
+/entrypoint.sh: setting data directory to /home/litecoin/.litecoin
+runtime: failed to create new OS thread (have 2 already; errno=22)
+fatal error: newosproc
+
+runtime stack:
+runtime.throw(0x4cb21f, 0x9)
+        /usr/local/go/src/runtime/panic.go:566 +0x95
+runtime.newosproc(0xc420028000, 0xc420037fc0)
+        /usr/local/go/src/runtime/os_linux.go:160 +0x194
+runtime.newm(0x4d6db8, 0x0)
+        /usr/local/go/src/runtime/proc.go:1572 +0x132
+runtime.main.func1()
+        /usr/local/go/src/runtime/proc.go:126 +0x36
+runtime.systemstack(0x53ae00)
+        /usr/local/go/src/runtime/asm_amd64.s:298 +0x79
+runtime.mstart()
+        /usr/local/go/src/runtime/proc.go:1079
+
+goroutine 1 [running]:
+runtime.systemstack_switch()
+        /usr/local/go/src/runtime/asm_amd64.s:252 fp=0xc420022768 sp=0xc420022760
+runtime.main()
+        /usr/local/go/src/runtime/proc.go:127 +0x6c fp=0xc4200227c0 sp=0xc420022768
+runtime.goexit()
+        /usr/local/go/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc4200227c8 sp=0xc4200227c0
+```
+Steps to reproduce:
+1. Run the following in a terminal window on a Mac with an M1 chip:
+```
+docker run  --platform=linux/amd64 --rm uphold/litecoin-core \     
+  -printtoconsole \
+  -regtest=1 \
+  -rpcallowip=172.17.0.0/16 \
+  -rpcauth='foo:1e72f95158becf7170f3bac8d9224$957a46166672d61d3218c167a223ed5290389e9990cc57397d24c979b4853f8e'
+```
+Additional information:
+I increased the limits using ``ulimit`` as follows:
+
+```
+clemens@M1-MacBook-Pro ~ % ulimit -a
+-t: cpu time (seconds)              unlimited
+-f: file size (blocks)              unlimited
+-d: data seg size (kbytes)          unlimited
+-s: stack size (kbytes)             8176
+-c: core file size (blocks)         0
+-v: address space (kbytes)          unlimited
+-l: locked-in-memory size (kbytes)  unlimited
+-u: processes                       5333
+-n: file descriptors                256
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/768 b/gitlab/issues_text/target_missing/host_missing/accel_missing/768
new file mode 100644
index 00000000..a90467e9
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/768
@@ -0,0 +1,12 @@
+Mouse cursor disappears in RHEL guest when using "-device virtio-vga-gl -display gtk,gl=on" option
+Description of problem:
+Mouse cursor disappears in RHEL guest when using -device virtio-vga-gl -display gtk,gl=on
+Steps to reproduce:
+1. Build qemu using the following `./configure` options:
+```
+--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-avx512f --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-gio --enable-fuse --enable-fuse-lseek
+```
+2. Install Red Hat Enterprise Linux 8.5 in qemu
+3. Run qemu using the above command line. The mouse cursor disappears once it moves into the VM.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/769 b/gitlab/issues_text/target_missing/host_missing/accel_missing/769
new file mode 100644
index 00000000..1b62c4c7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/769
@@ -0,0 +1,16 @@
+When the VM is about to enter GUI desktop or quit the system, the screen turns upside down.
+Description of problem:
+When the VM is about to enter GUI desktop, the remaining booting message on the screen turns upside down. I was wondering if it is a designed feature or a bug. I like it because when I see it I'm ensured I'll enter the VM's GUI desktop soon without any problem.
+
+An edit: This happens also at the quitting time when I type "sudo shutdown now" in the terminal.
+Steps to reproduce:
+1. Build qemu using the following `./configure` options:
+```
+--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-avx512f --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-gio --enable-fuse --enable-fuse-lseek
+```
+2. Install Red Hat Enterprise Linux 8.5 in qemu
+3. Run qemu using the above command line, or type "sudo shutdown now" in the terminal after VM starts.
+Additional information:
+![image](/uploads/b8d277e4b05417cc8b0a7905bdcd27a4/image.png)
+
+![image](/uploads/94afd242ef1fac44aa504bdc6661a6ad/image.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/774 b/gitlab/issues_text/target_missing/host_missing/accel_missing/774
new file mode 100644
index 00000000..ada08ec1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/774
@@ -0,0 +1,15 @@
+Win(PE) NIC issue with pc-q35-6.1
+Description of problem:
+When booting WinPE (via PXE via WDS) on a `pc-q35-6.1` machine, the NIC will not initialize.
+
+What I got with `pnputil.exe /enum-devices /class net` is `Device has problem: 56 0x38 (CM_PROB_NEED_CLASS_CONFIG)` See: [CM_PROB_NEED_CLASS_CONFIG](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/cm-prob-need-class-config)
+
+I'm using virt manager and I've tried both `e1000e` and `virtio` network adapters (virtio with drivers injected into the image of course). Both yield the aforementioned error and `ipconfig` remains empty. This is an obscure problem - I haven't checked if a normal windows install behaves the same way, but it might be unique to winpe.
+
+However, with `pc-q35-5.2`, the NIC initializes without a problem.
+Steps to reproduce:
+1. Create `pc-q35-6.1` based vm in virt manager with default settings (network bridged to network bridge)
+2. PXE boot Windows Setup
+3. Observe hang (observe errors with console `SHIFT+F10`)
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/775 b/gitlab/issues_text/target_missing/host_missing/accel_missing/775
new file mode 100644
index 00000000..97583561
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/775
@@ -0,0 +1,4 @@
+Backup always use Microsoft VSS-FULL Option and breaks other Backups
+Additional information:
+MS VSS-Options 
+[https://docs.microsoft.com/en-us/windows/win32/api/vss/ne-vss-vss_backup_type](https://docs.microsoft.com/en-us/windows/win32/api/vss/ne-vss-vss_backup_type)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/776 b/gitlab/issues_text/target_missing/host_missing/accel_missing/776
new file mode 100644
index 00000000..ec68848b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/776
@@ -0,0 +1,25 @@
+Windows guest fails to start on 6.1.0 - opengl is not available
+Description of problem:
+I've created a Windows 10 guest with virt-manager. The VM started successfully with qemu 6.0.0-3. After upgrading to 6.1.0
+it fails with the following error:
+
+```
+2021-12-14T19:11:52.884272Z qemu-system-x86_64: warning: This feature depends on other features that were not requested: CPUID.8000000AH:EDX.svme-addr-chk [bit 28]
+2021-12-14T19:11:52.885199Z qemu-system-x86_64: warning: This feature depends on other features that were not requested: CPUID.8000000AH:EDX.svme-addr-chk [bit 28]
+2021-12-14T19:11:52.885852Z qemu-system-x86_64: warning: This feature depends on other features that were not requested: CPUID.8000000AH:EDX.svme-addr-chk [bit 28]
+2021-12-14T19:11:52.886485Z qemu-system-x86_64: warning: This feature depends on other features that were not requested: CPUID.8000000AH:EDX.svme-addr-chk [bit 28]
+2021-12-14T19:11:52.887098Z qemu-system-x86_64: warning: This feature depends on other features that were not requested: CPUID.8000000AH:EDX.svme-addr-chk [bit 28]
+2021-12-14T19:11:52.887773Z qemu-system-x86_64: warning: This feature depends on other features that were not requested: CPUID.8000000AH:EDX.svme-addr-chk [bit 28]
+2021-12-14T19:11:52.912523Z qemu-system-x86_64: -device virtio-vga-gl,id=video0,max_outputs=1,bus=pcie.0,addr=0x1: opengl is not available
+2021-12-14 19:11:53.109+0000: shutting down, reason=failed
+```
+
+Upgrading to 6.2.0.rc4 did not fix it. Downgrading to 6.0.0-3 made it work again. This makes it clear to me that the bug was introduce in qemu > 6.0.0 and seems to be not fix by now.
+
+I was able to start the guest on 6.1.0 by disabling 3D acceleration.
+Steps to reproduce:
+1. Create Windows 10 guest VM
+2. Start with qemu 6.0.0 -> Works
+3. Start with qemu 6.1.0 -> Broken
+Additional information:
+People on Reddit mention the same characteristic of this bug -> https://www.reddit.com/r/Fedora/comments/qqw3sq/qemu_video_virtio_opengl_not_available_after/
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/778 b/gitlab/issues_text/target_missing/host_missing/accel_missing/778
new file mode 100644
index 00000000..77ec3d0c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/778
@@ -0,0 +1 @@
+heap-buffer-overflow in megasas_sgl_get_len
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/779 b/gitlab/issues_text/target_missing/host_missing/accel_missing/779
new file mode 100644
index 00000000..b0aad8d4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/779
@@ -0,0 +1,13 @@
+VNC server not work
+Description of problem:
+I've created a sandbox guest with kata containers. The VM started successfully, but vnc server not listen unix socket.
+
+`root@bootstrap02:~# netstat -anp | grep 1989153`  
+`unix  3      [ ]         STREAM     CONNECTED     369610592 1989153/qemu-system  /run/vc/vm/bash/qmp.sock`  
+`root@bootstrap02:~# lsof -p 1989153 | grep unix`  
+`qemu-syst 1989153 root  108u     unix 0xffff912740d3b800        0t0  369610592 /run/vc/vm/bash/qmp.sock type=STREAM`
+Steps to reproduce:
+1.Create Linux sandbox guest VM  
+2.connect vnc server
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/781 b/gitlab/issues_text/target_missing/host_missing/accel_missing/781
new file mode 100644
index 00000000..93d5b052
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/781
@@ -0,0 +1 @@
+Assertion `addr < cache->len && 2 <= cache->len - addr' failed in address_space_stw_le_cached
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/782 b/gitlab/issues_text/target_missing/host_missing/accel_missing/782
new file mode 100644
index 00000000..b69e0048
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/782
@@ -0,0 +1,5 @@
+nvme: DMA reentrancy issue leads to use-after-free (CVE-2021-3929)
+Description of problem:
+A DMA reentrancy issue was found in the NVM Express Controller (NVMe) emulation. Functions dma_buf_write() or dma_buf_read() in hw/nvme/ctrl.c:nvme_tx() can be called without checking if the destination region overlaps with device's MMIO. This is similar to CVE-2021-3750 (https://gitlab.com/qemu-project/qemu/-/issues/541) and, just like it, when the reentrancy write triggers the reset function nvme_ctrl_reset(), data structs will be freed leading to a use-after-free issue. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition or, potentially, executing arbitrary code within the context of the QEMU process on the host.
+
+This issue was reported by Qiuhao Li.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/784 b/gitlab/issues_text/target_missing/host_missing/accel_missing/784
new file mode 100644
index 00000000..010463a3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/784
@@ -0,0 +1,13 @@
+max_hostmem does not work with virtio-vga-gl
+Description of problem:
+With property `max_hostmem=1000`, I hope the virgl VGA device can have 1GB video memory. But, after the VM starts, the command `glxinfo -B` returns "Video memory: 0MB", which I think means the virgl VGA does not obtain any video memory, or `max_hostmem=1000` does not work with `virtio-vga-gl`. Is it a bug or virgl has other property parameter to specify video memory?
+Steps to reproduce:
+1. Build qemu using the following `./configure` options:
+```
+--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-avx512f --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-gio --enable-fuse --enable-fuse-lseek
+```
+2. Install Red Hat Enterprise Linux 8.5 in qemu
+3. Run qemu using the above command line.
+4. Type `glxinfo -B` in VM terminal
+Additional information:
+![image](/uploads/c0bfb7a336493387ee90ffe7e6209dfe/image.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/785 b/gitlab/issues_text/target_missing/host_missing/accel_missing/785
new file mode 100644
index 00000000..fe2a9e71
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/785
@@ -0,0 +1 @@
+Build failure on macOS with jack
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/787 b/gitlab/issues_text/target_missing/host_missing/accel_missing/787
new file mode 100644
index 00000000..f485be19
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/787
@@ -0,0 +1,12 @@
+6.2.0 Regression with Intel GVT-g
+Description of problem:
+Until version 6.1.0 the Intel GVT-g graphics passtrought was working flawless. But, since the version 6.2.0 the machine with the exact same configuration is not working anymore, presenting an error that the graphics device was not found.
+
+```
+qemu-system-x86_64: -set device.hostdev0.x-igd-opregion=on: there is no device "hostdev0" defined
+```
+
+Downgrade to 6.1.0 fixes the problem.
+Steps to reproduce:
+1. Create a virtual machine with GVT-g
+2. Try to run the machine.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/79 b/gitlab/issues_text/target_missing/host_missing/accel_missing/79
new file mode 100644
index 00000000..6f677cbd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/79
@@ -0,0 +1 @@
+support horisontal mouse wheel
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/793 b/gitlab/issues_text/target_missing/host_missing/accel_missing/793
new file mode 100644
index 00000000..b133940e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/793
@@ -0,0 +1 @@
+Wrong pci express bus type - qemu 6.1.0-5
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/794 b/gitlab/issues_text/target_missing/host_missing/accel_missing/794
new file mode 100644
index 00000000..2da57a24
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/794
@@ -0,0 +1,9 @@
+Documentation: Broken links to removed features in old changelog pages
+Description of problem:
+In QEMU changelogs prior to 6.1 (notably 6.0 at least) the removed features link goes to https://qemu-project.gitlab.io/qemu/system/removed-features.html instead of https://qemu-project.gitlab.io/qemu/about/removed-features.html. The deprecated features links are also broken.
+
+This caused me some amount of confusion while trying to find the cause of several emulation issues.
+Additional information:
+Would have fixed myself but I cannot create a QEMU wiki account to do so. If there is a process for approval for that I will happily follow it and fix the issue when approved. I also can't see anywhere else to report this so apologies if this is the wrong place.
+
+Perhaps the main changelog page could include links to the removed and deprecated features pages too?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/795 b/gitlab/issues_text/target_missing/host_missing/accel_missing/795
new file mode 100644
index 00000000..221c3321
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/795
@@ -0,0 +1 @@
+meson.build: coreaudio check failed
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/796 b/gitlab/issues_text/target_missing/host_missing/accel_missing/796
new file mode 100644
index 00000000..63c25872
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/796
@@ -0,0 +1,17 @@
+make -j126 check failed in qemu@6.2.0 on ubuntu_aarch64
+Steps to reproduce:
+the issue
+
+```console
+[root@localhost build]#make -j126 check
+Running test fp-test-sqrt
+Running test fp-test-sub
+Running test fp-test-log2
+**
+ERROR:../tests/unit/test-qga.c:718:test_qga_config: assertion failed (err == ""): ("/home/stage/root/spack-stage-qemu-6.2.0-532ksrh2smva65sb3ghqox222237khs5/spack-src/build/qga/qemu-ga: symbol lookup error: /home/stage/root/spack-stage-qemu-6.2.0-532ksrh2smva65sb3ghqox222237khs5/spack-src/build/qga/qemu-ga: undefined symbol: g_unix_get_passwd_entry\n" == "")
+ERROR test-qga - Bail out! ERROR:../tests/unit/test-qga.c:718:test_qga_config: assertion failed (err == ""): ("/home/stage/root/spack-stage-qemu-6.2.0-532ksrh2smva65sb3ghqox222237khs5/spack-src/build/qga/qemu-ga: symbol lookup error: /home/stage/root/spack-stage-qemu-6.2.0-532ksrh2smva65sb3ghqox222237khs5/spack-src/build/qga/qemu-ga: undefined symbol: g_unix_get_passwd_entry\n" == "")
+make: *** [Makefile.mtest:1472: run-test-182] Error 1
+make: *** Waiting for unfinished jobs....
+……
+```
+I don't know why happen,can you help me?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/798 b/gitlab/issues_text/target_missing/host_missing/accel_missing/798
new file mode 100644
index 00000000..b56e51c0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/798
@@ -0,0 +1,15 @@
+The sandbox option elevelateprivileges=deny does not work with -daemonize
+Description of problem:
+qemu will not launch if `-sandbox on,elevateprivileges=deny` and `-daemonize` are set at the same time.
+Steps to reproduce:
+```
+qemu-system-x86_64 -sandbox on,elevateprivileges=deny -nodefaults -daemonize
+```
+-> fails to launch
+
+```
+qemu-system-x86_64 -sandbox on -nodefaults -daemonize
+```
+-> runs normally
+Additional information:
+[journal.txt](/uploads/c0e2a973e749011c3b1ac2158420a4e8/journal.txt)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/80 b/gitlab/issues_text/target_missing/host_missing/accel_missing/80
new file mode 100644
index 00000000..e1c6942a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/80
@@ -0,0 +1 @@
+[Feature request] qemu-img multi-threaded compressed image conversion
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/800 b/gitlab/issues_text/target_missing/host_missing/accel_missing/800
new file mode 100644
index 00000000..a29195b0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/800
@@ -0,0 +1,25 @@
+Cannot write to MTP Devices in Qemu 6.0.0+
+Description of problem:
+QEMU versions above 6.0.0 are no longer able to write to MTP devices, the kernel prints a warning which is unique to versions above 6.0.0:
+```
+usb-mtp: file monitoring init failed: File monitoring not available on this platform is just warning
+```
+Steps to reproduce:
+1. Launch a QEMU virtual machine with `-usb -device usb-mtp,rootdir=/tmp,readonly=false` using any QEMU version above 6.0.0
+2. Mount the MTP device using something:
+   ```
+   mkdir mtpDevice && jmtpfs mtpDevice
+   ```
+3. Try to write to the mtp device:
+   ```
+   touch mtpDevice/test
+   ```
+4. Observe that you will get an input/output error when trying to write to the device, like this:
+   ```
+   vm-test-run-mtp> client: must succeed: /nix/store/xmib7222ybr72iyycra4w386s8p1k4av-jmtpfsTest.sh >&2
+   vm-test-run-mtp> client # Device 0 (VID=46f4 and PID=0004) is a QEMU Virtual MTP.
+   vm-test-run-mtp> client # qemu-system-x86_64: usb-mtp: file monitoring init failed: File monitoring not available on this platform
+   vm-test-run-mtp> client # /nix/store/xmib7222ybr72iyycra4w386s8p1k4av-jmtpfsTest.sh: line 4: phone/tmp/testFile: Input/output error
+   ```
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/801 b/gitlab/issues_text/target_missing/host_missing/accel_missing/801
new file mode 100644
index 00000000..c123af02
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/801
@@ -0,0 +1,12 @@
+QEMU test build failure with --enable-modules
+Description of problem:
+
+Steps to reproduce:
+1. ./configure --target-list=x86_64-softmmu --enable-kvm --enable-modules
+2.  make -j8 check-qtest-x86_64 V=1  
+ 
+ - A problem happens "qemu-system-x86_64: -accel qtest: invalid accelerator qtest" 
+ - The file accel-qtest-x86_64.so is not built
+ - This problem happens since 69c4c5c1c47f5dac140eb6485c5281a9f145dcf3 Mon Sep 17 00:00:00 2001
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/802 b/gitlab/issues_text/target_missing/host_missing/accel_missing/802
new file mode 100644
index 00000000..64604e30
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/802
@@ -0,0 +1,26 @@
+Devices created using '-device' JSON syntax don't emit DEVICE_DELETED when unplugged
+Description of problem:
+Run the following sequence:
+
+```
+  $ ./qemu-system-x86_64 -qmp stdio  \
+       -device '{"driver": "virtio-mouse-pci", "id": "dev0"}' \
+       -device virtio-mouse-pci,id=dev1 
+{"QMP": {"version": {"qemu": {"micro": 50, "minor": 2, "major": 6}, "package": "v6.2.0-105-g7494244ffc-dirty"}, "capabilities": ["oob"]}}
+{ "execute": "qmp_capabilities" }
+{"return": {}}
+{ "execute": "device_del", "arguments": { "id": "dev0"} }
+{"return": {}}
+{ "execute": "device_del", "arguments": { "id": "dev1"} }
+{"return": {}}
+{ "execute": "system_reset" }
+{"return": {}}
+{"timestamp": {"seconds": 1641385071, "microseconds": 120178}, "event": "RESET", "data": {"guest": false, "reason": "host-qmp-system-reset"}}
+{"timestamp": {"seconds": 1641385071, "microseconds": 121431}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/dev1/virtio-backend"}}
+{"timestamp": {"seconds": 1641385071, "microseconds": 121684}, "event": "DEVICE_DELETED", "data": {"device": "dev1", "path": "/machine/peripheral/dev1"}}
+{"timestamp": {"seconds": 1641385071, "microseconds": 122297}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/dev0/virtio-backend"}}
+{"timestamp": {"seconds": 1641385071, "microseconds": 198581}, "event": "RESET", "data": {"guest": true, "reason": "guest-reset"}}
+
+   ```
+
+Notice the lack of a "DEVICE_DELETED" event with path "/machine/peripheral/dev0" - the device created with JSON syntax
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/804 b/gitlab/issues_text/target_missing/host_missing/accel_missing/804
new file mode 100644
index 00000000..5a89392b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/804
@@ -0,0 +1,9 @@
+savevm - QXL preventing save
+Description of problem:
+Attempting to savevm with a QXL VGA device attached causes the error "pre-save failed: qxl" to appear.
+Steps to reproduce:
+1. Start a QEMU instance with a QXL device
+2. Attempt to savevm
+3. See error
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/806 b/gitlab/issues_text/target_missing/host_missing/accel_missing/806
new file mode 100644
index 00000000..da512a82
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/806
@@ -0,0 +1,63 @@
+Fixed VHDX inflates beyond its fixed size when data is copied onto it and also corrupts
+Description of problem:
+Fixed VHDX inflates beyond its fixed size when data is copied onto it
+Possibly also corrupted
+
+Filing this bug as separate from #727, that issue is for corruption during expansion of a dynamic disk.
+The effect seen here is different. There may or may not be a chance of common cause. New blocks should not have to be allocated to the VHDX spec Block-Allocation-Table (BAT), there may be a simpler and different fix for this issue.
+
+Perhaps blocks are written to a VHDX journal without being committed to allocated blocks.
+Perhaps the host's ExFAT filesystem, does not allow reclaiming the blocks that are to be replaced by punching holes and so must be over-written instead of punching holes.
+Steps to reproduce:
+1. Prepare virtual-disk1 
+   Create fixed vhdx 
+   ```
+   [root@sirius gana]# qemu-img create -f vhdx  /mnt/a16/gkpics01.vhdx -o subformat=fixed 99723771904
+   Formatting '/mnt/a16/gkpics01.vhdx', fmt=vhdx size=99723771904 log_size=1048576block_size=0 subformat=fixed```
+2. Prepare virtual-disk2
+   Put 85 GiB synthetic generated data sgdata as mentioned in https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694  
+3. Start qemu (command invocation given above)
+4. Partition /dev/sda, put ext4-fs on /dev/sda1
+5. Mount -t ext4 /dev/sda1 /mnt/a 
+6. Mount /dev/sdb2 /mnt/b (mounts using fuse-blk tuxera ntfs driver)
+7. Do rsync: 
+   ```
+   (sdate=`date` ; cd /mnt/b ; rsync -avH ./photos001 /mnt/a | tee /tmp/rst.txt ; echo $sdate ; date)
+   ```
+8. In a host terminal, do ls -l on the vhdx file, and observe that it grows in size (see logs below)
+Additional information:
+* virtual-disk-1 (<90 GiB) is on ExFAT partition (150 GiB) on SSD
+* virtual-disk-2 (~85 Gib) is on NTFS3 partition (1 TiB) on HDD
+
+
+```
+[root@sirius gana]# qemu-img create -f vhdx  /mnt/a16/gkpics01.vhdx -o subformat=fixed 99723771904
+Formatting '/mnt/a16/gkpics01.vhdx', fmt=vhdx size=99723771904 log_size=1048576block_size=0 subformat=fixed
+[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
+-rwxr-xr-x. 1 root root 99732160512 Jan  8 13:11 /mnt/a16/gkpics01.vhdx
+[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
+-rwxr-xr-x. 1 root root 99732160512 Jan  8 13:11 /mnt/a16/gkpics01.vhdx
+[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
+-rwxr-xr-x. 1 root root 99732160512 Jan  8 13:11 /mnt/a16/gkpics01.vhdx
+[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
+-rwxr-xr-x. 1 root root 99765714944 Jan  8 13:35 /mnt/a16/gkpics01.vhdx
+[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
+
+do gdisk and partition in guestvm
+-rwxr-xr-x. 1 root root 100705239040 Jan  8 13:36 /mnt/a16/gkpics01.vhdx
+
+do mkfs -t ext4 in guestvm
+[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
+-rwxr-xr-x. 1 root root 101342773248 Jan  8 13:36 /mnt/a16/gkpics01.vhdx
+
+start rsyncing data in guestvm
+[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
+-rwxr-xr-x. 1 root root 102097747968 Jan  8 13:38 /mnt/a16/gkpics01.vhdx
+[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
+-rwxr-xr-x. 1 root root 102215188480 Jan  8 13:38 /mnt/a16/gkpics01.vhdx
+[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
+-rwxr-xr-x. 1 root root 149375942656 Jan  8 13:50 /mnt/a16/gkpics01.vhdx
+[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
+-rwxr-xr-x. 1 root root 156170715136 Jan  8 13:58 /mnt/a16/gkpics01.vhdx
+```
+in my case partition fills up and not completed.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/807 b/gitlab/issues_text/target_missing/host_missing/accel_missing/807
new file mode 100644
index 00000000..aa00dda6
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/807
@@ -0,0 +1,18 @@
+TigerVNC client to built-in VNC server causes VM to crash/freeze
+Description of problem:
+Connecting to the built-in VNC server via TigerVNC upon disconnect the whole VM process freezes/crashes. The process continues to exist but does not respond to any network connection and the monitor socket is dead too. Killing it with TERM doesn't work.
+
+Using tigervnc-viewer 1.10.1+dfsg-3 (Ubuntu 20.04) with default options like `vncviwer localhost:0`
+Steps to reproduce:
+* `qemu-system-x86_64 -vnc 127.0.0.1:0`
+ * Connect to built-in VNC server via TigerVNC 
+ * Keep the VNC connection open and wait some period of time (usually 5-10 minutes is enough though sometimes hours) then disconnect/reconnect VNC. If the reconnect succeeds then wait again for a period of time then disconnect and try again until failure. Often just connecting and disconnecting to the VNC once is enough to make the VM eventually crash/freeze even if running only in the background but this is less reproducible.
+ * Observe VM is no longer responsive to anything
+
+If TigerVNC is never connected/disconnected from the VM then this doesn't happen.
+Additional information:
+Note due to the nature of this issue it might be hard to reproduce for unknown reasons. The VM always eventually freezes though. The qemu process has no output when it freezes.
+
+As far as I can tell connecting to the built-in VNC server via `gvncviwer` seems to be OK and doesn't cause an issue (?). I'm not sure about other VNC clients (eg. TurboVNC).
+
+I am connecting to the VNC server from a completely different machine than the host via SSH port redirection (the host is headless). Not sure if that matters.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/808 b/gitlab/issues_text/target_missing/host_missing/accel_missing/808
new file mode 100644
index 00000000..b7863582
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/808
@@ -0,0 +1,18 @@
+virtio-scsi in Windows guests cause QEMU to abort/crash
+Description of problem:
+* Attempting to load the virtio-scsi drivers in a Windows guest causes the VM to abort/crash.
+Steps to reproduce:
+* `qemu-system-x86_64 -accel kvm -m 4G -device virtio-scsi-pci,id=scsi0 -drive media=cdrom,file=windows7-x64.iso -drive media=cdrom,file=virtio-win-0.1.173.iso`
+ * Boot the installer ISO, click through all the menus to eventually get to Custom Install
+ * In "Where do you want to install" click Load driver
+ * Browse E: drive and pick the first amd64/w7 folder
+ * Should show "Red Had VirtIO SCSI pass-through controller"
+ * Click Next
+ * Abort/crash
+
+Same thing happens with VM's that used to work already running the virtio-scsi drivers. When they boot the VM aborts.
+Additional information:
+```
+qemu-system-x86_64: ../accel/kvm/kvm-all.c:1760: kvm_irqchip_commit_routes: Assertion `ret == 0' failed.
+Aborted (core dumped)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/81 b/gitlab/issues_text/target_missing/host_missing/accel_missing/81
new file mode 100644
index 00000000..164ea246
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/81
@@ -0,0 +1 @@
+[Feature request] qemu-img option about recompressing
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/811 b/gitlab/issues_text/target_missing/host_missing/accel_missing/811
new file mode 100644
index 00000000..268c1391
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/811
@@ -0,0 +1 @@
+qemu_irq_split() callers should use TYPE_SPLIT_IRQ device instead
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/812 b/gitlab/issues_text/target_missing/host_missing/accel_missing/812
new file mode 100644
index 00000000..08e604c8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/812
@@ -0,0 +1,124 @@
+Multicast packets (mDNS) are not sent out of VM
+Description of problem:
+The app is sending multicast packets (mDNS), but they are not sent out of VM.
+Here is the configuration of the network: `-netdev user,id=net0,hostfwd=tcp::2222-:22,hostfwd=tcp::50051-:50051,hostfwd=tcp::50050-:50050`
+Steps to reproduce:
+1. Install arduino-cli from https://github.com/arduino/arduino-cli/releases (eg. 0.20.2)
+2. `arduino-cli config init`
+3. `vi ~/.arduino15/arduino-cli.yaml`
+4. edit it to have it as follows:
+```
+board_manager:
+  additional_urls: ["http://arduino.esp8266.com/stable/package_esp8266com_index.json"]
+daemon:
+  port: "50051"
+directories:
+  data: /root/app/data
+  downloads: /root/app/downloads
+  user: /root/app/user
+library:
+  enable_unsafe_install: false
+logging:
+  file: ""
+  format: text
+  level: info
+metrics:
+  addr: :9090
+  enabled: false
+output:
+  no_color: false
+sketch:
+  always_export_binaries: false
+updater:
+  enable_notification: true
+```
+
+5. `arduino-cli core update-index`
+6. `arduino-cli core install esp8266:esp8266`
+7. `arduino-cli board list -v`
+
+This will give an output similar to:
+```
+INFO[0000] Using config file: /root/.arduino15/arduino-cli.yaml 
+INFO[0000] arduino-cli.x86_64 version git-snapshot      
+INFO[0000] Checking if CLI is Bundled into the IDE      
+INFO[0000] Adding libraries dir                          dir=/root/app/user/libraries location=user
+INFO[0000] Checking signature                            index=/root/app/data/package_index.json signatureFile=/root/app/data/package_index.json.sig =
+INFO[0000] Checking signature                            error="opening signature file: open /root/app/data/package_esp8266com_index.json.sig: no such file or d=
+INFO[0000] Loading hardware from: /root/app/data/packages 
+INFO[0000] Loading package builtin from: /root/app/data/packages/builtin 
+INFO[0000] Checking existence of 'tools' path: /root/app/data/packages/builtin/tools 
+INFO[0000] Loading tools from dir: /root/app/data/packages/builtin/tools 
+INFO[0000] Loaded tool                                   tool="builtin:ctags@5.8-arduino11"
+INFO[0000] Loaded tool                                   tool="builtin:mdns-discovery@1.0.2"
+INFO[0000] Loaded tool                                   tool="builtin:serial-discovery@1.3.1"
+INFO[0000] Loaded tool                                   tool="builtin:serial-monitor@0.9.1"
+INFO[0000] Loading package esp8266 from: /root/app/data/packages/esp8266/hardware 
+INFO[0000] Checking signature                            error="opening signature file: open /root/app/data/packages/esp8266/hardware/esp8266/3.0.2/installed.js=
+INFO[0000] Adding monitor tool                           protocol=serial tool="builtin:serial-monitor"
+INFO[0000] Loaded platform                               platform="esp8266:esp8266@3.0.2"
+INFO[0000] Checking existence of 'tools' path: /root/app/data/packages/esp8266/tools 
+INFO[0000] Loading tools from dir: /root/app/data/packages/esp8266/tools 
+INFO[0000] Loaded tool                                   tool="esp8266:mklittlefs@3.0.4-gcc10.3-1757bed"
+INFO[0000] Loaded tool                                   tool="esp8266:mkspiffs@3.0.4-gcc10.3-1757bed"
+INFO[0000] Loaded tool                                   tool="esp8266:python3@3.7.2-post1"
+INFO[0000] Loaded tool                                   tool="esp8266:xtensa-lx106-elf-gcc@3.0.4-gcc10.3-1757bed"
+INFO[0000] Adding libraries dir                          dir=/root/app/data/packages/esp8266/hardware/esp8266/3.0.2/libraries location=platform
+INFO[0007] Executing `arduino-cli board list`           
+INFO[0007] starting discovery builtin:serial-discovery process 
+INFO[0007] started discovery builtin:serial-discovery process 
+INFO[0007] sending command HELLO 1 "arduino-cli git-snapshot" to discovery builtin:serial-discovery 
+INFO[0007] starting discovery builtin:mdns-discovery process 
+INFO[0007] started discovery builtin:mdns-discovery process 
+INFO[0007] sending command HELLO 1 "arduino-cli git-snapshot" to discovery builtin:mdns-discovery 
+INFO[0007] from discovery builtin:serial-discovery received message type: hello, message: OK, protocol version: 1 
+INFO[0007] from discovery builtin:mdns-discovery received message type: hello, message: OK, protocol version: 1 
+INFO[0007] sending command START to discovery builtin:serial-discovery 
+INFO[0007] sending command START to discovery builtin:mdns-discovery 
+INFO[0007] from discovery builtin:mdns-discovery received message type: start, message: OK 
+INFO[0007] from discovery builtin:serial-discovery received message type: start, message: OK 
+INFO[0008] sending command LIST to discovery builtin:serial-discovery 
+INFO[0008] sending command LIST to discovery builtin:mdns-discovery 
+INFO[0008] from discovery builtin:mdns-discovery received message type: list 
+INFO[0008] from discovery builtin:serial-discovery received message type: list, ports: [/dev/ttyS0] 
+INFO[0008] sending command STOP to discovery builtin:serial-discovery 
+INFO[0008] sending command STOP to discovery builtin:mdns-discovery 
+INFO[0008] from discovery builtin:mdns-discovery received message type: stop, message: OK 
+INFO[0008] from discovery builtin:serial-discovery received message type: stop, message: OK 
+Port       Protocol Type    Board Name FQBN Core
+/dev/ttyS0 serial   Unknown                
+```
+
+Note `builtin:mdns-discovery` discovery started. It is expected to send the packets as follows (the screenshot from the host with Wireshark):
+
+![Снимок_экрана_2022-01-11_в_22.49.58](/uploads/4c2783c84aaa323bc9dfbca127494768/Снимок_экрана_2022-01-11_в_22.49.58.png)
+
+The screenshot is taken if running the same app (but for macOS) from the host and **i can't see the packets sent if executed from the QEMU guest os**.
+I believe i either configured it the wrong way (`-netdev user,id=net0,...`) or it's a QEMU bug.
+Additional information:
+I've tested on macOS host with qemu 6.0.0 and on Linux (Android) host with qemu 6.1.0 and both were not working.
+
+the network interface seems to be configured for multicasting:
+```
+# ifconfig
+eth0      Link encap:Ethernet  HWaddr 52:54:00:12:34:57  
+          inet addr:10.0.2.15  Bcast:0.0.0.0  Mask:255.255.255.0
+          inet6 addr: fec0::5054:ff:fe12:3457/64 Scope:Site
+          inet6 addr: fe80::5054:ff:fe12:3457/64 Scope:Link
+          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
+          RX packets:91955 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:25203 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000 
+          RX bytes:119904373 (114.3 MiB)  TX bytes:1868274 (1.7 MiB)
+
+lo        Link encap:Local Loopback  
+          inet addr:127.0.0.1  Mask:255.0.0.0
+          inet6 addr: ::1/128 Scope:Host
+          UP LOOPBACK RUNNING  MTU:65536  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:1000 
+          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+```
+
+It might be easier to skip using arduino-cli and just use any mdns discovery app.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/813 b/gitlab/issues_text/target_missing/host_missing/accel_missing/813
new file mode 100644
index 00000000..e1938a63
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/813
@@ -0,0 +1,15 @@
+On windows, preallocation=full qcow2 not creatable, qcow2 not resizable
+Description of problem:
+Not possible to create a fixed-virtual-disk qcow as one may do on linux.
+One sometimes may want to create a fixed size qcow2, as can be done with the fixed variants of VHDX, VMDK, VDI, 
+
+The advantage of a fixed virtual-disk format, such as fixed-VHDX, fixed-VMDK, fixed-VDI is that it keeps the disk-meta-data as a header bundled along with that is essentially a raw image, allowing for seamless tooling and management of virtual-disks
+
+Workaround use a raw file as diskimage. (see workaround given below)
+
+To be very general, the implementation of this may need to factor in what underlying operations (fallocate, fallocate_punchhole, truncate, sparse) are supported by what filesystems (NTFS, ExFAT, ext4), choice of filesystem-driver (sometimes the driver may not have yet implemented an underlying operation), and operating systems (Linux/Win), and possible workarounds to achieve the same effect in the absence of underlying-operation.
+Steps to reproduce:
+1. open command shell
+2. run the qemu-img command. In my case, qcow2 file is attempted to be created on a drive with ExFAT filesystem.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/814 b/gitlab/issues_text/target_missing/host_missing/accel_missing/814
new file mode 100644
index 00000000..4aaa9472
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/814
@@ -0,0 +1,37 @@
+On Windows, qcow2 is corrupted on expansion
+Description of problem:
+On Windows, the qcow2 loses blocks on account of which the filesystem withing is corrupted as data is copied to it, just the same way as in #727 VHDX is corrupted on expansion on both Linux/Windows.  
+
+After filing a bug for WNBD https://github.com/cloudbase/wnbd/issues/63 , I was suggested to try raw and qcow2. In the process I found that qcow2 is also affected. But it is also true that the kernel-5.15.4 ... 5.15.13 series have also been buggy https://bugzilla.kernel.org/show_bug.cgi?id=215460 . 
+On Linux, qcow2 never showed any signs of corruption.
+On Windows, however, qcow2 does corrupt.
+
+It is possible that, as Linux is so much more efficient at files and disk-IO, the kernel-block-code, qemu-block-code and qemu-qcow2-code do not hit the bug, and so the corruption does not show up as easily in Linux. Windows, being a little slower at this, might be causing the bug to show up in this qcow2 test. Possibly, the issue more likely to show up on slower machines. I am using an 2013-era intel-4rth gen i7-4700mq Haswell machine. 
+
+It is possible that, the resolution for this issue and that for #727 could be the same or very closely related. The bug may not be in qcow2.c or vhdx.c but maybe in the qemu/block subsystem. If the data-block that arrives from the VM-interface/nbd-interface which has to be written to file, but never gets to the virtual-disk code, not allocated and written to, then the data-block is lost.
+Steps to reproduce:
+1. Prepare virtual-disk1 as empty qcow2. In my-setup, the qcow2 file resides on an 150 GiB ExFAT partition on 512 GiB SSD. I use ExFAT as the ExFAT-filesystem does not have a concept of sparse files, eliminating that factor from troubleshooting.
+   ```qemu-img.exe create -f qcow2 H:\gkpics01.qcow2  99723771904```
+2. Prepare virtual-disk2 VHDX with synthetic generated data (sgdata). Scriptlets to recreate sgdata are described in https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694 . In my-setup, the vhdx file resides on an 1 TiB NTFS partition on a 2 TiB HDD.
+3. Start qemu with arguments as given above. 
+4. Inside VM, boot and bringup livecd desktop, close the installer and open a terminal
+5. Use gdisk to put an ext4 partition on /dev/sda
+6. Put ext4 partition on sda1 ```mkfs.ext4 -L fs_gkpics01 /dev/sda1```
+7. Create mount directories ```mkdir /mnt/a /mnt/b```
+8. Mount the empty partition from virtual-disk-1 ```mount -t ext4 /dev/sda1 /mnt/a```
+9. Mount the sgdata partition from virtual-disk-2 ```mount.ntfs-3g /dev/sdb2 /mnt/b```  or ```mount -t ntfs3 /dev/sdb2 /mnt/b```
+10. Keep a terminal tab open with ```dmesg -w``` running
+11. Rsync sgdata ```( sdate=`date` ; cd /mnt/b ; rsync -avH ./photos001 /mnt/a | tee /tmp/rst.txt ; echo $sdate ; date )```
+12. Check sha256sum ```( sdate=`date` ; cd /mnt/a/photos001 ; shas256sum -c ./find.CHECKSUM --quiet ; echo $sdate ; date )```  
+    corruption will show even without needing to unmount-remount or reboot-remount. 
+
+- About 1.4 GiB free-space left on the ext4 partition. 
+- Compared to #727, The number of files corrupted are less ``` sha256sum: WARNING: 31 computed checksums did not match ```
+- After, VM guest OS warm reboot, a recheck of the sha256sum shows the same 31 files as corrupted
+- After, qemu poweroff, restart qemu, VM guest OS cold boot, a recheck of the sha256sum shows the same 31 files as corrupted
+- df shows: sda1 has 95271336 1k-blocks, of which 88840860 are used, 1544820 available, 99% used. The numbers don't add up. Either file-blocks are lost in lost-clusters or the ext4-filesystem has a large journal or the file-system-metadata is too large, or the ext4-filesystem has large cluster-size which results in inefficient space usage.
+- An ```unmount /dev/sda1 ; fsck -y /dev/sda1 ; mount -t ext4 /dev/sda1 /mnt/a``` did not find any lost clusters.
+
+The reason I don't think this is a kernel bug, is because the raw-file as virtual-disk-1 doesn't show this issue. Also, it happens regardless of whether sgdata is on ntfs-3g or ntfs3-paragon.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/815 b/gitlab/issues_text/target_missing/host_missing/accel_missing/815
new file mode 100644
index 00000000..1d85c033
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/815
@@ -0,0 +1 @@
+Using spdk Vhost to accelerate QEMU, which QEMU version is the most appropriate？
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/816 b/gitlab/issues_text/target_missing/host_missing/accel_missing/816
new file mode 100644
index 00000000..4b00a017
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/816
@@ -0,0 +1,47 @@
+Some errors were encountered while compiling QEMU source code
+Description of problem:
+When I try to download the source code from gitlab and compile it, the output is as follows:
+
+```
+FAILED: subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o 
+clang -m64 -mcx16 -Isubprojects/libvhost-user/libvhost-user.a.p -Isubprojects/libvhost-user -I../subprojects/libvhost-user -fcolor-diagnostics -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -fsanitize=fuzzer-no-link -fsanitize=undefined -fsanitize=address -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-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -fstack-protector-strong -fprofile-instr-generate -fcoverage-mapping -fPIE -pthread -D_GNU_SOURCE -MD -MQ subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o -MF subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o.d -o subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o -c ../subprojects/libvhost-user/libvhost-user.c
+In file included from ../subprojects/libvhost-user/libvhost-user.c:43:
+../subprojects/libvhost-user/include/atomic.h:1:1: error: expected identifier or '('
+../../../include/qemu/atomic.h
+^
+In file included from ../subprojects/libvhost-user/libvhost-user.c:45:
+../subprojects/libvhost-user/libvhost-user.h:23:10: fatal error: 'standard-headers/linux/virtio_ring.h' file not found
+#include "standard-headers/linux/virtio_ring.h"
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+2 errors generated.
+[69/1511] Compiling C object subprojects/libvhost-user/libvhost-user-glib.a.p/libvhost-user-glib.c.o
+FAILED: subprojects/libvhost-user/libvhost-user-glib.a.p/libvhost-user-glib.c.o 
+clang -m64 -mcx16 -Isubprojects/libvhost-user/libvhost-user-glib.a.p -Isubprojects/libvhost-user -I../subprojects/libvhost-user -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fcolor-diagnostics -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -fsanitize=fuzzer-no-link -fsanitize=undefined -fsanitize=address -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-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -fstack-protector-strong -fprofile-instr-generate -fcoverage-mapping -fPIE -pthread -Wno-unused-function -MD -MQ subprojects/libvhost-user/libvhost-user-glib.a.p/libvhost-user-glib.c.o -MF subprojects/libvhost-user/libvhost-user-glib.a.p/libvhost-user-glib.c.o.d -o subprojects/libvhost-user/libvhost-user-glib.a.p/libvhost-user-glib.c.o -c ../subprojects/libvhost-user/libvhost-user-glib.c
+In file included from ../subprojects/libvhost-user/libvhost-user-glib.c:15:
+In file included from ../subprojects/libvhost-user/libvhost-user-glib.h:19:
+../subprojects/libvhost-user/libvhost-user.h:23:10: fatal error: 'standard-headers/linux/virtio_ring.h' file not found
+#include "standard-headers/linux/virtio_ring.h"
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+1 error generated.
+[70/1511] Generating trace-hw_alpha.h with a custom command
+[71/1511] Generating hmp-commands-info.h with a custom command (wrapped by meson to capture output)
+[72/1511] Generating qemu-img-cmds.h with a custom command (wrapped by meson to capture output)
+[73/1511] Generating hmp-commands.h with a custom command (wrapped by meson to capture output)
+[74/1511] Generating qemu-options.def with a custom command (wrapped by meson to capture output)
+[75/1511] Compiling C object libslirp.a.p/slirp_src_tcp_input.c.o
+[76/1511] Compiling C object libcapstone.a.p/capstone_arch_SystemZ_SystemZDisassembler.c.o
+[77/1511] Generating qemu-version.h with a custom command (wrapped by meson to capture output)
+[78/1511] Compiling C object libcapstone.a.p/capstone_arch_AArch64_AArch64Disassembler.c.o
+[79/1511] Compiling C object libcapstone.a.p/capstone_arch_ARM_ARMInstPrinter.c.o
+[80/1511] Compiling C object libcapstone.a.p/capstone_arch_ARM_ARMDisassembler.c.o
+[81/1511] Compiling C object libcapstone.a.p/capstone_arch_AArch64_AArch64InstPrinter.c.o
+ninja: build stopped: subcommand failed.
+Makefile:163: recipe for target 'run-ninja' failed
+make: *** [run-ninja] Error 1
+```
+
+I looked for the missing file standard-headers/linux/virtio_ring.h and found that the file existed.
+Steps to reproduce:
+1. ``git clone https://gitlab.com/qemu-project/qemu``
+2. ``CC=clang CXX=clang++ ../configure --enable-fuzzing  --enable-sanitizers``
+3. ``make qemu-fuzz-i386``
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/817 b/gitlab/issues_text/target_missing/host_missing/accel_missing/817
new file mode 100644
index 00000000..88c413a2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/817
@@ -0,0 +1 @@
+linux-user: waitid leaves target siginfo uninitialized when info.si_pid is zero
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/818 b/gitlab/issues_text/target_missing/host_missing/accel_missing/818
new file mode 100644
index 00000000..ab7cc437
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/818
@@ -0,0 +1,5 @@
+qemu with invalid arg will cause monitor error
+Steps to reproduce:
+```
+qemu-system-ppc.exe -m 1024M -monitor
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/819 b/gitlab/issues_text/target_missing/host_missing/accel_missing/819
new file mode 100644
index 00000000..9562c7cf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/819
@@ -0,0 +1,75 @@
+watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [swapper/1:0]
+Description of problem:
+During virtual disk live move/migration, VMs get severe stuttering and even cpu soft lockups, as described here:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=199727
+
+This also happens on some of our virtual machines when i/o load inside VM is high or workload is fsync centric.
+
+i'm searching for a solution to mitigate this problem, i.e. i can live with the stuttering/delays of several seconds, but getting cpu soft lockups of 22s or higher is inacceptable. 
+
+i have searched the web for a long long time now, but did not find a solution , nor did i find a way on how to troubleshoot this more in depth to find the real root cause.
+
+if this issue report will not getting accepted because of "non native qemu" (i.e. proxmox platform) , please tell me which qemu/distro i can/should use instead (which has easy usable live migration feature) to try reproducing the problem.
+Steps to reproduce:
+1. do a live migration of one or more virtual machine disks
+2. watch "ioping -WWWYy test.dat" inside VM (being moved) for disk latency
+3. you disk latency is heavily varying , from time to time it goes up to vaues of tens seconds, even leading to kernel messages like " kernel:[ 2155.520846] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [swapper/1:0]"
+
+```
+4 KiB >>> test.dat (ext4 /dev/sda1): request=55 time=1.07 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=56 time=1.24 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=57 time=567.4 ms (fast)
+4 KiB >>> test.dat (ext4 /dev/sda1): request=58 time=779.0 ms (fast)
+4 KiB >>> test.dat (ext4 /dev/sda1): request=59 time=589.0 ms (fast)
+4 KiB >>> test.dat (ext4 /dev/sda1): request=60 time=1.57 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=61 time=847.7 ms (fast)
+4 KiB >>> test.dat (ext4 /dev/sda1): request=62 time=933.0 ms
+4 KiB >>> test.dat (ext4 /dev/sda1): request=63 time=891.4 ms (fast)
+4 KiB >>> test.dat (ext4 /dev/sda1): request=64 time=820.8 ms (fast)
+4 KiB >>> test.dat (ext4 /dev/sda1): request=65 time=1.02 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=66 time=2.44 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=67 time=620.7 ms (fast)
+4 KiB >>> test.dat (ext4 /dev/sda1): request=68 time=1.03 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=69 time=1.24 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=70 time=1.42 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=71 time=1.36 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=72 time=1.41 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=73 time=1.33 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=74 time=2.36 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=75 time=1.46 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=76 time=1.45 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=77 time=1.28 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=78 time=1.41 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=79 time=2.33 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=80 time=1.39 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=81 time=1.35 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=82 time=1.54 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=83 time=1.52 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=84 time=1.50 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=85 time=2.00 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=86 time=1.47 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=87 time=1.26 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=88 time=1.29 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=89 time=2.05 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=90 time=1.44 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=91 time=1.43 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=92 time=1.72 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=93 time=1.77 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=94 time=2.56 s
+
+Message from syslogd@iotest2 at Jan 14 14:51:12 ...
+ kernel:[ 2155.520846] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [swapper/1:0]
+4 KiB >>> test.dat (ext4 /dev/sda1): request=95 time=22.5 s (slow)
+4 KiB >>> test.dat (ext4 /dev/sda1): request=96 time=3.56 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=97 time=1.52 s (fast)
+4 KiB >>> test.dat (ext4 /dev/sda1): request=98 time=1.69 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=99 time=1.90 s
+4 KiB >>> test.dat (ext4 /dev/sda1): request=100 time=1.15 s (fast)
+4 KiB >>> test.dat (ext4 /dev/sda1): request=101 time=890.0 ms (fast)
+4 KiB >>> test.dat (ext4 /dev/sda1): request=102 time=959.6 ms (fast)
+4 KiB >>> test.dat (ext4 /dev/sda1): request=103 time=926.5 ms (fast)
+4 KiB >>> test.dat (ext4 /dev/sda1): request=104 time=791.5 ms (fast)
+4 KiB >>> test.dat (ext4 /dev/sda1): request=105 time=577.8 ms (fast)
+4 KiB >>> test.dat (ext4 /dev/sda1): request=106 time=867.7 ms (fast)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/82 b/gitlab/issues_text/target_missing/host_missing/accel_missing/82
new file mode 100644
index 00000000..c37fcb5c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/82
@@ -0,0 +1 @@
+[Feature request] acceptance test class to run user-mode binaries
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/820 b/gitlab/issues_text/target_missing/host_missing/accel_missing/820
new file mode 100644
index 00000000..bd3b36e5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/820
@@ -0,0 +1,13 @@
+Hang During Initramfs
+Description of problem:
+[Hang During Initramfs](https://wiki.archlinux.org/title/QEMU#Hang_during_VM_initramfs)
+Is this still not fixed? I hang at startup. Previously I tried WIN11 and it booted fine.
+Steps to reproduce:
+1. Download Windows10 ISO
+2. qemu-img create -f raw Windows10 15G
+3. qemu-system-x86_64 -cdrom Win10.iso -boot order=d -drive file=Windows10,format=raw -m 4G
+Additional information:
+![qemu](/uploads/e122ebddb51e29de9bd16bc1815bb98e/qemu.mp4)
+
+
+`-enable-kvm` works but i removed it to slow down a bit to see what is going on.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/821 b/gitlab/issues_text/target_missing/host_missing/accel_missing/821
new file mode 100644
index 00000000..dde4c6f8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/821
@@ -0,0 +1 @@
+[SOLVED] ReactOS video problems...
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/823 b/gitlab/issues_text/target_missing/host_missing/accel_missing/823
new file mode 100644
index 00000000..f96528f7
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/823
@@ -0,0 +1,21 @@
+rcutorture: ../tests/unit/rcutorture.c:321: rcu_update_stress_test: Assertion `p != cp' failed.
+Description of problem:
+qemu rcutorture tests are failing when building qemu for Rawhide.  See the scratch build I did here and the follow log files:
+
+https://koji.fedoraproject.org/koji/taskinfo?taskID=81316487
+https://kojipkgs.fedoraproject.org//work/tasks/6509/81316509/build.log
+https://kojipkgs.fedoraproject.org//work/tasks/6508/81316508/build.log
+https://kojipkgs.fedoraproject.org//work/tasks/6510/81316510/build.log
+
+The full error is:
+
+```
+MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} G_TEST_SRCDIR=/builddir/build/BUILD/qemu-6.2.0/tests/unit G_TEST_BUILDDIR=/builddir/build/BUILD/qemu-6.2.0/qemu_kvm_build/tests/unit tests/unit/rcutorture --tap -k
+ERROR rcutorture - too few tests run (expected 2, got 0)
+rcutorture: ../tests/unit/rcutorture.c:321: rcu_update_stress_test: Assertion `p != cp' failed.
+make: *** [Makefile.mtest:1208: run-test-149] Error 1
+```
+Steps to reproduce:
+1. Compile qemu and run the test suite.
+Additional information:
+The only significant recent change since it was built successfully is adoption of GCC 12.  Could it be a change in compiler that causes this?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/825 b/gitlab/issues_text/target_missing/host_missing/accel_missing/825
new file mode 100644
index 00000000..d2172a80
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/825
@@ -0,0 +1,38 @@
+compilation error - "VIRTIO_F_VERSION"
+Description of problem:
+Encountered problem while "make"
+
+....
+`[65/2464] Compiling C object subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o
+FAILED: subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o 
+cc -m64 -mcx16 -Isubprojects/libvhost-user/libvhost-user.a.p -Isubprojects/libvhost-user -I../subprojects/libvhost-user -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -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 -fPIE -pthread -D_GNU_SOURCE -MD -MQ subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o -MF subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o.d -o subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o -c ../subprojects/libvhost-user/libvhost-user.c
+../subprojects/libvhost-user/libvhost-user.c: In function 'vu_get_features_exec':
+../subprojects/libvhost-user/libvhost-user.c:508:17: error: 'VIRTIO_F_VERSION_1' undeclared (first use in this function); did you mean 'INFLIGHT_VERSION'?
+         1ULL << VIRTIO_F_VERSION_1 |
+                 ^~~~~~~~~~~~~~~~~~
+                 INFLIGHT_VERSION
+../subprojects/libvhost-user/libvhost-user.c:508:17: note: each undeclared identifier is reported only once for each function it appears in
+../subprojects/libvhost-user/libvhost-user.c: In function 'vu_set_features_exec':
+../subprojects/libvhost-user/libvhost-user.c:542:30: error: 'VIRTIO_F_VERSION_1' undeclared (first use in this function); did you mean 'INFLIGHT_VERSION'?
+     if (!vu_has_feature(dev, VIRTIO_F_VERSION_1)) {
+                              ^~~~~~~~~~~~~~~~~~
+                              INFLIGHT_VERSION
+../subprojects/libvhost-user/libvhost-user.c: In function 'generate_faults':
+../subprojects/libvhost-user/libvhost-user.c:612:13: error: unused variable 'ret' [-Werror=unused-variable]
+         int ret;
+             ^~~
+../subprojects/libvhost-user/libvhost-user.c:611:22: error: unused variable 'dev_region' [-Werror=unused-variable]
+         VuDevRegion *dev_region = &dev->regions[i];
+                      ^~~~~~~~~~
+cc1: all warnings being treated as errors
+ninja: build stopped: subcommand failed.
+make[1]: *** [Makefile:163: run-ninja] Error 1
+make[1]: Leaving directory '/users/oneuser/qemu/qemu/build'
+make: *** [GNUmakefile:11: all] Error 2
+`
+Steps to reproduce:
+1. ./configure --prefix=/users/oneuser/qemu/myqemu-1 --enable-kvm  --target-list=x86_64-softmmu 
+2. make
+3.
+Additional information:
+Please let me know if more info is needed.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/827 b/gitlab/issues_text/target_missing/host_missing/accel_missing/827
new file mode 100644
index 00000000..b94355c1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/827
@@ -0,0 +1 @@
+Stack-overflow through virtio_blk_get_request
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/828 b/gitlab/issues_text/target_missing/host_missing/accel_missing/828
new file mode 100644
index 00000000..09f99ffa
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/828
@@ -0,0 +1,11 @@
+using qemu-system-x86_64 to start multiple windows 10 guests concurrently , the mac address of the guests is incorrect
+Description of problem:
+I plan to run multiple windows 10 guests concurrently, I choose NAT network and specify a unique MAC addr for each guest. and I choose dnsmasq as a dhcp server. but I found that all guests MAC addresses are the same as the guest started first. 
+This situation also occurs in windows 8. But the strange thing is that this never happened to windows7 guests.
+I'm Chinese and my English is pool, please forgive my bad expressions.
+Steps to reproduce:
+1.make a windows 10 image
+2.qemu-system-x86_64 command  assign unique MAC addr
+3. python multiprocess lib running command above
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/829 b/gitlab/issues_text/target_missing/host_missing/accel_missing/829
new file mode 100644
index 00000000..e9d023e4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/829
@@ -0,0 +1,14 @@
+user space emulation: openat() seems to defeat sysroot path translation
+Description of problem:
+It appears that the user space emulation code is doing some path manipulation of some syscalls to sometimes prefix them with the sysroot.  This seems to be interacting badly sometimes with certain usage patterns.  This was noticed because a test suite of various libc calls was failing under `qemu-arm`, and a `strace` of the qemu-arm process revealed that the translated paths were being inconsistently applied.
+
+In particular, the sequence which fails is:
+* create a file in `/tmp/`.
+* open `/tmp` itself.  This succeeds, but `strace` reveals that it actually opened `SYSROOT/tmp/`.
+* `openat(tmpfd, tmpfile_name)` then fails, as the fd provided to openat is actually inside the sysroot, not at `/tmp` as expected.
+Steps to reproduce:
+1. Get toolchain https://toolchains.bootlin.com/downloads/releases/toolchains/armv7-eabihf/tarballs/armv7-eabihf--uclibc--bleeding-edge-2021.11-1.tar.bz2
+2. Compile attached test program [test_openat.c](/uploads/69eb997256ff29d2178be85531c6b3c6/test_openat.c)
+3. Try to run under `qemu-arm`.
+
+This code passes in non-emulated situations, but fails under user-space emulation.  Presumably it would also pass under full system emulation.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/830 b/gitlab/issues_text/target_missing/host_missing/accel_missing/830
new file mode 100644
index 00000000..dd8b67af
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/830
@@ -0,0 +1 @@
+QEMU aarch64 support for Windows TPM driver (TIS, CRB interfaces)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/832 b/gitlab/issues_text/target_missing/host_missing/accel_missing/832
new file mode 100644
index 00000000..aef0c12a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/832
@@ -0,0 +1,13 @@
+error "# mkdir('/..../qtest-9p-local-M33XsI') failed: File exists"  on every  run of 'qos-test'
+Description of problem:
+```
+$ ./build//tests/qtest/qos-test -h
+# mkdir('/home/berrange/src/virt/qemu/qtest-9p-local-qThj5y') failed: File exists
+Usage:
+  ./build//tests/qtest/qos-test [OPTION...]
+...snip...
+```
+
+Notice the error message from 'mkdir()' whic appears every time you run this program.
+Steps to reproduce:
+1. Run  qos-test
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/833 b/gitlab/issues_text/target_missing/host_missing/accel_missing/833
new file mode 100644
index 00000000..4d46108c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/833
@@ -0,0 +1,42 @@
+linux-user: sendmsg fails to send messages without iov
+Description of problem:
+When run via qemu `sendmsg` fails to send messages which contain a zero length `iov` but _do_ contain ancillary data. This works fine on plain Linux.
+
+A practical example: the `ell` library relies on this for setting the IV on a kernel crypto (`AF_ALG`) socket: https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/cipher.c#n526
+
+A message without data but only ancillary data is used to set the IV.
+Steps to reproduce:
+See [qemu_ancillary.c](/uploads/84ee20aa3b9178022847d6cd7fcf0048/qemu_ancillary.c) for a self contained testcase which sends two mesages (one with `msg_iovlen=0`, one with `msg_iovlen=1`).
+
+(Test case is to be considered GPL, as I've copied bits from `ell`)
+
+Native:
+```
+$ strace -esendmsg ./a.out 
+sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 0
+sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16
++++ exited with 0 +++
+```
+
+
+Qemu (observe missing sendmsg call):
+```
+$ strace -esendmsg ~/debug/qemu/build/qemu-x86_64 ./a.out 
+sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16
++++ exited with 0 +++
+```
+
+For a practical reproducer:
+
+1. Compile and run `ell`'s `test-cipher` test case:
+
+```
+$ ~/debug/qemu/build/qemu-x86_64 ./unit/test-cipher 
+TEST: unsupported
+TEST: aes
+TEST: aes_ctr
+test-cipher: unit/test-cipher.c:102: test_aes_ctr: Assertion `!r' failed.
+Aborted (core dumped)
+```
+
+A strace will look similar.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/834 b/gitlab/issues_text/target_missing/host_missing/accel_missing/834
new file mode 100644
index 00000000..a6057d04
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/834
@@ -0,0 +1,59 @@
+linux-user: fails to deliver signals raised during pselect
+Description of problem:
+When run via qemu a program which blocks signals but unmasks them during `pselect` does not catch these signals when returning from `pselect`.
+
+Used as reference on expected behavior: [The new pselect() system call](https://lwn.net/Articles/176911/)
+Steps to reproduce:
+A minimal test case below mimics behavior as encountered in the test suite of `p11-kit` ([link](https://github.com/p11-glue/p11-kit)) (which attempts to catch `SIGTERM` in a similar way and results in lingering processes after running the test suite).
+
+```C
+#include <stdio.h>
+#include <unistd.h>
+#include <signal.h>
+#include <sys/select.h>
+
+static void handler(int sig)
+{
+	puts("SIGNAL");
+}
+
+int main(int argc, char *argv[])
+{
+	struct sigaction sa;
+
+	fd_set rfds;
+	sigset_t emptyset, blockset;
+
+	sigemptyset (&blockset);
+	sigemptyset (&emptyset);
+	sigaddset (&blockset, SIGUSR1);
+
+	sa.sa_handler = handler;
+	sigemptyset(&sa.sa_mask);
+	sa.sa_flags = 0;
+	sigaction(SIGUSR1, &sa, NULL);
+
+	sigprocmask (SIG_BLOCK, &blockset, NULL);
+
+	FD_ZERO(&rfds);
+
+	while(1) {
+		pselect(0, &rfds, NULL, NULL, NULL, &emptyset);
+	}
+
+	return 0;
+}
+```
+
+Running this without qemu should print _SIGNAL_ when sent `SIGUSR1`:
+
+```
+$ ./a.out &
+[1] 1683587
+$ kill -USR1 %1
+$ SIGNAL
+```
+
+When run with `qemu-x86_64` however, it does not (also qemu's `-strace` confirms the signal isn't received whereas a strace of qemu shows it's in fact delivered).
+
+The pselect call itself _is_ interrupted, but the signal goes missing.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/835 b/gitlab/issues_text/target_missing/host_missing/accel_missing/835
new file mode 100644
index 00000000..b8bc502b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/835
@@ -0,0 +1,9 @@
+SDL display does not handle ps2 relative packets
+Description of problem:
+The main problem: while tracing relative events input_event_rel all mouse events are positive and seems to be the absolute x and y mouse position. When that happens ps2 sends a +x -y of a full 127 count.
+Steps to reproduce:
+1. Trace input_event_rel
+2. Observe that when moving the mouse the trace always shows positive values, that doesn't depend on what direction you move the mouse
+3. Observe that the xrel and yrel is more like absolute positions
+Additional information:
+I noticed searching on sdl2 docs and some issues related to SDL2 mouse events that when you do not specify SDL_HINT_MOUSE_RELATIVE_MODE_WARP weird things happens, i tried adding SDL_SetHint(SDL_HINT_MOUSE_RELATIVE_MODE_WARP, "1"); at the end of the sdl2 init function and the mouse events started to show normal values. I'm not sure if that's the correct way to solve the bug, but it seems to be.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/839 b/gitlab/issues_text/target_missing/host_missing/accel_missing/839
new file mode 100644
index 00000000..34bc7a50
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/839
@@ -0,0 +1,50 @@
+qxl in COLO secondary node cause QEMU to segmentation fault
+Description of problem:
+After COLO checkpoint, the Secondary VM's qemu received segmentation fault while releasing qxl resources in interface_release_resource() routine.     
+i have used gdb and qemu trace to debug Secondary VM's qemu. the object 'qxl->last_release' is null and object 'ring->items[prod].el' != 0, it leads to null pointer dereference.     
+During COLO checkpoint,the Secondary VM's qemu has loaded Primary VM's qxl states,so i think it not need to release qxl resources.
+Steps to reproduce:
+1.Startup Primary VM and Secondary VM of COLO mode, and gdb to Secondary VM's qemu.     
+2.Connect to Primary VM's spice server.         
+3.Secondary VM's qemu will receiveing segmentation fault.
+Additional information:
+gdb to Secondary VM's qemu:     
+   ``` 
+Program received signal SIGSEGV, Segmentation fault.      
+[Switching to Thread 0x7ff9e3bff700 (LWP 44703)]     
+0x0000555555b2e8d6 in interface_release_resource (sin=0x555557d7c8a8, ext=...) at ../hw/display/qxl.c:783     
+783	        qxl->last_release->next = ext.info->id;    
+(gdb) bt   
+#0  0x0000555555b2e8d6 in interface_release_resource (sin=0x555557d7c8a8, ext=...) at ../hw/display/qxl.c:783    
+#1  0x00007fffd7751dd1 in red_drawable_unref () at /lib64/libspice-server.so.1    
+#2  0x00007fffd771eabe in drawable_unref () at /lib64/libspice-server.so.1    
+#3  0x00007fffd77206a7 in draw_until () at /lib64/libspice-server.so.1   
+#4  0x00007fffd771f7cd in display_channel_draw () at /lib64/libspice-server.so.1   
+#5  0x00007fffd7721b51 in display_channel_process_draw () at /lib64/libspice-server.so.1   
+#6  0x00007fffd7752142 in red_process_display () at /lib64/libspice-server.so.1
+#7  0x00007fffd77521fb in worker_source_dispatch () at /lib64/libspice-server.so.1
+#8  0x00007fffd6c2f049 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
+#9  0x00007fffd6c2f3a8 in g_main_context_iterate.isra.19 () at /lib64/libglib-2.0.so.0
+#10 0x00007fffd6c2f67a in g_main_loop_run () at /lib64/libglib-2.0.so.0
+#11 0x00007fffd775166a in red_worker_main () at /lib64/libspice-server.so.1
+#12 0x00007fffd5658dd5 in start_thread () at /lib64/libpthread.so.0
+#13 0x00007fffd538202d in clone () at /lib64/libc.so.6
+(gdb) frame 0
+#0  0x0000555555b2e8d6 in interface_release_resource (sin=0x555557d7c8a8, ext=...) at ../hw/display/qxl.c:783
+783	        qxl->last_release->next = ext.info->id;
+(gdb) print qxl->last_release
+$1 = (QXLReleaseInfo *) 0x0
+   ```
+
+qemu trace log:
+   ```
+44840@1643012769.363844:colo_send_message Send 'checkpoint-reply' message
+44840@1643012773.579053:colo_receive_message Receive 'vmstate-send' message
+44840@1643012773.978838:colo_receive_message Receive 'vmstate-size' message
+44840@1643012773.979041:colo_send_message Send 'vmstate-received' message
+44840@1643012774.180598:qxl_pre_load 0
+44703@1643012774.180660:qxl_ring_res_put 0 #res=20
+44840@1643012774.182627:qxl_post_load 0 native
+44840@1643012774.197993:colo_vm_state_change Change 'stop' => 'run'
+44840@1643012774.198030:colo_send_message Send 'vmstate-loaded' message
+   ```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/84 b/gitlab/issues_text/target_missing/host_missing/accel_missing/84
new file mode 100644
index 00000000..23cd25e0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/84
@@ -0,0 +1 @@
+Machine shut off after tons of lsi_scsi: error: MSG IN data too long
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/841 b/gitlab/issues_text/target_missing/host_missing/accel_missing/841
new file mode 100644
index 00000000..bedc6841
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/841
@@ -0,0 +1,78 @@
+SIGSEGV in memcpy in v9fs_co_readdir_many
+Description of problem:
+When running btrfs tests in vm (using `virtme`-like setup with 9pfs) occasionally qemu crashes with (`coredumpctl info` output):
+```
+...
+Message: Process 1764494 (qemu-system-x86) of user 502 dumped core.
+Stack trace of thread 1764817:
+ #0  0x00005555559ebeed v9fs_co_readdir_many (/usr/bin/qemu-system-x86_64 + 0x497eed)
+ #1  0x00005555559ec2e9 v9fs_readdir (/usr/bin/qemu-system-x86_64 + 0x4982e9)
+ #2  0x0000555555eb7983 coroutine_trampoline (/usr/bin/qemu-system-x86_64 + 0x963983)
+ #3  0x00007ffff73e0be0 n/a (n/a + 0x0)
+```
+Additional information:
+coredumpctl debug:
+```
+Failed to read a valid object file image from memory.
+Core was generated by `qemu-system-x86_64 -enable-kvm -m 40270M -smp cores=20 -nodefaults -nographic -'.
+Program terminated with signal SIGSEGV, Segmentation fault.
+#0  0x00005555559ebeed in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>, __dest=<optimized out>, __src=<optimized out>,
+    __len=<optimized out>) at /usr/include/bits/string_fortified.h:29
+29        return __builtin___memcpy_chk (__dest, __src, __len,
+[Current thread is 1 (LWP 1764817)]
+(gdb) list ../hw/9pfs/codir.c:147
+142                 *entries = e = g_malloc0(sizeof(V9fsDirEnt));
+143             } else {
+144                 e = e->next = g_malloc0(sizeof(V9fsDirEnt));
+145             }
+146             e->dent = g_malloc0(sizeof(struct dirent));
+147             memcpy(e->dent, dent, sizeof(struct dirent));
+148
+149             /* perform a full stat() for directory entry if requested by caller */
+150             if (dostat) {
+151                 err = s->ops->name_to_path(
+(gdb) bt
+#0  0x00005555559ebeed in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>, __dest=<optimized out>, __src=<optimized out>,
+    __len=<optimized out>) at /usr/include/bits/string_fortified.h:29
+#1  do_readdir_many (dostat=<optimized out>, maxsize=<optimized out>, offset=<optimized out>, entries=<optimized out>, fidp=<optimized out>,
+    pdu=0x555557353500) at ../hw/9pfs/codir.c:147
+#2  v9fs_co_readdir_many (pdu=pdu@entry=0x555557353500, fidp=fidp@entry=0x555556cdd280, entries=entries@entry=0x7ff5bf7f7f58, offset=<optimized out>,
+    maxsize=<optimized out>, dostat=<optimized out>) at ../hw/9pfs/codir.c:226
+#3  0x00005555559ec2e9 in v9fs_do_readdir (max_count=<optimized out>, offset=<optimized out>, fidp=0x555556cdd280, pdu=0x555557353500) at ../hw/9pfs/9p.c:2430
+#4  v9fs_readdir (opaque=0x555557353500) at ../hw/9pfs/9p.c:2543
+#5  0x0000555555eb7983 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at ../util/coroutine-ucontext.c:173
+#6  0x00007ffff73e0be0 in ?? ()
+#7  0x00007fffffffd480 in ?? ()
+#8  0x0000000000000000 in ?? ()
+(gdb) x/11i 0x00005555559ebeed - 27
+   0x5555559ebed2 <v9fs_co_readdir_many+530>:   call   0x555555928480 <g_malloc0@plt>
+   0x5555559ebed7 <v9fs_co_readdir_many+535>:   mov    %rbp,%rsi
+   0x5555559ebeda <v9fs_co_readdir_many+538>:   mov    %rax,(%r12)
+   0x5555559ebede <v9fs_co_readdir_many+542>:   mov    0x0(%rbp),%rdx
+   0x5555559ebee2 <v9fs_co_readdir_many+546>:   lea    0x8(%rax),%rdi
+   0x5555559ebee6 <v9fs_co_readdir_many+550>:   and    $0xfffffffffffffff8,%rdi
+   0x5555559ebeea <v9fs_co_readdir_many+554>:   mov    %rdx,(%rax)
+=> 0x5555559ebeed <v9fs_co_readdir_many+557>:   mov    0x110(%rbp),%rdx
+   0x5555559ebef4 <v9fs_co_readdir_many+564>:   mov    %rdx,0x110(%rax)
+   0x5555559ebefb <v9fs_co_readdir_many+571>:   sub    %rdi,%rax
+   0x5555559ebefe <v9fs_co_readdir_many+574>:   sub    %rax,%rsi
+(gdb) i r rdx rax rip
+rdx            0x29287d            2697341
+rax            0x7ff4bc12ccf0      140689104096496
+rip            0x5555559ebeed      0x5555559ebeed <v9fs_co_readdir_many+557>
+(gdb) x/11x 0x7ff4bc12ccf0
+0x7ff4bc12ccf0: 0x0029287d      0x00000000      0x00000000      0x00000000
+0x7ff4bc12cd00: 0x00000000      0x00000000      0x00000000      0x00000000
+0x7ff4bc12cd10: 0x00000000      0x00000000      0x00000000
+(gdb) frame 1
+#1  do_readdir_many (dostat=<optimized out>, maxsize=<optimized out>, offset=<optimized out>, entries=<optimized out>, fidp=<optimized out>,
+    pdu=0x555557353500) at ../hw/9pfs/codir.c:147
+147             memcpy(e->dent, dent, sizeof(struct dirent));
+(gdb) p e
+$3 = (struct V9fsDirEnt *) 0x7ff4bc12caa0
+(gdb) p e->dent
+$4 = (struct dirent *) 0x7ff4bc12ccf0
+(gdb) p dent
+$5 = (struct dirent *) 0x7ff4ec04cef0
+
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/845 b/gitlab/issues_text/target_missing/host_missing/accel_missing/845
new file mode 100644
index 00000000..05af39fc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/845
@@ -0,0 +1,59 @@
+Heap-use-after-free in remote_object_finalize
+Description of problem:
+While I was working with `QIOChannel` in my downstream QEMU fork, I looked at `hw/remote/remote-obj.c` as a usage example.
+
+I did the same thing to `remote_object_finalize` function in order to free the QIOChannel when the connection closed:
+
+```c
+    if (o->ioc) {
+        qio_channel_shutdown(o->ioc, QIO_CHANNEL_SHUTDOWN_BOTH, NULL);
+        qio_channel_close(o->ioc, NULL);
+    }
+
+    object_unref(OBJECT(o->ioc));
+```
+
+After the connection is closed for a while, my program SIGSEGV:
+
+```
+Thread 2 Crashed:
+0   qemu-system-aarch64           	0x000000010164513c qemu_coroutine_get_aio_context + 12 (qemu-coroutine.c:203)
+1   qemu-system-aarch64           	0x000000010145ad82 qio_channel_restart_read + 50
+2   qemu-system-aarch64           	0x0000000101614c8a aio_dispatch_handler + 378 (aio-posix.c:332)
+3   qemu-system-aarch64           	0x0000000101613fad aio_dispatch_handlers + 125 (aio-posix.c:372)
+4   qemu-system-aarch64           	0x0000000101613ef3 aio_dispatch + 51 (aio-posix.c:383)
+5   qemu-system-aarch64           	0x0000000101631e18 aio_ctx_dispatch + 104 (async.c:307)
+6   libglib-2.0.0.dylib           	0x000000010284b90c g_main_context_dispatch + 364
+7   qemu-system-aarch64           	0x0000000101644728 glib_pollfds_poll + 88 (main-loop.c:233)
+8   qemu-system-aarch64           	0x0000000101644170 os_host_main_loop_wait + 128 (main-loop.c:256)
+9   qemu-system-aarch64           	0x000000010164403c main_loop_wait + 188 (main-loop.c:530)
+10  qemu-system-aarch64           	0x00000001012f3014 qemu_main_loop + 36 (runstate.c:721)
+11  qemu-system-aarch64           	0x0000000100c25e38 qemu_main + 40 (main.c:51)
+12  qemu-system-aarch64           	0x0000000100c7b1f4 call_qemu_main + 52 (cocoa.m:1746)
+13  qemu-system-aarch64           	0x000000010161a459 qemu_thread_start + 185 (qemu-thread-posix.c:521)
+14  libsystem_pthread.dylib       	0x00007fff6a6e2109 _pthread_start + 148
+15  libsystem_pthread.dylib       	0x00007fff6a6ddb8b thread_start + 15
+```
+
+So apparently, there is a dangling pointer of the QIOChannel in AIOContext.
+
+And indeed, that caused by the fact that when the fd read/write is blocked, it sets the fd handlers to the AIO context before yielding the coroutine (https://gitlab.com/qemu-project/qemu/-/blob/master/io/channel.c#L544).
+
+So after the fd is closed, the AIO still dispatches the fd readable event when the main loop dispatches again, using the dangling QIOChannel pointer (When the fd is reused I think).
+
+I suggest adding a `qio_channel_detach_aio_context()` call before the channel is shutdown in `remote-obj.c`, or before the fd is closed in `qio_channel_close()` in `io/channel.c`
+
+```c
+
+    if (o->ioc) {
+        qio_channel_detach_aio_context(o->ioc);
+        qio_channel_shutdown(o->ioc, QIO_CHANNEL_SHUTDOWN_BOTH, NULL);
+        qio_channel_close(o->ioc, NULL);
+    }
+
+    object_unref(OBJECT(o->ioc));
+```
+
+This bug might have slipped through the cracks because `mpqemu_remote_msg_loop_co` issues a shutdown request immediately after an I/O error occured on the QIOChannel.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/846 b/gitlab/issues_text/target_missing/host_missing/accel_missing/846
new file mode 100644
index 00000000..9aa81305
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/846
@@ -0,0 +1 @@
+Why qemu crashes and calling SYS_SECCOMP function
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/848 b/gitlab/issues_text/target_missing/host_missing/accel_missing/848
new file mode 100644
index 00000000..9ad2208a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/848
@@ -0,0 +1,48 @@
+`checkinstall` on Devuan Chimaera (equiv to Debian Bullseye) fails with `FileNotFoundError:`
+Description of problem:
+Configure and compile work without errors, but `checkinstall` fails with following error.
+
+```
+Installing with make install...
+
+========================= Installation results ===========================
+changing dir to build for make "install"...
+make[1]: Entering directory '/root/go/src/github.com/qemu/qemu/build'
+  GIT     ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone slirp
+[1/20] Generating qemu-version.h with a meson_exe.py custom command
+[1/2] Installing files.
+Traceback (most recent call last):
+  File "/root/go/src/github.com/qemu/qemu/meson/mesonbuild/mesonmain.py", line 140, in run
+    return options.run_func(options)
+  File "/root/go/src/github.com/qemu/qemu/meson/mesonbuild/minstall.py", line 544, in run
+    installer.do_install(datafilename)
+  File "/root/go/src/github.com/qemu/qemu/meson/mesonbuild/minstall.py", line 362, in do_install
+    self.install_targets(d)
+  File "/root/go/src/github.com/qemu/qemu/meson/mesonbuild/minstall.py", line 472, in install_targets
+    file_copied = self.do_copyfile(fname, outname, makedirs=(d.dirmaker, outdir))
+  File "/root/go/src/github.com/qemu/qemu/meson/mesonbuild/minstall.py", line 277, in do_copyfile
+    shutil.copystat(from_file, to_file)
+  File "/usr/lib/python3.9/shutil.py", line 375, in copystat
+    lookup("utime")(dst, ns=(st.st_atime_ns, st.st_mtime_ns),
+FileNotFoundError: [Errno 2] No such file or directory
+Installing subdir /root/go/src/github.com/qemu/qemu/qga/run to /usr/local/var/run
+Installing trace/trace-events-all to /usr/local/share/qemu
+FAILED: meson-install 
+/usr/bin/python3 /root/go/src/github.com/qemu/qemu/meson/meson.py install --no-rebuild
+ninja: build stopped: subcommand failed.
+make[1]: *** [Makefile:156: run-ninja] Error 1
+make[1]: Leaving directory '/root/go/src/github.com/qemu/qemu/build'
+make: *** [GNUmakefile:11: install] Error 2
+
+****  Installation failed. Aborting package creation.
+
+Cleaning up...OK
+
+Bye.
+
+```
+Additional information:
+- All packages from [requirements](https://wiki.qemu.org/Hosts/Linux#Fedora_Linux_.2F_Debian_GNU_Linux_.2F_Ubuntu_Linux_.2F_Linux_Mint_distributions) installed.
+- command `utime` is available from `atfs` package
+
+I believe error may be related to the `from_file`/`to_file`in: `meson/mesonbuild/minstall.py` line 277.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/850 b/gitlab/issues_text/target_missing/host_missing/accel_missing/850
new file mode 100644
index 00000000..26e94f99
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/850
@@ -0,0 +1,59 @@
+virtio-gpu: bogus descriptor or out of resources
+Description of problem:
+The guest which I use have 1GB memory, also the guest contains 8GB swap, when I open lot of applications in the guest, the guest kernel starts using swap, after some time, I get this error
+
+<code>
+qemu-system-x86_64: virtio: bogus descriptor or out of resources
+</code>
+
+I tried to see which virtio device causing this issue, it seems this issue is happening in "virtio-gpu", I modified the sources ad added this line to see the device name
+
+virtio.c:1312: virtio_error(vdev, "virtio: %s: bogus descriptor or out of resources", vdev->name);
+Steps to reproduce:
+1. create a vm with 8GB swap
+2. run that vm with above mentioned commandline (memory = 1MB)
+3. open huge applications which eats ram in guest
+Additional information:
+Seems suddenly condition "if (!memory_access_is_direct(mr, is_write))" [physmem.c:1385] becomes true, this is the stack trace when "if (qatomic_xchg(&bounce.in_use, true)) {" [physmem.c:1386] line gets hit for the first time,
+
+<code>
+#0  address_space_map (as=<optimized out>, addr=addr@entry=45251811299328, plen=plen@entry=0x7fffffff7e30, is_write=is_write@entry=false, attrs=..., attrs@entry=...) at ../qemu-6.2.0/softmmu/physmem.c:3186
+#1  0x0000555555cb8cf4 in dma_memory_map (dir=DMA_DIRECTION_TO_DEVICE, len=<synthetic pointer>, addr=45251811299328, as=<optimized out>) at /home/mohan/Downloads/qemu/src/qemu-6.2.0/include/sysemu/dma.h:202
+#2  virtqueue_map_desc
+    (vdev=vdev@entry=0x5555579d3bb0, p_num_sg=p_num_sg@entry=0x7fffffff7ed8, addr=addr@entry=0x7fffffff7f70, iov=0x7fffffff9f70, max_num_sg=max_num_sg@entry=1024, is_write=is_write@entry=false, pa=45251811299328, sz=65536) at ../qemu-6.2.0/hw/virtio/virtio.c:1307
+#3  0x0000555555cb8f9e in virtqueue_packed_pop (vq=<optimized out>, sz=<optimized out>) at ../qemu-6.2.0/hw/virtio/virtio.c:1624
+#4  0x00007fffec0b329e in virtio_gpu_gl_handle_ctrl (vdev=<optimized out>, vq=0x7fffdced6010) at ../qemu-6.2.0/hw/display/virtio-gpu-gl.c:77
+#5  0x0000555555f74134 in aio_bh_call (bh=0x555556d02bc0) at ../qemu-6.2.0/util/async.c:141
+#6  aio_bh_poll (ctx=ctx@entry=0x555556958750) at ../qemu-6.2.0/util/async.c:169
+#7  0x0000555555f5f784 in aio_dispatch (ctx=0x555556958750) at ../qemu-6.2.0/util/aio-posix.c:381
+#8  0x0000555555f73d63 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../qemu-6.2.0/util/async.c:311
+#9  0x00007ffff787dfd3 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
+#10 0x0000555555f80129 in glib_pollfds_poll () at ../qemu-6.2.0/util/main-loop.c:232
+#11 os_host_main_loop_wait (timeout=0) at ../qemu-6.2.0/util/main-loop.c:255
+#12 main_loop_wait (nonblocking=nonblocking@entry=0) at ../qemu-6.2.0/util/main-loop.c:531
+#13 0x0000555555c48fe5 in qemu_main_loop () at ../qemu-6.2.0/softmmu/runstate.c:726
+#14 0x000055555597b664 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../qemu-6.2.0/softmmu/main.c:50
+</code>
+<br/>
+address_space_map() returns valid pointer in the first hit, but it returns NULL on the second hit because qatomic_xchg(bounce.in_use, true) returns true, I think it should suppose to return false. this is the stack trace when it happens for the second time
+<br/>
+<code>
+#0  address_space_map (as=<optimized out>, addr=addr@entry=45251811303424, plen=plen@entry=0x7fffffff7e30, is_write=is_write@entry=false, attrs=..., attrs@entry=...) at ../qemu-6.2.0/softmmu/physmem.c:3186
+#1  0x0000555555cb8cf4 in dma_memory_map (dir=DMA_DIRECTION_TO_DEVICE, len=<synthetic pointer>, addr=45251811303424, as=<optimized out>) at /home/mohan/Downloads/qemu/src/qemu-6.2.0/include/sysemu/dma.h:202
+#2  virtqueue_map_desc
+    (vdev=vdev@entry=0x5555579d3bb0, p_num_sg=p_num_sg@entry=0x7fffffff7ed8, addr=addr@entry=0x7fffffff7f70, iov=0x7fffffff9f70, max_num_sg=max_num_sg@entry=1024, is_write=is_write@entry=false, pa=45251811303424, sz=61440) at ../qemu-6.2.0/hw/virtio/virtio.c:1307
+#3  0x0000555555cb8f9e in virtqueue_packed_pop (vq=<optimized out>, sz=<optimized out>) at ../qemu-6.2.0/hw/virtio/virtio.c:1624
+#4  0x00007fffec0b329e in virtio_gpu_gl_handle_ctrl (vdev=<optimized out>, vq=0x7fffdced6010) at ../qemu-6.2.0/hw/display/virtio-gpu-gl.c:77
+#5  0x0000555555f74134 in aio_bh_call (bh=0x555556d02bc0) at ../qemu-6.2.0/util/async.c:141
+#6  aio_bh_poll (ctx=ctx@entry=0x555556958750) at ../qemu-6.2.0/util/async.c:169
+#7  0x0000555555f5f784 in aio_dispatch (ctx=0x555556958750) at ../qemu-6.2.0/util/aio-posix.c:381
+#8  0x0000555555f73d63 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../qemu-6.2.0/util/async.c:311
+#9  0x00007ffff787dfd3 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
+#10 0x0000555555f80129 in glib_pollfds_poll () at ../qemu-6.2.0/util/main-loop.c:232
+#11 os_host_main_loop_wait (timeout=0) at ../qemu-6.2.0/util/main-loop.c:255
+#12 main_loop_wait (nonblocking=nonblocking@entry=0) at ../qemu-6.2.0/util/main-loop.c:531
+#13 0x0000555555c48fe5 in qemu_main_loop () at ../qemu-6.2.0/softmmu/runstate.c:726
+#14 0x000055555597b664 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../qemu-6.2.0/softmmu/main.c:50
+</code>
+<br/>
+It seems virtqueue_packed_pop() receives one desc with desc.len=65536 (or -1) which should not suppose to happen. I dont know why this is happening
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/851 b/gitlab/issues_text/target_missing/host_missing/accel_missing/851
new file mode 100644
index 00000000..989a387c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/851
@@ -0,0 +1,233 @@
+qemu-img create results in tsan warnings
+Description of problem:
+Running qemu-img w/ tsan enabled results in a bunch of data races reported:
+
+```
+Formatting 'delta.img', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=0 backing_file=base.img backing_fmt=raw lazy_refcounts=off refcount_bits=16
+==================
+WARNING: ThreadSanitizer: data race (pid=217825)
+  Atomic write of size 8 at 0x7b4800000228 by main thread:
+    #0 __tsan_atomic64_exchange <null> (qemu-img+0xb6a55)
+    #1 aio_bh_poll /usr/local/google/home/pefoley/qemu/build/../util/async.c:151:5 (qemu-img+0x239931)
+    #2 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:707:17 (qemu-img+0x220822)
+    #3 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1)
+    #4 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b)
+    #5 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad)
+    #6 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3)
+
+  Previous read of size 8 at 0x7b4800000228 by thread T5 (mutexes: write M42):
+    #0 aio_bh_enqueue /usr/local/google/home/pefoley/qemu/build/../util/async.c:82:9 (qemu-img+0x239c4c)
+    #1 qemu_bh_schedule /usr/local/google/home/pefoley/qemu/build/../util/async.c:186:5 (qemu-img+0x239c4c)
+    #2 worker_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:113:9 (qemu-img+0x24fe7c)
+    #3 qemu_thread_start /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:556:9 (qemu-img+0x225960)
+
+  Location is heap block of size 336 at 0x7b4800000180 allocated by main thread:
+    #0 calloc <null> (qemu-img+0x68ff9)
+    #1 g_malloc0 <null> (libglib-2.0.so.0+0x59e70)
+    #2 qemu_init_main_loop /usr/local/google/home/pefoley/qemu/build/../util/main-loop.c:169:24 (qemu-img+0x24bd47)
+    #3 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5397:5 (qemu-img+0xddcd7)
+
+  Mutex M42 (0x7b3800000010) created at:
+    #0 pthread_mutex_init <null> (qemu-img+0x6bc0f)
+    #1 qemu_mutex_init /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:57:11 (qemu-img+0x223f69)
+    #2 thread_pool_init_one /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:306:5 (qemu-img+0x24f24d)
+    #3 thread_pool_new /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:319:5 (qemu-img+0x24f24d)
+    #4 aio_get_thread_pool /usr/local/google/home/pefoley/qemu/build/../util/async.c:390:28 (qemu-img+0x239fd4)
+    #5 raw_thread_pool_submit /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2045:24 (qemu-img+0x1b51f7)
+    #6 raw_regular_truncate /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2231:12 (qemu-img+0x1b51f7)
+    #7 raw_co_create /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2519:14 (qemu-img+0x1b51f7)
+    #8 raw_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2635:12 (qemu-img+0x1b5678)
+    #9 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf87c5)
+    #10 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:544:9 (qemu-img+0xf87c5)
+    #11 bdrv_create_file /usr/local/google/home/pefoley/qemu/build/../block.c:734:11 (qemu-img+0xf8d3d)
+    #12 qcow2_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/qcow2.c:3842:11 (qemu-img+0x170c63)
+    #13 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf8975)
+    #14 coroutine_trampoline /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:173:9 (qemu-img+0x23d008)
+    #15 <null> <null> (libc.so.6+0x51a2f)
+
+  Thread T5 'worker' (tid=217829, running) created by main thread at:
+    #0 pthread_create <null> (qemu-img+0x6a49d)
+    #1 qemu_thread_create /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:596:11 (qemu-img+0x225800)
+    #2 do_spawn_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:134:5 (qemu-img+0x24fac3)
+    #3 spawn_thread_bh_fn /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:142:5 (qemu-img+0x24fac3)
+    #4 aio_bh_call /usr/local/google/home/pefoley/qemu/build/../util/async.c:141:5 (qemu-img+0x239a96)
+    #5 aio_bh_poll /usr/local/google/home/pefoley/qemu/build/../util/async.c:169:13 (qemu-img+0x239a96)
+    #6 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:707:17 (qemu-img+0x220822)
+    #7 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1)
+    #8 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b)
+    #9 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad)
+    #10 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3)
+
+SUMMARY: ThreadSanitizer: data race (/usr/local/google/home/pefoley/qemu/build/qemu-img+0xb6a55) in __tsan_atomic64_exchange
+==================
+==================
+WARNING: ThreadSanitizer: data race (pid=217825)
+  Write of size 4 at 0x7b1c000005f0 by thread T5 (mutexes: write M42):
+    #0 worker_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:101:20 (qemu-img+0x24fde3)
+    #1 qemu_thread_start /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:556:9 (qemu-img+0x225960)
+
+  Previous read of size 4 at 0x7b1c000005f0 by main thread (mutexes: write M19):
+    #0 thread_pool_completion_bh /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:170:19 (qemu-img+0x24f7ae)
+    #1 aio_bh_call /usr/local/google/home/pefoley/qemu/build/../util/async.c:141:5 (qemu-img+0x239a96)
+    #2 aio_bh_poll /usr/local/google/home/pefoley/qemu/build/../util/async.c:169:13 (qemu-img+0x239a96)
+    #3 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:707:17 (qemu-img+0x220822)
+    #4 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1)
+    #5 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b)
+    #6 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad)
+    #7 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3)
+
+  Location is heap block of size 104 at 0x7b1c000005b0 allocated by thread T4:
+    #0 malloc <null> (qemu-img+0x68e0d)
+    #1 g_malloc <null> (libglib-2.0.so.0+0x59e18)
+    #2 thread_pool_submit_aio /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:249:11 (qemu-img+0x24edc8)
+    #3 thread_pool_submit_co /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:287:5 (qemu-img+0x24f0fe)
+    #4 raw_thread_pool_submit /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2046:12 (qemu-img+0x1b5334)
+    #5 raw_regular_truncate /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2231:12 (qemu-img+0x1b5334)
+    #6 raw_co_create /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2562:14 (qemu-img+0x1b5334)
+    #7 raw_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2635:12 (qemu-img+0x1b5678)
+    #8 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf87c5)
+    #9 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:544:9 (qemu-img+0xf87c5)
+    #10 bdrv_create_file /usr/local/google/home/pefoley/qemu/build/../block.c:734:11 (qemu-img+0xf8d3d)
+    #11 qcow2_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/qcow2.c:3842:11 (qemu-img+0x170c63)
+    #12 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf8975)
+    #13 coroutine_trampoline /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:173:9 (qemu-img+0x23d008)
+    #14 <null> <null> (libc.so.6+0x51a2f)
+
+  Mutex M42 (0x7b3800000010) created at:
+    #0 pthread_mutex_init <null> (qemu-img+0x6bc0f)
+    #1 qemu_mutex_init /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:57:11 (qemu-img+0x223f69)
+    #2 thread_pool_init_one /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:306:5 (qemu-img+0x24f24d)
+    #3 thread_pool_new /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:319:5 (qemu-img+0x24f24d)
+    #4 aio_get_thread_pool /usr/local/google/home/pefoley/qemu/build/../util/async.c:390:28 (qemu-img+0x239fd4)
+    #5 raw_thread_pool_submit /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2045:24 (qemu-img+0x1b51f7)
+    #6 raw_regular_truncate /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2231:12 (qemu-img+0x1b51f7)
+    #7 raw_co_create /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2519:14 (qemu-img+0x1b51f7)
+    #8 raw_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2635:12 (qemu-img+0x1b5678)
+    #9 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf87c5)
+    #10 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:544:9 (qemu-img+0xf87c5)
+    #11 bdrv_create_file /usr/local/google/home/pefoley/qemu/build/../block.c:734:11 (qemu-img+0xf8d3d)
+    #12 qcow2_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/qcow2.c:3842:11 (qemu-img+0x170c63)
+    #13 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf8975)
+    #14 coroutine_trampoline /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:173:9 (qemu-img+0x23d008)
+    #15 <null> <null> (libc.so.6+0x51a2f)
+
+  Mutex M19 (0x7b48000001e0) created at:
+    #0 pthread_mutex_init <null> (qemu-img+0x6bc0f)
+    #1 qemu_rec_mutex_init /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:120:11 (qemu-img+0x224625)
+    #2 aio_context_new /usr/local/google/home/pefoley/qemu/build/../util/async.c:555:5 (qemu-img+0x23a226)
+    #3 qemu_init_main_loop /usr/local/google/home/pefoley/qemu/build/../util/main-loop.c:169:24 (qemu-img+0x24bd47)
+    #4 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5397:5 (qemu-img+0xddcd7)
+
+  Thread T5 'worker' (tid=217829, running) created by main thread at:
+    #0 pthread_create <null> (qemu-img+0x6a49d)
+    #1 qemu_thread_create /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:596:11 (qemu-img+0x225800)
+    #2 do_spawn_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:134:5 (qemu-img+0x24fac3)
+    #3 spawn_thread_bh_fn /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:142:5 (qemu-img+0x24fac3)
+    #4 aio_bh_call /usr/local/google/home/pefoley/qemu/build/../util/async.c:141:5 (qemu-img+0x239a96)
+    #5 aio_bh_poll /usr/local/google/home/pefoley/qemu/build/../util/async.c:169:13 (qemu-img+0x239a96)
+    #6 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:707:17 (qemu-img+0x220822)
+    #7 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1)
+    #8 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b)
+    #9 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad)
+    #10 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3)
+
+  Thread T4 (tid=0, running) created by main thread at:
+    #0 on_new_fiber /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:90:25 (qemu-img+0x23cead)
+    #1 qemu_coroutine_new /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:219:5 (qemu-img+0x23cead)
+    #2 qemu_coroutine_create /usr/local/google/home/pefoley/qemu/build/../util/qemu-coroutine.c:75:14 (qemu-img+0x24c7be)
+    #3 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:546:14 (qemu-img+0xf8884)
+    #4 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b)
+    #5 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad)
+    #6 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3)
+
+SUMMARY: ThreadSanitizer: data race /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:101:20 in worker_thread
+==================
+==================
+WARNING: ThreadSanitizer: data race (pid=217825)
+  Atomic write of size 4 at 0x7b0c000000e8 by thread T5 (mutexes: write M42):
+    #0 __tsan_atomic32_fetch_or <null> (qemu-img+0xb9ec1)
+    #1 aio_bh_enqueue /usr/local/google/home/pefoley/qemu/build/../util/async.c:80:17 (qemu-img+0x239c23)
+    #2 qemu_bh_schedule /usr/local/google/home/pefoley/qemu/build/../util/async.c:186:5 (qemu-img+0x239c23)
+    #3 worker_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:113:9 (qemu-img+0x24fe7c)
+    #4 qemu_thread_start /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:556:9 (qemu-img+0x225960)
+
+  Previous read of size 4 at 0x7b0c000000e8 by main thread:
+    #0 aio_compute_bh_timeout /usr/local/google/home/pefoley/qemu/build/../util/async.c:209:18 (qemu-img+0x239e7f)
+    #1 aio_compute_timeout /usr/local/google/home/pefoley/qemu/build/../util/async.c:232:15 (qemu-img+0x239e7f)
+    #2 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:624:26 (qemu-img+0x21f9c2)
+    #3 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1)
+    #4 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b)
+    #5 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad)
+    #6 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3)
+
+  Location is heap block of size 48 at 0x7b0c000000c0 allocated by thread T4:
+    #0 malloc <null> (qemu-img+0x68e0d)
+    #1 g_malloc <null> (libglib-2.0.so.0+0x59e18)
+    #2 thread_pool_init_one /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:305:27 (qemu-img+0x24f235)
+    #3 thread_pool_new /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:319:5 (qemu-img+0x24f235)
+    #4 aio_get_thread_pool /usr/local/google/home/pefoley/qemu/build/../util/async.c:390:28 (qemu-img+0x239fd4)
+    #5 raw_thread_pool_submit /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2045:24 (qemu-img+0x1b51f7)
+    #6 raw_regular_truncate /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2231:12 (qemu-img+0x1b51f7)
+    #7 raw_co_create /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2519:14 (qemu-img+0x1b51f7)
+    #8 raw_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2635:12 (qemu-img+0x1b5678)
+    #9 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf87c5)
+    #10 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:544:9 (qemu-img+0xf87c5)
+    #11 bdrv_create_file /usr/local/google/home/pefoley/qemu/build/../block.c:734:11 (qemu-img+0xf8d3d)
+    #12 qcow2_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/qcow2.c:3842:11 (qemu-img+0x170c63)
+    #13 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf8975)
+    #14 coroutine_trampoline /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:173:9 (qemu-img+0x23d008)
+    #15 <null> <null> (libc.so.6+0x51a2f)
+
+  Mutex M42 (0x7b3800000010) created at:
+    #0 pthread_mutex_init <null> (qemu-img+0x6bc0f)
+    #1 qemu_mutex_init /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:57:11 (qemu-img+0x223f69)
+    #2 thread_pool_init_one /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:306:5 (qemu-img+0x24f24d)
+    #3 thread_pool_new /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:319:5 (qemu-img+0x24f24d)
+    #4 aio_get_thread_pool /usr/local/google/home/pefoley/qemu/build/../util/async.c:390:28 (qemu-img+0x239fd4)
+    #5 raw_thread_pool_submit /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2045:24 (qemu-img+0x1b51f7)
+    #6 raw_regular_truncate /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2231:12 (qemu-img+0x1b51f7)
+    #7 raw_co_create /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2519:14 (qemu-img+0x1b51f7)
+    #8 raw_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/file-posix.c:2635:12 (qemu-img+0x1b5678)
+    #9 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf87c5)
+    #10 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:544:9 (qemu-img+0xf87c5)
+    #11 bdrv_create_file /usr/local/google/home/pefoley/qemu/build/../block.c:734:11 (qemu-img+0xf8d3d)
+    #12 qcow2_co_create_opts /usr/local/google/home/pefoley/qemu/build/../block/qcow2.c:3842:11 (qemu-img+0x170c63)
+    #13 bdrv_create_co_entry /usr/local/google/home/pefoley/qemu/build/../block.c:516:11 (qemu-img+0xf8975)
+    #14 coroutine_trampoline /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:173:9 (qemu-img+0x23d008)
+    #15 <null> <null> (libc.so.6+0x51a2f)
+
+  Thread T5 'worker' (tid=217829, running) created by main thread at:
+    #0 pthread_create <null> (qemu-img+0x6a49d)
+    #1 qemu_thread_create /usr/local/google/home/pefoley/qemu/build/../util/qemu-thread-posix.c:596:11 (qemu-img+0x225800)
+    #2 do_spawn_thread /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:134:5 (qemu-img+0x24fac3)
+    #3 spawn_thread_bh_fn /usr/local/google/home/pefoley/qemu/build/../util/thread-pool.c:142:5 (qemu-img+0x24fac3)
+    #4 aio_bh_call /usr/local/google/home/pefoley/qemu/build/../util/async.c:141:5 (qemu-img+0x239a96)
+    #5 aio_bh_poll /usr/local/google/home/pefoley/qemu/build/../util/async.c:169:13 (qemu-img+0x239a96)
+    #6 aio_poll /usr/local/google/home/pefoley/qemu/build/../util/aio-posix.c:707:17 (qemu-img+0x220822)
+    #7 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:549:13 (qemu-img+0xf88b1)
+    #8 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b)
+    #9 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad)
+    #10 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3)
+
+  Thread T4 (tid=0, running) created by main thread at:
+    #0 on_new_fiber /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:90:25 (qemu-img+0x23cead)
+    #1 qemu_coroutine_new /usr/local/google/home/pefoley/qemu/build/../util/coroutine-ucontext.c:219:5 (qemu-img+0x23cead)
+    #2 qemu_coroutine_create /usr/local/google/home/pefoley/qemu/build/../util/qemu-coroutine.c:75:14 (qemu-img+0x24c7be)
+    #3 bdrv_create /usr/local/google/home/pefoley/qemu/build/../block.c:546:14 (qemu-img+0xf8884)
+    #4 bdrv_img_create /usr/local/google/home/pefoley/qemu/build/../block.c:6911:11 (qemu-img+0x107c1b)
+    #5 img_create /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:585:5 (qemu-img+0xe2dad)
+    #6 main /usr/local/google/home/pefoley/qemu/build/../qemu-img.c:5449:20 (qemu-img+0xddfc3)
+
+SUMMARY: ThreadSanitizer: data race (/usr/local/google/home/pefoley/qemu/build/qemu-img+0xb9ec1) in __tsan_atomic32_fetch_or
+==================
+ThreadSanitizer: reported 3 warnings
+```
+Steps to reproduce:
+1. ./configure --target-list=x86_64-softmmu --enable-tsan --cc=clang --cxx=clang++
+2. make -j12
+3. touch base.img
+4. build/qemu-img create -b base.img -f qcow2 -F raw delta.img
+
+./configure --target-list=x86_64-softmmu --enable-tsan --cc=clang --cxx=clang++
+touch base.img
+build/qemu-img create -b base.img -f qcow2 -F raw delta.img
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/853 b/gitlab/issues_text/target_missing/host_missing/accel_missing/853
new file mode 100644
index 00000000..589ef59f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/853
@@ -0,0 +1,10 @@
+Quaint English in qemu-options.hx
+Description of problem:
+qemu-options.hx contains grammar that a native English-speaking person would never use. I had to read a sentence in that file very slowly and more than once to understand it.
+Steps to reproduce:
+1. Install QEMU
+2. Run a command to display documentation that includes qemu-options.hx for instance "man qemu-system-x86_64"
+3. Observe "This option defines where is connected the drive ..."
+4. Scratch head, figure out that "This option defines where the drive is connected ..." is the meaning.
+Additional information:
+It is very difficult to report QEMU documentation bugs.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/854 b/gitlab/issues_text/target_missing/host_missing/accel_missing/854
new file mode 100644
index 00000000..b200c4e1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/854
@@ -0,0 +1,62 @@
+rsync to ext4-fs on dynamic expanding qcow2 fails
+Description of problem:
+Firstly, this issue does not seem to happen when the virtual-disk is dd-raw-img or fixed qcow2 (preallocation=falloc). The guest-kernel has multiple tracebacks during rsync to dst folder on ext4-fs on qcow2. 
+I ctrl-C-ed the rsync process after the first traceback, which happened after copying around 52 GiB. 
+On a previous run, wherein I had let it continue, somewhere near the end, around 83 GiB, dmesg would bloat with a zillion trace-backs and stall. The sha256sum verify seems to have succeeded for all files copied so far and correctly gives error "Failed open or read" on subsequent files that were not copied. 
+In this test, the partial-rsync completed files were not corrupted. However, as qemu's disk emulation allocates blocks, qemu may be inducing paging-bugs into the guest-kernel. Paging issues like these may also lead to corruption. The guest-kernel should see the same full emulated disk regardless of whether qemu provided a fixed disk, dynamic disk, or even a different type of virtual-disk-format. The guest-vm should not detect/perceive any difference between them.
+
+There may be upcoming trouble round the 5.17 corner.
+
+It is beyond me to figure out if this is due to
+* qemu-6.2 block code
+* guest-kernel ( kernel-5.17 folio/page management or ntfs3 driver or something else )  
+
+It may be necessary to ascertain if this is a new bug on account of qemu not being ready for folio type page-management or a bug in upstream kernel.org. My apologies in advance if it turns out that this is not a qemu bug.
+
+There there does seem to be some problem with qemu dealing with expanding virtual disks, with bugs that show up only if the underlying virtual-disk is dynamic and expanding.
+
+I just think that storage/block-code should be made rock solid with a much higher priority than adding new features.
+If storage code is undependable, then qemu/vm cannot be used, and there is no point in any other feature. qcow2 in particular is the qemu's native virtual-disk format.
+
+I had to stop testing on Issue #727 , Issue #814 , on account of what I thought was a bug in 5.15 kernels. I filed the bug as "fs/ntfs3: page_cache_ra_unbounded on rsync from ntfs3 to ext4" https://bugzilla.kernel.org/show_bug.cgi?id=215460 . I assume that bug is different because it happens even on raw image. 
+
+setup is as follows:
+- Host: Fedora-35 with kernel-5.17.0-0.rc2.83.fc35.x86_64 self-built from srpm ( https://koji.fedoraproject.org/koji/buildinfo?buildID=1910212 )
+- Guest: Fedora-Workstation-Live-x86_64-Rawhide-20220201.n.0.iso with 5.17.0-0.rc2.83.fc36.x86_64 ( https://koji.fedoraproject.org/koji/buildinfo?buildID=1910892 )  
+- qemu: 6.2.0 (qemu-6.2.0-2.fc35.1) self-built from srpm  ( https://koji.fedoraproject.org/koji/buildinfo?buildID=1897713 )
+- hda: qcow2(dyn) with ext4 and also 4 combinations of raw_img/fixed_qcow2 with ext4/ntfs3
+- hdb: vhdx, ntfs3 (pre-prepared sgdata https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694 )  
+
+qcow2 image is created as follows:
+``` 
+[root@sirius ~]# qemu-img create -f qcow2 /mnt/a16/gkpics01.qcow2 99723771904
+Formatting '/mnt/a16/gkpics01.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=99723771904 lazy_refcounts=off refcount_bits=16 
+```
+
+qemu command is as follows:
+``` 
+[root@sirius ~]# qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot "d" -cdrom "/vol/15KJ_Images/transcend/Fedora-Workstation-Live-x86_64-Rawhide-20220201.n.0.iso" -hda "/mnt/a16/gkpics01.raw" -hdb "/vol/15KJ_Images/test/sgdata.vhdx" -device "virtio-vga" -display "gtk,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" 
+```
+Steps to reproduce:
+1. Inside booted vm, use gdisk to partition /dev/sda1 if necessary
+2. ```dmesg -w (in another pty)``` 
+3. ```mkfs.ext4 /dev/sda1 -L fs_gkpics001``` 
+4. ```mkdir /mnt/a /mnt/b``` 
+5. ```mount -t ext4 /dev/sda1 /mnt/a``` 
+6. ```mount -t ntfs3 /dev/sdb2 /mnt/b```
+7. rsync testdata: ```(sdate=`date` ; echo "$sdate" ; cd /mnt/b ; rsync -avH ./photos001 /mnt/a | tee /tmp/rst.txt ; echo "$sdate" ; date )``` 
+8. ```umount /mnt/a ; ``` 
+9. ```mount -t ext4 /dev/sda1 /mnt/a``` 
+10. verify: ```(sdate=`date` ; echo "$sdate" ; cd /mnt/a/photos001 ; sha256sum -c ./find.CHECKSUM --quiet ; echo "$sdate" ; date )``` 
+11. ```umount /mnt/a ; umount /mnt/b;```
+Additional information:
+**Test attempts**
+- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/rawimg/ext4 with vhdx/ntfs3/sgdata 
+- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/rawimg/ntfs3 with vhdx/ntfs3/sgdata 
+- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/qcow2(fixed)/ext4 with vhdx/ntfs3/sgdata 
+- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/qcow2(fixed)/ntfs3 with vhdx/ntfs3/sgdata 
+- Bug **does** happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/**qcow2(dyn)**/ext4 with vhdx/ntfs3/sgdata 
+- Bug does not happen directly on Host with 5.17.0-0.rc2.83/ExFat with ntfs3/sgdata
+- Bug does not happen directly on Host with 5.17.0-0.rc2.83/ntfs3 with ntfs3/sgdata
+
+Also filed a linux-kernel bug titled "during rsync, vm guest kernel trace arising from memcg_kmem_charge_page alloc_pages" https://bugzilla.kernel.org/show_bug.cgi?id=215563
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/857 b/gitlab/issues_text/target_missing/host_missing/accel_missing/857
new file mode 100644
index 00000000..f5bb7f77
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/857
@@ -0,0 +1,12 @@
+qemu-x86_64 uses host libraries instead of emulated system libraries
+Description of problem:
+I'm using Buildroot to build a cross-compiled embedded Linux system. During the build process there is a little hack to create some header file using a cross-compiled application. For this hack they use qemu to run this application. Building this embedded system for aarch64 work fine, but for x86_64 I get the following messages:
+
+bytecode_builtins_list_generator: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by bytecode_builtins_list_generator)
+bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by bytecode_builtins_list_generator)
+bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by bytecode_builtins_list_generator)
+bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by bytecode_builtins_list_generator)
+
+The path of the libraries in this error message is from my host system. The embedded system uses /lib64 or /usr/lib64. It seems to me that the linker search for the libraries at first on the host system and later uses the path from the command line. So you have a mixed up of host and embedded system libraries (as you can see in the attached strace log).
+Additional information:
+[qemu-1.log](/uploads/f53e98b6b15cce7cbf94d14dffa39f90/qemu-1.log)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/861 b/gitlab/issues_text/target_missing/host_missing/accel_missing/861
new file mode 100644
index 00000000..696dbd83
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/861
@@ -0,0 +1 @@
+Using qemu+kvm is slower than using qemu in rv6(xv6 rust porting)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/865 b/gitlab/issues_text/target_missing/host_missing/accel_missing/865
new file mode 100644
index 00000000..fa179838
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/865
@@ -0,0 +1,45 @@
+virtio-vga gtk,gl=on Black Screen or GLXGears picture
+Description of problem:
+Blank screen for tab with name `virtio-vga` on GTK interface, however, if I run `glxgears` before running the machine, I see the following image: 
+
+![image](/uploads/08d426ab748826e4f291e2e5ed838288/image.png)
+Steps to reproduce:
+1.Run the invocation command provided above
+
+#
+Additional information:
+The host when the problem is occurring is a Dell Precision 5110 laptop that have Hybrid Graphics. I am running X11 with nvidia as the main driver, I am not using nouveau, I am using the nvidia drivers installed by the debian package, here the corresponding information for the nvida card:
+
+```
+nvidia-smi
+```
+```
+Thu Feb 10 23:32:21 2022       
++-----------------------------------------------------------------------------+
+| NVIDIA-SMI 460.91.03    Driver Version: 460.91.03    CUDA Version: 11.2     |
+|-------------------------------+----------------------+----------------------+
+| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
+| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
+|                               |                      |               MIG M. |
+|===============================+======================+======================|
+|   0  Quadro M1000M       On   | 00000000:01:00.0 Off |                  N/A |
+| N/A   44C    P8    N/A /  N/A |    846MiB /  2004MiB |      6%      Default |
+|                               |                      |                  N/A |
++-------------------------------+----------------------+----------------------+
+                                                                               
++-----------------------------------------------------------------------------+
+| Processes:                                                                  |
+|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
+|        ID   ID                                                   Usage      |
+|=============================================================================|
+|    0   N/A  N/A      6926      G   /usr/lib/xorg/Xorg                528MiB |
+|    0   N/A  N/A      7223      G   ...b/firefox-esr/firefox-esr      238MiB |
+|    0   N/A  N/A      7363      G   ...b/firefox-esr/firefox-esr        0MiB |
+|    0   N/A  N/A    276992      G   ...b/firefox-esr/firefox-esr        0MiB |
+|    0   N/A  N/A    282023      G   ...b/firefox-esr/firefox-esr        0MiB |
+|    0   N/A  N/A    282630      G   ...b/firefox-esr/firefox-esr        0MiB |
+|    0   N/A  N/A    322305      G   qemu-system-x86_64                 70MiB |
++-----------------------------------------------------------------------------+
+```
+
+##
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/866 b/gitlab/issues_text/target_missing/host_missing/accel_missing/866
new file mode 100644
index 00000000..7b3a2821
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/866
@@ -0,0 +1,53 @@
+linux-user: substantial memory leak when threads are created and destroyed
+Description of problem:
+Substantial memory leak when the following simple program is executed on `qemu-arm`,
+```c
+// compile with `arm-none-linux-gnueabihf-gcc test_qemu.c -o test_qemu.out -pthread`
+
+#include <assert.h>
+#include <pthread.h>
+
+#define MAGIC_RETURN ((void *)42)
+
+void *thread_main(void *arg)
+{
+    return MAGIC_RETURN;
+}
+
+int main(int argc, char *argv[])
+{
+    size_t i;
+    for (i = 0;; i++)
+    {
+        pthread_t thread;
+        assert(pthread_create(&thread, NULL, thread_main, NULL) == 0);
+        void *ret;
+        assert(pthread_join(thread, &ret) == 0);
+        assert(ret == MAGIC_RETURN);
+    }
+
+    return 0;
+}
+```
+Steps to reproduce:
+1. 
+```
+export TOOLCHAIN_PREFIX=arm-none-linux-gnueabihf
+export ARMSDK=/${TOOLCHAIN_PREFIX}
+export SYSROOT=${ARMSDK}/${TOOLCHAIN_PREFIX}/libc
+export CC=${ARMSDK}/bin/${TOOLCHAIN_PREFIX}-gcc
+```
+2. Download the arm toolchain: `curl --output ${TOOLCHAIN_PREFIX}.tar.xz -L 'https://developer.arm.com/-/media/Files/downloads/gnu-a/10.2-2020.11/binrel/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf.tar.xz?revision=d0b90559-3960-4e4b-9297-7ddbc3e52783&la=en&hash=985078B758BC782BC338DB947347107FBCF8EF6B'`
+3. `mkdir -p ${ARMSDK} && tar xf ${TOOLCHAIN_PREFIX}.tar.xz -C ${ARMSDK} --strip-components=1`
+4. `$CC test_qemu.c -o test_qemu.out -pthread`
+5. `qemu-arm -L $SYSROOT ./test_qemu.out`
+6. Observe memory usage keeps ramping up and crashes the process once out of memory.
+Additional information:
+Valgrind annotation logs [annot.log](/uploads/f8d05d8f216d5a589e8da0758a345de6/annot.log) generated by a local build on master@0a301624c2f4ced3331ffd5bce85b4274fe132af from
+```bash
+valgrind --xtree-memory=full --xtree-memory-file=xtmemory.kcg bin/debug/native/qemu-arm -L $SYSROOT /mnt/f/test_qemu3.out
+# Send CTRL-C before the process crashes due to oom
+callgrind_annotate --auto=yes --inclusive=yes --sort=curB:100,curBk:100,totB:100,totBk:100,totFdB:100,totFdBk:100  xtmemory.kcg > annot.log
+```
+
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/867 b/gitlab/issues_text/target_missing/host_missing/accel_missing/867
new file mode 100644
index 00000000..c74eb0e4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/867
@@ -0,0 +1,13 @@
+qemu-system-x86_64: warning: usb-redir connection broken during migration
+Description of problem:
+Create Snapshot, Restore snapshot, crash
+Steps to reproduce:
+1. Create Snapshot
+2. Restore Snapshot
+3. Crash
+Additional information:
+![image](/uploads/1a368b2b872b82321b9f4fefc8092467/image.png)
+
+No redirecting:
+
+![image](/uploads/9eb796b36d12fec2081e700ba0e7528c/image.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/868 b/gitlab/issues_text/target_missing/host_missing/accel_missing/868
new file mode 100644
index 00000000..0c43bfff
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/868
@@ -0,0 +1,15 @@
+Graphic session freezes and logs out
+Description of problem:
+Graphic session freezes and logs out resetting user session. I've tried with both X and Wayland.
+The session does not last longer than 10-15 mins while working with:
+    VSCode
+    Firefox browser (no more than 5 open tabs - nothing heavy)
+
+If only using console, the problem does not seem occur, or maybe it takes longer, but haven't been able to reproduce it.
+Steps to reproduce:
+No steps. Just using common apps (vscode editor and ffox browser) for 10-15 mins causes the problem. Standard sites: gitlab, stacoverflow.
+Additional information:
+I used this configuration for +1 year without issues. I guess some updates to either Ubuntu or Lubuntu causes the problem.
+I deleted the guest VM and started with a fresh new Lubuntu 20.04 LTS AS IS no exttra software and the problem persists.
+
+Happy to provide any info you may require. I've looked around in the logs but couldnn't find anything useful.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/87 b/gitlab/issues_text/target_missing/host_missing/accel_missing/87
new file mode 100644
index 00000000..3953d610
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/87
@@ -0,0 +1 @@
+doesn't clear screen on boot
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/872 b/gitlab/issues_text/target_missing/host_missing/accel_missing/872
new file mode 100644
index 00000000..c0f32bfc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/872
@@ -0,0 +1 @@
+linux-user getsockopt(fd, SOL_SOCKET, SO_ERROR) returns host errno to target
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/873 b/gitlab/issues_text/target_missing/host_missing/accel_missing/873
new file mode 100644
index 00000000..04913bbd
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/873
@@ -0,0 +1 @@
+Meson warns about a broken Python install on Debian/Ubuntu
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/874 b/gitlab/issues_text/target_missing/host_missing/accel_missing/874
new file mode 100644
index 00000000..f1ad2f77
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/874
@@ -0,0 +1 @@
+New Python QMP library races on NetBSD
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/875 b/gitlab/issues_text/target_missing/host_missing/accel_missing/875
new file mode 100644
index 00000000..6c866e0f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/875
@@ -0,0 +1 @@
+Failure to build using GCC on macOS
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/878 b/gitlab/issues_text/target_missing/host_missing/accel_missing/878
new file mode 100644
index 00000000..86765927
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/878
@@ -0,0 +1,42 @@
+Can't bind PCI device behind a PCI bridge (No such device)
+Description of problem:
+Qemu fails to assign the device with :
+```
+qemu-system-x86_64: -device vfio-pci,host=3b:00.0: vfio 0000:3b:00.0: error getting device from group 72: No such device
+Verify all devices in group 72 are bound to vfio-<bus> or pci-stub and not already in use
+```
+
+Looking at strace, we can see that the device is behind a PCI bridge:
+```
+lstat("/sys", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
+lstat("/sys/bus", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
+lstat("/sys/bus/pci", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
+lstat("/sys/bus/pci/devices", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
+lstat("/sys/bus/pci/devices/0000:3b:00.0", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
+readlink("/sys/bus/pci/devices/0000:3b:00.0", "../../../devices/pci0000:3a/0000"..., 4095) = 53
+lstat("/sys/devices", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
+lstat("/sys/devices/pci0000:3a", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
+lstat("/sys/devices/pci0000:3a/0000:3a:02.0", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
+lstat("/sys/devices/pci0000:3a/0000:3a:02.0/0000:3b:00.0", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
+lstat("/sys/devices/pci0000:3a/0000:3a:02.0/0000:3b:00.0/subsystem", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
+readlink("/sys/devices/pci0000:3a/0000:3a:02.0/0000:3b:00.0/subsystem", "../../../../bus/pci", 4095) = 19
+lstat("/sys/bus", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
+lstat("/sys/bus/pci", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
+ioctl(14, VFIO_GROUP_GET_DEVICE_FD, 0x56267b3b1320) = -1 ENODEV (No such device)
+```
+
+The issue is that the PCI bridge `0000:3a:02.0`, is used by "pcieport" kernel driver and not "vfio-pci".
+After manually unbinding the PCI bridge from it's driver and binding it to vfio-pci qemu successfully attaches it to the VM.
+
+I saw online that qemu is suposed to automaticly unbind devices from the host, make them available to the VM and restore them to their previous state once the VM is shutdown. 
+This is not happening here.
+Steps to reproduce:
+1. Have a PCI device behind a PCI bridge
+2. Launch a VM with the PCI device attached
+3. Observe similar error messages
+Additional information:
+After reading [kernel vfio doc](https://www.kernel.org/doc/html/latest/driver-api/vfio.html#vfio-usage-example), I can see that `ls -l /sys/bus/pci/devices/0000:3b:00.0/iommu_group/devices` was supposed to list the PCI bridge, but it is not the case for me.
+
+I could only notice the presence of the bridge by looking in the `/sys/bus/pci/devices/0000:3b:00.0` symlink.
+
+Maybe qemu misses it because of that ?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/879 b/gitlab/issues_text/target_missing/host_missing/accel_missing/879
new file mode 100644
index 00000000..2c828bf8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/879
@@ -0,0 +1,3 @@
+Microphone support for Macbooks
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/88 b/gitlab/issues_text/target_missing/host_missing/accel_missing/88
new file mode 100644
index 00000000..9d4980c1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/88
@@ -0,0 +1 @@
+VNC server does not work with Mac Screen Sharing
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/880 b/gitlab/issues_text/target_missing/host_missing/accel_missing/880
new file mode 100644
index 00000000..f3e53d6b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/880
@@ -0,0 +1 @@
+Documentation needs some updates
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/881 b/gitlab/issues_text/target_missing/host_missing/accel_missing/881
new file mode 100644
index 00000000..f3ef4545
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/881
@@ -0,0 +1,20 @@
+qemu-ga fs-freeze causes VM to
+Description of problem:
+I have fresh install of Debian 11 and installed MariaDB 10.7 from MariaDB's Repo. Guest is fully up to date.
+When Proxmox goes to do a backup it will call fs-freeze to the VM via the agent which then causes the backup process to hang and the VM will lockup or causes kernel message such as `**task qemu-ga:370 blocked for more than 120 seconds**`. The VM from what I can tell no longer is able to write to disk, and the only fix is to force reset the VM.
+
+The issue doesn't happen when the VM has first started or the agent has been restart from what I can tell, but if you leave it and wait for the nightly backup to run of the VM, it will then cause this issue to happen.
+
+There are other reports of this happening on the [proxmox forums](https://forum.proxmox.com/threads/snapshot-backup-not-working-guest-agent-fs-freeze-gets-timeout.99887/) More details on this topic. Other reports with the issue with MariaDB 10.6.
+
+My other Debian 11 VMs which were also setup recently, do not experience this problem, only difference is this VM is running the MariaDB. I have Gitlab, Docker, Mailcow, PowerDNS, OPNsense (each of these separate VM) in the other VMs and they do not experience this issue. All these VMs are running Debian 11.
+
+Agent Info
+```
+qemu-guest-agent/stable,stable-security,now 1:5.2+dfsg-11+deb11u1 amd64
+```
+Steps to reproduce:
+1. Install Proxmox (although I would assume any QEMU 6.1.1)
+2. Create a Debian 11 guest with MariaDB 10.7 from MariaDB repo
+3. Wait good few hours
+4. Issue a backup or fs-freeze
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/882 b/gitlab/issues_text/target_missing/host_missing/accel_missing/882
new file mode 100644
index 00000000..0850871d
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/882
@@ -0,0 +1,473 @@
+Build fails: error: ‘struct statx’ has no member named ‘stx_mnt_id’
+Description of problem:
+When trying to build qemu (both version 6.2.0 and upstream git), the build fails with the mentioned error message
+Steps to reproduce:
+1. Configure qemu with the following arguments (target list removed for the sake of brevity):
+```
+./configure \
+    --prefix=/usr \
+    --sysconfdir=/etc \
+    --localstatedir=/var \
+    --libexecdir=/usr/lib/qemu \
+    --smbd=/usr/bin/smbd \
+    --enable-modules \
+    --enable-sdl \
+    --enable-slirp=system \
+    --disable-werror 
+```
+2. Try to build qemu
+3. Build fails on target tools/virtiofsd/virtiofsd.p/passthrough_ll.c.o
+Additional information:
+Meson output:
+```
++ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --enable-slirp=system --disable-werror --target-list=x86_64-softmmu,x86_64-linux-user,aarch64-softmmu,aarch64-linux-user,ppc64-softmmu,ppc64-linux-user,riscv32-softmmu,riscv32-linux-user,riscv64-softmmu,riscv64-linux-user,arm-softmmu,arm-linux-user,avr-softmmu
+Using './build' as the directory for build output
+The Meson build system
+Version: 0.61.2
+Source dir: /home/mae/dev/qemubuild/qemu
+Build dir: /home/mae/dev/qemubuild/qemu/build
+Build type: native build
+Project name: qemu
+Project version: 6.2.50
+C compiler for the host machine: gcc -m64 -mcx16 (gcc 11.2.0 "gcc (GCC) 11.2.0")
+C linker for the host machine: gcc -m64 -mcx16 ld.bfd 2.37
+Host machine cpu family: x86_64
+Host machine cpu: x86_64
+Program sh found: YES (/usr/bin/sh)
+Program python3 found: YES (/usr/bin/python)
+Program bzip2 found: YES (/usr/bin/bzip2)
+C++ compiler for the host machine: g++ -m64 -mcx16 (gcc 11.2.0 "g++ (GCC) 11.2.0")
+C++ linker for the host machine: g++ -m64 -mcx16 ld.bfd 2.37
+Program cgcc found: NO
+Library m found: YES
+Run-time dependency threads found: YES
+Library util found: YES
+Run-time dependency appleframeworks found: NO (tried framework)
+Found pkg-config: /usr/bin/pkg-config (1.8.0)
+Run-time dependency pixman-1 found: YES 0.40.0
+Run-time dependency zlib found: YES 1.2.11
+Has header "libaio.h" : YES 
+Library aio found: YES
+Run-time dependency liburing found: YES 2.0
+Run-time dependency libnfs found: YES 5.0.1
+Run-time dependency appleframeworks found: NO (tried framework)
+Run-time dependency libseccomp found: YES 2.5.3
+Has header "cap-ng.h" : YES 
+Library cap-ng found: YES
+Run-time dependency xkbcommon found: YES 1.4.0
+Has header "libvdeplug.h" : YES 
+Library vdeplug found: YES
+Run-time dependency libpulse found: YES 15.0
+Run-time dependency alsa found: YES 1.2.6.1
+Run-time dependency jack found: NO (tried pkgconfig)
+Run-time dependency spice-protocol found: YES 0.14.4
+Run-time dependency spice-server found: YES 0.15.0
+Library rt found: YES
+Run-time dependency libiscsi found: YES 1.19.0
+Run-time dependency libzstd found: YES 1.5.2
+Run-time dependency virglrenderer found: YES 0.9.1
+Run-time dependency libcurl found: YES 7.81.0
+Run-time dependency libudev found: YES 250
+Library mpathpersist found: NO
+Run-time dependency ncursesw found: YES 6.3.20211021
+Has header "brlapi.h" : NO 
+Run-time dependency sdl2 found: YES 2.0.18
+Run-time dependency sdl2_image found: YES 2.0.5
+Library rados found: NO
+Has header "rbd/librbd.h" : NO 
+Run-time dependency glusterfs-api found: NO (tried pkgconfig)
+Run-time dependency libssh found: YES 0.9.6
+Has header "bzlib.h" : YES 
+Library bz2 found: YES
+Has header "lzfse.h" : NO 
+Has header "sys/soundcard.h" : YES 
+Run-time dependency gbm found: YES 21.3.1
+Run-time dependency gnutls found: YES 3.7.3
+Run-time dependency gtk+-3.0 found: YES 3.24.31
+Run-time dependency gtk+-x11-3.0 found: YES 3.24.31
+Run-time dependency vte-2.91 found: YES 0.66.2
+Run-time dependency x11 found: YES 1.7.3.1
+Run-time dependency libpng found: YES 1.6.37
+Run-time dependency libjpeg found: YES 2.1.2
+Has header "sasl/sasl.h" : YES 
+Library sasl2 found: YES
+Has header "security/pam_appl.h" : YES 
+Library pam found: YES
+Has header "snappy-c.h" : YES 
+Library snappy found: YES
+Has header "lzo/lzo1x.h" : YES 
+Library lzo2 found: YES
+Run-time dependency libcacard found: YES 2.7.0
+Run-time dependency u2f-emu found: NO (tried pkgconfig)
+Run-time dependency libusbredirparser-0.5 found: YES 0.12.0
+Run-time dependency libusb-1.0 found: YES 1.0.25
+Run-time dependency libpmem found: NO (tried pkgconfig)
+Run-time dependency libdaxctl found: YES 72.1+
+Run-time dependency libtasn1 found: YES 4.18.0
+Run-time dependency libkeyutils found: YES 1.6.3
+Checking for function "gettid" : YES 
+Run-time dependency libselinux found: NO (tried pkgconfig)
+Run-time dependency fuse3 found: YES 3.10.5
+Run-time dependency libbpf found: YES 0.7.0
+Has header "sys/epoll.h" : YES 
+Has header "linux/magic.h" : YES 
+Has header "valgrind/valgrind.h" : YES 
+Has header "linux/btrfs.h" : YES 
+Has header "libdrm/drm.h" : YES 
+Has header "pty.h" : YES 
+Has header "sys/disk.h" : NO 
+Has header "sys/ioccom.h" : NO 
+Has header "sys/kcov.h" : NO 
+Checking for function "accept4" : YES 
+Checking for function "clock_adjtime" : YES 
+Checking for function "dup3" : YES 
+Checking for function "fallocate" : YES 
+Checking for function "posix_fallocate" : YES 
+Checking for function "posix_memalign" : YES 
+Checking for function "ppoll" : YES 
+Checking for function "preadv" : YES 
+Checking for function "sem_timedwait" with dependency threads: YES 
+Checking for function "sendfile" : YES 
+Checking for function "setns" : YES 
+Checking for function "unshare" : YES 
+Checking for function "syncfs" : YES 
+Checking for function "sync_file_range" : YES 
+Checking for function "timerfd_create" : YES 
+Checking for function "copy_file_range" : YES 
+Checking for function "openpty" with dependency -lutil: YES 
+Checking for function "strchrnul" : YES 
+Checking for function "system" : YES 
+Header <byteswap.h> has symbol "bswap_32" : YES 
+Header <sys/epoll.h> has symbol "epoll_create1" : YES 
+Header <unistd.h> has symbol "environ" : YES 
+Header <linux/falloc.h> has symbol "FALLOC_FL_PUNCH_HOLE" : YES 
+Header <linux/falloc.h> has symbol "FALLOC_FL_KEEP_SIZE" : YES 
+Header <linux/falloc.h> has symbol "FALLOC_FL_ZERO_RANGE" : YES 
+Has header "linux/fiemap.h" : YES 
+Header <linux/fs.h> has symbol "FS_IOC_FIEMAP" : YES 
+Checking for function "getrandom" : YES 
+Header <sys/random.h> has symbol "GRND_NONBLOCK" : YES 
+Header <sys/inotify.h> has symbol "inotify_init" : YES 
+Header <sys/inotify.h> has symbol "inotify_init1" : YES 
+Header <machine/bswap.h> has symbol "bswap32" : NO 
+Header <sys/prctl.h> has symbol "PR_SET_TIMERSLACK" : YES 
+Header <linux/rtnetlink.h> has symbol "IFLA_PROTO_DOWN" : YES 
+Header <sys/sysmacros.h> has symbol "makedev" : YES 
+Header <getopt.h> has symbol "optreset" : NO 
+Header <netinet/in.h> has symbol "IPPROTO_MPTCP" : YES 
+Checking whether type "struct sigevent" has member "sigev_notify_thread_id" : NO 
+Checking whether type "struct stat" has member "st_atim" : YES 
+Checking for type "struct iovec" : YES 
+Checking for type "struct utmpx" : YES 
+Checking for type "struct mmsghdr" : YES 
+Program scripts/minikconf.py found: YES (/usr/bin/python /home/mae/dev/qemubuild/qemu/scripts/minikconf.py)
+Configuring x86_64-softmmu-config-target.h using configuration
+Configuring x86_64-softmmu-config-devices.mak with command
+Reading depfile: /home/mae/dev/qemubuild/qemu/build/meson-private/x86_64-softmmu-config-devices.mak.d
+Configuring x86_64-softmmu-config-devices.h using configuration
+Configuring x86_64-linux-user-config-target.h using configuration
+Configuring aarch64-softmmu-config-target.h using configuration
+Configuring aarch64-softmmu-config-devices.mak with command
+Reading depfile: /home/mae/dev/qemubuild/qemu/build/meson-private/aarch64-softmmu-config-devices.mak.d
+Configuring aarch64-softmmu-config-devices.h using configuration
+Configuring aarch64-linux-user-config-target.h using configuration
+Configuring ppc64-softmmu-config-target.h using configuration
+Configuring ppc64-softmmu-config-devices.mak with command
+Reading depfile: /home/mae/dev/qemubuild/qemu/build/meson-private/ppc64-softmmu-config-devices.mak.d
+Configuring ppc64-softmmu-config-devices.h using configuration
+Configuring ppc64-linux-user-config-target.h using configuration
+Configuring riscv32-softmmu-config-target.h using configuration
+Configuring riscv32-softmmu-config-devices.mak with command
+Reading depfile: /home/mae/dev/qemubuild/qemu/build/meson-private/riscv32-softmmu-config-devices.mak.d
+Configuring riscv32-softmmu-config-devices.h using configuration
+Configuring riscv32-linux-user-config-target.h using configuration
+Configuring riscv64-softmmu-config-target.h using configuration
+Configuring riscv64-softmmu-config-devices.mak with command
+Reading depfile: /home/mae/dev/qemubuild/qemu/build/meson-private/riscv64-softmmu-config-devices.mak.d
+Configuring riscv64-softmmu-config-devices.h using configuration
+Configuring riscv64-linux-user-config-target.h using configuration
+Configuring arm-softmmu-config-target.h using configuration
+Configuring arm-softmmu-config-devices.mak with command
+Reading depfile: /home/mae/dev/qemubuild/qemu/build/meson-private/arm-softmmu-config-devices.mak.d
+Configuring arm-softmmu-config-devices.h using configuration
+Configuring arm-linux-user-config-target.h using configuration
+Configuring avr-softmmu-config-target.h using configuration
+Configuring avr-softmmu-config-devices.mak with command
+Reading depfile: /home/mae/dev/qemubuild/qemu/build/meson-private/avr-softmmu-config-devices.mak.d
+Configuring avr-softmmu-config-devices.h using configuration
+Program scripts/make-config-poison.sh found: YES (/home/mae/dev/qemubuild/qemu/scripts/make-config-poison.sh)
+Run-time dependency capstone found: NO (tried pkgconfig)
+Configuring capstone-defs.h using configuration
+Run-time dependency slirp found: YES 4.6.1
+Library fdt found: YES
+Configuring config-host.h using configuration
+Program scripts/hxtool found: YES (/home/mae/dev/qemubuild/qemu/scripts/hxtool)
+Program scripts/shaderinclude.pl found: YES (/usr/bin/env perl /home/mae/dev/qemubuild/qemu/scripts/shaderinclude.pl)
+Program scripts/qapi-gen.py found: YES (/usr/bin/python /home/mae/dev/qemubuild/qemu/scripts/qapi-gen.py)
+Program scripts/qemu-version.sh found: YES (/home/mae/dev/qemubuild/qemu/scripts/qemu-version.sh)
+
+Executing subproject libvhost-user 
+
+libvhost-user| Project name: libvhost-user
+libvhost-user| Project version: undefined
+libvhost-user| C compiler for the host machine: gcc -m64 -mcx16 (gcc 11.2.0 "gcc (GCC) 11.2.0")
+libvhost-user| C linker for the host machine: gcc -m64 -mcx16 ld.bfd 2.37
+libvhost-user| Dependency threads found: YES unknown (cached)
+libvhost-user| Dependency glib-2.0 found: YES 2.71.2 (overridden)
+libvhost-user| Build targets in project: 10
+libvhost-user| Subproject libvhost-user finished.
+
+Program scripts/decodetree.py found: YES (/usr/bin/python /home/mae/dev/qemubuild/qemu/scripts/decodetree.py)
+Program ../scripts/modules/module_block.py found: YES (/usr/bin/python /home/mae/dev/qemubuild/qemu/block/../scripts/modules/module_block.py)
+Program ../scripts/block-coroutine-wrapper.py found: YES (/usr/bin/python /home/mae/dev/qemubuild/qemu/block/../scripts/block-coroutine-wrapper.py)
+Program scripts/modinfo-collect.py found: YES (/home/mae/dev/qemubuild/qemu/scripts/modinfo-collect.py)
+Program scripts/modinfo-generate.py found: YES (/home/mae/dev/qemubuild/qemu/scripts/modinfo-generate.py)
+Program nm found: YES
+Program scripts/undefsym.py found: YES (/usr/bin/python /home/mae/dev/qemubuild/qemu/scripts/undefsym.py)
+Program scripts/feature_to_c.sh found: YES (/bin/sh /home/mae/dev/qemubuild/qemu/scripts/feature_to_c.sh)
+Configuring 50-qemu-gpu.json using configuration
+Configuring 50-qemu-virtiofsd.json using configuration
+Configuring 50-edk2-i386-secure.json using configuration
+Configuring 50-edk2-x86_64-secure.json using configuration
+Configuring 60-edk2-aarch64.json using configuration
+Configuring 60-edk2-arm.json using configuration
+Configuring 60-edk2-i386.json using configuration
+Configuring 60-edk2-x86_64.json using configuration
+Program qemu-keymap found: NO
+Program cp found: YES (/usr/bin/cp)
+Program sphinx-build-3 sphinx-build found: NO
+Program python3 found: YES (/usr/bin/python)
+Program diff found: YES (/usr/bin/diff)
+Program dbus-daemon found: YES (/usr/bin/dbus-daemon)
+Program initrd-stress.sh found: YES (/home/mae/dev/qemubuild/qemu/tests/migration/initrd-stress.sh)
+Program xgettext found: YES (/usr/bin/xgettext)
+Build targets in project: 744
+
+qemu 6.2.50
+
+  Directories
+    Install prefix               : /usr
+    BIOS directory               : share/qemu
+    firmware path                : /usr/share/qemu-firmware
+    binary directory             : bin
+    library directory            : lib
+    module directory             : lib/qemu
+    libexec directory            : lib/qemu
+    include directory            : include
+    config directory             : /etc
+    local state directory        : /var
+    Manual directory             : share/man
+    Doc directory                : /usr/share/doc
+    Build directory              : /home/mae/dev/qemubuild/qemu/build
+    Source path                  : /home/mae/dev/qemubuild/qemu
+    GIT submodules               : ui/keycodemapdb tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone
+
+  Host binaries
+    git                          : git
+    make                         : make
+    python                       : /usr/bin/python (version: 3.10)
+    sphinx-build                 : NO
+    gdb                          : /usr/bin/gdb
+    genisoimage                  : 
+    smbd                         : "/usr/bin/smbd"
+
+  Configurable features
+    Documentation                : NO
+    system-mode emulation        : YES
+    user-mode emulation          : YES
+    block layer                  : YES
+    Install blobs                : YES
+    module support               : YES
+    alternative module path      : NO
+    fuzzing support              : NO
+    Audio drivers                : pa oss
+    Trace backends               : log
+    D-Bus display                : YES
+    QOM debugging                : YES
+    vhost-kernel support         : YES
+    vhost-net support            : YES
+    vhost-crypto support         : YES
+    vhost-scsi support           : YES
+    vhost-vsock support          : YES
+    vhost-user support           : YES
+    vhost-user-blk server support: YES
+    vhost-user-fs support        : YES
+    vhost-vdpa support           : YES
+    build guest agent            : YES
+
+  Compilation
+    host CPU                     : x86_64
+    host endianness              : little
+    C compiler                   : gcc -m64 -mcx16
+    Host C compiler              : gcc -m64 -mcx16
+    C++ compiler                 : g++ -m64 -mcx16
+    CFLAGS                       : -march=native -mtune=native -O3 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -O2 -g
+    CXXFLAGS                     : -march=native -mtune=native -O3 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -O2 -g
+    LDFLAGS                      : -march=native -mtune=native -O3 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
+    QEMU_CFLAGS                  : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=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-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
+    QEMU_LDFLAGS                 : -Wl,--warn-common -Wl,-z,relro -Wl,-z,now  -fstack-protector-strong
+    profiler                     : NO
+    link-time optimization (LTO) : NO
+    PIE                          : YES
+    static build                 : NO
+    malloc trim support          : YES
+    membarrier                   : NO
+    debug stack usage            : NO
+    mutex debugging              : NO
+    memory allocator             : system
+    avx2 optimization            : YES
+    avx512f optimization         : NO
+    gprof enabled                : NO
+    gcov                         : NO
+    thread sanitizer             : NO
+    CFI support                  : NO
+    strip binaries               : NO
+    sparse                       : NO
+    mingw32 support              : NO
+    x86_64 tests                 : gcc
+
+  Targets and accelerators
+    KVM support                  : YES
+    HAX support                  : NO
+    HVF support                  : NO
+    WHPX support                 : NO
+    NVMM support                 : NO
+    Xen support                  : NO
+    TCG support                  : YES
+    TCG backend                  : native (x86_64)
+    TCG plugins                  : YES
+    TCG debug enabled            : NO
+    target list                  : x86_64-softmmu x86_64-linux-user aarch64-softmmu aarch64-linux-user ppc64-softmmu ppc64-linux-user riscv32-softmmu riscv32-linux-user riscv64-softmmu riscv64-linux-user arm-softmmu arm-linux-user avr-softmmu
+    default devices              : YES
+    out of process emulation     : YES
+
+  Block layer support
+    coroutine backend            : ucontext
+    coroutine pool               : YES
+    Block whitelist (rw)         : 
+    Block whitelist (ro)         : 
+    Use block whitelist in tools : NO
+    VirtFS support               : YES
+    build virtiofs daemon        : YES
+    Live block migration         : YES
+    replication support          : YES
+    bochs support                : YES
+    cloop support                : YES
+    dmg support                  : YES
+    qcow v1 support              : YES
+    vdi support                  : YES
+    vvfat support                : YES
+    qed support                  : YES
+    parallels support            : YES
+    FUSE exports                 : YES 3.10.5
+
+  Crypto
+    TLS priority                 : "NORMAL"
+    GNUTLS support               : YES 3.7.3
+      GNUTLS crypto              : YES
+    libgcrypt                    : NO
+    nettle                       : NO
+    crypto afalg                 : NO
+    rng-none                     : NO
+    Linux keyring                : YES
+
+  Dependencies
+    SDL support                  : YES
+    SDL image support            : YES 2.0.5
+    GTK support                  : YES
+    pixman                       : YES 0.40.0
+    VTE support                  : YES 0.66.2
+    slirp support                : YES 4.6.1
+    libtasn1                     : YES 4.18.0
+    PAM                          : YES
+    iconv support                : YES
+    curses support               : YES
+    virgl support                : YES 0.9.1
+    curl support                 : YES 7.81.0
+    Multipath support            : NO
+    VNC support                  : YES
+    VNC SASL support             : YES
+    VNC JPEG support             : YES 2.1.2
+    VNC PNG support              : YES 1.6.37
+    OSS support                  : YES
+    ALSA support                 : YES 1.2.6.1
+    PulseAudio support           : YES 15.0
+    JACK support                 : NO
+    brlapi support               : NO
+    vde support                  : YES
+    netmap support               : NO
+    l2tpv3 support               : YES
+    Linux AIO support            : YES
+    Linux io_uring support       : YES 2.0
+    ATTR/XATTR support           : YES
+    RDMA support                 : NO
+    PVRDMA support               : NO
+    fdt support                  : system
+    libcap-ng support            : YES
+    bpf support                  : YES 0.7.0
+    spice protocol support       : YES 0.14.4
+      spice server support       : YES 0.15.0
+    rbd support                  : NO
+    smartcard support            : YES 2.7.0
+    U2F support                  : NO
+    libusb                       : YES 1.0.25
+    usb net redir                : YES 0.12.0
+    OpenGL support               : YES
+    GBM                          : YES 21.3.1
+    libiscsi support             : YES 1.19.0
+    libnfs support               : YES 5.0.1
+    seccomp support              : YES 2.5.3
+    GlusterFS support            : NO
+    TPM support                  : YES
+    libssh support               : YES 0.9.6
+    lzo support                  : YES
+    snappy support               : YES
+    bzip2 support                : YES
+    lzfse support                : NO
+    zstd support                 : YES 1.5.2
+    NUMA host support            : YES
+    capstone                     : internal
+    libpmem support              : NO
+    libdaxctl support            : YES 72.1+
+    libudev                      : YES 250
+    FUSE lseek                   : YES
+    selinux                      : NO
+
+  Subprojects
+    libvhost-user                : YES
+
+  User defined options
+    Native files                 : config-meson.cross
+    bindir                       : /usr/bin
+    datadir                      : /usr/share
+    debug                        : true
+    includedir                   : /usr/include
+    libdir                       : /usr/lib
+    libexecdir                   : /usr/lib/qemu
+    localedir                    : /usr/share/locale
+    localstatedir                : /var
+    mandir                       : /usr/share/man
+    optimization                 : 2
+    prefix                       : /usr
+    sysconfdir                   : /etc
+    werror                       : false
+    b_coverage                   : false
+    b_lto                        : false
+    b_pie                        : true
+    audio_drv_list               : default
+    capstone                     : auto
+    cfi                          : false
+    default_devices              : true
+    docdir                       : /usr/share/doc
+    fdt                          : auto
+    qemu_firmwarepath            : /usr/share/qemu-firmware
+    qemu_suffix                  : qemu
+    sdl                          : enabled
+    slirp                        : system
+    sphinx_build                 : 
+    tcg                          : enabled
+    trace_file                   : trace
+    xen                          : disabled
+
+Found ninja-1.10.2 at /usr/bin/ninja
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/883 b/gitlab/issues_text/target_missing/host_missing/accel_missing/883
new file mode 100644
index 00000000..19a13838
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/883
@@ -0,0 +1,27 @@
+DRBG: could not allocate CTR cipher TFM handle: ctr(aes)
+Description of problem:
+
+Steps to reproduce:
+1. Install Debian in Qemu using the command:
+```
+REM example to create disk
+REM qemu-img create -f qcow2 debian-qcow2.img 32G 
+
+qemu-system-x86_64.exe -hda debian-qcow2.img -cdrom debian-11.2.0-amd64-netinst.iso -boot d -m 8G -accel hax
+```
+
+2. Fight with installer and partitions to finally get this:
+![lfs-ftw-128_-_Screenshot_2022-02-22_202452](/uploads/a823feb358c456bd4d76b181ca689bec/lfs-ftw-128_-_Screenshot_2022-02-22_202452.png)
+
+3. System boots and shows a bunch of FAILED messages with crypto error:
+![lfs-ftw-144_-_Screenshot_2022-02-22_223848](/uploads/bf8922239d9bbf0ee26c9ffafdf81f2e/lfs-ftw-144_-_Screenshot_2022-02-22_223848.png)
+
+![lfs-ftw-139_-_Screenshot_2022-02-22_213744](/uploads/9ad52214610fa3a54ed3263e122ae395/lfs-ftw-139_-_Screenshot_2022-02-22_213744.png)
+
+I am new at using Qemu so may need pointers to provide more information.
+
+The system seems to be working to some degree.
+
+Color me impressed!!!
+Additional information:
+Related: #880
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/884 b/gitlab/issues_text/target_missing/host_missing/accel_missing/884
new file mode 100644
index 00000000..087503a4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/884
@@ -0,0 +1,8 @@
+Stuck when using virtio driver to rotate the screen
+Description of problem:
+Configure the virtual machine's graphics card as Virtio, and use `xrandr -o left` to rotate the screen and it will get stuck.
+
+Configure the graphics card as VGA, and use `xrandr -o left` to rotate the screen normally.
+Steps to reproduce:
+1. Configure the virtual machine's graphics card as Virtio
+2. use `xrandr -o left` to rotate the screen
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/885 b/gitlab/issues_text/target_missing/host_missing/accel_missing/885
new file mode 100644
index 00000000..630e9107
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/885
@@ -0,0 +1 @@
+linux-user: `getsockopt` on `SO_RCVTIMEO_NEW`/`SO_SNDTIMEO_NEW` writes unexpected `int`
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/889 b/gitlab/issues_text/target_missing/host_missing/accel_missing/889
new file mode 100644
index 00000000..3ab04cbf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/889
@@ -0,0 +1 @@
+cc1: error: ‘-fcf-protection’ is not compatible with this target
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/89 b/gitlab/issues_text/target_missing/host_missing/accel_missing/89
new file mode 100644
index 00000000..c8fbd900
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/89
@@ -0,0 +1 @@
+Documentation for mtdblock, option-rom, and pflash is non-existent
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/891 b/gitlab/issues_text/target_missing/host_missing/accel_missing/891
new file mode 100644
index 00000000..4b278864
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/891
@@ -0,0 +1 @@
+how to know  jpeg-wan-compression  is in force
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/892 b/gitlab/issues_text/target_missing/host_missing/accel_missing/892
new file mode 100644
index 00000000..921b114f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/892
@@ -0,0 +1,5 @@
+Ensure qemu-storage-daemon builds, works and is included in win10 setup
+Additional information:
+- Job run on 20220315 "msys2-64bit build target" seems to have created binary: https://gitlab.com/qemu-project/qemu/-/jobs/2201739711
+  - ```2456 [1324/1586] Linking target storage-daemon/qemu-storage-daemon.exe```
+  - I hope it will be included in final distributed setup files
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/894 b/gitlab/issues_text/target_missing/host_missing/accel_missing/894
new file mode 100644
index 00000000..c501d480
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/894
@@ -0,0 +1,31 @@
+target/riscv64 qemu-iotests 040 failed
+Description of problem:
+I cross-compiled a riscv64 QEMU flavor based on the most updated code, then make check. Some qemu-iotests failed, 040 041 127 256 267. I mainly focused on test 040 and tried to find out what happened.
+Steps to reproduce:
+1. change directory to QEMU source tree root
+2. ./configure --prefix=~/temp --target-list=riscv64-softmmu
+3. make
+4. cd build/tests/qemu-iotests/
+5. ./check -qcow2 040
+
+Then a lot of error messages(please see attachment). The following log might hint the root cause I thought:
+```
++       Command: /home/qemu/qemu/build/tests/qemu-iotests/../../qemu-system-riscv64 -display none -vga none -chardev socket,id=mon,path=/tmp/tmpwhnx3jq0/qemu-28363-monitor.sock -mon chardev=mon,mode=control -qtest unix:path=/tmp/tmpwhnx3jq0/qemu-28363-qtest.sock -accel qtest -nodefaults -display none -accel qtest -drive if=none,id=drive0,file=/home/qemu/qemu/build/tests/qemu-iotests/scratch/test.img,format=qcow2,cache=writeback,aio=threads,node-name=top,backing.node-name=mid,backing.backing.node-name=base -device virtio-scsi -device scsi-hd,id=scsi0,drive=drive0
++       Output: [I 1646574338.669217] OPENED
++qemu-system-riscv64: -device virtio-scsi: No 'PCI' bus found for device 'virtio-scsi-pci'
+```
+The command had no '-machine' argument. For riscv64 target, 'spike' will be the default machine. Maybe 'spike' have no PCI bus? Then I tried to change it to 'virt' machine but failed, nothing new happen.
+```
+QEMU_DEFAULT_MACHINE=virt ./check -qcow2 040
+```
+```
+QEMU_OPTIONS="-machine virt" ./check -qcow2 040
+```
+Last, I modified [testenv.py](https://gitlab.com/qemu-project/qemu/-/blob/master/tests/qemu-iotests/testenv.py#L239) and added one line in machine-map, all tests passed!
+```
+('riscv64', 'virt'),
+```
+
+Is there any way to easy the issue or do I miss something? Thank you!
+Additional information:
+[zlog.riscv.xz](/uploads/cbbad7c5c256d2b49d220aa6425e2b17/zlog.riscv.xz)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/895 b/gitlab/issues_text/target_missing/host_missing/accel_missing/895
new file mode 100644
index 00000000..27f449a4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/895
@@ -0,0 +1,38 @@
+can't find table device while call qemu_input_is_absolute function
+Description of problem:
+vnc service can‘t run with mouse absolute mode
+Steps to reproduce:
+1.create a virtual machine with vnc service via virt-manager.
+
+2.delete mouse and table device  if exists.
+
+3.add table devices first,next add mouse device.
+
+4.gdb attach corresponding qemu thread, run command 
+print "%d",qemu_input_is_absolute()
+display function return false ,so I can't use mouse with absolute mode.
+Additional information:
+code in  qemu_input_is_absolute() is
+```
+bool qemu_input_is_absolute(void)
+{
+    QemuInputHandlerState *s;
+
+    s = qemu_input_find_handler(INPUT_EVENT_MASK_REL | INPUT_EVENT_MASK_ABS,
+                                NULL);
+    return (s != NULL) && (s->handler->mask & INPUT_EVENT_MASK_ABS);
+}
+```
+qemu_input_find_handler function find a handler INPUT_EVENT_MASK_REL or INPUT_EVENT_MASK_ABS,but just compare with INPUT_EVENT_MASK_ABS,
+I think it should be 
+```
+bool qemu_input_is_absolute(void)
+{
+    QemuInputHandlerState *s;
+
+    s = qemu_input_find_handler(INPUT_EVENT_MASK_ABS,
+                                NULL);
+    return (s != NULL) && (s->handler->mask & INPUT_EVENT_MASK_ABS);
+}
+```
+thanks for your help.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/90 b/gitlab/issues_text/target_missing/host_missing/accel_missing/90
new file mode 100644
index 00000000..73cf9a18
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/90
@@ -0,0 +1 @@
+vga/std lacks few wide screen modes.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/900 b/gitlab/issues_text/target_missing/host_missing/accel_missing/900
new file mode 100644
index 00000000..54801f63
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/900
@@ -0,0 +1 @@
+how to install gemu guest agent without configure script ?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/901 b/gitlab/issues_text/target_missing/host_missing/accel_missing/901
new file mode 100644
index 00000000..9887c8a0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/901
@@ -0,0 +1,10 @@
+Bad screen behavior with adaptive sync
+Description of problem:
+KDE Wayland has freesync automatically enabled for full screen applications[[1]](https://wiki.archlinux.org/title/Variable_refresh_rate#Wayland_configuration). When using a VM in full screen mode, the screen starts having a strange behavior, like "blinking". I've tried windows 10, Linux Mint, MX Linux and Ubuntu 21.10.
+The problem disappears if using Xorg or disabling freesync trough KDE settings.
+Steps to reproduce:
+1. On KDE Wayland, check if freesync is activated in settings> screen> adaptive synchronization 
+2. Launch any vm in fuul screen mode
+3. Observe the screen
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/905 b/gitlab/issues_text/target_missing/host_missing/accel_missing/905
new file mode 100644
index 00000000..70e59098
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/905
@@ -0,0 +1 @@
+Null-ptr dereference in blk_bs
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/907 b/gitlab/issues_text/target_missing/host_missing/accel_missing/907
new file mode 100644
index 00000000..c8a2d736
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/907
@@ -0,0 +1,7 @@
+qemu-system-x86_64 -blockdev fails with "CURL: Error opening file" when supplied url of ISO file
+Steps to reproduce:
+1. Run: qemu-system-x86_64 -blockdev driver=https,url=https://archive.fedoraproject.org:443/pub/archive/fedora/linux/releases/28/Server/x86_64/os/images/boot.iso,node-name=libvirt-1-storage,auto-read-only=true
+
+The command returns error: qemu-system-x86_64: -blockdev driver=https,url=https://archive.fedoraproject.org:443/pub/archive/fedora/linux/releases/28/Server/x86_64/os/images/boot.iso,node-name=libvirt-1-storage,auto-read-only=true,discard=unmap: CURL: Error opening file:
+Additional information:
+This bug is not present in qemu 6.1.0, it surfaced with an update to 6.2.0
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/908 b/gitlab/issues_text/target_missing/host_missing/accel_missing/908
new file mode 100644
index 00000000..3b844642
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/908
@@ -0,0 +1 @@
+since when is qemu-guest-agent included in the qemu package ?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/911 b/gitlab/issues_text/target_missing/host_missing/accel_missing/911
new file mode 100644
index 00000000..675a31b1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/911
@@ -0,0 +1,17 @@
+Unable to strace execve calls in mipsel user mode
+Description of problem:
+Used 6.2.0 ZIP and git to build, configured with 
+```
+./configure --target-list=mipsel-linux-user --static --disable-system --enable-linux-user
+```
+
+When trying to strace a mipsel-arch application, I cannot see traces for the `execve` syscall. It looks like the call to `safe_execve` is not returning, so the strace printout is never completed. I'm assuming this has to do with `execve` syscall not returning on success, but older versions appeared to be able to do it. I tried it with QEMU 4.2.1 from the package manager on Ubuntu and I saw the `execve` syscall (see qemu-4.2.1.log).
+Steps to reproduce:
+1. Build mipsel app: ` mipsel-linux-gnu-gcc -o test.mipsel test.c` (Test code is attached as `test.c`)
+2. Run qemu-mipsel: `./build/qemu-mipsel -L /usr/mipsel-linux-gnu/ -strace ../test.mipsel`
+3. Note that even though the app uses both `system` and `popen` to create subprocesses, no `execve` syscall is shown in the strace output.
+Additional information:
+[qemu-6.2.90.log](/uploads/ca03e6f40b3b0ea79a042786a123760a/qemu-6.2.90.log)
+[qemu-6.2.0.log](/uploads/ca15057398377d49b396e9e77a5cb639/qemu-6.2.0.log)
+[qemu-4.2.1.log](/uploads/1087250dd9fc4d8d106d2cbc58c2b14a/qemu-4.2.1.log)
+[test.c](/uploads/9d242a724b10b296cfd7a945ae4d6c4d/test.c)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/912 b/gitlab/issues_text/target_missing/host_missing/accel_missing/912
new file mode 100644
index 00000000..0c155c12
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/912
@@ -0,0 +1 @@
+Cannot access RHEL8_s390x installed OS using SSH from host OS network
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/913 b/gitlab/issues_text/target_missing/host_missing/accel_missing/913
new file mode 100644
index 00000000..5690f280
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/913
@@ -0,0 +1 @@
+QEMU Sharing Host files with Guest
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/917 b/gitlab/issues_text/target_missing/host_missing/accel_missing/917
new file mode 100644
index 00000000..01b8b1c0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/917
@@ -0,0 +1 @@
+FireWire Device Passthrough?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/918 b/gitlab/issues_text/target_missing/host_missing/accel_missing/918
new file mode 100644
index 00000000..cd3ecea5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/918
@@ -0,0 +1 @@
+TILE Cpu Host & Emulator support?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/919 b/gitlab/issues_text/target_missing/host_missing/accel_missing/919
new file mode 100644
index 00000000..4a544798
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/919
@@ -0,0 +1,5 @@
+Slow in Windows
+Description of problem:
+Eg . Win8.1 in QEMU on Windows is very slow and other os also are very slow
+Steps to reproduce:
+Just run a qemu instance
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/92 b/gitlab/issues_text/target_missing/host_missing/accel_missing/92
new file mode 100644
index 00000000..c6188f1a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/92
@@ -0,0 +1 @@
+qemu 1.3.0: usb devices shouldn't have same vendor/product ID and same serial
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/926 b/gitlab/issues_text/target_missing/host_missing/accel_missing/926
new file mode 100644
index 00000000..118354df
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/926
@@ -0,0 +1 @@
+block-backend assertion with Cocoa UI
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/927 b/gitlab/issues_text/target_missing/host_missing/accel_missing/927
new file mode 100644
index 00000000..9d3d21a3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/927
@@ -0,0 +1,32 @@
+linux-user: openat on /proc/self/exe can return a closed file descriptor
+Description of problem:
+`open("/proc/self/exe", ...)` returns a closed file descriptor if qemu-user was executed as an interpreter, passing a file descriptor in the `AT_EXECFD` auxval.
+
+When the `AT_EXECFD` auxval is nonzero the user program is loaded through `load_elf_binary()` (in `linux-user/elfload.c`) which ultimately calls `load_elf_image()` with that same file descriptor, and `load_elf_image()` closes the file descriptor before returning. 
+
+`do_openat` in `linux-user/syscall.c` will return that file descriptor to the user if the opened path satisfies `is_proc_myself(pathname, "exe")`, which is obviously wrong both in that the file descriptor is closed as part of the initialization process of qemu itself, and that the user program would then close that file descriptor and thus the next invocation of `open` would have the same problem.
+Steps to reproduce:
+This program prints `3 3` in a x86_64 docker container on my machine (arm64 macos, which docker desktop handles by running containers in a native linux VM under qemu-user).
+
+```c
+#include <fcntl.h>
+#include <stdio.h>
+
+int main(int argc, char **argv) {
+    int selfexe = open("/proc/self/exe", O_RDONLY | O_CLOEXEC);
+    if (selfexe < 0) {
+        perror("open self");
+        return 1;
+    }
+
+    int devnull = open("/dev/null", O_WRONLY | O_CLOEXEC);
+    if (devnull < 0) {
+        perror("open devnull");
+        return 1;
+    }
+
+    printf("%d %d\n", selfexe, devnull);
+}
+```
+Additional information:
+Thanks to @pm215 for helping me pinpoint the exact issue I was encountering.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/929 b/gitlab/issues_text/target_missing/host_missing/accel_missing/929
new file mode 100644
index 00000000..45ab9e1f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/929
@@ -0,0 +1,33 @@
+qemu-user syscall clone fails
+Description of problem:
+This seems very similar to the issue reported here (https://bugs.launchpad.net/qemu/+bug/1926996). When attempting to perform the clone syscall, an error of -1 is returned where I would expect it to succeed. Running the same executable outside of qemu works as expected.
+Steps to reproduce:
+1. gcc clone.c
+2. qemu-x86_64 a.out
+Additional information:
+I've tried building with gcc, zig cc, and clang and the output of each works fine when running natively, but running under qemu fails. I originally discovered it when cross compiling to riscv64 but it doesn't seem to be limited to that architecture.
+
+```
+// clone.c
+
+#include <linux/sched.h>
+#include <sched.h>
+#include <sys/syscall.h>
+#include <unistd.h>
+#include <stdio.h>
+
+int main(void) {
+
+  long pid = syscall( SYS_clone, 0, 0, 0, 0, 0 );
+
+  if (pid < 0) {
+    printf( "error %ld\n", pid );
+  } else if (pid == 0) {
+    printf( "child %ld\n", pid );
+  } else {
+    printf( "parent %ld\n", pid );
+  }
+
+  return 0;
+}
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/93 b/gitlab/issues_text/target_missing/host_missing/accel_missing/93
new file mode 100644
index 00000000..8a9fa56b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/93
@@ -0,0 +1 @@
+qemu 1.4.2: usb keyboard not fully working
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/931 b/gitlab/issues_text/target_missing/host_missing/accel_missing/931
new file mode 100644
index 00000000..79a73839
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/931
@@ -0,0 +1 @@
+Create GitLab 7.1 milestone
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/932 b/gitlab/issues_text/target_missing/host_missing/accel_missing/932
new file mode 100644
index 00000000..a73014e8
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/932
@@ -0,0 +1,14 @@
+Snapshot created with 6.2.0 cannot be loaded with 7.0.0-rc1
+Description of problem:
+Loading the snapshot will fail with:
+
+````
+qemu-system-x86_64: Missing section footer for 0000:00:01.3/piix4_pm
+qemu-system-x86_64: Error -22 while loading VM state
+````
+Steps to reproduce:
+1. Start VM with `6.2.0`.
+2. Create a snapshot `takenwith620` with `snapshot-save` QMP command.
+3. Stop VM and try to load snapshot with `v7.0.0-rc1`.
+Additional information:
+Bisecting led to `5ead62185d ("memory: Make memory_region_is_mapped() succeed when mapped via an alias")`, but reverting that alone wasn't enough, so I continued and got to `7c0fa8dff8 ("pcie: Add support for Single Root I/O Virtualization (SR/IOV)")`. Only reverting both seems to fix the issue.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/933 b/gitlab/issues_text/target_missing/host_missing/accel_missing/933
new file mode 100644
index 00000000..3ca0949a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/933
@@ -0,0 +1,26 @@
+Changing CD ROM medium sometimes fails with 'Tray of device is not open'
+Description of problem:
+QEMU reports that a CD ROM tray is not open when exchanging media:
+`unable to execute QEMU command 'blockdev-remove-medium': Tray of device 'ide0-1-0' is not open`
+
+We see the issue in upstream libvirt integration tests. However, this issue is a race and the reproducibility rate is <15%.
+Steps to reproduce:
+On the high level this is what we do:
+1. eject medium that the machine was started with
+2. insert a different medium into the CD ROM
+
+Translating the above to QEMU QMP commands this is what the test exercises:
+1. blockdev-open-tray
+2. blockdev-remove-medium
+3. blockdev-del
+4. blockdev-close-tray
+5. blockdev-open-tray
+6. blockdev-remove-medium
+7. blockdev-add
+8. blockdev-insert-medium <<< This is where the test fails
+9. blockdev-close-tray
+Additional information:
+I bisected the code (3 times just to be sure since it's a race) and the following commit fell out of it:
+55adb3c45620c31f29978f209e2a44a08d34e2da
+
+I'm attaching QEMU trace events and a bunch of libvirt test logs (good and bad for comparison). If you think of anything else I should provide in order to help with the issue analysis, please let me know what other option should be turned on.[qemu_traces.tar.gz](/uploads/32e48c92efce3484e552df063795af4d/qemu_traces.tar.gz)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/935 b/gitlab/issues_text/target_missing/host_missing/accel_missing/935
new file mode 100644
index 00000000..899aaf0b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/935
@@ -0,0 +1,59 @@
+insert ivshmem device into pci-bridge, but vm network disconnects
+Description of problem:
+To extend PCI slot number in Windows vm, a new pci-bridge is created in Windows vm as bus.1. But when I insert a ivshmem file in host to this pci-bridge(bus.1), the Windows vm disconnects(lose remote desktop connection).
+Steps to reproduce:
+1. add new pci-bridge into windows vm, add windows vm xml configuration like this:
+```xml
+<devices>
+  <controller type='pci' index='0' model='pci-root'/>
+  <controller type='pci' index='1' model='pci-bridge'>
+    <address type='pci' domain='0' bus='0' slot='0x0d' function='0' multifunction='off'/>
+  </controller>
+</devices>
+```
+
+2.restart this Windows vm, new pci-bridge has been created, its name is pci.1 and bus is bus.1:
+```sh
+$ virsh qemu-monitor-command --hmp --domain 56 --cmd info pci
+  Bus  0, device  13, function 0:
+    PCI bridge: PCI device 1b36:0001
+      IRQ 10.
+      BUS 0.
+      secondary bus 1.
+      subordinate bus 1.
+      IO range [0xc000, 0xcfff]
+      memory range [0xfe000000, 0xfe1fffff]
+      prefetchable memory range [0xe4000000, 0xe41fffff]
+      BAR0: 64 bit memory at 0xfe422000 [0xfe4220ff].
+      id "pci.1"
+```
+3. create a shm file `/dev/shm/test1` in host using `shm_open()`, size is 32M
+
+4. create new object: 
+```sh
+virsh qemu-monitor-command --hmp --domain 56 --cmd object_add memory-backend-file,share=on,id=objtest1,size=32M,mem-path=/dev/shm/test1
+```
+
+5. insert this ivshmem file into new pci-bridge and use bus.1 slot number(1:1.0):
+```sh
+virsh qemu-monitor-command --hmp --domain 56 --cmd device_add ivshmem-plain,memdev=objtest1,id=test1,bus=pci.1,addr=0x01.0x00
+```
+
+6. After inserting this ivshmem file into new pci-bridge, the remote desktop connection of this windows vm disconnects.
+
+7. New ivshmem file has been created:
+```
+$ virsh qemu-monitor-command --hmp --domain 57 --cmd info pci
+  Bus  1, device   1, function 0:
+    RAM controller: PCI device 1af4:1110
+      BAR0: 32 bit memory at 0xfe1fff00 [0xfe1fffff].
+      BAR2: 64 bit prefetchable memory at 0x4bc000000 [0x4bfffffff].
+      id "test1"
+
+```
+Additional information:
+When insert ivshmem file into bus.1(pci-bridge), the remote desktop connection of Windows vm is sometimes disconnected, and sometimes it is normal.
+
+The newly added ivshmem device can be found in the device manager of the Windows vm, but sometimes it cannot be found.
+
+Thanks for your help!
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/936 b/gitlab/issues_text/target_missing/host_missing/accel_missing/936
new file mode 100644
index 00000000..a78153eb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/936
@@ -0,0 +1,16 @@
+Serial output mangled in terminal
+Description of problem:
+My hobby OS uses the serial port at `0x3f8` to log messages to QEMU's stdout. This used to work fine, I can even emit ANSI escape codes to get color output and it renders in my terminal as expected. I left this project for about a year and just returned to it with the latest version of QEMU. Now, all of the QEMU serial output from my OS in the terminal seems to be missing carriage returns and buffering strangely. It's as if every log line ends up on the same line in the stdout buffer, but with newlines (without returning to the start of the line) between them. For example (these aren't my real logs but demonstrate the issue):
+```
+[KERNEL] startup
+                [KERNEL] initializing heap
+                                          [KERNEL] initializing drivers
+                                                                       [KERNEL] ready!
+```
+Also, when QEMU exits, I notice that my shell indicates that the last command's output didn't end in a newline which is strange.
+
+I tried debugging this myself by piping the output to a file and inspecting it in a hex editor, but it looks like just normal newlines in the output. I tried piping the output to `tr '\n' '\r\n'` to add carriage returns, but that ends up rendering all the output on a single line which resets to the first column every line. I tried sending the output to a file and watching the file, but it seems to get buffered and the data only shows up once QEMU exits. My best guess is that the output hasn't changed, but this new version of QEMU is changing some kind of buffering setting on its output which is causing this, but I'm really not sure what's going on.
+Steps to reproduce:
+I can provide the boot image if that would be helpful to reproduce.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/937 b/gitlab/issues_text/target_missing/host_missing/accel_missing/937
new file mode 100644
index 00000000..654f53ea
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/937
@@ -0,0 +1,68 @@
+I/O errors occur when qcow2 files created via gluster fuse mount are accessed via libgfapi (gluster://)
+Description of problem:
+Environment: a Gluster volume 'v0' (Gluster versions tested were 9.2-1 and 10.1) is built on 3 nodes on top of 3 ZFS pools. It is mounted to check fuse mount functionality. Mount point is `/mnt/gl`.
+When an empty qcow2 is created via fuse mount (qemu-img create -f qcow2 /mnt/gl/123.qcow2 10G) and then this qcow2 is attached to qemu guest -- error appears:
+```
+qemu-system-x86_64: -blockdev {"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-2-storage","backing":null}: Could not read L1 table: Input/output error
+```
+When the same file is attached to qemu guest via fuse mount there is no error. When the same file is created via GFAPI (gluster://) there is no error too.
+Steps to reproduce:
+1. Create file via fuse-mount: `qemu-img create -f qcow2 /mnt/gl/123.qcow2 10G`
+2. Attach this file via gluster:// to qemu guest and observe an error
+3. Attach this file via fuse mount, run a guest -- no error.
+4. Create file via gluster:// : `qemu-img create -f qcow2 gluster://v0/234.qcow2 10g`
+5. Attach this file (via GFAPI or via fuse mount) to qemu guest and run guest -- there is no error.
+Additional information:
+When an empty qcow2 file with virtual size 10G with default cluster size is created, its proper size is 196768 (0x300a0) bytes. If file is created via fuse mount, that is true and file size is 0x300a0 bytes.
+In the end of file L1 table resides, its offset is 0x30000 and size is 0xa0. When this qcow2 is attached via fuse mount it seems that i/o requests are conforming to file size and file is read without errors. 
+But when file with size 0x300a0 is attached via gluster://, qemu aligns i/o requests by 0x200 bytes boundary (see dump below, frame #12. NB: dump is taken from qemu-img create cmd so there are write requests). Thus, request goes beyond the file end and read error occurs.
+
+When file is created via gluster:// its size is 197120 (0x30200) bytes because write requests are aligned to 512 bytes too. And guest runs normally with it regardless of connection type.
+
+```
+Thread 1 "qemu-img" hit Breakpoint 1, 0x00007fffec014f10 in ec_gf_writev () from /usr/lib64/glusterfs/11dev/xlator/cluster/disperse.so
+(gdb) bt
+#0  0x00007fffec014f10 in ec_gf_writev () from /usr/lib64/glusterfs/11dev/xlator/cluster/disperse.so
+#1  0x00007ffff68eeea6 in default_writev () from /lib64/libglusterfs.so.0
+#2  0x00007ffff4024ab8 in gf_utime_writev (frame=0x555556126aa8, this=0x7fffe40113d8, fd=0x555556126b88, vector=0x555556130868, count=1, off=196608, flags=0, iobref=0x555556130608, xdata=0x0) at utime-autogen-fops.c:81
+#3  0x00007ffff68eeea6 in default_writev () from /lib64/libglusterfs.so.0
+#4  0x00007ffff4013c39 in ob_writev (frame=frame@entry=0x555556126aa8, this=0x7fffe4012408, fd=fd@entry=0x555556126b88, iov=iov@entry=0x555556130868, count=count@entry=1, offset=offset@entry=196608, flags=0,
+    iobref=0x555556130608, xdata=0x0) at open-behind.c:584
+#5  0x00007fffdff37774 in mdc_writev (frame=frame@entry=0x5555561522d8, this=0x7fffe40139e8, fd=fd@entry=0x555556126b88, vector=vector@entry=0x555556130868, count=count@entry=1, offset=offset@entry=196608, flags=0,
+    iobref=0x555556130608, xdata=0x0) at md-cache.c:2151
+#6  0x00007fffdff143fb in io_stats_writev (frame=0x55555611dc08, this=0x7fffe4015468, fd=0x555556126b88, vector=0x555556130868, count=1, offset=196608, flags=0, iobref=0x555556130608, xdata=0x0) at io-stats.c:2952
+#7  0x00007ffff68eeea6 in default_writev () from /lib64/libglusterfs.so.0
+#8  0x00007fffdfee88ca in meta_writev (frame=0x55555611dc08, this=0x7fffe40173d8, fd=0x555556126b88, iov=0x555556130868, count=1, offset=196608, flags=0, iobref=0x555556130608, xdata=0x0) at meta.c:131
+#9  0x00007ffff6942f22 in glfs_pwritev_async_common () from /lib64/libgfapi.so.0
+#10 0x00007ffff69462f6 in glfs_pwritev_async () from /lib64/libgfapi.so.0
+#11 0x00007ffff7fc5839 in qemu_gluster_co_writev () from /usr/lib64/qemu/block-gluster.so
+#12 0x0000555555623b7e in bdrv_driver_pwritev (bs=bs@entry=0x55555611eda0, offset=offset@entry=196608, bytes=bytes@entry=512, qiov=qiov@entry=0x7ffff5e9cb40, qiov_offset=qiov_offset@entry=0, flags=flags@entry=0)
+    at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:1243
+#13 0x00005555556244d2 in bdrv_aligned_pwritev (child=child@entry=0x55555611e3a0, req=req@entry=0x7ffff5e9ca80, offset=196608, bytes=512, align=align@entry=512, qiov=0x7ffff5e9cb40, qiov_offset=0, flags=0)
+    at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:2020
+#14 0x0000555555625433 in bdrv_co_pwritev_part (child=0x55555611e3a0, offset=<optimized out>, bytes=<optimized out>, qiov=<optimized out>, qiov_offset=<optimized out>, flags=0)
+    at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:2188
+#15 0x00005555556267a0 in bdrv_run_co (opaque=0x7ffff5e9cbb0, entry=0x5555556260a0 <bdrv_rw_co_entry>, bs=0x55555611eda0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:915
+#16 bdrv_prwv_co (flags=0, is_write=true, qiov=0x7ffff5e9cbd0, offset=196608, child=0x55555611e3a0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:966
+#17 bdrv_pwritev (qiov=0x7ffff5e9cbd0, offset=196608, child=0x55555611e3a0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:1048
+#18 bdrv_pwrite (bytes=160, buf=0x555556116000, offset=196608, child=0x55555611e3a0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:1070
+#19 bdrv_pwrite_sync (child=0x55555611e3a0, offset=offset@entry=196608, buf=buf@entry=0x555556116000, count=count@entry=160) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:1084
+#20 0x00005555555f60de in qcow2_grow_l1_table (bs=bs@entry=0x55555610d0a0, min_size=min_size@entry=20, exact_size=exact_size@entry=true) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/qcow2-cluster.c:161
+#21 0x00005555555ec252 in qcow2_co_truncate (bs=0x55555610d0a0, offset=<optimized out>, exact=<optimized out>, prealloc=PREALLOC_MODE_OFF, flags=0, errp=0x7ffff5e9cfa0)
+    at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/qcow2.c:4172
+#22 0x000055555562758d in bdrv_co_truncate (child=0x55555617b290, offset=10737418240, exact=<optimized out>, prealloc=PREALLOC_MODE_OFF, flags=0, errp=0x7ffff5e9cfa0)
+    at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:3394
+#23 0x0000555555627a01 in bdrv_truncate_co_entry (opaque=0x7ffff5e9ceb0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:3437
+#24 bdrv_run_co (opaque=0x7ffff5e9ceb0, entry=0x555555627980 <bdrv_truncate_co_entry>, bs=0x55555610d0a0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:915
+#25 bdrv_truncate (child=<optimized out>, offset=<optimized out>, exact=<optimized out>, prealloc=<optimized out>, flags=flags@entry=0, errp=errp@entry=0x7ffff5e9cfa0)
+    at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:3453
+#26 0x0000555555611d32 in blk_truncate (blk=blk@entry=0x55555611e420, offset=<optimized out>, exact=exact@entry=false, prealloc=<optimized out>, flags=flags@entry=0, errp=errp@entry=0x7ffff5e9cfa0)
+    at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/block-backend.c:2184
+#27 0x00005555555e9a0f in qcow2_co_create (create_options=0x55555612c000, errp=errp@entry=0x7ffff5e9cfa0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/qcow2.c:3614
+#28 0x00005555555ea0ec in qcow2_co_create_opts (drv=<optimized out>, filename=<optimized out>, opts=0x5555557a3f90, errp=0x7ffff5e9cfa0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/qcow2.c:3795
+#29 0x00005555555bd631 in bdrv_create_co_entry (opaque=0x7fffffffdff0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block.c:487
+#30 0x00005555556a7d8b in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/util/coroutine-ucontext.c:173
+#31 0x00007ffff76a01c0 in ?? () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 from /lib64/libc.so.6
+#32 0x00007fffffffd820 in ?? ()
+#33 0x0000000000000000 in ?? ()
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/938 b/gitlab/issues_text/target_missing/host_missing/accel_missing/938
new file mode 100644
index 00000000..bd148571
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/938
@@ -0,0 +1 @@
+Impossible to cross compile from Ubuntu or Debian to Windows with the tutorial
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/940 b/gitlab/issues_text/target_missing/host_missing/accel_missing/940
new file mode 100644
index 00000000..6d3d5ccb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/940
@@ -0,0 +1 @@
+"analyze-migration.py -m" does not appear to account for the pci-hole
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/941 b/gitlab/issues_text/target_missing/host_missing/accel_missing/941
new file mode 100644
index 00000000..1211f967
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/941
@@ -0,0 +1,41 @@
+qemu-img cannot repair a qcow2 in an LV because size is mis-detected when qcow2 is on an LV
+Description of problem:
+This is RHEV with Tb's of VMs which need to be repaired due to a datacenter-wide (the real datacenter) power outage.
+
+Each of these VMs are on individual LVs but qemu-img check fails to perform repairs:
+
+
+```
+ERROR cluster 24481205 refcount=0 reference=1
+ERROR cluster 24481206 refcount=0 reference=1
+Rebuilding refcount structure
+ERROR writing refblock: No space left on device <============
+qemu-img: Check failed: No space left on device
+```
+
+Running qemu-img check or info on the LV (/dev/dm-*) works well but repairs cannot be completed:
+
+```
+# qemu-img info /dev/cdd4e215-8c6b-4877-b2be-fdba383e7eb0/fb32333b-2334-4e10-8c42-02bc97e826cc
+image: /dev/cdd4e215-8c6b-4877-b2be-fdba383e7eb0/fb32333b-2334-4e10-8c42-02bc97e826cc
+file format: qcow2
+virtual size: 1.5 TiB (1649267441664 bytes)
+disk size: 0 B <================================
+cluster_size: 65536
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: true
+    refcount bits: 16
+    corrupt: false
+    extended l2: false
+```
+Steps to reproduce:
+1. Have a damaged VM with its qcow2 in an LV
+2. run 'qemu-img check <device>' verify that it properly detects the blocks which need fixing.
+3. run 'qemu-img check -r all <device>', it exits with 'no space left on device´ after a few seconds.
+Additional information:
+https://bugzilla.redhat.com/show_bug.cgi?id=1519071
+
+
+Here is one example:
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/943 b/gitlab/issues_text/target_missing/host_missing/accel_missing/943
new file mode 100644
index 00000000..fbd4a3ec
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/943
@@ -0,0 +1 @@
+Calling get-fsinfo on a virtual machine does not include ZFS (zfsonlinux, debian guest tested) volumes
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/944 b/gitlab/issues_text/target_missing/host_missing/accel_missing/944
new file mode 100644
index 00000000..b2058d84
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/944
@@ -0,0 +1,28 @@
+9p virtfs issue under MacOS in 7.0.0-rc1
+Description of problem:
+9p virtfs under MacOS has an issue with sed inline replacements (sed -i).
+The issue somewhere in xattr I believe
+Steps to reproduce:
+1. /Users/sid/ is mounted via 9p virtfs from MacOS host
+2.
+```
+[core@localhost ~]$ sed -i 's/aaa/zzz/g' /Users/sid/q/123
+sed: preserving permissions for ‘/Users/sid/q/sed3MLMjp’: Protocol not supported
+```
+Additional information:
+strace part with error
+```
+openat(AT_FDCWD, "/proc/thread-self/attr/fscreate", O_RDWR|O_CLOEXEC) = 5
+write(5, NULL, 0)                       = 0
+close(5)                                = 0
+newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=12, ...}, AT_EMPTY_PATH) = 0
+read(3, "qqq\nzzz\nsss\n", 8192)        = 12
+newfstatat(4, "", {st_mode=S_IFREG|0600, st_size=0, ...}, AT_EMPTY_PATH) = 0
+read(3, "", 8192)                       = 0
+fchown(4, 501, 1000)                    = 0
+fgetxattr(3, "system.posix_acl_access", 0x7ffd6dbd18b0, 132) = -1 ENODATA (No data available)
+newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=12, ...}, AT_EMPTY_PATH) = 0
+fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377 \0\4\0\377\377\377\377", 28, 0) = -1 EPROTONOSUPPORT (Protocol not supported)
+fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377 \0\4\0\377\377\377\377", 28, 0) = -1 EPROTONOSUPPORT (Protocol not supported)
+fchmod(4, 0100644)                      = 0
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/945 b/gitlab/issues_text/target_missing/host_missing/accel_missing/945
new file mode 100644
index 00000000..eed71935
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/945
@@ -0,0 +1,10 @@
+For QEMU 7.0.0-rc1, nbd-server-add fails with qcow2 image with iothread in migration context
+Description of problem:
+Upon adding the drive for NBD (via QMP), there is an error message
+````kvm: ../block.c:3657: bdrv_open_child: Assertion `qemu_in_main_thread()' failed.````
+and then the process aborts.
+Steps to reproduce:
+1. Create image: `qemu-img create -f qcow2 /root/target-disk.qcow2 4G`
+2. Start QEMU as mentioned above.
+3. Issue `nbd-server-start` QMP command (I used type unix).
+4. Issue `nbd-server-add` command for the single disk.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/946 b/gitlab/issues_text/target_missing/host_missing/accel_missing/946
new file mode 100644
index 00000000..12727555
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/946
@@ -0,0 +1,12 @@
+qemu-img can't create qcow2 file on nfs path，which report error(Image is not in qcow2 format)
+Description of problem:
+I mount a nfs disk on my host,and use qemu-img to create a qcow2 file on this nfs path,but it not work,i have no idea,This problem has come up before in red-hat community: 
+[BUGID:1817640](https://bugzilla.redhat.com/show_bug.cgi?id=1817640#)
+Steps to reproduce:
+![image](/uploads/ff131e4be09699ae3a1226f7cf1358ba/image.png)
+
+**strace file:**
+[qemu-img-strace.log](/uploads/85517b7550ba1ea459f85cfd37b74332/qemu-img-strace.log)
+
+See form this strace file,in the line 1077,we can see pread64 read result is empty,it casuse the error,but i don't know why the resulut is empty.
+![image](/uploads/8861295db3c9bbddbc19596d97bbb126/image.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/948 b/gitlab/issues_text/target_missing/host_missing/accel_missing/948
new file mode 100644
index 00000000..51f59d1f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/948
@@ -0,0 +1,32 @@
+7.0.0-rc1, -rc2 cannot build - config-poison.h is not generated
+Description of problem:
+`make` halts with:
+
+```
+[557/2583] Generating module_block.h with a custom command
+[558/2583] Generating block-gen.c with a custom command
+[559/2583] Generating x86_64-softmmu-gdbstub-xml.c with a custom command (wrapped by meson to capture output)
+[560/2583] Compiling C object libpage-vary-common.a.p/page-vary-common.c.o
+[561/2583] Generating trace-target_sparc.c with a custom command
+[562/2583] Generating trace-target_s390x_kvm.c with a custom command
+ninja: job failed: clang -m64 -mcx16 -Ilibpage-vary-common.a.p -I. -I.. -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -flto -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/dummy/qemu-7.0.0-rc2/linux-headers -isystem linux-headers -iquote . -iquote /home/dummy/qemu-7.0.0-rc2 -iquote /home/dummy/qemu-7.0.0-rc2/include -iquote /home/dummy/qemu-7.0.0-rc2/disas/libvixl -iquote /home/dummy/qemu-7.0.0-rc2/tcg/i386 -pthread -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-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong -fsanitize=cfi-icall -fsanitize-cfi-icall-generalize-pointers -fPIE -fno-lto -fno-sanitize=cfi-icall -MD -MQ libpage-vary-common.a.p/page-vary-common.c.o -MF libpage-vary-common.a.p/page-vary-common.c.o.d -o libpage-vary-common.a.p/page-vary-common.c.o -c ../page-vary-common.c
+In file included from ../page-vary-common.c:22:
+In file included from /home/dummy/qemu-7.0.0-rc2/include/qemu/osdep.h:34:
+/home/dummy/qemu-7.0.0-rc2/include/exec/poison.h:7:10: fatal error: 'config-poison.h' file not found
+#include "config-poison.h"
+         ^~~~~~~~~~~~~~~~~
+1 error generated.
+ninja: subcommand failed
+make[1]: *** [Makefile:163: run-ninja] Error 1
+make[1]: Leaving directory '/home/dummy/qemu-7.0.0-rc2/build'
+make: *** [GNUmakefile:11: all] Error 2
+
+```
+
+It seems that `config-poison.h` is not generated in `configure` and is not explicitly a dependency for some of necessary object file.
+Steps to reproduce:
+1. `docker pull alpine:3.15`
+2. `docker build -t qemubad .` with the attached dockerfile
+Additional information:
+6.2.0 is good
+7.0.0-rc0, 7.0.0-rc1, 7.0.0-rc2 exhibits the issue
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/950 b/gitlab/issues_text/target_missing/host_missing/accel_missing/950
new file mode 100644
index 00000000..49492139
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/950
@@ -0,0 +1,23 @@
+7.0.0-rc2 hw/9pfs/9p.h cannot find XATTR_SIZE_MAX
+Description of problem:
+```
+[844/2583] Compiling C object tests/qtest/qos-test.p/virtio-rng-test.c.o
+ninja: job failed: clang -m64 -mcx16 -Itests/qtest/qos-test.p -Itests/qtest -I../tests/qtest -I. -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -flto -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/dummy/qemu-7.0.0-rc2/linux-headers -isystem linux-headers -iquote . -iquote /home/dummy/qemu-7.0.0-rc2 -iquote /home/dummy/qemu-7.0.0-rc2/include -iquote /home/dummy/qemu-7.0.0-rc2/disas/libvixl -iquote /home/dummy/qemu-7.0.0-rc2/tcg/i386 -pthread -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-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong -fsanitize=cfi-icall -fsanitize-cfi-icall-generalize-pointers -fPIE -MD -MQ tests/qtest/qos-test.p/virtio-9p-test.c.o -MF tests/qtest/qos-test.p/virtio-9p-test.c.o.d -o tests/qtest/qos-test.p/virtio-9p-test.c.o -c ../tests/qtest/virtio-9p-test.c
+In file included from ../tests/qtest/virtio-9p-test.c:18:
+/home/dummy/qemu-7.0.0-rc2/hw/9pfs/9p.h:497:2: error: Missing definition for P9_XATTR_SIZE_MAX for this host system
+#error Missing definition for P9_XATTR_SIZE_MAX for this host system
+ ^
+1 error generated.
+ninja: subcommand failed
+make[1]: *** [Makefile:163: run-ninja] Error 1
+make[1]: Leaving directory '/home/dummy/qemu-7.0.0-rc2/build'
+make: *** [GNUmakefile:11: all] Error 2
+The command '/bin/sh -c make -j"`grep -c '^processor' /proc/cpuinfo`"' returned a non-zero code: 2
+
+```
+Steps to reproduce:
+1. build with attached Dockerfile
+Additional information:
+This problem is introduced by lore.kernel.org/all/20220227223522.91937-7-wwcohen@gmail.com/
+
+`XATTR_SIZE_MAX` is in `<linux/limits.h>` which is included by `9p.c` but not `9p.h`. However the `9p.h` checks existence of XATTR_SIZE_MAX, so any other file including `9p.h` would be illegal. This is clearly misplacement of header including.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/951 b/gitlab/issues_text/target_missing/host_missing/accel_missing/951
new file mode 100644
index 00000000..71d7ba4a
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/951
@@ -0,0 +1,195 @@
+Build error
+Description of problem:
+```
+changing dir to build for make ""...
+make[1]: Entering directory '/qemu-git/qemu/build'
+  GIT     ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone slirp
+[1/1037] Generating ar with a custom command
+[2/1037] Generating bepo with a custom command
+[3/1037] Generating cz with a custom command
+[4/1037] Generating da with a custom command
+[5/1037] Generating de with a custom command
+[6/1037] Generating de-ch with a custom command
+[7/1037] Generating en-gb with a custom command
+[8/1037] Generating en-us with a custom command
+[9/1037] Generating es with a custom command
+[10/1037] Generating et with a custom command
+[11/1037] Generating fi with a custom command
+[12/1037] Generating fo with a custom command
+[13/1037] Generating fr-be with a custom command
+[14/1037] Generating fr with a custom command
+[15/1037] Generating fr-ca with a custom command
+[16/1037] Generating fr-ch with a custom command
+[17/1037] Generating hr with a custom command
+[18/1037] Generating hu with a custom command
+[19/1037] Generating is with a custom command
+[20/1037] Generating it with a custom command
+[21/1037] Generating ja with a custom command
+[22/1037] Generating lt with a custom command
+[23/1037] Generating mk with a custom command
+[24/1037] Generating lv with a custom command
+[25/1037] Generating nl with a custom command
+[26/1037] Generating no with a custom command
+[27/1037] Generating pt with a custom command
+[28/1037] Generating pl with a custom command
+[29/1037] Generating ru with a custom command
+[30/1037] Generating pt-br with a custom command
+[31/1037] Generating th with a custom command
+[32/1037] Generating tr with a custom command
+[33/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_i64.c.o
+[34/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_common.c.o
+[35/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_ui32.c.o
+[36/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_random.c.o
+[37/1037] Generating Test QAPI files with a custom command
+[38/1037] Generating QAPI test (include) with a custom command
+[39/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_uint128.c.o
+[40/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_functions_common.c.o
+[41/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_extF80.c.o
+[42/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_functionInfos.c.o
+[43/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_ui64.c.o
+[44/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_f16.c.o
+[45/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_i32.c.o
+[46/1037] Generating edk2-i386-vars.fd with a custom command (wrapped by meson to capture output)
+[47/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_uint128_inline.c.o
+[48/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_standardFunctionInfos.c.o
+[49/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_fail.c.o
+[50/1037] Generating qemu-version.h with a custom command (wrapped by meson to capture output)
+[51/1034] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_f32.c.o
+[52/1034] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_s_eq128.c.o
+[53/1034] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_writeTestsTotal.c.o
+[54/1034] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_f64.c.o
+[55/1034] Generating edk2-x86_64-code.fd with a custom command (wrapped by meson to capture output)
+[56/1034] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_f128.c.o
+[57/1034] Generating edk2-x86_64-secure-code.fd with a custom command (wrapped by meson to capture output)
+[58/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-iova-tree.c.o
+[59/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-shadow-virtqueue.c.o
+[60/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_vfio_pci-quirks.c.o
+FAILED: libqemu-x86_64-softmmu.fa.p/hw_vfio_pci-quirks.c.o
+cc -m64 -mcx16 -Ilibqemu-x86_64-softmmu.fa.p -I. -I.. -Itarget/i386 -I../target/i386 -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /qemu-git/qemu/linux-headers -isystem linux-headers -iquote . -iquote /qemu-git/qemu -iquote /qemu-git/qemu/include -iquote /qemu-git/qemu/disas/libvixl -iquote /qemu-git/qemu/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=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-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 -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="x86_64-softmmu-config-target.h"' '-DCONFIG_DEVICES="x86_64-softmmu-config-devices.h"' -MD -MQ libqemu-x86_64-softmmu.fa.p/hw_vfio_pci-quirks.c.o -MF libqemu-x86_64-softmmu.fa.p/hw_vfio_pci-quirks.c.o.d -o libqemu-x86_64-softmmu.fa.p/hw_vfio_pci-quirks.c.o -c ../hw/vfio/pci-quirks.c
+../hw/vfio/pci-quirks.c: In function ‘vfio_igd_gtt_max’:
+../hw/vfio/pci-quirks.c:1356:55: error: ‘IGD_GMCH’ undeclared (first use in this function)
+ 1356 |     uint32_t gmch = vfio_pci_read_config(&vdev->pdev, IGD_GMCH, sizeof(gmch));
+      |                                                       ^~~~~~~~
+../hw/vfio/pci-quirks.c:1356:55: note: each undeclared identifier is reported only once for each function it appears in
+../hw/vfio/pci-quirks.c:1357:21: error: implicit declaration of function ‘igd_gen’ [-Werror=implicit-function-declaration]
+ 1357 |     int ggms, gen = igd_gen(vdev);
+      |                     ^~~~~~~
+../hw/vfio/pci-quirks.c:1357:21: error: nested extern declaration of ‘igd_gen’ [-Werror=nested-externs]
+../hw/vfio/pci-quirks.c: In function ‘vfio_igd_quirk_data_read’:
+../hw/vfio/pci-quirks.c:1384:5: error: unknown type name ‘VFIOIGDQuirk’; did you mean ‘VFIOQuirk’?
+ 1384 |     VFIOIGDQuirk *igd = opaque;
+      |     ^~~~~~~~~~~~
+      |     VFIOQuirk
+../hw/vfio/pci-quirks.c:1385:30: error: request for member ‘vdev’ in something not a structure or union
+ 1385 |     VFIOPCIDevice *vdev = igd->vdev;
+      |                              ^~
+../hw/vfio/pci-quirks.c:1387:8: error: request for member ‘index’ in something not a structure or union
+ 1387 |     igd->index = ~0;
+      |        ^~
+../hw/vfio/pci-quirks.c: In function ‘vfio_igd_quirk_data_write’:
+../hw/vfio/pci-quirks.c:1395:5: error: unknown type name ‘VFIOIGDQuirk’; did you mean ‘VFIOQuirk’?
+ 1395 |     VFIOIGDQuirk *igd = opaque;
+      |     ^~~~~~~~~~~~
+      |     VFIOQuirk
+../hw/vfio/pci-quirks.c:1396:30: error: request for member ‘vdev’ in something not a structure or union
+ 1396 |     VFIOPCIDevice *vdev = igd->vdev;
+      |                              ^~
+../hw/vfio/pci-quirks.c:1414:13: error: request for member ‘index’ in something not a structure or union
+ 1414 |     if ((igd->index % 4 == 1) && igd->index < vfio_igd_gtt_max(vdev)) {
+      |             ^~
+../hw/vfio/pci-quirks.c:1414:37: error: request for member ‘index’ in something not a structure or union
+ 1414 |     if ((igd->index % 4 == 1) && igd->index < vfio_igd_gtt_max(vdev)) {
+      |                                     ^~
+../hw/vfio/pci-quirks.c:1415:28: error: request for member ‘index’ in something not a structure or union
+ 1415 |         if (gen < 8 || (igd->index % 8 == 1)) {
+      |                            ^~
+../hw/vfio/pci-quirks.c:1418:53: error: ‘IGD_BDSM’ undeclared (first use in this function)
+ 1418 |             base = pci_get_long(vdev->pdev.config + IGD_BDSM);
+      |                                                     ^~~~~~~~
+../hw/vfio/pci-quirks.c:1420:17: error: implicit declaration of function ‘hw_error’; did you mean ‘herror’? [-Werror=implicit-function-declaration]
+ 1420 |                 hw_error("vfio-igd: Guest attempted to program IGD GTT before "
+      |                 ^~~~~~~~
+      |                 herror
+../hw/vfio/pci-quirks.c:1420:17: error: nested extern declaration of ‘hw_error’ [-Werror=nested-externs]
+../hw/vfio/pci-quirks.c:1424:29: error: request for member ‘bdsm’ in something not a structure or union
+ 1424 |             val = data - igd->bdsm + base;
+      |                             ^~
+../hw/vfio/pci-quirks.c:1430:42: error: request for member ‘index’ in something not a structure or union
+ 1430 |                                       igd->index, data, val);
+      |                                          ^~
+../hw/vfio/pci-quirks.c:1435:8: error: request for member ‘index’ in something not a structure or union
+ 1435 |     igd->index = ~0;
+      |        ^~
+../hw/vfio/pci-quirks.c: In function ‘vfio_igd_quirk_index_read’:
+../hw/vfio/pci-quirks.c:1447:5: error: unknown type name ‘VFIOIGDQuirk’; did you mean ‘VFIOQuirk’?
+ 1447 |     VFIOIGDQuirk *igd = opaque;
+      |     ^~~~~~~~~~~~
+      |     VFIOQuirk
+../hw/vfio/pci-quirks.c:1448:30: error: request for member ‘vdev’ in something not a structure or union
+ 1448 |     VFIOPCIDevice *vdev = igd->vdev;
+      |                              ^~
+../hw/vfio/pci-quirks.c:1450:8: error: request for member ‘index’ in something not a structure or union
+ 1450 |     igd->index = ~0;
+      |        ^~
+../hw/vfio/pci-quirks.c: In function ‘vfio_igd_quirk_index_write’:
+../hw/vfio/pci-quirks.c:1458:5: error: unknown type name ‘VFIOIGDQuirk’; did you mean ‘VFIOQuirk’?
+ 1458 |     VFIOIGDQuirk *igd = opaque;
+      |     ^~~~~~~~~~~~
+      |     VFIOQuirk
+../hw/vfio/pci-quirks.c:1459:30: error: request for member ‘vdev’ in something not a structure or union
+ 1459 |     VFIOPCIDevice *vdev = igd->vdev;
+      |                              ^~
+../hw/vfio/pci-quirks.c:1461:8: error: request for member ‘index’ in something not a structure or union
+ 1461 |     igd->index = data;
+      |        ^~
+../hw/vfio/pci-quirks.c: At top level:
+../hw/vfio/pci-quirks.c:1472:13: error: static declaration of ‘vfio_probe_igd_bar4_quirk’ follows non-static declaration
+ 1472 | static void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int nr)
+      |             ^~~~~~~~~~~~~~~~~~~~~~~~~
+In file included from ../hw/vfio/pci-quirks.c:27:
+../hw/vfio/pci.h:211:6: note: previous declaration of ‘vfio_probe_igd_bar4_quirk’ was here
+  211 | void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int nr);
+      |      ^~~~~~~~~~~~~~~~~~~~~~~~~
+../hw/vfio/pci-quirks.c: In function ‘vfio_probe_igd_bar4_quirk’:
+../hw/vfio/pci-quirks.c:1477:5: error: unknown type name ‘VFIOIGDQuirk’; did you mean ‘VFIOQuirk’?
+ 1477 |     VFIOIGDQuirk *igd;
+      |     ^~~~~~~~~~~~
+      |     VFIOQuirk
+../hw/vfio/pci-quirks.c:1511:46: error: ‘IGD_GMCH’ undeclared (first use in this function)
+ 1511 |     gmch = vfio_pci_read_config(&vdev->pdev, IGD_GMCH, 4);
+      |                                              ^~~~~~~~
+../hw/vfio/pci-quirks.c:1603:32: error: ‘ERR_PREFIX’ undeclared (first use in this function)
+ 1603 |         error_reportf_err(err, ERR_PREFIX, vdev->vbasedev.name);
+      |                                ^~~~~~~~~~
+../hw/vfio/pci-quirks.c:1638:8: error: request for member ‘vdev’ in something not a structure or union
+ 1638 |     igd->vdev = vdev;
+      |        ^~
+../hw/vfio/pci-quirks.c:1639:8: error: request for member ‘index’ in something not a structure or union
+ 1639 |     igd->index = ~0;
+      |        ^~
+../hw/vfio/pci-quirks.c:1640:8: error: request for member ‘bdsm’ in something not a structure or union
+ 1640 |     igd->bdsm = vfio_pci_read_config(&vdev->pdev, IGD_BDSM, 4);
+      |        ^~
+../hw/vfio/pci-quirks.c:1640:51: error: ‘IGD_BDSM’ undeclared (first use in this function)
+ 1640 |     igd->bdsm = vfio_pci_read_config(&vdev->pdev, IGD_BDSM, 4);
+      |                                                   ^~~~~~~~
+../hw/vfio/pci-quirks.c:1641:8: error: request for member ‘bdsm’ in something not a structure or union
+ 1641 |     igd->bdsm &= ~((1 << 20) - 1); /* 1MB aligned */
+      |        ^~
+cc1: all warnings being treated as errors
+[61/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_virtio-crypto-pci.c.o
+[62/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_virtio-crypto.c.o
+[63/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-user-fs.c.o
+[64/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-user-fs-pci.c.o
+[65/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-vdpa.c.o
+[66/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_virtio-balloon.c.o
+[67/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-user.c.o
+ninja: build stopped: subcommand failed.
+make[1]: *** [Makefile:163: run-ninja] Error 1
+make[1]: Leaving directory '/qemu-git/qemu/build'
+make: *** [GNUmakefile:11: all] Error 2
+```
+Steps to reproduce:
+1. git clone git://git.qemu.org/qemu.git
+2. ./configure --prefix=/usr \--target-list=x86_64-softmmu
+3. make -j8
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/956 b/gitlab/issues_text/target_missing/host_missing/accel_missing/956
new file mode 100644
index 00000000..3c412080
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/956
@@ -0,0 +1,42 @@
+ARM: When 'virsh dump' exports vmcore, specifies --format compression format, virtual machine assert hangs
+Description of problem:
+**ARM: virsh dump exports vmcore, specifies --format compression format, virtual machine assert hangs**
+
+**why 'virsh dump' page size configured as target page size (64KiB), but 'Implement kvm-steal-time' page size configured as host page size (4KB)?**
+Steps to reproduce:
+The vm image page size is configured as 64KiB, and the host page size is configured as 4KiB
+
+1.start vm
+
+2.Execute the virsh dump command to export vmcore
+
+Specify the compression format of vmcore, --format (kdump-zlib, kdump-snappy, kdump-lzo)
+
+/usr/bin/virsh dump avocado-vt-vm1 /var/tmp/vm.core --memory-only --format kdump-zlib
+
+/usr/bin/virsh dump avocado-vt-vm1 /var/tmp/vm.core --memory-only --format kdump-lzo
+
+/usr/bin/virsh dump avocado-vt-vm1 /var/tmp/vm.core --memory-only --format kdump-snappy
+
+**expected results**: The vmcore file is successfully exported and the virtual machine is running normally.
+
+**actual results**: The vmcore file is not exported normally, and the virtual machine is shut down abnormally.
+Additional information:
+qemu log:
+![image](/uploads/95df79f1cda2531e00906493cc586cda/image.png)
+
+host page size:
+![image](/uploads/1b8f7c6c1c3248b9c68d577105aed65a/image.png)
+
+vm page size:
+![image](/uploads/e11f4013d90ce9cd41966c05aefc56e2/image.png)
+
+dump.c: get_next_page assert:
+![image](/uploads/aa73fc306ff19d6da4ff86fba6860d94/image.png)
+
+The code for the error assert exit is shown above. Here, it will check whether the memory to be dumped is actually aligned with the termination address. It needs to be aligned with the page size of the virtual machine. You can see through gdb that it is 64KiB.
+
+![image](/uploads/7e60743bea0009b1deb97539750630e6/image.png)
+
+After binary search, it was found that a feature of kvm_steal_time was added to arm in version 5.2. Added the following code:
+![image](/uploads/1caf8df4b3599b3c453a11592d0ce033/image.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/959 b/gitlab/issues_text/target_missing/host_missing/accel_missing/959
new file mode 100644
index 00000000..0d00f781
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/959
@@ -0,0 +1,9 @@
+100% CPU utilization when the guest is idle (FreeBSD on M1 Mac)
+Description of problem:
+100% CPU utilization when the guest is idle.
+Steps to reproduce:
+1. Download the FreeBSD qcow2 image and decompress it: https://download.freebsd.org/releases/VM-IMAGES/13.0-RELEASE/aarch64/Latest/
+2. Execute the above command.
+3. The QEMU process consumes 100% CPU. 
+4. 
+![qemu-100-cpu-utilization](/uploads/417fb05ff6d57d64b9849a0dcbbf6eb2/qemu-100-cpu-utilization.png)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/96 b/gitlab/issues_text/target_missing/host_missing/accel_missing/96
new file mode 100644
index 00000000..c5058ca1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/96
@@ -0,0 +1 @@
+qemu-1.5.0 savevm error -95 while writing vm with ceph-rbd as storage-backend
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/960 b/gitlab/issues_text/target_missing/host_missing/accel_missing/960
new file mode 100644
index 00000000..fb6a9d77
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/960
@@ -0,0 +1 @@
+Windows host / win98 guest, i don't understand how to use network
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/962 b/gitlab/issues_text/target_missing/host_missing/accel_missing/962
new file mode 100644
index 00000000..8cae3130
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/962
@@ -0,0 +1,19 @@
+Screenshot images are skewed
+Description of problem:
+1. Start a guest with SPICE
+2. Connect with a SPICE client
+3. Resize screen to a width that is not a multiple of 4 (e. g. 487x956)
+4. Take a screenshot
+
+The screenshot ppm file will contain the actual dimensions in the header, e. g.
+```
+P6
+487 956
+255
+```
+but the image data will contain more than that (e. g. 488 * 956 * 3 bytes).
+As a result, when displaying the image it appears skewed.
+Steps to reproduce:
+See above.
+Additional information:
+I'm not familiar with qemu code nor the pixman library, but I assume that in [this line](https://gitlab.com/qemu-project/qemu/-/blob/bc6ec396d471d9e4aae7e2ff8b72e11da9a97665/ui/console.c#L316) `get_stride` is wrong. Instead, it should write `width*3` bytes.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/963 b/gitlab/issues_text/target_missing/host_missing/accel_missing/963
new file mode 100644
index 00000000..b1336a94
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/963
@@ -0,0 +1 @@
+qemu-7.0.0-rc2/migration/ram.c:1292: possible wrong operator ?
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/965 b/gitlab/issues_text/target_missing/host_missing/accel_missing/965
new file mode 100644
index 00000000..f8960f22
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/965
@@ -0,0 +1 @@
+Creating a NVME disk using qemu in the Host not in the VM
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/967 b/gitlab/issues_text/target_missing/host_missing/accel_missing/967
new file mode 100644
index 00000000..2b351d25
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/967
@@ -0,0 +1,224 @@
+qemu 6.2 user mode memory leak when mmap + munmap is called
+Description of problem:
+Launch a program with qemu user mode emulator,
+If this program calls mmap to allocate 40GB virtual memory and call munmap to free it later, the memory const of qemu user mode emulator grows to a very big value. 
+
+Excepted behavior: qemu-x86_64 costs very less memory after munmap is called.
+Observed behavior: qemu-x86_64 costs around 2.5GiB after munmap is called. Most of the memory is consumed by [heap].
+Steps to reproduce:
+1.Compile this code with g++.
+```shell
+g++ -o main.bin main.cpp
+```
+```cpp
+#include <chrono>
+#include <cstdio>
+#include <sys/types.h>
+#include <unistd.h>
+#include <cstdlib>
+#include <sys/mman.h>
+
+#include <thread>
+
+static constexpr size_t  pageSize = 4096;
+
+int main(){
+	constexpr size_t size = 1024*100*pageSize*1000;
+
+	void* data = mmap(nullptr, size, PROT_NONE,  MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
+	
+	if(data == nullptr){
+		perror("mmap failed");
+		exit(1);
+	}
+
+	int error = munmap(data, size);
+
+	if(error !=0){
+		perror("munmap failed");
+		exit(1);
+	}
+	
+
+	printf("mmap munmap test done\n");
+	while(true){
+		std::this_thread::sleep_for(std::chrono::seconds(10000));
+	}
+	
+	return 0;
+}
+```
+2. run main.bin with qemu-x86_64
+```shell
+$ qemu-x86_64 ./main.bin
+mmap munmap test done
+```
+3. check memory usage by top
+```
+$ top -p `pgrep "qemu"`
+top - 16:00:39 up  6:41,  1 user,  load average: 0.08, 0.12, 0.10
+Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
+%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
+MiB Mem :  15969.1 total,   8249.3 free,   6048.2 used,   1671.5 buff/cache
+MiB Swap:   2048.0 total,   1209.6 free,    838.4 used.   9544.3 avail Mem 
+
+    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                                             
+  38521 jcq       20   0 2634324   2.3g   7840 S   0.0  14.8   0:04.48 qemu-x86_64                                                                                                                         
+```
+
+4. check memory usage by mmap. Heap is 5611ca5e0000-56125d125000, the size of heap is more than 2GiB.
+```shell
+$ cat /proc/38521/maps
+4000000000-4000001000 r--p 00000000 00:35 49812                          /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin
+4000001000-4000002000 r--p 00001000 00:35 49812                          /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin
+4000002000-4000003000 r--p 00002000 00:35 49812                          /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin
+4000003000-4000004000 r--p 00002000 00:35 49812                          /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin
+4000004000-4000005000 rw-p 00003000 00:35 49812                          /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin
+4000005000-4000026000 rw-p 00000000 00:00 0 
+4001005000-4001006000 ---p 00000000 00:00 0 
+4001006000-4001806000 rw-p 00000000 00:00 0 
+4001806000-400183d000 r--p 00000000 08:05 4456513                        /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+400183d000-400183e000 ---p 00000000 00:00 0 
+400183e000-4001840000 r--p 00037000 08:05 4456513                        /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+4001840000-4001842000 rw-p 00039000 08:05 4456513                        /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+4001842000-4001844000 rw-p 00000000 00:00 0 
+4001863000-4001a78000 r--p 00000000 08:05 4456541                        /usr/lib/x86_64-linux-gnu/libc.so.6
+4001a78000-4001a7c000 r--p 00214000 08:05 4456541                        /usr/lib/x86_64-linux-gnu/libc.so.6
+4001a7c000-4001a7e000 rw-p 00218000 08:05 4456541                        /usr/lib/x86_64-linux-gnu/libc.so.6
+4001a7e000-4001a8d000 rw-p 00000000 00:00 0 
+5611c96af000-5611c9734000 r--p 00000000 08:05 4467878                    /usr/bin/qemu-x86_64
+5611c9734000-5611c9885000 r-xp 00085000 08:05 4467878                    /usr/bin/qemu-x86_64
+5611c9885000-5611c9901000 r--p 001d6000 08:05 4467878                    /usr/bin/qemu-x86_64
+5611c9902000-5611c993c000 r--p 00252000 08:05 4467878                    /usr/bin/qemu-x86_64
+5611c993c000-5611c9950000 rw-p 0028c000 08:05 4467878                    /usr/bin/qemu-x86_64
+5611c9950000-5611c996e000 rw-p 00000000 00:00 0 
+5611ca5e0000-56125d125000 rw-p 00000000 00:00 0                          [heap]
+7f2038000000-7f203ffff000 rwxp 00000000 00:00 0 
+7f203ffff000-7f2040000000 ---p 00000000 00:00 0 
+7f2040000000-7f2040021000 rw-p 00000000 00:00 0 
+7f2040021000-7f2044000000 ---p 00000000 00:00 0 
+7f2047def000-7f2047e70000 rw-p 00000000 00:00 0 
+7f2047e70000-7f2047e71000 ---p 00000000 00:00 0 
+7f2047e71000-7f2048676000 rw-p 00000000 00:00 0 
+7f2048676000-7f2048678000 r--p 00000000 08:05 4456538                    /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0
+7f2048678000-7f204867f000 r-xp 00002000 08:05 4456538                    /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0
+7f204867f000-7f2048680000 r--p 00009000 08:05 4456538                    /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0
+7f2048680000-7f2048681000 ---p 0000a000 08:05 4456538                    /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0
+7f2048681000-7f2048682000 r--p 0000a000 08:05 4456538                    /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0
+7f2048682000-7f2048683000 rw-p 0000b000 08:05 4456538                    /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0
+7f2048683000-7f204868d000 r--p 00000000 08:05 4457088                    /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1
+7f204868d000-7f20486ec000 r-xp 0000a000 08:05 4457088                    /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1
+7f20486ec000-7f2048703000 r--p 00069000 08:05 4457088                    /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1
+7f2048703000-7f2048704000 r--p 0007f000 08:05 4457088                    /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1
+7f2048704000-7f2048705000 rw-p 00080000 08:05 4457088                    /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1
+7f2048705000-7f204870d000 r--p 00000000 08:05 4461541                    /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4
+7f204870d000-7f2048720000 r-xp 00008000 08:05 4461541                    /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4
+7f2048720000-7f204874a000 r--p 0001b000 08:05 4461541                    /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4
+7f204874a000-7f204874b000 ---p 00045000 08:05 4461541                    /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4
+7f204874b000-7f204874c000 r--p 00045000 08:05 4461541                    /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4
+7f204874c000-7f204874d000 rw-p 00046000 08:05 4461541                    /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4
+7f204874d000-7f2048757000 r--p 00000000 08:05 4464736                    /usr/lib/x86_64-linux-gnu/libnettle.so.8.4
+7f2048757000-7f204877a000 r-xp 0000a000 08:05 4464736                    /usr/lib/x86_64-linux-gnu/libnettle.so.8.4
+7f204877a000-7f2048790000 r--p 0002d000 08:05 4464736                    /usr/lib/x86_64-linux-gnu/libnettle.so.8.4
+7f2048790000-7f2048792000 r--p 00042000 08:05 4464736                    /usr/lib/x86_64-linux-gnu/libnettle.so.8.4
+7f2048792000-7f2048793000 rw-p 00044000 08:05 4464736                    /usr/lib/x86_64-linux-gnu/libnettle.so.8.4
+7f2048793000-7f2048795000 rw-p 00000000 00:00 0 
+7f2048795000-7f2048798000 r--p 00000000 08:05 4459610                    /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2
+7f2048798000-7f20487a6000 r-xp 00003000 08:05 4459610                    /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2
+7f20487a6000-7f20487aa000 r--p 00011000 08:05 4459610                    /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2
+7f20487aa000-7f20487ab000 ---p 00015000 08:05 4459610                    /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2
+7f20487ab000-7f20487ac000 r--p 00015000 08:05 4459610                    /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2
+7f20487ac000-7f20487ad000 rw-p 00016000 08:05 4459610                    /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2
+7f20487ad000-7f20487be000 r--p 00000000 08:05 4460136                    /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0
+7f20487be000-7f20487f4000 r-xp 00011000 08:05 4460136                    /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0
+7f20487f4000-7f2048952000 r--p 00047000 08:05 4460136                    /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0
+7f2048952000-7f2048956000 r--p 001a5000 08:05 4460136                    /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0
+7f2048956000-7f2048957000 rw-p 001a9000 08:05 4460136                    /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0
+7f2048957000-7f2048959000 r--p 00000000 08:05 4465922                    /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7
+7f2048959000-7f204895d000 r-xp 00002000 08:05 4465922                    /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7
+7f204895d000-7f2048976000 r--p 00006000 08:05 4465922                    /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7
+7f2048976000-7f2048977000 r--p 0001e000 08:05 4465922                    /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7
+7f2048977000-7f2048978000 rw-p 0001f000 08:05 4465922                    /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7
+7f2048978000-7f20489a1000 r--p 00000000 08:05 4459606                    /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0
+7f20489a1000-7f2048a45000 r-xp 00029000 08:05 4459606                    /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0
+7f2048a45000-7f2048a9f000 r--p 000cd000 08:05 4459606                    /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0
+7f2048a9f000-7f2048aa9000 r--p 00126000 08:05 4459606                    /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0
+7f2048aa9000-7f2048ab3000 rw-p 00130000 08:05 4459606                    /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0
+7f2048ab3000-7f2048ab5000 r--p 00000000 08:05 4456747                    /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3
+7f2048ab5000-7f2048b0a000 r-xp 00002000 08:05 4456747                    /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3
+7f2048b0a000-7f2048b27000 r--p 00057000 08:05 4456747                    /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3
+7f2048b27000-7f2048b28000 r--p 00073000 08:05 4456747                    /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3
+7f2048b28000-7f2048b29000 rw-p 00074000 08:05 4456747                    /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3
+7f2048b29000-7f2048b51000 r--p 00000000 08:05 4456541                    /usr/lib/x86_64-linux-gnu/libc.so.6
+7f2048b51000-7f2048ce6000 r-xp 00028000 08:05 4456541                    /usr/lib/x86_64-linux-gnu/libc.so.6
+7f2048ce6000-7f2048d3e000 r--p 001bd000 08:05 4456541                    /usr/lib/x86_64-linux-gnu/libc.so.6
+7f2048d3e000-7f2048d42000 r--p 00214000 08:05 4456541                    /usr/lib/x86_64-linux-gnu/libc.so.6
+7f2048d42000-7f2048d44000 rw-p 00218000 08:05 4456541                    /usr/lib/x86_64-linux-gnu/libc.so.6
+7f2048d44000-7f2048d53000 rw-p 00000000 00:00 0 
+7f2048d53000-7f2048d56000 r--p 00000000 08:05 4457972                    /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
+7f2048d56000-7f2048d6d000 r-xp 00003000 08:05 4457972                    /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
+7f2048d6d000-7f2048d71000 r--p 0001a000 08:05 4457972                    /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
+7f2048d71000-7f2048d72000 r--p 0001d000 08:05 4457972                    /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
+7f2048d72000-7f2048d73000 rw-p 0001e000 08:05 4457972                    /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
+7f2048d73000-7f2048d81000 r--p 00000000 08:05 4456717                    /usr/lib/x86_64-linux-gnu/libm.so.6
+7f2048d81000-7f2048dfd000 r-xp 0000e000 08:05 4456717                    /usr/lib/x86_64-linux-gnu/libm.so.6
+7f2048dfd000-7f2048e58000 r--p 0008a000 08:05 4456717                    /usr/lib/x86_64-linux-gnu/libm.so.6
+7f2048e58000-7f2048e59000 r--p 000e4000 08:05 4456717                    /usr/lib/x86_64-linux-gnu/libm.so.6
+7f2048e59000-7f2048e5a000 rw-p 000e5000 08:05 4456717                    /usr/lib/x86_64-linux-gnu/libm.so.6
+7f2048e5a000-7f2048e8b000 r--p 00000000 08:05 4456481                    /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0
+7f2048e8b000-7f2048fb4000 r-xp 00031000 08:05 4456481                    /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0
+7f2048fb4000-7f2049031000 r--p 0015a000 08:05 4456481                    /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0
+7f2049031000-7f2049041000 r--p 001d6000 08:05 4456481                    /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0
+7f2049041000-7f2049043000 rw-p 001e6000 08:05 4456481                    /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0
+7f2049043000-7f2049045000 rw-p 00000000 00:00 0 
+7f2049045000-7f2049047000 r--p 00000000 08:05 4465165                    /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0
+7f2049047000-7f2049049000 r-xp 00002000 08:05 4465165                    /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0
+7f2049049000-7f204904a000 r--p 00004000 08:05 4465165                    /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0
+7f204904a000-7f204904b000 r--p 00004000 08:05 4465165                    /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0
+7f204904b000-7f204904c000 rw-p 00005000 08:05 4465165                    /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0
+7f204904c000-7f2049069000 r--p 00000000 08:05 4465132                    /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0
+7f2049069000-7f20490f8000 r-xp 0001d000 08:05 4465132                    /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0
+7f20490f8000-7f2049182000 r--p 000ac000 08:05 4465132                    /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0
+7f2049182000-7f2049183000 ---p 00136000 08:05 4465132                    /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0
+7f2049183000-7f2049184000 r--p 00136000 08:05 4465132                    /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0
+7f2049184000-7f2049185000 rw-p 00137000 08:05 4465132                    /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0
+7f2049185000-7f2049186000 rw-p 00000000 00:00 0 
+7f2049186000-7f2049188000 r--p 00000000 08:05 4463546                    /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0
+7f2049188000-7f204918a000 r-xp 00002000 08:05 4463546                    /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0
+7f204918a000-7f204918b000 r--p 00004000 08:05 4463546                    /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0
+7f204918b000-7f204918c000 r--p 00004000 08:05 4463546                    /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0
+7f204918c000-7f204918d000 rw-p 00005000 08:05 4463546                    /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0
+7f20491ac000-7f20491ae000 rw-p 00000000 00:00 0 
+7f20491ae000-7f20491b0000 r--p 00000000 08:05 4456513                    /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+7f20491b0000-7f20491da000 r-xp 00002000 08:05 4456513                    /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+7f20491da000-7f20491e5000 r--p 0002c000 08:05 4456513                    /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+7f20491e6000-7f20491e8000 r--p 00037000 08:05 4456513                    /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+7f20491e8000-7f20491ea000 rw-p 00039000 08:05 4456513                    /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+7fffe17ee000-7fffe1810000 rw-p 00000000 00:00 0                          [stack]
+7fffe19d1000-7fffe19d5000 r--p 00000000 00:00 0                          [vvar]
+7fffe19d5000-7fffe19d7000 r-xp 00000000 00:00 0                          [vdso]
+ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]
+```
+Additional information:
+qemu is installed by ubuntu's apt.
+
+sudo apt install qemu-user
+
+compiler version:
+```
+g++ --version
+g++ (Ubuntu 11.2.0-19ubuntu1) 11.2.0
+Copyright (C) 2021 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+```
+
+libc version:
+```
+ldd --version
+ldd (Ubuntu GLIBC 2.35-0ubuntu3) 2.35
+Copyright (C) 2022 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+Written by Roland McGrath and Ulrich Drepper.
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/968 b/gitlab/issues_text/target_missing/host_missing/accel_missing/968
new file mode 100644
index 00000000..022932ea
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/968
@@ -0,0 +1,95 @@
+QEMU guest agent fails to install if COM+ Application: QEMU Guest Agent VSS Provider not properly uninstalled
+Description of problem:
+QEMU guest agent fails to install if COM+ Application: QEMU Guest Agent VSS Provider not properly uninstalled
+Steps to reproduce:
+1. Install QEMU guest agent
+2. Uninstall QEMU guest agent (in rare cases it didn't uninstall the COM+ component) 
+3. Install QEMU guest agent and get error: `Product: QEMU guest agent -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action RegisterCom, location: cmd.exe, command: /c "C:\Program Files\Qemu-ga\qemu-ga.exe" -s vss-install`
+Additional information:
+1. **Qemu GA is already uninstalled:**
+
+```
+gwmi Win32_Product
+
+
+IdentifyingNumber : {EE3877E4-07B0-41F2-ADB8-B45133DDCE37}
+Name              : Spice Agent 0.10.0-5 (64-bit)
+Vendor            : Red Hat, Inc.
+Version           : 0.10.5
+Caption           : Spice Agent 0.10.0-5 (64-bit)
+
+IdentifyingNumber : {4C49C419-DE39-421B-B0F8-5F0DE1486869}
+Name              : Virtio-win-driver-installer
+Vendor            : Red Hat, Inc.
+Version           : 0.1.189
+Caption           : Virtio-win-driver-installer
+
+IdentifyingNumber : {85F4CBCB-9BBC-4B50-A7D8-E1106771498D}
+Name              : Orca
+Vendor            : Microsoft Corporation
+Version           : 3.1.5299.0000
+Caption           : Orca
+
+IdentifyingNumber : {89F4137D-6C26-4A84-BDB8-2E5A4BB71E00}
+Name              : Microsoft Silverlight
+Vendor            : Microsoft Corporation
+Version           : 5.1.50918.0
+Caption           : Microsoft Silverlight
+
+IdentifyingNumber : {AB392F9F-0C0C-4098-B5BA-B1E84E62D6CE}
+Name              : Icinga 2
+Vendor            : Icinga GmbH
+Version           : 2.11.0
+Caption           : Icinga 2
+```
+
+2. **Extract files from installer and run `qemu-ga.exe -s vss-install`**
+
+It fails with: `QGA VSS Provider is already installed. (Error: 80004004) Vorgang abgebrochen`
+
+3. **Uninstall COM+ component: `qemu-ga.exe -s vss-uninstall`**
+
+`Removing COM+ Application: QEMU Guest Agent VSS Provider`
+
+4. **Now you can install GA**
+
+```
+gwmi Win32_Product
+
+
+IdentifyingNumber : {EE3877E4-07B0-41F2-ADB8-B45133DDCE37}
+Name              : Spice Agent 0.10.0-5 (64-bit)
+Vendor            : Red Hat, Inc.
+Version           : 0.10.5
+Caption           : Spice Agent 0.10.0-5 (64-bit)
+
+IdentifyingNumber : {4C49C419-DE39-421B-B0F8-5F0DE1486869}
+Name              : Virtio-win-driver-installer
+Vendor            : Red Hat, Inc.
+Version           : 0.1.189
+Caption           : Virtio-win-driver-installer
+
+IdentifyingNumber : {85F4CBCB-9BBC-4B50-A7D8-E1106771498D}
+Name              : Orca
+Vendor            : Microsoft Corporation
+Version           : 3.1.5299.0000
+Caption           : Orca
+
+IdentifyingNumber : {99AD6A3C-F854-4E6E-865F-11D4A5E46172}
+Name              : QEMU guest agent
+Vendor            : RedHat
+Version           : 101.1.0
+Caption           : QEMU guest agent
+
+IdentifyingNumber : {89F4137D-6C26-4A84-BDB8-2E5A4BB71E00}
+Name              : Microsoft Silverlight
+Vendor            : Microsoft Corporation
+Version           : 5.1.50918.0
+Caption           : Microsoft Silverlight
+
+IdentifyingNumber : {AB392F9F-0C0C-4098-B5BA-B1E84E62D6CE}
+Name              : Icinga 2
+Vendor            : Icinga GmbH
+Version           : 2.11.0
+Caption           : Icinga 2
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/969 b/gitlab/issues_text/target_missing/host_missing/accel_missing/969
new file mode 100644
index 00000000..1ed29d89
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/969
@@ -0,0 +1 @@
+qemu: Georgian translation
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/97 b/gitlab/issues_text/target_missing/host_missing/accel_missing/97
new file mode 100644
index 00000000..920e4ef1
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/97
@@ -0,0 +1 @@
+-serial tcp should hang up when DTR goes low
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/972 b/gitlab/issues_text/target_missing/host_missing/accel_missing/972
new file mode 100644
index 00000000..7b412d9c
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/972
@@ -0,0 +1 @@
+LSI SCSI Use After Free (CVE-2022-0216)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/974 b/gitlab/issues_text/target_missing/host_missing/accel_missing/974
new file mode 100644
index 00000000..c279f5aa
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/974
@@ -0,0 +1,3 @@
+Enable virtio-9pfs on windows hosts
+Additional information:
+attn: @schoenebeck
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/976 b/gitlab/issues_text/target_missing/host_missing/accel_missing/976
new file mode 100644
index 00000000..d2db3b18
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/976
@@ -0,0 +1 @@
+Qemu - Bridge direct network connection not working
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/978 b/gitlab/issues_text/target_missing/host_missing/accel_missing/978
new file mode 100644
index 00000000..d19b0f0b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/978
@@ -0,0 +1 @@
+Running QEMU with "-vga help" crashes if there is no default VGA card
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/98 b/gitlab/issues_text/target_missing/host_missing/accel_missing/98
new file mode 100644
index 00000000..bdce8bc5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/98
@@ -0,0 +1 @@
+Curses Keyboard Broken On OS X
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/980 b/gitlab/issues_text/target_missing/host_missing/accel_missing/980
new file mode 100644
index 00000000..b872d540
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/980
@@ -0,0 +1,16 @@
+Binary emulation of a Solaris-8-compiled dynamically linked C program gives a bus error immediately on startup when running with qemu-sparc
+Description of problem:
+I am currently trying to use binary emulation to run a dynamically-linked executable C program that was written and compiled on a Solaris 8 VM. However, when I do so, I immediately get a bus error, and I'm not sure what the cause is. Below I'll delineate all of the steps I took to recreate this.
+Steps to reproduce:
+1. Start Solaris 8 VM (this was done via QEMU, actually, and there are no issues here)
+2. Write a simple `.c` program.
+3. Compile that program with `/usr/local/bin/gcc`. The name of the program is `binary_emulation`.
+4. Test program on the VM to ensure functionality.
+5. Stop VM.
+6. Mount `.qcow2` on the Linux host so I can easily extract files from it.
+7. Copy the entire `/` directory off to `~/binary_emulation/target`
+8. Copy `binary_emulation` to a separate directory.
+9. `cd` to `.../qemu/build`
+10. Run `./qemu-sparc -L ~/binary_emulation/target ~/binary_emulation/binary_emulation`
+Additional information:
+#
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/981 b/gitlab/issues_text/target_missing/host_missing/accel_missing/981
new file mode 100644
index 00000000..620d5df4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/981
@@ -0,0 +1,10 @@
+VNC UNIX sockets are not deleted
+Description of problem:
+After exiting QEMU a unix VNC socket file is left behind. Upon termination I would expect it to remove the socket file like it does for example with a monitor unix socket.
+Steps to reproduce:
+```
+   rm -f foo.socket
+   qemu-system-x86_64 -vnc unix:foo.socket
+   # Exit QEMU
+   ls foo.socket
+   ```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/982 b/gitlab/issues_text/target_missing/host_missing/accel_missing/982
new file mode 100644
index 00000000..30572e6e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/982
@@ -0,0 +1,37 @@
+linux-user: --strace incorrectly decodes writev arguments for 64-bit binaries on 32-bit machine
+Description of problem:
+With `--strace`, the arguments to `writev` appear to be decoded incorrectly.
+The syscall still succeeds and has the expected effects.
+Steps to reproduce:
+```
+$ cat main.c
+#include <sys/uio.h>
+
+int main(void) {
+  struct iovec iov;
+  iov.iov_base = "hello, world!\n";
+  iov.iov_len = 14;
+  return writev(1, &iov, 1);
+}
+
+$ aarch64-unknown-linux-gnu-gcc -static -o aarch64-main main.c
+
+$ x86_64-pc-linux-gnu-gcc -static -o x86_64-main main.c
+
+$ i686-pc-linux-gnu-gcc -static -o i686-main main.c
+
+$ ./i686-main
+hello, world!
+
+$ strace ./i686-main |& grep writev
+writev(1, [{iov_base="hello, world!\n", iov_len=14}], 1hello, world!
+
+$ qemu-i386 --strace ./i686-main |& grep writev
+21953 writev(1,0x407ffe54,0x1) = 14
+
+$ qemu-x86_64 --strace ./x86_64-main |& grep writev
+22218 writev(1,(nil),0x407ffcc0) = 14
+
+$ qemu-aarch64 --strace ./aarch64-main |& grep writev
+22523 writev(1,(nil),0x407ffcc8) = 14
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/983 b/gitlab/issues_text/target_missing/host_missing/accel_missing/983
new file mode 100644
index 00000000..23c36b03
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/983
@@ -0,0 +1,8 @@
+Qemu Wiki Database Query Error
+Steps to reproduce:
+1. Access the Qemu Wiki.  https://wiki.qemu.org/Main_Page
+2. Type "serial" in the search bar and hit the enter key.
+3. Crash ensues.
+Additional information:
+Crash info attached.
+[qemu_wiki_bug.txt](/uploads/06fb534ea65c486f72dce14e75c834bd/qemu_wiki_bug.txt)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/985 b/gitlab/issues_text/target_missing/host_missing/accel_missing/985
new file mode 100644
index 00000000..257c5357
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/985
@@ -0,0 +1,59 @@
+pkg_add is working very slow on NetBSD
+Description of problem:
+pkg_add is working very slow, it installs one package in ~30 minutes although network speed is normal.
+Steps to reproduce:
+1. `wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.2/images/NetBSD-9.2-amd64.iso`
+2. `qemu-img create -f qcow2 disk.qcow2 15G`
+3. Install
+```
+qemu-system-x86_64 -m 2048 -enable-kvm \
+  -drive if=virtio,file=disk.qcow2,format=qcow2 \
+  -netdev user,id=mynet0,hostfwd=tcp::7722-:22 \
+  -device e1000,netdev=mynet0 \
+  -cdrom NetBSD-9.2-amd64.iso
+```
+       # Installation steps
+       - 1) Boot Normally
+       - a) Installation messages in English
+       - a) unchanged
+       - a) Install NetBSD to hard disk
+       - b) Yes
+       - a) 15G
+       - a) GPT
+       - a) This is the correct geometry
+       - b) Use default partition sizes
+       - x) Partition sizes are ok
+       - b) Yes
+       - a) Use BIOS console
+       - b) Installation without X11
+       - a) CD-ROM / DVD / install image media
+       - Hit enter to continue
+       - a) configure network (Select defaults here, perform autoconf)
+       - x) Finished configuring
+       - Hit enter to continue
+       - x) Exit Install System
+       - Close QEMU
+4. Run
+```
+ qemu-system-x86_64 -m 2048 \
+  -drive if=virtio,file=disk.qcow2,format=qcow2 \
+  -enable-kvm  \
+  -netdev user,id=mynet0,hostfwd=tcp:127.0.0.1:7722-:22 \
+  -device e1000,netdev=mynet0
+```
+5. Login as root
+6. In NetBSD
+```
+export PKG_PATH="http://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/$(uname -p)/$(uname -r)/All/" && \
+pkg_add pkgin
+
+```
+You should see that each of the package's installation takes ~30 minutes.
+Additional information:
+NetBSD 9.2 is also tested in Debian 11 with 'QEMU 6.2.0' and encountered same slowness. 
+
+NetBSD 7.1 and 8.1 are tested on openSUSE Tumbleweed and encountered same slowness.
+
+OpenBSD's pkg_add is working correctly.
+
+I am not sure if it will help but Virtualbox(at least 6.1) is working correctly.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/986 b/gitlab/issues_text/target_missing/host_missing/accel_missing/986
new file mode 100644
index 00000000..ceee89eb
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/986
@@ -0,0 +1,39 @@
+vpc images are created with bigger virtual size than required
+Description of problem:
+Required virtual size is 895287296, but as qemu-img info reports it is 895426560.
+Steps to reproduce:
+1. qemu-img create -f vpc img1.vpc 895287296
+2. qemu-img info img1.vpc
+Additional information:
+Converting back and forth is not possible as a result
+   ```
+$ qemu-img info openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso 
+image: openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso
+file format: raw
+virtual size: 854 MiB (895287296 bytes)
+disk size: 854 MiB
+
+$ qemu-img create -f vpc img1.vpc 895287296
+Formatting 'img1.vpc', fmt=vpc size=895287296
+
+$ qemu-img convert -n \
+    -f raw openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso \
+    -O vpc img1.vpc
+    
+$ qemu-img compare \
+    -f raw openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso \
+    -F vpc img1.vpc
+Warning: Image size mismatch!
+Images are identical.
+
+$ qemu-img create -f raw img2.raw 895287296
+Formatting 'img2.raw', fmt=raw size=895287296
+
+$ qemu-img convert -n -f vpc img1.vpc -O raw img2.raw
+qemu-img: output file is smaller than input file
+
+$ qemu-img compare \
+    -f raw openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso \
+    -F raw img2.raw
+Content mismatch at offset 0!
+   ```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/987 b/gitlab/issues_text/target_missing/host_missing/accel_missing/987
new file mode 100644
index 00000000..1a9ce9ce
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/987
@@ -0,0 +1,49 @@
+compiling issue
+Description of problem:
+compilation error issue while building for qemu-riscv32-static
+Steps to reproduce:
+1.git clone https://github.com/qemu/qemu.git
+
+2. ./configure --static --disable-system --target-list=riscv32-linux-user
+
+
+issue output:
+```
+/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry':
+(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+[954/960] Compiling C object tests/unit/test-string-output-visitor.p/test-string-output-visitor.c.o
+[955/960] Linking target tests/unit/test-string-output-visitor
+/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry':
+(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+[956/960] Compiling C object tests/unit/test-string-input-visitor.p/test-string-input-visitor.c.o
+[957/960] Linking target tests/unit/test-string-input-visitor
+/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry':
+(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+[958/960] Linking target tests/unit/test-x86-cpuid
+/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry':
+(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+[959/960] Compiling C object tests/unit/test-visitor-serialization.p/test-visitor-serialization.c.o
+[960/960] Linking target tests/unit/test-visitor-serialization
+/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry':
+(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
+make[1]: Leaving directory '/home/sadiq/work/qemu/build'
+changing dir to build for make ""...
+make[1]: Entering directory '/home/sadiq/work/qemu/build'
+  GIT     ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone slirp
+[1/3] Generating qemu-version.h with a custom command (wrapped by meson to capture output)
+make[1]: Leaving directory '/home/sadiq/work/qemu/build'
+```
+
+Any suggestions to resolve the issue would be helpful
+
+Thanks
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/988 b/gitlab/issues_text/target_missing/host_missing/accel_missing/988
new file mode 100644
index 00000000..1100490e
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/988
@@ -0,0 +1 @@
+Cirrus video, graphical corruption, bad fonts
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/989 b/gitlab/issues_text/target_missing/host_missing/accel_missing/989
new file mode 100644
index 00000000..2d35e489
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/989
@@ -0,0 +1,100 @@
+Segmentation fault on Apple M1 inside a docker container
+Description of problem:
+I cannot build a Rust dependency (`regex-syntax`) in a docker container for the platform linux/amd64 using Rancher Desktop (v1.2.1; Kubernetes v1.22.7) on Apple M1 hardware.
+I suppose it is a QEMU issue because I didn't observe it on x86_64 hardware where the exact same docker container was built and executed natively without emulation.
+Moreover, valgrind does not detect an invalid memory access either.
+Steps to reproduce:
+1. `nerdctl build --platform linux/amd64 -t rust-x86_64 .`
+2. `nerdctl run --platform linux/amd64 -it rust-x86_64`
+3. `cargo new hello`
+4. `cd hello`
+5. `echo 'regex-syntax = "0.6.25"' >> Cargo.toml`
+6. `cargo build --release -v`
+Additional information:
+Dockerfile:
+```
+FROM ubuntu:21.10
+
+# Install a basic environment needed for our build tools
+ARG DEBIAN_FRONTEND=noninteractive
+RUN apt -yq update && \
+    apt -yqq install --no-install-recommends curl ca-certificates \
+        build-essential pkg-config libssl-dev llvm-dev liblmdb-dev clang cmake
+
+# Install Rust and Cargo in /opt
+ARG rust_version=1.60.0
+ARG platform=x86_64
+ENV RUSTUP_HOME=/opt/rustup \
+    CARGO_HOME=/opt/cargo \
+    PATH=/opt/cargo/bin:$PATH
+RUN curl --fail https://sh.rustup.rs -sSf \
+        | sh -s -- -y --default-toolchain ${rust_version}-${platform}-unknown-linux-gnu --no-modify-path && \
+    rustup default ${rust_version}-${platform}-unknown-linux-gnu
+```
+
+
+
+Output inside the docker container:
+
+```
+# cargo build --release -v
+    Updating crates.io index
+  Downloaded regex-syntax v0.6.25
+  Downloaded 1 crate (293.3 KB) in 0.84s
+   Compiling regex-syntax v0.6.25
+     Running `rustc --crate-name regex_syntax --edition=2018 /opt/cargo/registry/src/github.com-1ecc6299db9ec823/regex-syntax-0.6.25/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg 'feature="default"' --cfg 'feature="unicode"' --cfg 'feature="unicode-age"' --cfg 'feature="unicode-bool"' --cfg 'feature="unicode-case"' --cfg 'feature="unicode-gencat"' --cfg 'feature="unicode-perl"' --cfg 'feature="unicode-script"' --cfg 'feature="unicode-segment"' -C metadata=fc954162c3ed8ec3 -C extra-filename=-fc954162c3ed8ec3 --out-dir /hello/target/release/deps -L dependency=/hello/target/release/deps --cap-lints allow`
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x4b3d23)[0x400215fd23]
+/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x4005cab520]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-14-rust-1.60.0-stable.so(_ZNK4llvm13AttributeList19addAttributeAtIndexERNS_11LLVMContextEjNS_9AttributeE+0x834)[0x40088d3484]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-14-rust-1.60.0-stable.so(_ZN4llvm8Function19addAttributeAtIndexEjNS_9AttributeE+0x18)[0x40088d2c48]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXs4_NtCsfrnhObXyzQM_18rustc_codegen_llvm3abiINtNtNtCsaEkRwEFRwNk_12rustc_target3abi4call5FnAbiNtNtCs12ixbLjc5mB_12rustc_middle2ty2TyENtB5_12FnAbiLlvmExt16apply_attrs_llfn+0x14d)[0x40033d532d]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXNtCsfrnhObXyzQM_18rustc_codegen_llvm9mono_itemNtNtB4_7context9CodegenCxNtNtNtCsegTyfRY58Oj_17rustc_codegen_ssa6traits7declare16PreDefineMethods12predefine_fn+0x56a)[0x40033bba5a]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x17007c0)[0x40033ac7c0]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23761e6)[0x40040221e6]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x2373a6f)[0x400401fa6f]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23a1e45)[0x400404de45]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXs5_CsfrnhObXyzQM_18rustc_codegen_llvmNtB5_18LlvmCodegenBackendNtNtNtCsegTyfRY58Oj_17rustc_codegen_ssa6traits7backend14CodegenBackend13codegen_crate+0xda)[0x400400e70a]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23544e7)[0x40040004e7]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x233ac88)[0x4003fe6c88]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvMs0_NtCsf5CM6ndXTHU_15rustc_interface7queriesNtB5_7Queries15ongoing_codegen+0xaf)[0x4003fdd02f]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x2308b04)[0x4003fb4b04]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x22ee134)[0x4003f9a134]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23213e9)[0x4003fcd3e9]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/libstd-8d61b92a0a02f53a.so(rust_metadata_std_cd3cf6af28dff6de+0xa7d03)[0x400598fd03]
+/lib/x86_64-linux-gnu/libc.so.6(+0x94947)[0x4005cfd947]
+/lib/x86_64-linux-gnu/libc.so.6(clone+0x44)[0x4005d8da44]
+error: could not compile `regex-syntax`
+
+Caused by:
+  process didn't exit successfully: `rustc --crate-name regex_syntax --edition=2018 /opt/cargo/registry/src/github.com-1ecc6299db9ec823/regex-syntax-0.6.25/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg 'feature="default"' --cfg 'feature="unicode"' --cfg 'feature="unicode-age"' --cfg 'feature="unicode-bool"' --cfg 'feature="unicode-case"' --cfg 'feature="unicode-gencat"' --cfg 'feature="unicode-perl"' --cfg 'feature="unicode-script"' --cfg 'feature="unicode-segment"' -C metadata=fc954162c3ed8ec3 -C extra-filename=-fc954162c3ed8ec3 --out-dir /hello/target/release/deps -L dependency=/hello/target/release/deps --cap-lints allow` (signal: 11, SIGSEGV: invalid memory reference)
+
+# valgrind rustc --crate-name regex_syntax --edition=2018 /opt/cargo/registry/src/github.com-1ecc6299db9ec823/regex-syntax-0.6.25/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg 'feature="default"' --cfg 'feature="unicode"' --cfg 'feature="unicode-age"' --cfg 'feature="unicode-bool"' --cfg 'feature="unicode-case"' --cfg 'feature="unicode-gencat"' --cfg 'feature="unicode-perl"' --cfg 'feature="unicode-script"' --cfg 'feature="unicode-segment"' -C metadata=fc954162c3ed8ec3 -C extra-filename=-fc954162c3ed8ec3 --out-dir /hello/target/release/deps -L dependency=/hello/target/release/deps --cap-lints allow
+==977== Memcheck, a memory error detector
+==977== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
+==977== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
+==977== Command: rustc --crate-name regex_syntax --edition=2018 /opt/cargo/registry/src/github.com-1ecc6299db9ec823/regex-syntax-0.6.25/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg feature="default" --cfg feature="unicode" --cfg feature="unicode-age" --cfg feature="unicode-bool" --cfg feature="unicode-case" --cfg feature="unicode-gencat" --cfg feature="unicode-perl" --cfg feature="unicode-script" --cfg feature="unicode-segment" -C metadata=fc954162c3ed8ec3 -C extra-filename=-fc954162c3ed8ec3 --out-dir /hello/target/release/deps -L dependency=/hello/target/release/deps --cap-lints allow
+==977== 
+{"artifact":"/hello/target/release/deps/regex_syntax-fc954162c3ed8ec3.d","emit":"dep-info"}
+{"artifact":"/hello/target/release/deps/libregex_syntax-fc954162c3ed8ec3.rmeta","emit":"metadata"}
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x4b3d23)[0x400215fd23]
+/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x4005cab520]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-14-rust-1.60.0-stable.so(_ZNK4llvm13AttributeList19addAttributeAtIndexERNS_11LLVMContextEjNS_9AttributeE+0x834)[0x40088d3484]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-14-rust-1.60.0-stable.so(_ZN4llvm8Function19addAttributeAtIndexEjNS_9AttributeE+0x18)[0x40088d2c48]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXs4_NtCsfrnhObXyzQM_18rustc_codegen_llvm3abiINtNtNtCsaEkRwEFRwNk_12rustc_target3abi4call5FnAbiNtNtCs12ixbLjc5mB_12rustc_middle2ty2TyENtB5_12FnAbiLlvmExt16apply_attrs_llfn+0x101)[0x40033d52e1]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXNtCsfrnhObXyzQM_18rustc_codegen_llvm9mono_itemNtNtB4_7context9CodegenCxNtNtNtCsegTyfRY58Oj_17rustc_codegen_ssa6traits7declare16PreDefineMethods12predefine_fn+0x56a)[0x40033bba5a]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x17007c0)[0x40033ac7c0]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23761e6)[0x40040221e6]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x2373a6f)[0x400401fa6f]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23a1e45)[0x400404de45]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXs5_CsfrnhObXyzQM_18rustc_codegen_llvmNtB5_18LlvmCodegenBackendNtNtNtCsegTyfRY58Oj_17rustc_codegen_ssa6traits7backend14CodegenBackend13codegen_crate+0xda)[0x400400e70a]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23544e7)[0x40040004e7]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x233ac88)[0x4003fe6c88]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvMs0_NtCsf5CM6ndXTHU_15rustc_interface7queriesNtB5_7Queries15ongoing_codegen+0xaf)[0x4003fdd02f]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x2308b04)[0x4003fb4b04]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x22ee134)[0x4003f9a134]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23213e9)[0x4003fcd3e9]
+/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/libstd-8d61b92a0a02f53a.so(rust_metadata_std_cd3cf6af28dff6de+0xa7d03)[0x400598fd03]
+/lib/x86_64-linux-gnu/libc.so.6(+0x94947)[0x4005cfd947]
+/lib/x86_64-linux-gnu/libc.so.6(clone+0x44)[0x4005d8da44]
+Segmentation fault (core dumped)
+```
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/99 b/gitlab/issues_text/target_missing/host_missing/accel_missing/99
new file mode 100644
index 00000000..b48878e5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/99
@@ -0,0 +1 @@
+Feature Request:  Please add TCG OPAL 2 emulation support to the virtio disk emulation
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/991 b/gitlab/issues_text/target_missing/host_missing/accel_missing/991
new file mode 100644
index 00000000..881a1de2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/991
@@ -0,0 +1,6 @@
+Failed to get write lock on qcow2 image from a sigkilled vm
+Additional information:
+That feature will solve an issue i have with qemu that i muself created 
+by sending a `kill -9` to a qemu VM after it stopped accepting vnc connections.
+I can't use the same qcow2 image currently. Maybe a reboot will fix it, but i did 
+check `lslocks` and there was no lock on it there.
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/994 b/gitlab/issues_text/target_missing/host_missing/accel_missing/994
new file mode 100644
index 00000000..6d380855
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/994
@@ -0,0 +1,5 @@
+7.0.0-rc4 doesn't launch on Windows
+Description of problem:
+The program immediately exits, without even printing version information (or anything).
+Steps to reproduce:
+1. Run the command above
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/996 b/gitlab/issues_text/target_missing/host_missing/accel_missing/996
new file mode 100644
index 00000000..8a3a71c3
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/996
@@ -0,0 +1,26 @@
+Alt-TAB minimizes a full screen key-grabbed SDL window
+Description of problem:
+I was made aware of a case where a qemu seems to respond to a keyboard event `Alt+Tab` that isn't meant for it.
+
+When running in "SDL + full-screen + keys being grabbed by the guest" (see steps to reproduce below) one would expect `Alt+Tab` to do nothing on the host. But it does minimize the qemu window.
+
+This does not happen if:
+- using GTK instead of SDL
+- not being in full-screen mode
+
+No error message or warning appears while this happens.
+Steps to reproduce:
+You do not need and workload to run inside qemu for this
+
+1. `qemu-system-x86_64 -display sdl`
+2. Get your key grabbed: `click inside the window`
+3. Go full screen: `Alt+Ctrl+F`
+4. Press `Alt+Tab`
+5. Expected: nothing, Experienced: window minimizes
+
+Note: it even is reproducible if running the qemu binary from another system through SSH with X11 forwarding.
+
+P.S.
+I haven't had a chance yet to try qemu 7.0 from git, but will in a bit.
+It is easy enough to reproduce that I considered it worth filing without.
+For the start it would be great to hear if others see that as well or not. In case of the latter we'd have to compare library versions (currently I use sdl 2.0.20+dfsg-2build1).
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/997 b/gitlab/issues_text/target_missing/host_missing/accel_missing/997
new file mode 100644
index 00000000..1c19b47b
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/997
@@ -0,0 +1,17 @@
+Iothread is stuck at 100% CPU usage with virtio-scsi on QEMU 7.0.0
+Description of problem:
+Starting with QEMU 7.0.0, the iothread associated attached to a virtio-scsi controller is stuck at 100% CPU usage. Bisected to: https://gitlab.com/qemu-project/qemu/-/commit/826cc32423db2a99d184dbf4f507c737d7e7a4ae
+
+- Works as expected without the iothread
+- No issue with virtio-blk + iothread
+- Same behavior regardless of io=threads/native/io_uring
+- Same behavior with default vs increased queue count
+- The issue is triggered when the guest OS initializes the virtio driver
+Steps to reproduce:
+1. Add virtio-scsi controller with iothread
+2. Boot VM
+3. Check per-thread CPU usage such as in htop
+Additional information:
+[fedora.log](/uploads/776fbf8e5b823d0ab326946684ef9022/fedora.log)
+
+[fedora.xml](/uploads/54879e5adfb227ddef79d382e86fc608/fedora.xml)
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/999 b/gitlab/issues_text/target_missing/host_missing/accel_missing/999
new file mode 100644
index 00000000..279b7459
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/999
@@ -0,0 +1,6 @@
+Update ipv4 function calls
+Description of problem:
+Qemu still uses obsolete ipv4 functions, it would be fine to convert them to their ipv6 counterparts:
+* gethostbyname
+* inet_aton
+* inet_ntoa
diff --git a/gitlab/issues_text/target_missing/host_ppc/accel_TCG/1422 b/gitlab/issues_text/target_missing/host_ppc/accel_TCG/1422
new file mode 100644
index 00000000..da215159
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_ppc/accel_TCG/1422
@@ -0,0 +1,15 @@
+/wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/tcg/ppc/tcg-target.c.inc:1882:9: error: couldn't allocate output register for constraint 'Q'
+Description of problem:
+Qemu 7.2.0 doesn't build on powerpc64le.
+Steps to reproduce:
+Build qemu.
+Additional information:
+```
+FAILED: libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o 
+cc -m64 -mlittle-endian -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -Iqapi -Itrace -Iui -Iui/shader -I/usr/local/include/pixman-1 -I/usr/local/include -I/wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -iquote . -iquote /wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0 -iquote /wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/include -iquote /wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/tcg/ppc -pthread -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-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -Wno-gnu-variable-sized-type-not-at-end -fstack-protector-strong -O2 -pipe -fstack-protector-strong -fno-strict-aliasing '-DPREFIX=\""/usr/local\""' -fPIE -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o -MF libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o.d -o libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o -c ../tcg/tcg.c
+In file included from ../tcg/tcg.c:432:
+/wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/tcg/ppc/tcg-target.c.inc:1882:9: error: couldn't allocate output register for constraint 'Q'
+    asm("mr  %%r6, %1\n\t"
+        ^
+1 error generated.
+```
diff --git a/gitlab/issues_text/target_missing/host_ppc/accel_missing/1765 b/gitlab/issues_text/target_missing/host_ppc/accel_missing/1765
new file mode 100644
index 00000000..e31b3831
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_ppc/accel_missing/1765
@@ -0,0 +1,95 @@
+Linux kernel fails to boot on powernv machines with nvme device on s390x hosts
+Description of problem:
+When running a powernv guest with nvme device on a s390x host, the guest linux kernel fails to boot with the following panic:
+
+```
+nvme nvme0: pci function 0002:01:00.0
+nvme 0002:01:00.0: enabling device (0100 -> 0102)
+nvme nvme0: 1/0/0 default/read/poll queues
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+nvme nvme0: invalid id 0 completed on queue 0
+BUG: Kernel NULL pointer dereference on read at 0x00000008
+Faulting instruction address: 0xc0000000000c02ec
+Oops: Kernel access of bad area, sig: 11 [#1]
+LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
+Modules linked in: nvme powernv_flash(+) rtc_opal ibmpowernv mtd nvme_core
+CPU: 0 PID: 100 Comm: pb-console Not tainted 5.10.50-openpower1 #2
+NIP:  c0000000000c02ec LR: c00000000050d5dc CTR: c00000000024a2d0
+REGS: c00000003ffdfa00 TRAP: 0300   Not tainted  (5.10.50-openpower1)
+MSR:  9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>  CR: 24000402  XER: 20000000
+CFAR: c00000000000f3c0 DAR: 0000000000000008 DSISR: 40000000 IRQMASK: 1 
+GPR00: c0000000000ba058 c00000003ffdfc90 c00000000180db00 0000000000000008 
+GPR04: 000000000000000a 0000000000000000 c000000002740210 c00000000274e218 
+GPR08: c00000000183be00 0000000080000000 0000000000000000 c0080000003ba798 
+GPR12: c00000000024a2d0 c000000001a30000 0000000000000000 0000000000000100 
+GPR16: 0000000000000004 0000000000000020 0000000000000100 c00000000bbe8080 
+GPR20: 0000000000000028 c000000001830100 0000000000000001 0000000000000000 
+GPR24: c000000001831a00 c000000001410c00 00000000ffff9097 0000000000400040 
+GPR28: 000000000000000a 000000000000000a 0000000000000008 0000000000000000 
+NIP [c0000000000c02ec] __arch_spin_trylock+0x4/0x24
+LR [c00000000050d5dc] _raw_spin_lock_irqsave+0x2c/0x78
+Call Trace:
+[c00000003ffdfc90] [c00000003ffdfcc0] 0xc00000003ffdfcc0 (unreliable)
+[c00000003ffdfcd0] [c0000000000ba058] complete+0x24/0x64
+[c00000003ffdfd10] [c00000000024a2f8] blk_end_sync_rq+0x28/0x3c
+[c00000003ffdfd30] [c00000000024f44c] __blk_mq_end_request+0x134/0x160
+[c00000003ffdfd70] [c0080000003b481c] nvme_complete_rq+0xcc/0x13c [nvme_core]
+[c00000003ffdfda0] [c0080000000a1078] nvme_pci_complete_rq+0x78/0x108 [nvme]
+[c00000003ffdfdd0] [c00000000024de38] blk_done_softirq+0xc0/0xd0
+[c00000003ffdfe30] [c00000000050da20] __do_softirq+0x238/0x28c
+[c00000003ffdff20] [c0000000000875d4] __irq_exit_rcu+0x80/0xc8
+[c00000003ffdff50] [c000000000087844] irq_exit+0x18/0x30
+[c00000003ffdff70] [c000000000011c4c] __do_irq+0x80/0xa0
+[c00000003ffdff90] [c00000000001d7a4] call_do_irq+0x14/0x24
+[c00000000bff3960] [c000000000011d20] do_IRQ+0xb4/0xbc
+[c00000000bff39f0] [c000000000008fac] hardware_interrupt_common_virt+0x1ac/0x1b0
+--- interrupt: 500 at arch_local_irq_restore+0xac/0xe8
+    LR = __raw_spin_unlock_irq+0x34/0x40
+[c00000000bff3cf0] [0000000000000000] 0x0 (unreliable)
+[c00000000bff3d20] [c0000000000a8344] __raw_spin_unlock_irq+0x34/0x40
+[c00000000bff3d50] [c0000000000a84b0] finish_task_switch+0x160/0x228
+[c00000000bff3df0] [c0000000000aa3d0] schedule_tail+0x20/0x8c
+[c00000000bff3e20] [c00000000000cb50] ret_from_fork+0x4/0x54
+Instruction dump:
+a14d0b7a 7da96b78 2f8a0000 419e0010 39400000 b14d0b7a 7c0004ac a1490b78 
+394affff b1490b78 4e800020 812d0000 <7d401829> 2c0a0000 40c20010 7d20192d 
+---[ end trace 6b7a11c45e4fc465 ]---
+
+Kernel panic - not syncing: Fatal exception
+Rebooting in 30 seconds..
+```
+
+The issue has been noticed while running the avocado tests on a s390x host:
+
+```
+make check-venv
+./tests/venv/bin/avocado run tests/avocado/boot_linux_console.py:BootLinuxConsole.test_ppc_powernv8
+```
+
+But they can also be reproduced manually:
+Steps to reproduce:
+1. wget https://github.com/open-power/op-build/releases/download/v2.7/zImage.epapr
+2. ./qemu-system-ppc64 -nographic -M powernv8 -kernel zImage.epapr -append "console=tty0 console=hvc0" -device pcie-pci-bridge,id=bridge1,bus=pcie.1,addr=0x0 -device nvme,bus=pcie.2,addr=0x0,serial=1234
diff --git a/gitlab/issues_text/target_missing/host_ppc/accel_missing/1861 b/gitlab/issues_text/target_missing/host_ppc/accel_missing/1861
new file mode 100644
index 00000000..38b36684
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_ppc/accel_missing/1861
@@ -0,0 +1,29 @@
+qemu 8.1.0 fails to build with ppc64l and musl libc
+Description of problem:
+qemu 8.1.0 fails to build on alpine linux ppc64le:
+
+```
+ninja: job failed: gcc -m64 -mlittle-endian -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui/shader -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -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 -Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -isystem /home/ncopa/aports/community/qemu/src/qemu-8.1.0/linux-headers -isystem linux-headers -iquote . -iquote /home/ncopa/aports/community/qemu/src/qemu-8.1.0 -iquote /home/ncopa/aports/community/qemu/src/qemu-8.1.0/include -iquote /home/ncopa/aports/community/qemu/src/qemu-8.1.0/host/include/ppc64 -iquote /home/ncopa/aports/community/qemu/src/qemu-8.1.0/host/include/generic -iquote /home/ncopa/aports/community/qemu/src/qemu-8.1.0/tcg/ppc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -Os -fstack-clash-protection -Wformat -Werror=format-security -O2 -fPIE -pthread -MD -MQ libqemuutil.a.p/util_cpuinfo-ppc.c.o -MF libqemuutil.a.p/util_cpuinfo-ppc.c.o.d -o libqemuutil.a.p/util_cpuinfo-ppc.c.o -c ../util/cpuinfo-ppc.c
+../util/cpuinfo-ppc.c: In function 'cpuinfo_init':
+../util/cpuinfo-ppc.c:33:18: error: 'PPC_FEATURE2_ARCH_3_1' undeclared (first use in this function); did you mean 'PPC_FEATURE2_ARCH_3_00'?
+   33 |     if (hwcap2 & PPC_FEATURE2_ARCH_3_1) {
+      |                  ^~~~~~~~~~~~~~~~~~~~~
+      |                  PPC_FEATURE2_ARCH_3_00
+../util/cpuinfo-ppc.c:33:18: note: each undeclared identifier is reported only once for each function it appears in
+../util/cpuinfo-ppc.c:43:18: error: 'PPC_FEATURE2_HAS_ISEL' undeclared (first use in this function); did you mean 'PPC_FEATURE_HAS_VSX'?
+   43 |     if (hwcap2 & PPC_FEATURE2_HAS_ISEL) {
+      |                  ^~~~~~~~~~~~~~~~~~~~~
+      |                  PPC_FEATURE_HAS_VSX
+../util/cpuinfo-ppc.c:56:26: error: 'PPC_FEATURE2_HAS_VEC_CRYPTO' undeclared (first use in this function); did you mean 'PPC_FEATURE2_VEC_CRYPTO'?
+   56 |             if (hwcap2 & PPC_FEATURE2_HAS_VEC_CRYPTO) {
+      |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
+      |                          PPC_FEATURE2_VEC_CRYPTO
+ninja: subcommand failed
+make: *** [Makefile:162: run-ninja] Error 1
+```
+Steps to reproduce:
+Build qemu 8.1.0 on alpine linux ppc64le.
+Additional information:
+Likely introduced by 623d7e3551a6fc5693c06ea938c60fe281b52e27
+
+Explicit `#include <asm/cputable.h>` fixes the `PPC_FEATURE2_ARCH_3_1` case but not the other two.
diff --git a/gitlab/issues_text/target_missing/host_riscv/accel_TCG/1921 b/gitlab/issues_text/target_missing/host_riscv/accel_TCG/1921
new file mode 100644
index 00000000..7431aabc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_riscv/accel_TCG/1921
@@ -0,0 +1,30 @@
+qemu-system-x86_64 segfaults in iotlb_to_section() on riscv64
+Description of problem:
+QEMU segfaults when booting up the Arch Linux x86_64 installation ISO. The ISO could be downloaded from https://geo.mirror.pkgbuild.com/iso/2023.09.01/archlinux-2023.09.01-x86_64.iso or any other Arch Linux mirrors.
+
+The crash often happens after "Probing EDD...". It's more reliably reproducible with higher `-smp` numbers, and may hang with "rcu_preempt detected stalls" without the -smp option.
+Additional information:
+I have reproduced the same issues with different RISC-V hardware, including SG2042 and TH1520.
+
+Errors:
+```
+qemu-system-x86_64: ../qemu-8.1.1/softmmu/physmem.c:2419: iotlb_to_section: Assertion `section_index < d->map.sections_nb' failed.
+```
+
+Backtrace:
+```
+#0  0x0000003fa74f0ece in __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
+#1  0x0000003fa74f0f0e in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
+#2  0x0000003fa74ba912 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
+#3  0x0000003fa74aa164 in __GI_abort () at abort.c:79
+#4  0x0000003fa74b54a4 in __assert_fail_base
+    (fmt=0x3fa7594c10 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x2ae1de0458 "section_index < d->map.sections_nb", file=file@entry=0x2ae1ddf980 "../qemu-8.1.1/softmmu/physmem.c", line=line@entry=2419, function=function@entry=0x2ae1f05f20 <__PRETTY_FUNCTION__.11> "iotlb_to_section") at assert.c:92
+#5  0x0000003fa74b54f8 in __assert_fail (assertion=0x2ae1de0458 "section_index < d->map.sections_nb", file=0x2ae1ddf980 "../qemu-8.1.1/softmmu/physmem.c", line=2419, function=0x2ae1f05f20 <__PRETTY_FUNCTION__.11> "iotlb_to_section") at assert.c:101
+#6  0x0000002ae1b69788 in iotlb_to_section () at ../qemu-8.1.1/softmmu/physmem.c:2419
+#7  0x0000002ae1b9d774 in io_writex () at ../qemu-8.1.1/accel/tcg/cputlb.c:1432
+#8  0x0000002ae1b9d924 in do_st_mmio_leN () at ../qemu-8.1.1/accel/tcg/cputlb.c:2755
+#9  0x0000002ae1ba127c in do_st_4 () at ../qemu-8.1.1/accel/tcg/cputlb.c:2921
+#10 do_st4_mmu () at ../qemu-8.1.1/accel/tcg/cputlb.c:3006
+#11 0x0000003f600dd7ec in code_gen_buffer ()
+#12 0x5f085e2755518600 in  ()
+```
diff --git a/gitlab/issues_text/target_missing/host_riscv/accel_TCG/2711 b/gitlab/issues_text/target_missing/host_riscv/accel_TCG/2711
new file mode 100644
index 00000000..a1e0efa0
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_riscv/accel_TCG/2711
@@ -0,0 +1 @@
+TSTEQ lowering and optimization bug
diff --git a/gitlab/issues_text/target_missing/host_riscv/accel_missing/2041 b/gitlab/issues_text/target_missing/host_riscv/accel_missing/2041
new file mode 100644
index 00000000..ed86b480
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_riscv/accel_missing/2041
@@ -0,0 +1,27 @@
+RISC-V KVM build error with Alpine Linux
+Description of problem:
+Native build of qemu fails on alpine linux riscv64.
+Steps to reproduce:
+1. install alpine on riscv or set up a container with qemu-riscv64
+2. build qemu 8.1.3 from source
+3.
+Additional information:
+```
+kvm.c:(.text+0xc50): undefined reference to `strerrorname_np'                                       
+/usr/lib/gcc/riscv64-alpine-linux-musl/13.2.1/../../../../riscv64-alpine-linux-musl/bin/ld: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm.c.o: in function `.L0 ':                                           
+kvm.c:(.text+0xcda): undefined reference to `strerrorname_np'
+/usr/lib/gcc/riscv64-alpine-linux-musl/13.2.1/../../../../riscv64-alpine-linux-musl/bin/ld: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm.c.o: in function `.L111':                                          
+kvm.c:(.text+0xd02): undefined reference to `strerrorname_np'  
+```
+
+The `strerrorname_np` is a GNU specific non-portable function (that what _np stands for). This is the only place where it is use in the entire qemu codebase:
+```
+$ rg strerrorname_np
+target/riscv/kvm/kvm-cpu.c
+837:                             strerrorname_np(errno));
+899:                     strerrorname_np(errno));
+909:                     strerrorname_np(errno));
+932:                         strerrorname_np(errno));
+```
+
+Seems like other places uses `strerror(errno)`.
diff --git a/gitlab/issues_text/target_missing/host_riscv/accel_missing/2598 b/gitlab/issues_text/target_missing/host_riscv/accel_missing/2598
new file mode 100644
index 00000000..703ff532
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_riscv/accel_missing/2598
@@ -0,0 +1 @@
+linux-user on riscv64 host: Unable to find a guest_base to satisfy all guest address mapping requirements 00000000-ffffffff
diff --git a/gitlab/issues_text/target_missing/host_s390/accel_missing/1934 b/gitlab/issues_text/target_missing/host_s390/accel_missing/1934
new file mode 100644
index 00000000..9a5f8f15
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_s390/accel_missing/1934
@@ -0,0 +1,24 @@
+Build failure on s390x with Clang 17 due to int128 alignment used in `__sync_` operations
+Description of problem:
+We experienced this downstream, but filing this here since the code still seems to be the same in git.
+
+https://reviews.llvm.org/D143813 introduced this warning since, according to the description, `__int128`
+needs to be 8-byte aligned on s390 but the code in `host/include/generic/host/atomic128-ldst.h` unconditionally uses 16-byte alignment.
+
+The output is:
+
+```
+In file included from ../accel/tcg/cputlb.c:32:
+In file included from /builddir/build/BUILD/qemu-8.1.0/include/exec/helper-proto-common.h:10:
+In file included from /builddir/build/BUILD/qemu-8.1.0/include/qemu/atomic128.h:62:
+/builddir/build/BUILD/qemu-8.1.0/host/include/generic/host/atomic128-ldst.h:68:15: error: __sync builtin operation MUST have natural alignment (consider using __atomic). [-Werror,-Wsync-alignment]
+   68 |     } while (!__sync_bool_compare_and_swap_16(ptr_align, old, new.i));
+      |               ^
+In file included from ../accel/tcg/cputlb.c:32:
+In file included from /builddir/build/BUILD/qemu-8.1.0/include/exec/helper-proto-common.h:10:
+In file included from /builddir/build/BUILD/qemu-8.1.0/include/qemu/atomic128.h:61:
+/builddir/build/BUILD/qemu-8.1.0/host/include/generic/host/atomic128-cas.h:36:11: error: __sync builtin operation MUST have natural alignment (consider using __atomic). [-Werror,-Wsync-alignment]
+   36 |     r.i = __sync_val_compare_and_swap_16(ptr_align, c.i, n.i);
+      |           ^
+2 errors generated.
+```
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_HAX/1084 b/gitlab/issues_text/target_missing/host_x86/accel_HAX/1084
new file mode 100644
index 00000000..7df38adc
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_HAX/1084
@@ -0,0 +1 @@
+Qemu -  VCPU shutdown request error
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_HVF/2115 b/gitlab/issues_text/target_missing/host_x86/accel_HVF/2115
new file mode 100644
index 00000000..04a67807
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_HVF/2115
@@ -0,0 +1,54 @@
+HVF accelerator crash in vmx_write_mem (mmu_gva_to_gpa)
+Description of problem:
+During the installation of Windows 2000 from CD-ROM (image), following disk initialization/formatting, a base operating system is copied to the (virtual) hard disk and the system is rebooted. During the start from hard disk to resume installation, QEMU crashes.
+
+This crash occurs whether using installation media for Windows 2000 Professional or Windows 2000 Advanced Server. It can be reproduced before any product key or Terminal Services licensing information is entered.
+
+Undertaking the same process with TCG accelerator on the same host, the issue is not observed.
+
+Unlike in #1603, `-pdpe1gb` does not work around this crash.
+Steps to reproduce:
+1. In HVF QEMU accelerator on x86_64 macOS, start up a pc-i440fx virtual machine w/ Windows 2000 (SP4) installation media.
+2. Initialize/format a (qcow2-powered) hard drive as NTFS when prompted.
+3. Allow the system to reboot.
+Additional information:
+Crash stderr:
+```
+vmx_write_mem: mmu_gva_to_gpa bfd391f0 failed
+<pid> Abort trap: 6
+```
+(it's always "bfd391f0")
+
+Stacktrace:
+```
+0   libsystem_kernel.dylib              0x7ff8164771e2 __pthread_kill + 10
+1   libsystem_pthread.dylib             0x7ff8164aeee6 pthread_kill + 263
+2   libsystem_c.dylib                   0x7ff8163d5b45 abort + 123
+3   qemu-system-x86_64                     0x106a3d98d vmx_write_mem + 190
+4   qemu-system-x86_64                     0x106a39f1c write_val_ext + 88
+5   qemu-system-x86_64                     0x106a3cb1c exec_movs_single + 92
+6   qemu-system-x86_64                     0x106a3c412 exec_movs + 61
+7   qemu-system-x86_64                     0x106a3b35e exec_instruction + 48
+8   qemu-system-x86_64                     0x106a36707 hvf_vcpu_exec + 2411
+9   qemu-system-x86_64                     0x106b16532 hvf_cpu_thread_fn + 283
+10  qemu-system-x86_64                     0x106c752fc qemu_thread_start + 130
+11  libsystem_pthread.dylib             0x7ff8164af1d3 _pthread_start + 125
+12  libsystem_pthread.dylib             0x7ff8164aabd3 thread_start + 15
+```
+
+Registers at crash:
+```
+rax: 0x0000000000000000  rbx: 0x000070000322d000  rcx: 0x000070000322cc58  rdx: 0x0000000000000000
+rdi: 0x0000000000001103  rsi: 0x0000000000000006  rbp: 0x000070000322cc80  rsp: 0x000070000322cc58
+ r8: 0x00007ff859b93d08   r9: 0x0000000000000000  r10: 0x0000000000000000  r11: 0x0000000000000246
+r12: 0x0000000000001103  r13: 0x0000000000000000  r14: 0x0000000000000006  r15: 0x0000000000000016
+rip: 0x00007ff8164771e2  rfl: 0x0000000000000246  cr2: 0x0000000000000000
+```
+
+OS response:  
+**Exception Type:** EXC_CRASH (SIGABRT)  
+**Exception Codes:** 0x0000000000000000, 0x0000000000000000  
+**Termination Reason:** Namespace SIGNAL, Code 6 Abort trap: 6  
+**Logical CPU:** 0  
+**Error Code:** 0x02000148  
+**Trap Number:** 133
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_KVM/1928 b/gitlab/issues_text/target_missing/host_x86/accel_KVM/1928
new file mode 100644
index 00000000..e3d15d71
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_KVM/1928
@@ -0,0 +1,65 @@
+Run testpmd in VM on virtio-net cause qemu crash/assert
+Description of problem:
+Run testpmd in VM on virtio-net device(vhost-user), dpdk virtio pmd as backend. Qemu crash as:
+```
+qemu-system-x86_64: ../accel/kvm/kvm-all.c:1717: kvm_irqchip_commit_routes: Assertion `ret == 0' failed.
+2023-10-11 04:44:51.058+0000: shutting down, reason=crashed
+```
+If revert this commit `1680542862 virtio-pci: add support for configure interrupt  <Cindy Lu>`, no issue observed.
+And previous hash `cd336e8346 virtio-mmio: add support for configure interrupt  <Cindy Lu>` also tested fine.
+Steps to reproduce:
+1. Run dpdk-testpmd as vhost-user backend in HV.
+```
+build/app/dpdk-testpmd -a 0000:00:00.0  -l 0-3 -n 4 --vdev 'net_vhost0,iface=/tmp/vfe-net0,queues=4'
+```
+2. Prepare virtio device inside VM
+
+```
+ifconfig eth1 down 
+echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
+mount -t hugetlbfs nodev /mnt/huge
+modprobe uio
+
+insmod dpdk-kmods/linux/igb_uio/igb_uio.ko
+
+dpdk/usertools/dpdk-devbind.py --bind=igb_uio 00:06.0 
+```
+3. Run testpmd inside VM
+
+```
+dpdk/build/app/dpdk-testpmd -a 00:06.0  -- --txd=128 --rxd=128 --txq=4 --rxq=4 --nb-cores=1 --forward-mode=txonly --stats-period=1 
+```
+4. QEMU crashed
+Additional information:
+Testpmd is working on polling mode, so no VQ interrupt enable. Not sure about config interrupt. 
+
+[dpdk.log.txt](/uploads/d98d6eb959f16c24fc4ebfefbc56b98b/dpdk.log.txt)
+```
+#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
+#1  0x00007fab56c7ddb5 in __GI_abort () at abort.c:79
+#2  0x00007fab56c7dc89 in __assert_fail_base (fmt=0x7fab56de65f8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x5611b5df95e3 "ret == 0", 
+    file=0x5611b5df9202 "../accel/kvm/kvm-all.c", line=1717, function=<optimized out>) at assert.c:92
+#3  0x00007fab56c8ba76 in __GI___assert_fail (assertion=0x5611b5df95e3 "ret == 0", file=0x5611b5df9202 "../accel/kvm/kvm-all.c", line=1717, 
+    function=0x5611b5df9fd0 <__PRETTY_FUNCTION__.37261> "kvm_irqchip_commit_routes") at assert.c:101
+#4  0x00005611b5a5094b in kvm_irqchip_commit_routes (s=0x5611b7ba2150) at ../accel/kvm/kvm-all.c:1717
+#5  0x00005611b573d00a in virtio_pci_one_vector_unmask (proxy=0x5611b8d6b460, queue_no=4294967295, vector=0, msg=..., n=0x5611b8d73a10) at ../hw/virtio/virtio-pci.c:980
+#6  0x00005611b573d276 in virtio_pci_vector_unmask (dev=0x5611b8d6b460, vector=0, msg=...) at ../hw/virtio/virtio-pci.c:1045
+#7  0x00005611b567eb78 in msix_fire_vector_notifier (dev=0x5611b8d6b460, vector=0, is_masked=false) at ../hw/pci/msix.c:118
+#8  0x00005611b567ebe9 in msix_handle_mask_update (dev=0x5611b8d6b460, vector=0, was_masked=true) at ../hw/pci/msix.c:131
+#9  0x00005611b567efe3 in msix_table_mmio_write (opaque=0x5611b8d6b460, addr=12, val=0, size=4) at ../hw/pci/msix.c:222
+#10 0x00005611b59ae141 in memory_region_write_accessor (mr=0x5611b8d6ba90, addr=12, value=0x7fab3b7fd348, size=4, shift=0, mask=4294967295, attrs=...) at ../softmmu/memory.c:493
+#11 0x00005611b59ae37c in access_with_adjusted_size (addr=12, value=0x7fab3b7fd348, size=4, access_size_min=1, access_size_max=4, 
+    access_fn=0x5611b59ae04f <memory_region_write_accessor>, mr=0x5611b8d6ba90, attrs=...) at ../softmmu/memory.c:555
+#12 0x00005611b59b1470 in memory_region_dispatch_write (mr=0x5611b8d6ba90, addr=12, data=0, op=MO_32, attrs=...) at ../softmmu/memory.c:1515
+#13 0x00005611b59bef55 in flatview_write_continue (fv=0x5611b7ea2860, addr=4273815564, attrs=..., ptr=0x7fab5d980028, len=4, addr1=12, l=4, mr=0x5611b8d6ba90)
+    at ../softmmu/physmem.c:2825
+#14 0x00005611b59bf0b8 in flatview_write (fv=0x5611b7ea2860, addr=4273815564, attrs=..., buf=0x7fab5d980028, len=4) at ../softmmu/physmem.c:2867
+#15 0x00005611b59bf46a in address_space_write (as=0x5611b6752f80 <address_space_memory>, addr=4273815564, attrs=..., buf=0x7fab5d980028, len=4) at ../softmmu/physmem.c:2963
+#16 0x00005611b59bf4d7 in address_space_rw (as=0x5611b6752f80 <address_space_memory>, addr=4273815564, attrs=..., buf=0x7fab5d980028, len=4, is_write=true)
+    at ../softmmu/physmem.c:2973
+#17 0x00005611b5a53435 in kvm_cpu_exec (cpu=0x5611b7e4b5f0) at ../accel/kvm/kvm-all.c:2900
+#18 0x00005611b5a560c6 in kvm_vcpu_thread_fn (arg=0x5611b7e4b5f0) at ../accel/kvm/kvm-accel-ops.c:51
+#19 0x00005611b5c42e9b in qemu_thread_start (args=0x5611b7e537d0) at ../util/qemu-thread-posix.c:505
+#20 0x00007fab580d814a in start_thread (arg=<optimized out>) at pthread_create.c:479
+#21 0x00007fab56d58dc3 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
+```
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_missing/1891 b/gitlab/issues_text/target_missing/host_x86/accel_missing/1891
new file mode 100644
index 00000000..16b4addf
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_missing/1891
@@ -0,0 +1,48 @@
+qemu 8.1.0 breaks gvt-g + qemu-ui-gtk w gl=on (black screen, qemu: eglCreateImageKHR failed)
+Description of problem:
+As of 8.1.0, qemu-ui-gtk renders a black window with the error `qemu: eglCreateImageKHR failed` repeatedly appearing in the command line.
+
+
+#
+Steps to reproduce:
+1. enable kernel modules, set parameters etc.
+2. create vgpu
+     `echo "$GVT_GUID" > "/sys/devices/pci0000:00/0000:00:02.0/mdev_supported_types/i915-GVTg_V4_2/create"`
+3. launch VM
+4. wait
+
+Instructions (a small part of which I wrote by trial and error) for the setup are on the [Arch Wiki](https://wiki.archlinux.org/title/Intel_GVT-g).
+
+#
+Additional information:
+Windows is installed directly to a second SSD, I dual-boot it.  
+I've been using this exact VM, from libvirt, for almost two years.  
+relevant sections:
+```
+    <hostdev mode="subsystem" type="mdev" managed="no" model="vfio-pci" display="off">
+      <source>
+        <address uuid="$GVT_GUID"/>
+      </source>
+    </hostdev>
+  </devices>
+  <qemu:commandline>
+    <qemu:arg value="-display"/>
+    <qemu:arg value="gtk,gl=on,zoom-to-fit=off"/>
+    <qemu:env name="DISPLAY" value=":0.0"/>
+  </qemu:commandline>
+  <qemu:override>
+    <qemu:device alias="hostdev0">
+      <qemu:frontend>
+        <qemu:property name="x-igd-opregion" type="bool" value="true"/>
+        <qemu:property name="driver" type="string" value="vfio-pci-nohotplug"/>
+        <qemu:property name="ramfb" type="bool" value="true"/>
+        <qemu:property name="display" type="string" value="on"/>
+        <qemu:property name="romfile" type="string" value="/home/user/VM/vbios_gvt_uefi.rom"/>
+      </qemu:frontend>
+    </qemu:device>
+  </qemu:override>
+```
+
+The patched vBIOS necessary to use DMA-BUF with OVMF is linked there too, but its [successors](https://github.com/patmagauran/i915ovmfPkg) doesn't work either.
+
+#
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_missing/1895 b/gitlab/issues_text/target_missing/host_x86/accel_missing/1895
new file mode 100644
index 00000000..7d234926
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_missing/1895
@@ -0,0 +1,146 @@
+qemu-user uses fixed stack size and ignores RLIMIT_STACK request, causing some guest programs to crash
+Description of problem:
+When compiling a source file, g++ segmentation faults in qemu-user riscv64. But it doesn't fail on real riscv64 boards.
+
+We discovered this problem while compiling nodejs-lts-hydrogen. The source file has been reduced to 5KB by cvise.
+Steps to reproduce:
+1. Setup an Arch Linux riscv64 qemu-user container: https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-Development-Environment
+2. Start the container: `sudo systemd-nspawn -D ./archriscv -a -U`
+3. Install gcc inside the container: `sudo pacman -Syu gcc`
+4. Run the following command in the container: `g++ -S testcase.i -w -fpreprocessed -o /dev/null` [testcase.i](/uploads/d63b1867a458a240ef0d90c760d76bc7/testcase.i)
+5. g++ segmentation faults: `g++: internal compiler error: Segmentation fault signal terminated program cc1plus`
+Additional information:
+Initially I thought this is a g++ bug. But I can't reproduce this bug on real riscv64 hardware.
+
+g++ version: g++ (GCC) 13.2.1 20230801
+
+testcase.i:
+
+```c++
+namespace std {
+typedef long unsigned size_t;
+inline namespace __cxx11 {}
+} // namespace std
+typedef char uint8_t;
+namespace std {
+template <typename _Default, typename, template <typename> class>
+struct __detector {
+  using type = _Default;
+};
+template <typename _Default, template <typename> class _Op>
+using __detected_or = __detector<_Default, void, _Op>;
+template <typename _Default, template <typename> class _Op>
+using __detected_or_t = typename __detected_or<_Default, _Op>::type;
+template <typename> class allocator;
+namespace __cxx11 {
+template <typename _CharT, typename = _CharT, typename = allocator<_CharT>>
+class basic_string;
+}
+typedef basic_string<char> string;
+} // namespace std
+template <typename _Tp> class __new_allocator {
+public:
+  typedef _Tp value_type;
+};
+namespace std {
+template <typename _Tp> using __allocator_base = __new_allocator<_Tp>;
+template <typename _Tp> class allocator : public __allocator_base<_Tp> {};
+template <class _E> class initializer_list {
+  typedef size_t size_type;
+  typedef _E *iterator;
+  iterator _M_array;
+  size_type _M_len;
+};
+struct __allocator_traits_base {
+  template <typename _Tp> using __pointer = typename _Tp::const_pointer;
+};
+template <typename _Alloc> struct allocator_traits : __allocator_traits_base {
+  typedef typename _Alloc::value_type value_type;
+  using pointer = __detected_or_t<value_type, __pointer>;
+};
+} // namespace std
+namespace __gnu_cxx {
+template <typename _Alloc>
+struct __alloc_traits : std::allocator_traits<_Alloc> {};
+} // namespace __gnu_cxx
+namespace std {
+namespace __cxx11 {
+template <typename _CharT, typename, typename _Alloc> class basic_string {
+  typedef __gnu_cxx::__alloc_traits<_Alloc> _Alloc_traits;
+
+public:
+  typedef typename _Alloc_traits::pointer pointer;
+  struct _Alloc_hider {
+    _Alloc_hider(pointer, _Alloc);
+  } _M_dataplus;
+  pointer _M_local_data();
+  basic_string(_CharT *, _Alloc __a = _Alloc())
+      : _M_dataplus(_M_local_data(), __a) {}
+  ~basic_string();
+};
+} // namespace __cxx11
+} // namespace std
+namespace v8 {
+class StartupData {};
+} // namespace v8
+namespace std {
+template <typename _Tp> class vector {
+public:
+  typedef _Tp value_type;
+  vector(initializer_list<value_type>);
+};
+namespace builtins {
+struct CodeCacheInfo {
+  string id;
+  vector<uint8_t> data;
+};
+} // namespace builtins
+struct IsolateDataSerializeInfo {};
+struct EnvSerializeInfo {};
+struct SnapshotMetadata {
+  enum { kDefault } type;
+  string node_version;
+  string node_arch;
+  string v8_cache_version_tag;
+};
+struct SnapshotData {
+  enum { kNotOwned } data_ownership;
+  SnapshotMetadata metadata;
+  v8::StartupData v8_snapshot_blob_data;
+  IsolateDataSerializeInfo isolate_data_info;
+  EnvSerializeInfo env_info;
+  vector<builtins::CodeCacheInfo> code_cache;
+} snapshot_data{
+    SnapshotData::kNotOwned,
+    SnapshotMetadata::kDefault,
+    "",
+    "",
+    "",
+    {},
+    {},
+    {},
+    {{""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}}};
+} // namespace std
+```
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_missing/1912 b/gitlab/issues_text/target_missing/host_x86/accel_missing/1912
new file mode 100644
index 00000000..64c0380f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_missing/1912
@@ -0,0 +1 @@
+linux-user: (recursive) segfault when built with -static -disable-pie
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_missing/1916 b/gitlab/issues_text/target_missing/host_x86/accel_missing/1916
new file mode 100644
index 00000000..4cea7ed4
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_missing/1916
@@ -0,0 +1,28 @@
+qemu-fixed-text-console.device not found error when using display set to anything but SDL
+Description of problem:
+When attempting to launch QEmu from the command line using any display option aside from `sdl`, QEmu fails to launch with this error message:
+
+```plaintext
+Unexpected error in object_property_find_err() at ../qom/object.c:1314:
+qemu: Property 'qemu-fixed-text-console.device' not found
+Aborted
+```
+
+This error is almost nonexistent when searching online. There is a mention of it in this chain of messages on the mailing list from about a week ago, but it doesn't seem to discuss any kind of way to remedy it. Link: https://www.mail-archive.com/qemu-devel@nongnu.org/msg988630.html
+
+I came across this issue because I was attempting to launch QEmu in other display modes, because for some reason if I launch with the `-display sdl` option, QEmu successfully starts up but then the display is black the majority of the time with some very brief flickers of the OS, and mouse/keyboard input don't seem to be correctly handled, making it unusable. So when trying to see if another display configuration could help me be able to resolve the black screen issue, I learned that I can't even launch with any other configuration due to the fixed text console not being found.
+
+I have been using these simple arguments for running the configure script:
+
+```plaintext
+../configure --enable-debug --target-list=x86_64-softmmu
+```
+
+I tried using the configure flags `--enable-gtk` and `--enable-sdl` to see if they made any difference, but it seemed like they did not (neither the black screen issue or the fixed text console device error changed) so I just started leaving them off.
+Steps to reproduce:
+1. Run configure script
+2. Run make to build QEmu
+3. Launch QEmu using `-display gtk` or with no `-display` option specified at all (also tried: `./qemu-system-x86_64 -m 6G -smp 2 -hda ../../vdisk1.qcow2`) and the error occurred.
+4. Error occurs
+Additional information:
+I am new to QEmu and am trying to use it as part of a college project, so if anyone wants to respond, please let me know if I can give any additional information at all that could help.
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_missing/2200 b/gitlab/issues_text/target_missing/host_x86/accel_missing/2200
new file mode 100644
index 00000000..e1486f9f
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_missing/2200
@@ -0,0 +1,9 @@
+QEMU OpenGL of SDL and GTK not working properly on Windows hosts
+Description of problem:
+QEMU OpenGL of SDL and GTK not working properly on Windows hosts.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_missing/host_x86/accel_missing/2405 b/gitlab/issues_text/target_missing/host_x86/accel_missing/2405
new file mode 100644
index 00000000..933b9dc2
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_x86/accel_missing/2405
@@ -0,0 +1,16 @@
+Qemu on Windows fails to parse absolute file path in -acpitable switch
+Description of problem:
+I expect qemu-system-x86_64.exe to navigate to the path provided with -acpitable switch and to try to parse it. Instead, Qemu prints: "can't open file C: No such file or directory" if provided with absolute path. Qemu thinks "C:" itself is a file with acpi table.
+
+However, Qemu correctly processes files with relative path. If I run this command to try to parse file COPYING bundled in default qemu build:
+
+`qemu-system-x86_64.exe -acpitable "file=copying"`
+
+Qemu says: `qemu-system-x86_64.exe: -acpitable file=copying: warning: ACPI table has wrong length, header says 1313284128, actual size 17992 bytes`
+
+Then it proceeds to boot BIOS, as usual.
+Steps to reproduce:
+1. Run `qemu-system-x86_64.exe -acpitable "file=C:\temp\temp.txt"`
+2. Experience "can't open file C: No such file or directory" error message returning you to the command prompt. No BIOS screen.
+3. Run `qemu-system-x86_64.exe -acpitable "file=copying"` 
+4. Experience insignificant warning and then a normal BIOS screen.
diff --git a/gitlab/issues_text/target_nios2/host_missing/accel_TCG/1258 b/gitlab/issues_text/target_nios2/host_missing/accel_TCG/1258
new file mode 100644
index 00000000..1666a927
--- /dev/null
+++ b/gitlab/issues_text/target_nios2/host_missing/accel_TCG/1258
@@ -0,0 +1 @@
+nios2 system tests are exiting early and not showing an error
diff --git a/gitlab/issues_text/target_nios2/host_missing/accel_missing/261 b/gitlab/issues_text/target_nios2/host_missing/accel_missing/261
new file mode 100644
index 00000000..9c3b62ba
--- /dev/null
+++ b/gitlab/issues_text/target_nios2/host_missing/accel_missing/261
@@ -0,0 +1 @@
+broken signal handling in nios2 user-mode emulation
diff --git a/gitlab/issues_text/target_nios2/host_s390/accel_missing/1693 b/gitlab/issues_text/target_nios2/host_s390/accel_missing/1693
new file mode 100644
index 00000000..4c6c4aac
--- /dev/null
+++ b/gitlab/issues_text/target_nios2/host_s390/accel_missing/1693
@@ -0,0 +1,29 @@
+qemu-system-nios2 not working on s390x (big endian) hosts
+Description of problem:
+qemu-system-nios2 fails to boot a Linux kernel on s390x hosts.
+Steps to reproduce:
+1. wget https://qemu-advcal.gitlab.io/qac-best-of-multiarch/download/day14.tar.xz
+2. tar -xJf day14.tar.xz 
+3. cd day14/
+4. qemu-system-nios2 -nographic -kernel vmlinux.elf
+Additional information:
+When running with "-d in_asm", it seems like the code initially starts executing ok, but in one of the early translation blocks, there is a difference when comparing the log with a run from a x86 host:
+
+```
+IN: fdt_check_header
+0xc81afd48:  ldw	r3,0(r4)
+0xc81afd4c:  srli	r5,r3,24
+0xc81afd50:  slli	r2,r3,24
+0xc81afd54:  or	r2,r2,r5
+0xc81afd58:  slli	r5,r3,8
+0xc81afd5c:  srli	r3,r3,8
+0xc81afd60:  andhi	r5,r5,255
+0xc81afd64:  andi	r3,r3,65280
+0xc81afd68:  or	r2,r2,r5
+0xc81afd6c:  or	r2,r2,r3
+0xc81afd70:  movhi	r3,53262
+0xc81afd74:  addi	r3,r3,-275
+0xc81afd78:  bne	r2,r3,0xc81afde8
+```
+
+On the x86 host, the branch at the end is not taken, while on the s390x host, the branch is taken.
diff --git a/gitlab/issues_text/target_openrisc/host_missing/accel_TCG/1051 b/gitlab/issues_text/target_openrisc/host_missing/accel_TCG/1051
new file mode 100644
index 00000000..ad6a0013
--- /dev/null
+++ b/gitlab/issues_text/target_openrisc/host_missing/accel_TCG/1051
@@ -0,0 +1 @@
+or1k tcg SIGILL
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_KVM/748 b/gitlab/issues_text/target_ppc/host_missing/accel_KVM/748
new file mode 100644
index 00000000..6b734df7
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_KVM/748
@@ -0,0 +1 @@
+Enable postcopy migration for mixed Hugepage backed KVM guests and improve handling of dirty-page tracking by QEMU/KVM
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_KVM/809 b/gitlab/issues_text/target_ppc/host_missing/accel_KVM/809
new file mode 100644
index 00000000..991d8ace
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_KVM/809
@@ -0,0 +1 @@
+ppc cpu_interrupt_exittb kvm check is inverted
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1536 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1536
new file mode 100644
index 00000000..62628e88
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1536
@@ -0,0 +1,16 @@
+Test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le)
+Description of problem:
+Some of the test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le).
+Steps to reproduce:
+1. Download the vsx_mask_extract_runnable_test_030723.c test program from https://gist.githubusercontent.com/johnplatts/db0e9f6683e85e9288fde5c031b3c0e5/raw/ccfb8170f3e613398750830451eebb362875493d/vsx_mask_extract_runnable_test_030723.c.
+2. Install the ppc64 gcc cross-compiler and required libraries, which can be done using the ```sudo apt install build-essential gdb-multiarch g++-12-powerpc64-linux-gnu binutils-powerpc64-linux-gnu binutils-powerpc64-linux-gnu-dbg libc6-ppc64-cross libstdc++6-ppc64-cross``` command on Ubuntu 22.04.
+3. Compile the vsx_mask_extract_runnable_test_030723.c test program downloaded in step 1 using the ```powerpc64-linux-gnu-gcc-12``` cross-compiler with the ```-mcpu=power10``` option.
+4. Execute the program compiled in step 3 using the ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu qemu-ppc64 -cpu power10 ./vsx_mask_extract_runnable_test_030723``` command.
+
+The issue can also be reproduced by compiling Google Highway and running its unit tests as follows:
+1. Clone the Google Highway git repository by running the ```git clone https://github.com/google/highway.git google_highway``` command.
+2. Create a ```hwy_ppcbe10_build``` directory inside of the ```google_highway``` directory created in step #1.
+3. In the ```hwy_ppc10be_build``` directory created in the previous step, execute the following commands:
+   - ```CC=powerpc64-linux-gnu-gcc-12 CXX=powerpc64-linux-gnu-g++-12 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CXX_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CROSSCOMPILING=true -DCMAKE_CROSSCOMPILING_EMULATOR='/usr/local/bin/qemu-ppc64;-cpu;power10' -DCMAKE_C_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824' -DCMAKE_CXX_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824'```
+   - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu make```
+   - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ctest -j```
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1634 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1634
new file mode 100644
index 00000000..18bc1d27
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1634
@@ -0,0 +1,18 @@
+[8.0.0] Broken snapshot replay support on PowerPC
+Description of problem:
+QEMU 8.0.0 can no longer replay snapshots on PowerPC e500mc (Book-E) architecture. The issue is caused by https://gitlab.com/qemu-project/qemu/-/commit/c4b075318eb1e87de5fc942e6b987694a0e677e1, reverting this commit solves the issue.
+Steps to reproduce:
+1. Run bare metal example from the attachment with the first command-line to create snapshot.
+2. Run bare metal example from the attachment with the second command-line to replay snapshot.
+Additional information:
+Any e500mc example would do really. I was unable to find a prebuilt Linux distribution, thus just wrote a minimal sample that prints hello world to UART: [ppc-e500.zip](/uploads/f9328c4b8355a92877d784661aa69fa4/ppc-e500.zip)
+
+Log output:
+
+```
+% qemu-system-ppc -cpu e500mc -M ppce500 -m 128M -net none -icount 1,rr=record,rrfile=main.bin,rrsnapshot=init -drive file=empty.qcow2,if=none,id=rr -display none -kernel hello.elf -serial stdio
+Hello world
+qemu-system-ppc: terminating on signal 2 from pid 4505 (<unknown process>)
+% qemu-system-ppc -cpu e500mc -M ppce500 -m 128M -net none -icount 1,rr=replay,rrfile=main.bin,rrsnapshot=init -drive file=empty.qcow2,if=none,id=rr -display none -kernel hello.elf -serial stdio
+qemu-system-ppc: Missing random event in the replay log
+```
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1726 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1726
new file mode 100644
index 00000000..0f274735
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1726
@@ -0,0 +1,97 @@
+qemu-system-ppc64 option -smp 2 broken with commit 20b6643324a79860dcdfe811ffe4a79942bca21e
+Description of problem:
+I was trying to boot rhel9 image with upstream qemu-system-ppc64 -smp 2 option and observed a segfault (qemu crash).
+After doing a git bisect, I found the first bad commit which introduced this issue is below:
+```
+[qemu]# git bisect good
+20b6643324a79860dcdfe811ffe4a79942bca21e is the first bad commit
+commit 20b6643324a79860dcdfe811ffe4a79942bca21e
+Author: Richard Henderson <richard.henderson@linaro.org>
+Date:   Mon Dec 5 17:45:02 2022 -0600
+
+    tcg/ppc: Reorg goto_tb implementation
+    
+    The old ppc64 implementation replaces 2 or 4 insns, which leaves a race
+    condition in which a thread could be stopped at a PC in the middle of
+    the sequence, and when restarted does not see the complete address
+    computation and branches to nowhere.
+    
+    The new implemetation replaces only one insn, swapping between
+    
+            b       <dest>
+    and
+            mtctr   r31
+    
+    falling through to a general-case indirect branch.
+    
+    Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
+    Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
+
+ tcg/ppc/tcg-target.c.inc | 152 +++++++++++++----------------------------------
+ tcg/ppc/tcg-target.h     |   3 +-
+ 2 files changed, 41 insertions(+), 114 deletions(-)
+[qemu]# 
+```
+Steps to reproduce:
+1. Run the qemu command line mentioned
+2. Wait for the qemu to crash.
+Additional information:
+git bisect log:
+```
+[root@ltcden6-lp2 qemu]# git bisect log
+git bisect start
+# status: waiting for both good and bad commits
+# bad: [b455ce4c2f300c8ba47cba7232dd03261368a4cb] Merge tag 'q800-for-8.1-pull-request' of https://github.com/vivier/qemu-m68k into staging
+git bisect bad b455ce4c2f300c8ba47cba7232dd03261368a4cb
+# status: waiting for good commit(s), bad commit known
+# good: [b247dba067bf2808de6395ff09ff0cb220ed7c95] tests/avocado: add explicit timeout for ppc64le TCG tests
+git bisect good b247dba067bf2808de6395ff09ff0cb220ed7c95
+# bad: [3db629f03e8caf39526cd0415dac16a6a6484107] Merge tag 'pull-request-2023-02-27' of https://gitlab.com/thuth/qemu into staging
+git bisect bad 3db629f03e8caf39526cd0415dac16a6a6484107
+# good: [777fa06376ce0249c76d0d852e8f7ed103a63864] Merge tag 'pull-loongarch-20221202' of https://gitlab.com/gaosong/qemu into staging
+git bisect good 777fa06376ce0249c76d0d852e8f7ed103a63864
+# bad: [c66ffcd5358ba88e93e1ffb15ae42ca52dab12a8] target/riscv/cpu: set cpu->cfg in register_cpu_props()
+git bisect bad c66ffcd5358ba88e93e1ffb15ae42ca52dab12a8
+# good: [bc92f261519d5c77c70cf2ebcf0a3b9a414d82d0] hw/intc: sifive_plic: Fix the pending register range check
+git bisect good bc92f261519d5c77c70cf2ebcf0a3b9a414d82d0
+# good: [aa96ab7c9df59c615ca82b49c9062819e0a1c287] Merge tag 'pull-request-2023-01-09' of https://gitlab.com/thuth/qemu into staging
+git bisect good aa96ab7c9df59c615ca82b49c9062819e0a1c287
+# good: [a8d6abe1292e1db1ad9be5b2b124b9c01bcda094] Merge tag 'mips-20230113' of https://github.com/philmd/qemu into staging
+git bisect good a8d6abe1292e1db1ad9be5b2b124b9c01bcda094
+# bad: [ef4f031fab7b070816454949a1b6b6c7aa3cf503] Merge tag 'pull-tcg-20230117' of https://gitlab.com/rth7680/qemu into staging
+git bisect bad ef4f031fab7b070816454949a1b6b6c7aa3cf503
+# good: [0fe1c98da9d9abb8e5dc4a67c7e3bcf19aad1e85] tcg: Change tb_target_set_jmp_target arguments
+git bisect good 0fe1c98da9d9abb8e5dc4a67c7e3bcf19aad1e85
+# good: [701ed34833f53880ba38bde09b0846d01fc16d66] Merge tag 'pull-request-2023-01-18' of https://gitlab.com/thuth/qemu into staging
+git bisect good 701ed34833f53880ba38bde09b0846d01fc16d66
+# bad: [20b6643324a79860dcdfe811ffe4a79942bca21e] tcg/ppc: Reorg goto_tb implementation
+git bisect bad 20b6643324a79860dcdfe811ffe4a79942bca21e
+# good: [90c0fee3a28b25d23081b3c435762cadde813ec4] tcg: Always define tb_target_set_jmp_target
+git bisect good 90c0fee3a28b25d23081b3c435762cadde813ec4
+# good: [d59d83a1c38869b1e1a4f957eb939aaa8a342721] tcg/aarch64: Reorg goto_tb implementation
+git bisect good d59d83a1c38869b1e1a4f957eb939aaa8a342721
+# first bad commit: [20b6643324a79860dcdfe811ffe4a79942bca21e] tcg/ppc: Reorg goto_tb implementation
+```
+
+gdb backtrace output:
+
+```
+Program terminated with signal SIGSEGV, Segmentation fault.
+#0  0x00007fff4becfa8c in ?? ()
+[Current thread is 1 (Thread 0x7fff9e80e780 (LWP 31456))]
+(gdb) bt
+#0  0x00007fff4becfa8c in  ()
+#1  0x00007fff5682d044 in code_gen_buffer ()
+#2  0x000000013e3224ec in cpu_tb_exec (cpu=cpu@entry=0x16144fb70, itb=itb@entry=0x7fff5682cf00 <code_gen_buffer+111332932>, tb_exit=tb_exit@entry=0x7fff9e80d7f0) at ../accel/tcg/cpu-exec.c:438
+#3  0x000000013e322ad4 in cpu_loop_exec_tb (tb_exit=0x7fff9e80d7f0, last_tb=<synthetic pointer>, pc=13835058055286981664, tb=0x7fff5682cf00 <code_gen_buffer+111332932>, cpu=<optimized out>)
+    at ../accel/tcg/cpu-exec.c:871
+#4  cpu_exec_loop (cpu=cpu@entry=0x16144fb70, sc=sc@entry=0x7fff9e80d940) at ../accel/tcg/cpu-exec.c:981
+#5  0x000000013e3234e8 in cpu_exec_setjmp (cpu=cpu@entry=0x16144fb70, sc=sc@entry=0x7fff9e80d940) at ../accel/tcg/cpu-exec.c:1012
+#6  0x000000013e323e64 in cpu_exec (cpu=0x16144fb70) at ../accel/tcg/cpu-exec.c:1038
+#7  0x000000013e35bba0 in tcg_cpus_exec (cpu=0x16144fb70) at ../accel/tcg/tcg-accel-ops.c:69
+#8  0x000000013e35bd90 in mttcg_cpu_thread_fn (arg=0x16144fb70) at ../accel/tcg/tcg-accel-ops-mttcg.c:95
+#9  0x000000013e57193c in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:505
+#10 0x00007fffa12aa0f0 in start_thread (arg=0x7fff9e80e780) at pthread_create.c:443
+#11 0x00007fffa1352ec8 in clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107
+```
+For any further additional information contact me at : anushree.mathur@linux.vnet.ibm.com
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1750 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1750
new file mode 100644
index 00000000..b38b2c4c
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1750
@@ -0,0 +1 @@
+target/ppc/translate.c - ppc_fixup_cpu and VSX - is still necessary?
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1769 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1769
new file mode 100644
index 00000000..ba1c1036
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1769
@@ -0,0 +1 @@
+RHEL9 ppc64le Power9 pseries guest userspace segfaults
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1795 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1795
new file mode 100644
index 00000000..cf1b89b3
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/1795
@@ -0,0 +1,8 @@
+PPC: not honouring single stepping through branches and skips a nip
+Description of problem:
+When debugging in MacsBug, tracing/stepping over any branches (e.g. blt, bgt) will land on the instruction immediately passed the expected address. It appears that branches will execute the target instruction then single step to the next instruction in one go, instead of single stepping to the target instruction.
+
+For example, if a blt should land on 13371234, stepping over the branch will land on 13371238. The instruction at 13371234 still executes, but this is not the behaviour on a baremetal Mac OS system.
+Additional information:
+A <a href="https://i.imgur.com/f6dguMt.png">screenshot</a> before the branch.
+A <a href="https://imgur.com/WoVDtN7.png">screenshot<a/> after pressing 't' to step over the branch. Note that the PC is now 1E36CAB8 instead of the expected 1E36CAB4.
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/2097 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/2097
new file mode 100644
index 00000000..cdf5c21e
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/2097
@@ -0,0 +1 @@
+qtest timeouts on cross-i686-tci job
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/212 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/212
new file mode 100644
index 00000000..262ea3f8
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/212
@@ -0,0 +1 @@
+ppc64 TCG application crashes
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/2523 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/2523
new file mode 100644
index 00000000..9179ad8d
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/2523
@@ -0,0 +1,20 @@
+[9.0.2] PPC: snapshot replay freeze on PowerPC
+Description of problem:
+Qemu 9.0.2 cannot replay snapshots on PowerPC e500mc (Book-E) architecture. When I try to do this, the program freezes.
+Steps to reproduce:
+1. Run bare metal example from the attachment with the first command-line to create snapshot. Then end it using ctrl+c.
+2. Run bare metal example from the attachment with the second command-line to replay snapshot. Running will freeze, use ctrl+c.
+Additional information:
+e500mc example that prints Hello World: [ppc-e500.zip](/uploads/ef9ce53abc3f17490d4894c041956038/ppc-e500.zip)
+
+Log output:
+```
+% qemu-system-ppc -cpu e500  -M ppce500 -kernel hello.elf -display none -serial stdio -icount 1,rr=record,rrfile=main.bin,rrsnapshot=init -drive file=empty.qcow2,if=none,id=rr
+Hello world
+qemu-system-ppc: terminating on signal 2
+% qemu-system-ppc -cpu e500  -M ppce500 -kernel hello.elf -display none -serial stdio -icount 1,rr=replay,rrfile=main.bin,rrsnapshot=init -drive file=empty.qcow2,if=none,id=rr
+qemu-system-ppc: terminating on signal 2
+qemu-system-ppc: Playback shouldn't have to iowait (insn total 0/68 left, event 4 is EVENT_INSTRUCTION)
+zsh: IOT instruction (core dumped)  qemu-system-ppc -cpu e500 -M ppce500 -kernel hello.elf -display none -serial
+```
+`Playback shouldn't have to iowait` error caused by 1f881ea4a444ef36a8b6907b0b82be4b3af253a2 commit, see https://gitlab.com/qemu-project/qemu/-/issues/2524
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/312 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/312
new file mode 100644
index 00000000..731b4b5e
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/312
@@ -0,0 +1 @@
+QEMU emulation of fmadds instruction on powerpc64le is buggy
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/356 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/356
new file mode 100644
index 00000000..636d9f37
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/356
@@ -0,0 +1 @@
+qemu linux-user doesn't translate host/target data for iovec I/O
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/390 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/390
new file mode 100644
index 00000000..c0aa4c24
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/390
@@ -0,0 +1 @@
+target/ppc: atomic path of Load Quadword instruction require address with write permission
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/588 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/588
new file mode 100644
index 00000000..fa8435c4
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/588
@@ -0,0 +1,65 @@
+ppc64le: fatal: Tried to call a TRAP
+Description of problem:
+`qemu: fatal: Tried to call a TRAP` occurs while running the:
+
+`/etc/ca-certificates/update.d/jks-keystore` script which is part of the package `ca-certificates-java` that is installed as a dependency of `openjdk-11-jdk`
+
+```
+Unknown privilege violation (03)
+NIP 0000004012db12b0   LR 0000004002a4335c CTR 0000004012db1280 XER 0000000000000000 CPU#1
+MSR 9000000102806901 HID0 0000000000000000  HF 9000000002806001 iidx 6 didx 6
+TB 00000538 2314542730558
+GPR00 ffffffbffcc22660 00000040033dd940 0000004002d92f00 00000040033de9a0
+GPR04 0000000000000000 0000000000002000 0000000000000000 0000000000000000
+GPR08 0000004002df2f00 0000004002df3460 0000000000000001 0000000000000000
+GPR12 0000004012db1280 00000040033e88f0 0000004001b87410 0000000000000000
+GPR16 0000004001872000 0000004012db12a4 0000004012db12ac 0000004012db12d0
+GPR20 0000004012db12d8 00000000000003d8 0000004004014e20 00000040040151f8
+GPR24 0000004002dc39f8 00000040033df9a0 0000004004014e10 0000004004014dd0
+GPR28 0000004002df3470 0000004012db1280 0000004002df4600 00000040033dd940
+CR 24884400  [ E  G  L  L  G  G  -  -  ]             RES 00000040033de9a0
+qemu: fatal: Tried to call a TRAP
+
+NIP 0000004013342588   LR 0000004013340d84 CTR 0000004013340c8c XER 0000000000000000 CPU#1
+MSR 9000000102806901 HID0 0000000000000000  HF 9000000002806001 iidx 6 didx 6
+TB 00000539 2317026761994
+GPR00 0000000000000001 00000040033df9d0 0000004013340c00 00000000fff7ad68
+GPR04 00000000fff7ad68 000000404d235860 0000000000000105 0000000000000000
+GPR08 0000000100013f10 0000000000000000 0000000000000008 00000040033cfa60
+GPR12 000000010003cd10 00000040033e88f0 000000404d204303 00000040033dfac0
+GPR16 0000004004016000 00000000fff7ad68 00000040033dfb88 0000000100001808
+GPR20 0000004012db8b90 00000040033dfa50 0000004012db8b90 0000000044000000
+GPR24 0000004012dd9000 0000004002dd6aa0 00000040033dfad8 000000404d204b08
+GPR28 0000000000000000 0000004012db1000 0000000000000010 000000404d2047a8
+CR 48884424  [ G  L  L  L  G  G  E  G  ]             RES ffffffffffffffff
+FPR00 0000000100016f00 3ff000853ce957eb 0000000000000000 0000000000000000
+FPR04 000000000000000a 0000000000000006 000000000000000e 0000000000000000
+FPR08 0000000000000042 403a000000000000 0000000000000064 0000000000000064
+FPR12 4060000000000000 0000003000000000 0000000000000000 0000000000000060
+FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPSCR 000000008a008000
+Aborted (core dumped)
+```
+Steps to reproduce:
+1. `apt-get install -y qemu qemu-user-static`
+2. `docker run --rm --privileged multiarch/qemu-user-static --reset -p yes`
+3. `docker run -it ppc64le/ubuntu:20.04 bash`
+4. `apt-get update && apt-get install -y openjdk-11-jdk`
+Additional information:
+I actually encountered this while building https://github.com/jenkinsci/docker/blob/22f3f03e03e9902640c730cdfa896dc16a21d9d5/11/debian/bullseye/hotspot/Dockerfile
+
+Specifically running:
+```
+jlink \
+         --add-modules ALL-MODULE-PATH \
+         --no-man-pages \
+         --compress=2 \
+         --output /javaruntime
+```
+
+But when I tried to reduce this down installing openjdk from the ubuntu repository didn't work and it looks to be the same issue.
+
+This looks quite similar to https://gitlab.com/qemu-project/qemu/-/issues/319, we hit that issue as well and I've verified that s390x works now
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/744 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/744
new file mode 100644
index 00000000..73964fac
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/744
@@ -0,0 +1,3 @@
+ppc64: Implement the remaining PowerISA v3.1 instructions
+Additional information:
+[PowerISA_public.v3.1.pdf](https://wiki.raptorcs.com/w/images/f/f5/PowerISA_public.v3.1.pdf)
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/767 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/767
new file mode 100644
index 00000000..eab9999f
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/767
@@ -0,0 +1,3 @@
+Improve softmmu TLB utilisation by improving tlb_flush usage on PPC64
+Additional information:
+
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/85 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/85
new file mode 100644
index 00000000..25335e0d
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/85
@@ -0,0 +1 @@
+info registers' command leads to segfault with -M none
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/852 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/852
new file mode 100644
index 00000000..af687914
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/852
@@ -0,0 +1,31 @@
+ppc64le: possible SIMD issue casting double to int
+Description of problem:
+Working with numpy in a ppc64le VM, I ran into a strange double -to casting issue, specifically when casting an array of 1.0 values to 1 values. The numpy folks guided me to a small reproducible test case.
+
+The attached [convert.c](/uploads/2dd7936f4defccf816ffee7c7c002e77/convert.c) creates double and int arrays of length `1 <= n <= 16`. The double array is filled with the value 1.0, and both arrays are passed to a function that converts the value.
+
+With `-O2`, output is as expected (truncated here): 
+
+```
+i =  1:   1
+i =  2:   1 1
+i =  3:   1 1 1
+i =  4:   1 1 1 1
+i =  5:   1 1 1 1 1
+i =  6:   1 1 1 1 1 1
+```
+
+With `-O3`, all values that fit into blocks of four become zero:
+```
+i =  1:   1
+i =  2:   1 1
+i =  3:   1 1 1
+i =  4:   0 0 0 0
+i =  5:   0 0 0 0 1
+i =  6:   0 0 0 0 1 1
+```
+
+I tested this with executables compiled on a physical ppc64le host, where the issue is not reproducible.
+Steps to reproduce:
+1. `gcc -O2 -o convert convert.c && ./convert`
+2. `gcc -O3 -o convert convert.c && ./convert`
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_TCG/86 b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/86
new file mode 100644
index 00000000..45846202
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_TCG/86
@@ -0,0 +1 @@
+powerpc 7450 MMU initialization broken
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1038 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1038
new file mode 100644
index 00000000..33416d53
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1038
@@ -0,0 +1,11 @@
+ppc 'max' CPU model is unlike the other targets 'max' CPU model
+Description of problem:
+On most targets the 'max' CPU model is either equivalent to 'host' (for KVM) or equivalent to all available CPU features (for TCG).
+
+On PPC64, however, this is not the case. Instead the 'max' model is an alias of the old '7400_v2.9' and simply doesn't work.
+
+This is confusing. At the very least the 'max' model alias should be deleted. Ideally a proper replacement would be introduced that matches semantics on other arches.
+Steps to reproduce:
+1. qemu-system-ppc64 -cpu max
+
+should be equiv to '-cpu host' or should expose all TCG features.
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1087 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1087
new file mode 100644
index 00000000..e414f506
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1087
@@ -0,0 +1 @@
+QEMU 7.0.0 fails to build on PowerPC
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1092 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1092
new file mode 100644
index 00000000..3288539f
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1092
@@ -0,0 +1,14 @@
+PPC: `sraw` instructions does not set `ca` and `ca32` flags.
+Description of problem:
+The translation of Power PC instruction `sraw` and `sraw.` don't set the `ca` or `ca32` flags although, according to
+[PowerISA 3.1b](https://files.openpower.foundation/s/dAYSdGzTfW4j2r2) (page 140), they should.
+Additional information:
+This gets particular apparent if compared to `srawi` (which does set `ca`, `ca32`).
+
+**sraw**
+
+https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2914
+
+**srawi**
+
+https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2924
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1097 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1097
new file mode 100644
index 00000000..fc99931c
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1097
@@ -0,0 +1 @@
+linux-user build broken on 32-bit ppc
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1124 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1124
new file mode 100644
index 00000000..b2e89488
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1124
@@ -0,0 +1 @@
+AIX 5 not working with qemu-system-ppc64
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1136 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1136
new file mode 100644
index 00000000..c2837bf1
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1136
@@ -0,0 +1 @@
+qemu-system-ppc64: KVM HPT guest sometimes fails to migrate
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1146 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1146
new file mode 100644
index 00000000..288d24a2
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1146
@@ -0,0 +1,101 @@
+ppc: mac99 immediate segfault in vga_init with bus=pci.0
+Description of problem:
+I'm trying to figure out why `mac99` PowerPC VMs launched by libvirt always immediately segfault (signal SIGSEGV, segmentation fault).  I narrowed it down to the `bus=pci.0` option that libvirt adds to the `-device VGA` argument.  If I remove the `bus=pci.0` option then it doesn't segfault.  Full backtrace from gdb:
+
+```
+#0  memory_region_update_container_subregions (subregion=0x555556d795e0) at ../softmmu/memory.c:2538
+        mr = <optimized out>
+        other = <optimized out>
+        alias = <optimized out>
+        __PRETTY_FUNCTION__ = "memory_region_add_subregion_common"
+#1  memory_region_add_subregion_common (mr=<optimized out>, offset=<optimized out>, subregion=0x555556d795e0) at ../softmmu/memory.c:2556
+        alias = <optimized out>
+        __PRETTY_FUNCTION__ = "memory_region_add_subregion_common"
+#2  0x0000555555b81fad in vga_init (s=s@entry=0x555556dbe590, obj=obj@entry=0x555556dbdb70, address_space=0x5555568ea570, address_space_io=address_space_io@entry=0x5555568ea790, init_vga_ports=init_vga_ports@entry=true) at ../hw/display/vga.c:2305
+        vga_io_memory = 0x555556d795e0
+        vga_ports = 0x55555623bda0 <vga_portio_list>
+        vbe_ports = 0x55555623bd20 <vbe_portio_list>
+#3  0x00005555558fbe3a in pci_std_vga_realize (dev=0x555556dbdb70, errp=<optimized out>) at ../hw/display/vga-pci.c:245
+        d = 0x555556dbdb70
+        s = 0x555556dbe590
+        qext = false
+        edid = false
+#4  0x0000555555990128 in pci_qdev_realize (qdev=0x555556dbdb70, errp=<optimized out>) at ../hw/pci/pci.c:2218
+        pci_dev = 0x555556dbdb70
+        pc = <optimized out>
+        klass = <optimized out>
+        local_err = 0x0
+        is_default_rom = <optimized out>
+        class_id = <optimized out>
+        __func__ = "pci_qdev_realize"
+#5  0x0000555555c6aa2f in device_set_realized (obj=<optimized out>, value=true, errp=0x7fffffffd570) at ../hw/core/qdev.c:553
+        dev = 0x555556dbdb70
+        dc = 0x555556634130
+        hotplug_ctrl = 0x0
+        bus = <optimized out>
+        ncl = <optimized out>
+        local_err = 0x0
+        unattached_parent = false
+        unattached_count = 12
+        __func__ = "device_set_realized"
+        __PRETTY_FUNCTION__ = "device_set_realized"
+#6  0x0000555555c6de7a in property_set_bool (obj=0x555556dbdb70, v=<optimized out>, name=<optimized out>, opaque=0x5555564c40b0, errp=0x7fffffffd570) at ../qom/object.c:2273
+        prop = 0x5555564c40b0
+        value = true
+#7  0x0000555555c70158 in object_property_set (obj=obj@entry=0x555556dbdb70, name=name@entry=0x555555ee1196 "realized", v=v@entry=0x555556d745d0, errp=errp@entry=0x7fffffffd570) at ../qom/object.c:1408
+        _auto_errp_prop = {local_err = 0x0, errp = 0x7fffffffd570}
+        prop = <optimized out>
+        __func__ = "object_property_set"
+#8  0x0000555555c73384 in object_property_set_qobject (obj=obj@entry=0x555556dbdb70, name=name@entry=0x555555ee1196 "realized", value=value@entry=0x555556d732c0, errp=errp@entry=0x7fffffffd570) at ../qom/qom-qobject.c:28
+        v = 0x555556d745d0
+        ok = <optimized out>
+#9  0x0000555555c703c9 in object_property_set_bool (obj=0x555556dbdb70, name=name@entry=0x555555ee1196 "realized", value=value@entry=true, errp=errp@entry=0x7fffffffd570) at ../qom/object.c:1477
+        qbool = 0x555556d732c0
+        ok = <optimized out>
+#10 0x0000555555c69ec2 in qdev_realize (dev=<optimized out>, bus=bus@entry=0x5555568eb750, errp=errp@entry=0x7fffffffd570) at ../hw/core/qdev.c:333
+        __PRETTY_FUNCTION__ = "qdev_realize"
+#11 0x0000555555a1db80 in qdev_device_add_from_qdict (opts=opts@entry=0x555556d72130, from_json=from_json@entry=false, errp=<optimized out>, errp@entry=0x5555563be3d0 <error_fatal>) at /home/rhansen/floss/qemu/include/hw/qdev-core.h:17
+        _auto_errp_prop = {local_err = 0x0, errp = 0x5555563be3d0 <error_fatal>}
+        dc = 0x555556634130
+        driver = 0x555556d73150 "VGA"
+        path = <optimized out>
+        id = <optimized out>
+        dev = 0x555556dbdb70
+        bus = <optimized out>
+        __func__ = "qdev_device_add_from_qdict"
+#12 0x0000555555a1dca6 in qdev_device_add (opts=0x5555564c10d0, errp=errp@entry=0x5555563be3d0 <error_fatal>) at ../softmmu/qdev-monitor.c:733
+        qdict = 0x555556d72130
+        ret = <optimized out>
+#13 0x0000555555a1fb83 in device_init_func (opaque=<optimized out>, opts=<optimized out>, errp=0x5555563be3d0 <error_fatal>) at ../softmmu/vl.c:1142
+        dev = <optimized out>
+#14 0x0000555555dde692 in qemu_opts_foreach (list=<optimized out>, func=func@entry=0x555555a1fb70 <device_init_func>, opaque=opaque@entry=0x0, errp=0x5555563be3d0 <error_fatal>) at ../util/qemu-option.c:1135
+        loc = {kind = LOC_CMDLINE, num = 2, ptr = 0x7fffffffd990, prev = 0x5555563be400 <std_loc>}
+        opts = 0x5555564c10d0
+        next = 0x0
+        rc = 0
+        __PRETTY_FUNCTION__ = "qemu_opts_foreach"
+#15 0x0000555555a22921 in qemu_create_cli_devices () at ../softmmu/vl.c:2522
+        opt = <optimized out>
+        __func__ = "qmp_x_exit_preconfig"
+        __func__ = "qmp_x_exit_preconfig"
+#16 qmp_x_exit_preconfig (errp=0x5555563be3d0 <error_fatal>) at ../softmmu/vl.c:2590
+        __func__ = "qmp_x_exit_preconfig"
+        __func__ = "qmp_x_exit_preconfig"
+#17 qmp_x_exit_preconfig (errp=0x5555563be3d0 <error_fatal>) at ../softmmu/vl.c:2582
+        __func__ = "qmp_x_exit_preconfig"
+#18 0x0000555555a25ec2 in qemu_init (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/vl.c:3586
+        opts = <optimized out>
+        icount_opts = <optimized out>
+        accel_opts = <optimized out>
+        olist = <optimized out>
+        optind = 11
+        optarg = 0x7fffffffdec3 "chardev=mon0,mode=readline"
+        machine_class = <optimized out>
+        userconfig = <optimized out>
+        vmstate_dump_file = <optimized out>
+        __func__ = "qemu_init"
+        __PRETTY_FUNCTION__ = "qemu_init"
+#19 0x000055555585410d in qemu_main (envp=0x0, argv=<optimized out>, argc=<optimized out>) at ../softmmu/main.c:47
+        status = <optimized out>
+#20 main (argc=<optimized out>, argv=<optimized out>) at ../softmmu/main.c:47
+```
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1301 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1301
new file mode 100644
index 00000000..d919ef6a
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1301
@@ -0,0 +1,17 @@
+qemu-system-ppc in Homebrew on macOS has mouse warps and ghost clicks
+Description of problem:
+The QEMU version in Homebrew (Intel macOS host, PowerPC Mac OS 9 guest) has random warping of the mouse cursor as well as ghost clicks which begin as soon as the operating system finishes loading. Video demonstration: https://youtu.be/DjXO0hwHArk
+
+Notably, the exact same version of the QEMU source code with the same build arguments built *outside* of the Homebrew environment does not have this issue. I copied the following arguments from the QEMU Homebrew formula, and tried building QEMU on the command line:
+
+    ../configure --prefix=/Users/josh/Desktop/qemu-homebrew-build --cc=clang --host-cc=clang --disable-bsd-user --disable-guest-agent --enable-capstone --enable-curses --enable-libssh --enable-slirp --enable-vde --enable-virtfs --enable-zstd --extra-cflags=-DNCURSES_WIDECHAR=1 --disable-sdl --smbd=/usr/local/sbin/samba-dot-org-smbd --disable-gtk --enable-cocoa --target-list=ppc-softmmu
+
+This creates a `qemu-system-ppc` binary which is 15MB in size and works perfectly. By contrast, the exact same build commands within the Homebrew build process create a binary which is 10MB in size (!!!) and has this mouse warping and ghost clicks issue. This occurs whether QEMU was installed with `brew install qemu` or `brew install --build-from-source qemu`. Providing the `--HEAD` argument also makes no difference. The list of linked libraries (via `otool -L qemu-system-ppc`) is the same between the two versions.
+
+The only way I can reproduce this issue outside of Homebrew is to dump the Homebrew environmental variables (with `env`) to a file and then set up those same environmental variables with the `source` command, after which the resulting `qemu-system-ppc` binary is now 10MB in size like the Homebrew version, and has the mouse issue like the Homebrew version. I'll attach the file with the Homebrew environmental variables. It seems that the issue must lie somewhere in there, but I'm really pushing the limits of my abilities, so I could definitely use some ideas and/or insights.
+Steps to reproduce:
+1. Install QEMU via `brew install qemu`
+2. Start QEMU with an image of Mac OS 9
+3. After the boot process completes, the issue manifests
+Additional information:
+[Homebrew_ENV_Variables.txt](/uploads/2393aed8f29fa9c32bcaca44281bd2a5/Homebrew_ENV_Variables.txt)
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1361 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1361
new file mode 100644
index 00000000..258025a7
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1361
@@ -0,0 +1,20 @@
+ppc64le linux user emulation w/ 64KiB pages seems broken since v5.0.0
+Description of problem:
+[Our (snmalloc's)](https://github.com/microsoft/snmalloc) CI includes running a PowerPC64 little-endian Linux build inside qemu, running with 64KiB pages as, at least, Debian runs them by default.  As reported [over there](https://github.com/microsoft/snmalloc/issues/576), this broke when GitHub's CI runners moved from Ubuntu Focal (20.04) to Jammy (22.04), bringing qemu from v4.2 to v6.2.
+
+The failing test case appears to die of an erroneous `SIGSEGV` `SEGV_MAPERR`:
+```
+--- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0x0000004001be5000} ---
+```
+despite that address nominally being mapped by the last memory syscall to touch that area
+```
+openat(AT_FDCWD,"/usr/powerpc64le-linux-gnu/lib/libstdc++.so.6",O_RDONLY|O_CLOEXEC) = 4
+[...]
+mmap(0x0000004001bd0000,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,4,0x2f0000) = 0x4001bd0000
+```
+
+Bisection reveals that the breakage first occurred with 4dcf078f094d436866ef793aa25c96fba85ac8d0, though I suspect this is merely the commit that exposes some underlying bug rather than being the actual root cause.
+Steps to reproduce:
+Run a ppc64el Linux executable under `qemu-user` with `-p 65536`.
+Additional information:
+Please advise what more would be useful.
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1390 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1390
new file mode 100644
index 00000000..914e034b
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1390
@@ -0,0 +1 @@
+Any plans for P5020 P5040 CPUs?
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1494 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1494
new file mode 100644
index 00000000..1ddfb35b
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1494
@@ -0,0 +1,932 @@
+[regression] [bisected] [coredump] qemu-x86_64 segfaults on ppc64le (4K page size) when downloading go dependencies: unexpected fault address 0x0
+Description of problem:
+qemu-x86_64 segfaults when trying to compile yay inside an Arch Linux x86_64 chroot from a Gentoo Linux ppc64le (4K page size) host. Hardware is a Raptor CS Talos 2 Power 9.
+
+It works with qemu-7.2 so this is a regression in git master (or less likely with the patch).
+
+```
+[niko@talos2 yay]$ makepkg -s
+==> Making package: yay 11.3.2-1 (Wed 15 Feb 2023 05:03:01 PM CET)
+==> Checking runtime dependencies...
+==> Checking buildtime dependencies...
+==> Retrieving sources...
+  -> Found yay-11.3.2.tar.gz
+==> Validating source files with sha256sums...
+    yay-11.3.2.tar.gz ... Passed
+==> Extracting sources...
+  -> Extracting yay-11.3.2.tar.gz with bsdtar
+==> Removing existing $pkgdir/ directory...
+==> Starting build()...
+go build -trimpath -mod=readonly -modcacherw  -ldflags '-X "main.yayVersion=11.3.2" -X "main.localePath=/usr/share/locale/" -linkmode=external' -buildmode=pie -o yay
+go: downloading github.com/Jguer/votar v1.0.0
+go: downloading github.com/Jguer/aur v1.0.1
+go: downloading github.com/Jguer/go-alpm/v2 v2.1.2
+go: downloading github.com/Morganamilo/go-pacmanconf v0.0.0-20210502114700-cff030e927a5
+go: downloading golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab
+go: downloading github.com/Morganamilo/go-srcinfo v1.0.0
+go: downloading golang.org/x/term v0.0.0-20220722155259-a9ba230a4035
+go: downloading github.com/leonelquinteros/gotext v1.5.0
+go: downloading github.com/adrg/strutil v0.3.0
+go: downloading golang.org/x/text v0.3.7
+make: *** [Makefile:113: yay] Illegal instruction (core dumped)
+```
+
+```
+[niko@talos2 yay]$ makepkg -s
+==> Making package: yay 11.3.2-1 (Wed 15 Feb 2023 05:10:01 PM CET)
+==> Checking runtime dependencies...
+==> Checking buildtime dependencies...
+==> Retrieving sources...
+  -> Found yay-11.3.2.tar.gz
+==> Validating source files with sha256sums...
+    yay-11.3.2.tar.gz ... Passed
+==> Extracting sources...
+  -> Extracting yay-11.3.2.tar.gz with bsdtar
+==> Starting build()...
+go build -trimpath -mod=readonly -modcacherw  -ldflags '-X "main.yayVersion=11.3.2" -X "main.localePath=/usr/share/locale/" -linkmode=external' -buildmode=pie -o yay
+go: downloading github.com/Jguer/votar v1.0.0
+go: downloading github.com/Jguer/go-alpm/v2 v2.1.2
+go: downloading github.com/Morganamilo/go-srcinfo v1.0.0
+go: downloading github.com/Jguer/aur v1.0.1
+go: downloading github.com/leonelquinteros/gotext v1.5.0
+go: downloading github.com/Morganamilo/go-pacmanconf v0.0.0-20210502114700-cff030e927a5
+go: downloading golang.org/x/term v0.0.0-20220722155259-a9ba230a4035
+go: downloading github.com/adrg/strutil v0.3.0
+go: downloading golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab
+go: downloading golang.org/x/text v0.3.7
+# math/bits
+unexpected fault address 0x0
+fatal error: fault
+[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0xabb70a]
+
+goroutine 4 [running]:
+runtime.throw({0xdbf491?, 0x1?})
+	/usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0xc0001d7750 sp=0xc0001d7720 pc=0x4389fd
+runtime.sigpanic()
+	/usr/lib/go/src/runtime/signal_unix.go:851 +0x28a fp=0xc0001d77b0 sp=0xc0001d7750 pc=0x44f4ea
+cmd/compile/internal/ssa.ValHeap.Less({{0xc0001ae1c0, 0x4, 0x8}, {0xc0001de700, 0x28, 0x100}}, 0x8?, 0xc0001de700?)
+	/usr/lib/go/src/cmd/compile/internal/ssa/schedule.go:59 +0xaa fp=0xc0001d77e0 sp=0xc0001d77b0 pc=0xabb70a
+cmd/compile/internal/ssa.(*ValHeap).Less(0x4?, 0x8?, 0xc0001de700?)
+	<autogenerated>:1 +0x77 fp=0xc0001d7860 sp=0xc0001d77e0 pc=0xad7677
+container/heap.up({0xf24240, 0xc00019eb40}, 0xc00081b370?)
+	/usr/lib/go/src/container/heap/heap.go:92 +0x7e fp=0xc0001d7898 sp=0xc0001d7860 pc=0x7024de
+container/heap.Push({0xf24240, 0xc00019eb40}, {0xdb1f80?, 0xc00081b370?})
+	/usr/lib/go/src/container/heap/heap.go:53 +0x5a fp=0xc0001d78c0 sp=0xc0001d7898 pc=0x7022da
+cmd/compile/internal/ssa.schedule(0xc0004ea000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/schedule.go:349 +0x151c fp=0xc0001d7eb0 sp=0xc0001d78c0 pc=0xabcd9c
+cmd/compile/internal/ssa.Compile(0xc0004ea000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc0001dbb68 sp=0xc0001d7eb0 pc=0x76bc43
+cmd/compile/internal/ssagen.buildssa(0xc00071b540, 0x2)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc0001dbea8 sp=0xc0001dbb68 pc=0xaf0527
+cmd/compile/internal/ssagen.Compile(0xc00071b540, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0001dbf70 sp=0xc0001dbea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0001dbfb0 sp=0xc0001dbf70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0001dbfe0 sp=0xc0001dbfb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0001dbfe8 sp=0xc0001dbfe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 1 [semacquire]:
+runtime.gopark(0xc0000062e8?, 0xc00019a050?, 0x0?, 0xa0?, 0x4027dba128?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0005ad968 sp=0xc0005ad948 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.semacquire1(0xc0008c4768, 0x20?, 0x1, 0x0, 0x0?)
+	/usr/lib/go/src/runtime/sema.go:160 +0x20f fp=0xc0005ad9d0 sp=0xc0005ad968 pc=0x44c9af
+sync.runtime_Semacquire(0xc0008b8000?)
+	/usr/lib/go/src/runtime/sema.go:62 +0x27 fp=0xc0005ada08 sp=0xc0005ad9d0 pc=0x46a6e7
+sync.(*WaitGroup).Wait(0xc000659800?)
+	/usr/lib/go/src/sync/waitgroup.go:116 +0x4b fp=0xc0005ada30 sp=0xc0005ada08 pc=0x487deb
+cmd/compile/internal/gc.compileFunctions()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:183 +0x235 fp=0xc0005ada88 sp=0xc0005ada30 pc=0xcc6675
+cmd/compile/internal/gc.Main(0xdf8e28)
+	/usr/lib/go/src/cmd/compile/internal/gc/main.go:332 +0x13aa fp=0xc0005adf20 sp=0xc0005ada88 pc=0xcc86aa
+main.main()
+	/usr/lib/go/src/cmd/compile/main.go:57 +0xdd fp=0xc0005adf80 sp=0xc0005adf20 pc=0xcf00bd
+runtime.main()
+	/usr/lib/go/src/runtime/proc.go:250 +0x207 fp=0xc0005adfe0 sp=0xc0005adf80 pc=0x43b2e7
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0005adfe8 sp=0xc0005adfe0 pc=0x46e201
+
+goroutine 2 [force gc (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009afb0 sp=0xc00009af90 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.forcegchelper()
+	/usr/lib/go/src/runtime/proc.go:305 +0xb0 fp=0xc00009afe0 sp=0xc00009afb0 pc=0x43b550
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009afe8 sp=0xc00009afe0 pc=0x46e201
+created by runtime.init.6
+	/usr/lib/go/src/runtime/proc.go:293 +0x25
+
+goroutine 17 [GC sweep wait]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc000096780 sp=0xc000096760 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.bgsweep(0x0?)
+	/usr/lib/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc0000967c8 sp=0xc000096780 pc=0x425cce
+runtime.gcenable.func1()
+	/usr/lib/go/src/runtime/mgc.go:178 +0x26 fp=0xc0000967e0 sp=0xc0000967c8 pc=0x41aee6
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000967e8 sp=0xc0000967e0 pc=0x46e201
+created by runtime.gcenable
+	/usr/lib/go/src/runtime/mgc.go:178 +0x6b
+
+goroutine 18 [GC scavenge wait]:
+runtime.gopark(0xc000194000?, 0xf1ad58?, 0x1?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc000096f70 sp=0xc000096f50 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.(*scavengerState).park(0x1487ce0)
+	/usr/lib/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc000096fa0 sp=0xc000096f70 pc=0x423c13
+runtime.bgscavenge(0x0?)
+	/usr/lib/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc000096fc8 sp=0xc000096fa0 pc=0x4241e5
+runtime.gcenable.func2()
+	/usr/lib/go/src/runtime/mgc.go:179 +0x26 fp=0xc000096fe0 sp=0xc000096fc8 pc=0x41ae86
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000096fe8 sp=0xc000096fe0 pc=0x46e201
+created by runtime.gcenable
+	/usr/lib/go/src/runtime/mgc.go:179 +0xaa
+
+goroutine 33 [finalizer wait]:
+runtime.gopark(0x43ba92?, 0x4027cf9f48?, 0x0?, 0x0?, 0xc00009a770?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009a628 sp=0xc00009a608 pc=0x43b716
+runtime.runfinq()
+	/usr/lib/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00009a7e0 sp=0xc00009a628 pc=0x419f27
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009a7e8 sp=0xc00009a7e0 pc=0x46e201
+created by runtime.createfing
+	/usr/lib/go/src/runtime/mfinal.go:163 +0x45
+
+goroutine 49 [select]:
+runtime.gopark(0xc0004e6fb0?, 0x2?, 0xf0?, 0x6d?, 0xc0004e6f6c?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0004e6da0 sp=0xc0004e6d80 pc=0x43b716
+runtime.selectgo(0xc0004e6fb0, 0xc0004e6f68, 0xc000504000?, 0x0, 0xd26040?, 0x1)
+	/usr/lib/go/src/runtime/select.go:327 +0x7be fp=0xc0004e6ee0 sp=0xc0004e6da0 pc=0x44b8be
+cmd/compile/internal/gc.compileFunctions.func3()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:141 +0x132 fp=0xc0004e6fe0 sp=0xc0004e6ee0 pc=0xcc6a12
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0004e6fe8 sp=0xc0004e6fe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:134 +0xf8
+
+goroutine 3 [runnable]:
+runtime.asyncPreempt2()
+	/usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0004f7858 sp=0xc0004f7838 pc=0x439e1f
+runtime.asyncPreempt()
+	/usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0004f79e0 sp=0xc0004f7858 pc=0x46f85b
+cmd/compile/internal/ssa.is64BitInt(0xc000141480)
+	/usr/lib/go/src/cmd/compile/internal/ssa/rewrite.go:218 +0xa fp=0xc0004f79e8 sp=0xc0004f79e0 pc=0x7e2e8a
+cmd/compile/internal/ssa.rewriteValueAMD64_OpLoad(0xc00086a458)
+	/usr/lib/go/src/cmd/compile/internal/ssa/rewriteAMD64.go:29312 +0x51 fp=0xc0004f7a28 sp=0xc0004f79e8 pc=0x884911
+cmd/compile/internal/ssa.rewriteValueAMD64(0xc00089f678?)
+	/usr/lib/go/src/cmd/compile/internal/ssa/rewriteAMD64.go:838 +0x31be fp=0xc0004f7a48 sp=0xc0004f7a28 pc=0x819bbe
+cmd/compile/internal/ssa.applyRewrite(0xc0001b2000, 0xdf92a8, 0xdf9348, 0x1)
+	/usr/lib/go/src/cmd/compile/internal/ssa/rewrite.go:133 +0x1016 fp=0xc0004f7e80 sp=0xc0004f7a48 pc=0x7e27d6
+cmd/compile/internal/ssa.lower(0xc0001b2000?)
+	/usr/lib/go/src/cmd/compile/internal/ssa/lower.go:10 +0x2f fp=0xc0004f7eb0 sp=0xc0004f7e80 pc=0x7b4c4f
+cmd/compile/internal/ssa.Compile(0xc0001b2000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc0004fbb68 sp=0xc0004f7eb0 pc=0x76bc43
+cmd/compile/internal/ssagen.buildssa(0xc00071b900, 0x3)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc0004fbea8 sp=0xc0004fbb68 pc=0xaf0527
+cmd/compile/internal/ssagen.Compile(0xc00071b900, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0004fbf70 sp=0xc0004fbea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0004fbfb0 sp=0xc0004fbf70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0004fbfe0 sp=0xc0004fbfb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0004fbfe8 sp=0xc0004fbfe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 50 [runnable]:
+cmd/compile/internal/ssa.(*Value).clobbersFlags(0xc0007ce6d8?)
+	/usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:243 +0xd5 fp=0xc0000dbbf0 sp=0xc0000dbbe8 pc=0x79c375
+cmd/compile/internal/ssa.flagalloc(0xc0000ca000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:39 +0x172a fp=0xc0000dbeb0 sp=0xc0000dbbf0 pc=0x79c0ca
+cmd/compile/internal/ssa.Compile(0xc0000ca000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc0000dfb68 sp=0xc0000dbeb0 pc=0x76bc43
+cmd/compile/internal/ssagen.buildssa(0xc00071ba40, 0x1)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc0000dfea8 sp=0xc0000dfb68 pc=0xaf0527
+cmd/compile/internal/ssagen.Compile(0xc00071ba40, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0000dff70 sp=0xc0000dfea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0000dffb0 sp=0xc0000dff70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0000dffe0 sp=0xc0000dffb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000dffe8 sp=0xc0000dffe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 51 [runnable]:
+cmd/compile/internal/ssa.(*Value).clobbersFlags(0xc000780d90?)
+	/usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:243 +0xd5 fp=0xc00091bbf0 sp=0xc00091bbe8 pc=0x79c375
+cmd/compile/internal/ssa.flagalloc(0xc000774540)
+	/usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:39 +0x172a fp=0xc00091beb0 sp=0xc00091bbf0 pc=0x79c0ca
+cmd/compile/internal/ssa.Compile(0xc000774540)
+	/usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc00091fb68 sp=0xc00091beb0 pc=0x76bc43
+cmd/compile/internal/ssagen.buildssa(0xc000703900, 0x0)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc00091fea8 sp=0xc00091fb68 pc=0xaf0527
+cmd/compile/internal/ssagen.Compile(0xc000703900, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc00091ff70 sp=0xc00091fea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc00091ffb0 sp=0xc00091ff70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc00091ffe0 sp=0xc00091ffb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00091ffe8 sp=0xc00091ffe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+# unicode/utf8
+unexpected fault address 0x0
+fatal error: fault
+[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x411410]
+
+goroutine 19 [running]:
+runtime.throw({0xdbf491?, 0x4000804d28?})
+	/usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0xc0004f1830 sp=0xc0004f1800 pc=0x4389fd
+runtime.sigpanic()
+	/usr/lib/go/src/runtime/signal_unix.go:851 +0x28a fp=0xc0004f1890 sp=0xc0004f1830 pc=0x44f4ea
+runtime.mapaccess2_fast32(0xc0009b3c00, 0xc000562000, 0x6be729)
+	/usr/lib/go/src/runtime/map_fast32.go:53 +0x170 fp=0xc0004f1898 sp=0xc0004f1890 pc=0x411410
+cmd/compile/internal/ssagen.genssa(0xc000562000, 0xc000988ee0)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:6964 +0x965 fp=0xc0004f1ea8 sp=0xc0004f1898 pc=0xb27345
+cmd/compile/internal/ssagen.Compile(0xc0000fcb40, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0004f1f70 sp=0xc0004f1ea8 pc=0xae7b8f
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0004f1fb0 sp=0xc0004f1f70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0004f1fe0 sp=0xc0004f1fb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0004f1fe8 sp=0xc0004f1fe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 1 [semacquire]:
+runtime.gopark(0x20?, 0xd7ca20?, 0x0?, 0x60?, 0xc00003a600?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0005a9968 sp=0xc0005a9948 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.semacquire1(0xc0006d5a88, 0x20?, 0x1, 0x0, 0x0?)
+	/usr/lib/go/src/runtime/sema.go:160 +0x20f fp=0xc0005a99d0 sp=0xc0005a9968 pc=0x44c9af
+sync.runtime_Semacquire(0xc0000fdb80?)
+	/usr/lib/go/src/runtime/sema.go:62 +0x27 fp=0xc0005a9a08 sp=0xc0005a99d0 pc=0x46a6e7
+sync.(*WaitGroup).Wait(0xc0008ca400?)
+	/usr/lib/go/src/sync/waitgroup.go:116 +0x4b fp=0xc0005a9a30 sp=0xc0005a9a08 pc=0x487deb
+cmd/compile/internal/gc.compileFunctions()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:183 +0x235 fp=0xc0005a9a88 sp=0xc0005a9a30 pc=0xcc6675
+cmd/compile/internal/gc.Main(0xdf8e28)
+	/usr/lib/go/src/cmd/compile/internal/gc/main.go:332 +0x13aa fp=0xc0005a9f20 sp=0xc0005a9a88 pc=0xcc86aa
+main.main()
+	/usr/lib/go/src/cmd/compile/main.go:57 +0xdd fp=0xc0005a9f80 sp=0xc0005a9f20 pc=0xcf00bd
+runtime.main()
+	/usr/lib/go/src/runtime/proc.go:250 +0x207 fp=0xc0005a9fe0 sp=0xc0005a9f80 pc=0x43b2e7
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0005a9fe8 sp=0xc0005a9fe0 pc=0x46e201
+
+goroutine 2 [force gc (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009cfb0 sp=0xc00009cf90 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.forcegchelper()
+	/usr/lib/go/src/runtime/proc.go:305 +0xb0 fp=0xc00009cfe0 sp=0xc00009cfb0 pc=0x43b550
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009cfe8 sp=0xc00009cfe0 pc=0x46e201
+created by runtime.init.6
+	/usr/lib/go/src/runtime/proc.go:293 +0x25
+
+goroutine 3 [GC sweep wait]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009d780 sp=0xc00009d760 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.bgsweep(0x0?)
+	/usr/lib/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc00009d7c8 sp=0xc00009d780 pc=0x425cce
+runtime.gcenable.func1()
+	/usr/lib/go/src/runtime/mgc.go:178 +0x26 fp=0xc00009d7e0 sp=0xc00009d7c8 pc=0x41aee6
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009d7e8 sp=0xc00009d7e0 pc=0x46e201
+created by runtime.gcenable
+	/usr/lib/go/src/runtime/mgc.go:178 +0x6b
+
+goroutine 4 [GC scavenge wait]:
+runtime.gopark(0xc0000380e0?, 0xf1ad58?, 0x1?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009df70 sp=0xc00009df50 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.(*scavengerState).park(0x1487ce0)
+	/usr/lib/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc00009dfa0 sp=0xc00009df70 pc=0x423c13
+runtime.bgscavenge(0x0?)
+	/usr/lib/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc00009dfc8 sp=0xc00009dfa0 pc=0x4241e5
+runtime.gcenable.func2()
+	/usr/lib/go/src/runtime/mgc.go:179 +0x26 fp=0xc00009dfe0 sp=0xc00009dfc8 pc=0x41ae86
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009dfe8 sp=0xc00009dfe0 pc=0x46e201
+created by runtime.gcenable
+	/usr/lib/go/src/runtime/mgc.go:179 +0xaa
+
+goroutine 17 [finalizer wait]:
+runtime.gopark(0x43ba92?, 0x4027cf9fe8?, 0x0?, 0x0?, 0xc00009c770?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009c628 sp=0xc00009c608 pc=0x43b716
+runtime.runfinq()
+	/usr/lib/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00009c7e0 sp=0xc00009c628 pc=0x419f27
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009c7e8 sp=0xc00009c7e0 pc=0x46e201
+created by runtime.createfing
+	/usr/lib/go/src/runtime/mfinal.go:163 +0x45
+
+goroutine 49 [runnable]:
+runtime.asyncPreempt2()
+	/usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0009c1308 sp=0xc0009c12e8 pc=0x439e1f
+runtime.asyncPreempt()
+	/usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0009c1490 sp=0xc0009c1308 pc=0x46f85b
+cmd/compile/internal/ssa.PopulateABIInRegArgOps(0xc000754700)
+	/usr/lib/go/src/cmd/compile/internal/ssa/debug.go:436 +0x57 fp=0xc0009c16f0 sp=0xc0009c1490 pc=0x779bb7
+cmd/compile/internal/ssa.BuildFuncDebug(0xc00041e5a0?, 0xc000754700, 0xc000000049?, 0xa?, 0xc00098c000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/debug.go:578 +0x1d6 fp=0xc0009c1898 sp=0xc0009c16f0 pc=0x77adb6
+cmd/compile/internal/ssagen.genssa(0xc000754700, 0xc0004bfce0)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7157 +0xf2b fp=0xc0009c1ea8 sp=0xc0009c1898 pc=0xb2790b
+cmd/compile/internal/ssagen.Compile(0xc0000fc8c0, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0009c1f70 sp=0xc0009c1ea8 pc=0xae7b8f
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0009c1fb0 sp=0xc0009c1f70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0009c1fe0 sp=0xc0009c1fb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0009c1fe8 sp=0xc0009c1fe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 5 [select]:
+runtime.gopark(0xc00009e7b0?, 0x2?, 0xf0?, 0xe5?, 0xc00009e76c?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009e5a0 sp=0xc00009e580 pc=0x43b716
+runtime.selectgo(0xc00009e7b0, 0xc00009e768, 0x0?, 0x0, 0xd26040?, 0x1)
+	/usr/lib/go/src/runtime/select.go:327 +0x7be fp=0xc00009e6e0 sp=0xc00009e5a0 pc=0x44b8be
+cmd/compile/internal/gc.compileFunctions.func3()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:141 +0x132 fp=0xc00009e7e0 sp=0xc00009e6e0 pc=0xcc6a12
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009e7e8 sp=0xc00009e7e0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:134 +0xf8
+
+goroutine 50 [runnable]:
+runtime.asyncPreempt2()
+	/usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0001cd308 sp=0xc0001cd2e8 pc=0x439e1f
+runtime.asyncPreempt()
+	/usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0001cd490 sp=0xc0001cd308 pc=0x46f85b
+cmd/compile/internal/ssa.PopulateABIInRegArgOps(0xc000192000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/debug.go:436 +0x57 fp=0xc0001cd6f0 sp=0xc0001cd490 pc=0x779bb7
+cmd/compile/internal/ssa.BuildFuncDebug(0xc0001a65a0?, 0xc000192000, 0xc000000049?, 0x12?, 0xc0001a4000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/debug.go:578 +0x1d6 fp=0xc0001cd898 sp=0xc0001cd6f0 pc=0x77adb6
+cmd/compile/internal/ssagen.genssa(0xc000192000, 0xc00019f260)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7157 +0xf2b fp=0xc0001cdea8 sp=0xc0001cd898 pc=0xb2790b
+cmd/compile/internal/ssagen.Compile(0xc0000fca00, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0001cdf70 sp=0xc0001cdea8 pc=0xae7b8f
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0001cdfb0 sp=0xc0001cdf70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0001cdfe0 sp=0xc0001cdfb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0001cdfe8 sp=0xc0001cdfe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 20 [runnable]:
+runtime.asyncPreempt2()
+	/usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0008e10f8 sp=0xc0008e10d8 pc=0x439e1f
+runtime.asyncPreempt()
+	/usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0008e1280 sp=0xc0008e10f8 pc=0x46f85b
+cmd/compile/internal/ssagen.AddrAuto(0xc000201ed0, 0x81308171a15?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7649 +0x94 fp=0xc0008e12a8 sp=0xc0008e1280 pc=0xb2d9d4
+cmd/compile/internal/amd64.ssaGenValue(0xc0008bec60, 0xc000781ab0)
+	/usr/lib/go/src/cmd/compile/internal/amd64/ssa.go:1037 +0x13dc fp=0xc0008e1898 sp=0xc0008e12a8 pc=0xb3d6bc
+cmd/compile/internal/ssagen.genssa(0xc0004e4000, 0xc0008e8070)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7024 +0x3ff8 fp=0xc0008e1ea8 sp=0xc0008e1898 pc=0xb2a9d8
+cmd/compile/internal/ssagen.Compile(0xc0000fcc80, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0008e1f70 sp=0xc0008e1ea8 pc=0xae7b8f
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0008e1fb0 sp=0xc0008e1f70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0008e1fe0 sp=0xc0008e1fb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0008e1fe8 sp=0xc0008e1fe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+# internal/reflectlite
+unexpected fault address 0x0
+fatal error: fault
+[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x66b360]
+
+goroutine 6 [running]:
+runtime.throw({0xdbf491?, 0x8?})
+	/usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0xc0000dc720 sp=0xc0000dc6f0 pc=0x4389fd
+runtime.sigpanic()
+	/usr/lib/go/src/runtime/signal_unix.go:851 +0x28a fp=0xc0000dc780 sp=0xc0000dc720 pc=0x44f4ea
+cmd/compile/internal/abi.(*assignState).regAllocate(0xc0000dc7a0, 0x41b2b1, {0x14cdd40, 0xc0000dc808}, 0xa8)
+	/usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:607 fp=0xc0000dc788 sp=0xc0000dc780 pc=0x66b360
+cmd/compile/internal/abi.(*assignState).assignParamOrReturn(0xc0000dc8a8, 0xc0008977a0, {0xf23198, 0xc000a0b080}, 0x20?)
+	/usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:777 +0x165 fp=0xc0000dc840 sp=0xc0000dc788 pc=0x66bae5
+cmd/compile/internal/abi.(*ABIConfig).ABIAnalyzeFuncType(0xc0000bca60, 0xc00089b710)
+	/usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:404 +0x3d7 fp=0xc0000dc9f8 sp=0xc0000dc840 pc=0x669a17
+cmd/compile/internal/abi.(*ABIConfig).ABIAnalyze(0xd41a80?, 0xc0000d0600?, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:432 +0x5d fp=0xc0000dcb68 sp=0xc0000dc9f8 pc=0x669e7d
+cmd/compile/internal/ssagen.buildssa(0xc0008cc500, 0x1)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:455 +0x1209 fp=0xc0000dcea8 sp=0xc0000dcb68 pc=0xaef709
+cmd/compile/internal/ssagen.Compile(0xc0008cc500, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0000dcf70 sp=0xc0000dcea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0000dcfb0 sp=0xc0000dcf70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0000dcfe0 sp=0xc0000dcfb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000dcfe8 sp=0xc0000dcfe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 1 [runnable]:
+runtime.gopark(0xc0000be000?, 0xc0004edec0?, 0xb0?, 0x99?, 0xc000739978?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc000739910 sp=0xc0007398f0 pc=0x43b716
+runtime.chansend(0xc000d540c0, 0xc0007399e8, 0x1, 0xc0007399d8?)
+	/usr/lib/go/src/runtime/chan.go:259 +0x42e fp=0xc000739998 sp=0xc000739910 pc=0x40602e
+runtime.chansend1(0xd7ca20?, 0x4000803501?)
+	/usr/lib/go/src/runtime/chan.go:145 +0x1d fp=0xc0007399c8 sp=0xc000739998 pc=0x405bdd
+cmd/compile/internal/gc.compileFunctions.func4(0xc00180cc40)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:160 +0x27 fp=0xc0007399e8 sp=0xc0007399c8 pc=0xcc68a7
+cmd/compile/internal/gc.compileFunctions.func5({0xc001099500, 0x222, 0x350?})
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:170 +0x53 fp=0xc000739a30 sp=0xc0007399e8 pc=0xcc6713
+cmd/compile/internal/gc.compileFunctions()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:181 +0x1ff fp=0xc000739a88 sp=0xc000739a30 pc=0xcc663f
+cmd/compile/internal/gc.Main(0xdf8e28)
+	/usr/lib/go/src/cmd/compile/internal/gc/main.go:332 +0x13aa fp=0xc000739f20 sp=0xc000739a88 pc=0xcc86aa
+main.main()
+	/usr/lib/go/src/cmd/compile/main.go:57 +0xdd fp=0xc000739f80 sp=0xc000739f20 pc=0xcf00bd
+runtime.main()
+	/usr/lib/go/src/runtime/proc.go:250 +0x207 fp=0xc000739fe0 sp=0xc000739f80 pc=0x43b2e7
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000739fe8 sp=0xc000739fe0 pc=0x46e201
+
+goroutine 2 [force gc (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009cfb0 sp=0xc00009cf90 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.forcegchelper()
+	/usr/lib/go/src/runtime/proc.go:305 +0xb0 fp=0xc00009cfe0 sp=0xc00009cfb0 pc=0x43b550
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009cfe8 sp=0xc00009cfe0 pc=0x46e201
+created by runtime.init.6
+	/usr/lib/go/src/runtime/proc.go:293 +0x25
+
+goroutine 3 [GC sweep wait]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009d780 sp=0xc00009d760 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.bgsweep(0x0?)
+	/usr/lib/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc00009d7c8 sp=0xc00009d780 pc=0x425cce
+runtime.gcenable.func1()
+	/usr/lib/go/src/runtime/mgc.go:178 +0x26 fp=0xc00009d7e0 sp=0xc00009d7c8 pc=0x41aee6
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009d7e8 sp=0xc00009d7e0 pc=0x46e201
+created by runtime.gcenable
+	/usr/lib/go/src/runtime/mgc.go:178 +0x6b
+
+goroutine 4 [GC scavenge wait]:
+runtime.gopark(0xc0000380e0?, 0xf1ad58?, 0x1?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009df70 sp=0xc00009df50 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.(*scavengerState).park(0x1487ce0)
+	/usr/lib/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc00009dfa0 sp=0xc00009df70 pc=0x423c13
+runtime.bgscavenge(0x0?)
+	/usr/lib/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc00009dfc8 sp=0xc00009dfa0 pc=0x4241e5
+runtime.gcenable.func2()
+	/usr/lib/go/src/runtime/mgc.go:179 +0x26 fp=0xc00009dfe0 sp=0xc00009dfc8 pc=0x41ae86
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009dfe8 sp=0xc00009dfe0 pc=0x46e201
+created by runtime.gcenable
+	/usr/lib/go/src/runtime/mgc.go:179 +0xaa
+
+goroutine 17 [finalizer wait]:
+runtime.gopark(0x43ba92?, 0x4027d38828?, 0x0?, 0x0?, 0xc00009c770?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009c628 sp=0xc00009c608 pc=0x43b716
+runtime.runfinq()
+	/usr/lib/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00009c7e0 sp=0xc00009c628 pc=0x419f27
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009c7e8 sp=0xc00009c7e0 pc=0x46e201
+created by runtime.createfing
+	/usr/lib/go/src/runtime/mfinal.go:163 +0x45
+
+goroutine 5 [runnable]:
+runtime.asyncPreempt2()
+	/usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc000194658 sp=0xc000194638 pc=0x439e1f
+runtime.asyncPreempt()
+	/usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0001947e0 sp=0xc000194658 pc=0x46f85b
+cmd/compile/internal/ssagen.(*state).stmt(0xc0001fe500, {0xf2a400, 0xc000a990a0?})
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1432 +0xbb fp=0xc000194b68 sp=0xc0001947e0 pc=0xaf509b
+cmd/compile/internal/ssagen.(*state).stmtList(...)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421
+cmd/compile/internal/ssagen.buildssa(0xc0005d9540, 0x2)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:552 +0x1ee6 fp=0xc000194ea8 sp=0xc000194b68 pc=0xaf03e6
+cmd/compile/internal/ssagen.Compile(0xc0005d9540, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc000194f70 sp=0xc000194ea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc000194fb0 sp=0xc000194f70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc000194fe0 sp=0xc000194fb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000194fe8 sp=0xc000194fe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 33 [select]:
+runtime.gopark(0xc0000997b0?, 0x2?, 0xf0?, 0x95?, 0xc00009976c?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0000995a0 sp=0xc000099580 pc=0x43b716
+runtime.selectgo(0xc0000997b0, 0xc000099768, 0xc000110000?, 0x0, 0xd26040?, 0x1)
+	/usr/lib/go/src/runtime/select.go:327 +0x7be fp=0xc0000996e0 sp=0xc0000995a0 pc=0x44b8be
+cmd/compile/internal/gc.compileFunctions.func3()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:141 +0x132 fp=0xc0000997e0 sp=0xc0000996e0 pc=0xcc6a12
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000997e8 sp=0xc0000997e0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:134 +0xf8
+
+goroutine 22 [runnable]:
+runtime.asyncPreempt2()
+	/usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0000ad2d0 sp=0xc0000ad2b0 pc=0x439e1f
+runtime.asyncPreempt()
+	/usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0000ad458 sp=0xc0000ad2d0 pc=0x46f85b
+cmd/compile/internal/ssagen.(*state).stmt(0xc0016ada00, {0xf295c0, 0xc00134d450?})
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1455 +0x19a fp=0xc0000ad7e0 sp=0xc0000ad458 pc=0xaf517a
+cmd/compile/internal/ssagen.(*state).stmtList(...)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421
+cmd/compile/internal/ssagen.(*state).stmt(0xc0016ada00, {0xf29800, 0xc0013eebc0?})
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1441 +0x45e5 fp=0xc0000adb68 sp=0xc0000ad7e0 pc=0xaf95c5
+cmd/compile/internal/ssagen.(*state).stmtList(...)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421
+cmd/compile/internal/ssagen.buildssa(0xc0005d8b40, 0x3)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:552 +0x1ee6 fp=0xc0000adea8 sp=0xc0000adb68 pc=0xaf03e6
+cmd/compile/internal/ssagen.Compile(0xc0005d8b40, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0000adf70 sp=0xc0000adea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0000adfb0 sp=0xc0000adf70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0000adfe0 sp=0xc0000adfb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000adfe8 sp=0xc0000adfe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 49 [runnable]:
+runtime.asyncPreempt2()
+	/usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0017932d0 sp=0xc0017932b0 pc=0x439e1f
+runtime.asyncPreempt()
+	/usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc001793458 sp=0xc0017932d0 pc=0x46f85b
+cmd/compile/internal/ssagen.(*state).stmt(0xc001794000, {0xf295c0, 0xc00140a960?})
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1455 +0x19a fp=0xc0017937e0 sp=0xc001793458 pc=0xaf517a
+cmd/compile/internal/ssagen.(*state).stmtList(...)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421
+cmd/compile/internal/ssagen.(*state).stmt(0xc001794000, {0xf2a400, 0xc000a92a10?})
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1436 +0x150 fp=0xc001793b68 sp=0xc0017937e0 pc=0xaf5130
+cmd/compile/internal/ssagen.(*state).stmtList(...)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421
+cmd/compile/internal/ssagen.buildssa(0xc0005d9680, 0x0)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:552 +0x1ee6 fp=0xc001793ea8 sp=0xc001793b68 pc=0xaf03e6
+cmd/compile/internal/ssagen.Compile(0xc0005d9680, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc001793f70 sp=0xc001793ea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc001793fb0 sp=0xc001793f70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc001793fe0 sp=0xc001793fb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc001793fe8 sp=0xc001793fe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+```
+Steps to reproduce:
+1. Create an Arch Linux chroot from a bootstrap tarball: https://wiki.archlinux.org/title/Install_Arch_Linux_from_existing_Linux#Method_A:_Using_the_bootstrap_tarball_(recommended)
+2. Chroot into it using the following script:
+```
+#!/bin/bash
+
+basedir="/home/niko/chroots/arch-x86_64"
+cp /etc/resolv.conf ${basedir}/etc/
+cp /usr/bin/qemu-x86_64 ${basedir}/usr/bin/
+sed -i 's!#Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$arch!Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$a>
+mount --make-slave --bind  ${basedir} ${basedir}
+mount -t proc none ${basedir}/proc
+mount -t sysfs none ${basedir}/sys/
+mount --make-rslave --rbind /dev ${basedir}/dev
+mount --make-rslave --rbind /run ${basedir}/run
+chroot ${basedir} /bin/bash
+sleep 3
+umount -R ${basedir}/run
+umount -R ${basedir}/dev
+umount ${basedir}/sys
+umount ${basedir}/proc
+umount ${basedir}
+mount | grep chroots | grep arch-x86_64 | grep -v snap
+```
+3. Initialize pacaman keyring and update system:
+```
+# pacman-key --init
+# pacman-key --populate
+# pacman -Syu
+```
+4. Download the yay `PKGBUILD` from the AUR (https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=yay) and run `makepkg -s`
+5. Wait for the crash.
+Additional information:
+```
+Wed 2023-02-15 17:03:22 CET   495600 1000 1000 SIGILL  present  /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64                         >
+Wed 2023-02-15 17:11:25 CET   509058 1000 1000 SIGSEGV present  /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64                         >
+talos2 ~ # coredumpctl gdb 495600
+           PID: 495600 (go)
+           UID: 1000 (niko)
+           GID: 1000 (niko)
+        Signal: 4 (ILL)
+     Timestamp: Wed 2023-02-15 17:03:21 CET (13min ago)
+  Command Line: /usr/bin/qemu-x86_64 /usr/bin/go build -trimpath -mod=readonly -modcacherw -ldflags $'-X "main.yayVersion=11.3.2" -X "main.localePath=/usr/share/locale/" -linkmode=external' -buildmode=pie -o yay
+    Executable: /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64
+ Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope
+          Unit: user@1000.service
+     User Unit: vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope
+         Slice: user-1000.slice
+     Owner UID: 1000 (niko)
+       Boot ID: 33cad872d21043ebbe3dd6581bdd28c6
+    Machine ID: b3e834569b8ff461391f5ac061feb773
+      Hostname: talos2
+       Storage: /var/lib/systemd/coredump/core.go.1000.33cad872d21043ebbe3dd6581bdd28c6.495600.1676477001000000.zst (present)
+  Size on Disk: 7.4M
+       Message: Process 495600 (go) of user 1000 dumped core.
+
+GNU gdb (Gentoo 12.1 vanilla) 12.1
+Copyright (C) 2022 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+Type "show copying" and "show warranty" for details.
+This GDB was configured as "powerpc64le-unknown-linux-gnu".
+Type "show configuration" for configuration details.
+For bug reporting instructions, please see:
+<https://bugs.gentoo.org/>.
+Find the GDB manual and other documentation resources online at:
+    <http://www.gnu.org/software/gdb/documentation/>.
+
+For help, type "help".
+Type "apropos word" to search for commands related to "word"...
+Reading symbols from /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64...
+BFD: warning: /var/tmp/coredump-8CHpqc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002
+BFD: warning: /var/tmp/coredump-8CHpqc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
+BFD: warning: /var/tmp/coredump-8CHpqc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
+
+warning: Can't open file /usr/lib/ld-linux-x86-64.so.2 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libresolv.so.2 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libc.so.6 during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/f2/f2133743f1bb49d82c152c57fea6c71755a865029a19ff845dd27e420f5fa0be-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/89/89e115246dee235465b64002c5ab8a7df3a3f1b776d78dab9cd937c4892860a0-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/79/791d1887c70eed91dc52577c14310590649cb307ef557d46d8cc10df4704a957-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/86/86d5a3a0121a98ed0805aa57bc14d0bd85178c04054816d99495336d86c5bf5f-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/31/31d19f3051c8985f29f85ea43d9445e4b848c58a17a79d4e726280a9bced5743-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/79/79d75d9215f18cbef6b6a66468f78efd92edc13f7093f600b1552032732410aa-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/bc/bcdca8f344789eb190a1124fe919aa975d08f07250bfc6d780b0ae0cc28092fe-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/86/86e73e7b053ab6e1e1d149b5d1bbba621bfc3d0bbc66ec6310c072c82a7221e7-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/b1/b12eb8399331175352cb92b971280ba5c0c501c6ffa5c330921c3c0667c5f199-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/32/3264d3f95a5e2e731c952060b0cd4cb3bc37ff884513397336d40c935d098e5b-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/19/1977592d2d60e1dd1025609428d04f6cc17283759aae0c97bd8f35e8a341679b-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/a9/a9b261a012c19401c1fd78154a20f58bb7778e731e17f903eb3fe8ed3a5ddd59-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/96/9697f94a563c1bd04db2a82ac1770821f97548911f616dd1149bb87d0f48d65b-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/56/56e54c1dc0b6bee517915ce0bdf694a3b94f4de88b2cabb987b645e1255594fb-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/7e/7e9d9d14f25fe76951999c17680e09a181c5f14c9c4f30fe6bff8d0d669590c3-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/f4/f431652315a861a2a85b47ae12cfc99734b3db4754aa35c9158254e4ba3507c0-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/1c/1c51052ad1af6b1a1575f9bbc3f4616ed673578a285ae9a29f5548eed68c05dd-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/be/be3037525f021f1d7e2e8499d3dcc0f44be39adf70eb91979c96db3e5645bcf1-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/55/557fa6c4030abc2d7b6407ce3093ae5772939f1a2595be09dd670ecd1c5ec8f2-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/69/69a73f1b9f395cf4a1666dde8d7971a0bd9313fbfa55a5109eb02e59b301be09-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/ab/abc0750a5bd45b2346aa5bc87092f67207e9436307e3e32cb470952f87d13fb6-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/da/dadc71547f56ab68eccefd0d571599f99739a3d75acc444d97829d6ab62a6922-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/91/915619420aacc3b5964e7537365661258ab52ec44fb7ab29790258822c793de5-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/68/6834d594cb4ffe53979a0c4611bb5200e6e0c580acb42f4383ed2fb6a93d758d-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/c6/c6ccbc76ef432925fc1a5ea22ab750ac591f3e8983d2f33f54b01c799e3a274d-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/89/893c62418d079bf692b5ff17db226ae3d0fefdc87cbd0c64f30c437677a288ec-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/d8/d8666c5d7807c5a08b30f2278a1efd691c188804b3090704bd0b3f8ef06c40d9-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/d4/d401ca16783c19ff776f35305023173b63e2610e313b9a793734af80afda4e83-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/d0/d0593989dbf79e26b8bf6705325c6b44044e560a22c3ab81d320c67dcd97f1eb-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/57/572953ae015634b922f88b0191804a949206100adb6bd2454db615e2774dbe30-d during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libnss_mymachines.so.2 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libcap.so.2.67 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libgcc_s.so.1 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libnss_resolve.so.2 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libm.so.6 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libnss_myhostname.so.2 during file-backed mapping note processing
+
+warning: core file may not match specified executable file.
+[New LWP 495627]
+[New LWP 495604]
+[New LWP 495603]
+[New LWP 495614]
+[New LWP 495602]
+[New LWP 495610]
+[New LWP 495618]
+[New LWP 495606]
+[New LWP 495621]
+[New LWP 495608]
+[New LWP 495612]
+[New LWP 495629]
+[New LWP 495615]
+[New LWP 495622]
+[New LWP 495600]
+[New LWP 495605]
+[New LWP 495623]
+[New LWP 495630]
+[New LWP 495616]
+[New LWP 495633]
+[New LWP 495634]
+[New LWP 495635]
+[New LWP 495636]
+[New LWP 495637]
+[New LWP 495632]
+[New LWP 495609]
+[New LWP 495620]
+[New LWP 495617]
+[New LWP 495624]
+[New LWP 495628]
+[New LWP 495625]
+[New LWP 495607]
+[New LWP 495613]
+[New LWP 495626]
+[New LWP 495619]
+[New LWP 495611]
+[New LWP 495631]
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/usr/lib64/libthread_db.so.1".
+Core was generated by `/usr/bin/qemu-x86_64 /usr/bin/go build -trimpath -mod=readonly -modcacherw -ldf'.
+Program terminated with signal SIGILL, Illegal instruction.
+#0  0x00003fff9d5d7284 in code_gen_buffer ()
+[Current thread is 1 (Thread 0x3fff4bf3c380 (LWP 495627))]
+(gdb) info threads
+  Id   Target Id                          Frame 
+* 1    Thread 0x3fff4bf3c380 (LWP 495627) 0x00003fff9d5d7284 in code_gen_buffer ()
+  2    Thread 0x3fffa85ec380 (LWP 495604) 0x000000001029ba2c in __lll_lock_wait ()
+  3    Thread 0x3fffa862d380 (LWP 495603) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  4    Thread 0x3fffa8362380 (LWP 495614) 0x00000000100ef210 in tb_jmp_cache_get_tb (hash=3271, jc=0x3fff6c00c5c0)
+    at ../accel/tcg/tb-jmp-cache.h:38
+  5    Thread 0x3fffa8eaf380 (LWP 495602) 0x00000000102cf6ec in syscall ()
+  6    Thread 0x3fffa8466380 (LWP 495610) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  7    Thread 0x3fffa815d380 (LWP 495618) 0x00000000101e07c8 in g_hash_table_lookup ()
+  8    Thread 0x3fffa856a380 (LWP 495606) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  9    Thread 0x3fffa809a380 (LWP 495621) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  10   Thread 0x3fffa84e8380 (LWP 495608) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  11   Thread 0x3fffa83e4380 (LWP 495612) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  12   Thread 0x3fff4beba380 (LWP 495629) 0x00003fff9c1c84b8 in code_gen_buffer ()
+  13   Thread 0x3fffa8321380 (LWP 495615) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  14   Thread 0x3fffa86ae380 (LWP 495622) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  15   Thread 0x200f4000 (LWP 495600)     safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  16   Thread 0x3fffa85ab380 (LWP 495605) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  17   Thread 0x3fffa8059380 (LWP 495623) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  18   Thread 0x3fff4be79380 (LWP 495630) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  19   Thread 0x3fffa82e0380 (LWP 495616) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  20   Thread 0x3fff4bdb6380 (LWP 495633) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  21   Thread 0x3fff4bd75380 (LWP 495634) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  22   Thread 0x3fff4bd34380 (LWP 495635) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  23   Thread 0x3fff4bcf3380 (LWP 495636) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  24   Thread 0x3fff4bcb2380 (LWP 495637) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  25   Thread 0x3fff4bdf7380 (LWP 495632) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  26   Thread 0x3fffa84a7380 (LWP 495609) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  27   Thread 0x3fffa80db380 (LWP 495620) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  28   Thread 0x3fffa829f380 (LWP 495617) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  29   Thread 0x3fff4bfff380 (LWP 495624) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  30   Thread 0x3fff4befb380 (LWP 495628) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  31   Thread 0x3fff4bfbe380 (LWP 495625) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  32   Thread 0x3fffa8529380 (LWP 495607) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  33   Thread 0x3fffa83a3380 (LWP 495613) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  34   Thread 0x3fff4bf7d380 (LWP 495626) 0x00003fff9d5d7284 in code_gen_buffer ()
+  35   Thread 0x3fffa811c380 (LWP 495619) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  36   Thread 0x3fffa8425380 (LWP 495611) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  37   Thread 0x3fff4be38380 (LWP 495631) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+(gdb) quit
+talos2 ~ # coredumpctl gdb 509058
+           PID: 509058 (make)
+           UID: 1000 (niko)
+           GID: 1000 (niko)
+        Signal: 11 (SEGV)
+     Timestamp: Wed 2023-02-15 17:11:24 CET (6min ago)
+  Command Line: /usr/bin/qemu-x86_64 /usr/bin/make VERSION=11.3.2 DESTDIR=/home/niko/devel/yay/pkg/yay PREFIX=/usr build
+    Executable: /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64
+ Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope
+          Unit: user@1000.service
+     User Unit: vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope
+         Slice: user-1000.slice
+     Owner UID: 1000 (niko)
+       Boot ID: 33cad872d21043ebbe3dd6581bdd28c6
+    Machine ID: b3e834569b8ff461391f5ac061feb773
+      Hostname: talos2
+       Storage: /var/lib/systemd/coredump/core.make.1000.33cad872d21043ebbe3dd6581bdd28c6.509058.1676477484000000.zst (present)
+  Size on Disk: 1.0M
+       Message: Process 509058 (make) of user 1000 dumped core.
+
+GNU gdb (Gentoo 12.1 vanilla) 12.1
+Copyright (C) 2022 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+Type "show copying" and "show warranty" for details.
+This GDB was configured as "powerpc64le-unknown-linux-gnu".
+Type "show configuration" for configuration details.
+For bug reporting instructions, please see:
+<https://bugs.gentoo.org/>.
+Find the GDB manual and other documentation resources online at:
+    <http://www.gnu.org/software/gdb/documentation/>.
+
+For help, type "help".
+Type "apropos word" to search for commands related to "word"...
+Reading symbols from /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64...
+BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002
+BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002
+BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
+BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
+
+warning: Can't open file /usr/lib/ld-linux-x86-64.so.2 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libguile-3.0.so.1.6.0 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libc.so.6 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libgc.so.1.5.1 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libffi.so.8.1.2 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libunistring.so.5.0.0 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libgmp.so.10.4.1 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libcrypt.so.2.0.0 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libm.so.6 during file-backed mapping note processing
+
+warning: core file may not match specified executable file.
+[New LWP 509058]
+[New LWP 509060]
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/usr/lib64/libthread_db.so.1".
+Core was generated by `/usr/bin/qemu-x86_64 /usr/bin/make VERSION=11.3.2 DESTDIR=/home/niko/devel/yay/'.
+Program terminated with signal SIGSEGV, Segmentation fault.
+#0  0x0000000010278798 in sigsuspend ()
+[Current thread is 1 (Thread 0x1bde9000 (LWP 509058))]
+(gdb) info threads
+  Id   Target Id                          Frame 
+* 1    Thread 0x1bde9000 (LWP 509058)     0x0000000010278798 in sigsuspend ()
+  2    Thread 0x3fffae0ef380 (LWP 509060) 0x00000000102cf6ec in syscall ()
+(gdb) quit
+```
+
+Download coredumps:
+
+https://drive.google.com/file/d/1GosaobKvmuRg-olaA1-aZcp7zAZcWmcF/view?usp=share_link
+
+https://drive.google.com/file/d/1N0BmlBIYY-qT5lHqlrKXvPL_FdYl3GfI/view?usp=share_link
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1501 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1501
new file mode 100644
index 00000000..97e7ea59
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1501
@@ -0,0 +1 @@
+IBM AIX 73 not supported under QEMU
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1509 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1509
new file mode 100644
index 00000000..14f7b582
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1509
@@ -0,0 +1,161 @@
+ppc64 tcg guests get incorrect Capacity Entitlement values from SMP spapr machine's RTAS - examples given from AIX guest OS
+Description of problem:
+Entitled Capacity of the guest OS is not equal to the number of vCPUs you configure with QEMU.
+
+It only gives you 1/4 entitlements to your configured capacity, and if you increase the number of processors, it converts the LPAR capacity to hundredths of a core, throttling guest performance.
+Steps to reproduce:
+Definition of terms from lparstat:
+Entitled Capacity: The number of processing units this LPAR is entitled to receive.
+Maximum Capacity: The maximum number of processing units this LPAR was defined to ever have. Entitled capacity can be increased up to this value.
+
+Some examples:
+
+1 QEMU vCPU:
+Entitled Capacity: 0.25
+Maximum Capacity: 1.00
+
+2 QEMU vCPUs (-smp cpus=2,sockets=1,cores=2,threads=1):
+Entitled Capacity = 0.50
+Maximum Capacity: 0.02
+
+3 QEMU CPUs (-smp cpus=3,sockets=1,cores=3,threads=1):
+Entitled Capacity = 0.75
+Maximum Capacity: 0.03
+
+4 QEMU CPUs (-smp cpus=4,sockets=1,cores=4,threads=1):
+Entitled Capacity = 1.00
+Maximum Capacity: 0.04
+
+I believe these Entitled and Maximum values are comming from the spapr machine's MaxEntCap, DesProcs and MaxPlatProcs settings which get affected by -smp passed to QEMU.
+Additional information:
+Details:
+
+1 QEMU vCPU:
+   ```
+kens@aix-ppc64$ lparstat -i | head -20
+Node Name                                  : aix-ppc64
+Partition Name                             : IBM AIX - IBM POWER9
+Partition Number                           : 0
+Type                                       : Shared
+Mode                                       : Capped
+Entitled Capacity                          : 0.25
+Partition Group-ID                         : 1
+Shared Pool ID                             : 1
+Online Virtual CPUs                        : 1
+Maximum Virtual CPUs                       : 1
+Minimum Virtual CPUs                       : 1
+Online Memory                              : 8192 MB
+Maximum Memory                             : 8192 MB
+Minimum Memory                             : 8192 MB
+Variable Capacity Weight                   : 128
+Minimum Capacity                           : 0.01
+Maximum Capacity                           : 1.00
+Capacity Increment                         : 1.00
+Maximum Physical CPUs in system            : 1
+Active Physical CPUs in system             : 1
+   ```
+2 QEMU vCPUs:
+   ```
+kens@aix-ppc64$ lparstat -i | head -20
+Node Name                                  : aix-ppc64
+Partition Name                             : IBM AIX - IBM POWER9
+Partition Number                           : 0
+Type                                       : Shared
+Mode                                       : Capped
+Entitled Capacity                          : 0.50
+Partition Group-ID                         : 1
+Shared Pool ID                             : 1
+Online Virtual CPUs                        : 2
+Maximum Virtual CPUs                       : 2
+Minimum Virtual CPUs                       : 2
+Online Memory                              : 8192 MB
+Maximum Memory                             : 8192 MB
+Minimum Memory                             : 8192 MB
+Variable Capacity Weight                   : 128
+Minimum Capacity                           : 0.02
+Maximum Capacity                           : 0.02
+Capacity Increment                         : 1.00
+Maximum Physical CPUs in system            : 2
+Active Physical CPUs in system             : 2
+   ```
+3 QEMU vCPUs:
+   ```
+kens@aix-ppc64$ lparstat -i | head -20
+Node Name                                  : aix-ppc64
+Partition Name                             : IBM AIX - IBM POWER9
+Partition Number                           : 0
+Type                                       : Shared
+Mode                                       : Capped
+Entitled Capacity                          : 0.75
+Partition Group-ID                         : 1
+Shared Pool ID                             : 1
+Online Virtual CPUs                        : 3
+Maximum Virtual CPUs                       : 3
+Minimum Virtual CPUs                       : 3
+Online Memory                              : 8192 MB
+Maximum Memory                             : 8192 MB
+Minimum Memory                             : 8192 MB
+Variable Capacity Weight                   : 128
+Minimum Capacity                           : 0.03
+Maximum Capacity                           : 0.03
+Capacity Increment                         : 1.00
+Maximum Physical CPUs in system            : 3
+Active Physical CPUs in system             : 3
+   ```
+4 QEMU vCPUs:
+   ```
+kens@aix-ppc64$ lparstat -i | head -2
+lparstat -i | head -2
+Node Name                                  : aix-ppc64
+Partition Name                             : IBM AIX - IBM POWER9
+kens@aix-ppc64$ lparstat -i | head -20
+lparstat -i | head -20
+Node Name                                  : aix-ppc64
+Partition Name                             : IBM AIX - IBM POWER9
+Partition Number                           : 0
+Type                                       : Shared
+Mode                                       : Capped
+Entitled Capacity                          : 1.00
+Partition Group-ID                         : 1
+Shared Pool ID                             : 1
+Online Virtual CPUs                        : 4
+Maximum Virtual CPUs                       : 4
+Minimum Virtual CPUs                       : 4
+Online Memory                              : 8192 MB
+Maximum Memory                             : 8192 MB
+Minimum Memory                             : 8192 MB
+Variable Capacity Weight                   : 128
+Minimum Capacity                           : 0.04
+Maximum Capacity                           : 0.04
+Capacity Increment                         : 1.00
+Maximum Physical CPUs in system            : 4
+Active Physical CPUs in system             : 4
+   ```
+So it seems to me like the OS assumes the following from the spapr machine settings:
+Entitled Capacity = cpus / 4 (OS is assuming smt=4 threads maybe, see below)
+Maximim Capacity = cpus / 100 (OS is assuming hundredths of a core, even though the Capacity Increment is 1.00, see below))
+
+On a real Power system (POWER8, smt=8), it looks like this:
+   ```
+kens@aix72$ lparstat -i | head -20
+Node Name                                  : aix72
+Partition Name                             : n1
+Partition Number                           : 1
+Type                                       : Shared-SMT-4
+Mode                                       : Uncapped
+Entitled Capacity                          : 6.00
+Partition Group-ID                         : 32784
+Shared Pool ID                             : 0
+Online Virtual CPUs                        : 12
+Maximum Virtual CPUs                       : 28
+Minimum Virtual CPUs                       : 1
+Online Memory                              : 131072 MB
+Maximum Memory                             : 196608 MB
+Minimum Memory                             : 1024 MB
+Variable Capacity Weight                   : 128
+Minimum Capacity                           : 0.50
+Maximum Capacity                           : 14.00
+Capacity Increment                         : 0.01
+Maximum Physical CPUs in system            : 80
+Active Physical CPUs in system             : 80
+   ```
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1535 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1535
new file mode 100644
index 00000000..73adbfdb
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1535
@@ -0,0 +1,91 @@
+spapr set host serial number visible to AIX from -M pseries,host-serial and not -uuid
+Description of problem:
+-M pseries,host-serial populates "/host-serial" which is not used in AIX and populates "/system-id" with UUID instead of serial number. Patch to write host-serial passed to -M as "/system-id" prefixed with IBM,06 visible from `uname -u` and `nmon`.
+Steps to reproduce:
+1. Set -uuid and -M pseries,host-serial
+2. Execute `uname -u` and `nmon` in guest
+Additional information:
+Patch:
+```
+diff -ru a/hw/ppc/spapr.c b/hw/ppc/spapr.c
+--- a/hw/ppc/spapr.c    2023-03-06 13:59:32.942881783 -0500
++++ b/hw/ppc/spapr.c    2023-03-06 21:37:32.504570961 -0500
+@@ -1163,7 +1163,10 @@
+     }
+
+     if (spapr->host_serial) {
+-        _FDT(fdt_setprop_string(fdt, 0, "host-serial", spapr->host_serial));
++        /* plus 1 byte for null character */
++        char result[sizeof("IBM,06") + sizeof(spapr->host_serial) + 1];
++        snprintf(result, sizeof(result), "%s%s", "IBM,06", spapr->host_serial);
++        _FDT(fdt_setprop_string(fdt, 0, "system-id", result));
+     } else if (smc->broken_host_serial_model && kvmppc_get_host_serial(&buf)) {
+         _FDT(fdt_setprop_string(fdt, 0, "host-serial", buf));
+         g_free(buf);
+```
+
+Before patch:
+```
+$ uname -u
+2d861abf-5cb7-434a-86d5-65167d85e5af
+
+$ nmon
+┌──────────────────────────────────────────────────────────────────────────────────┐
+│  ------------------------------                                                  │
+│  N    N  M    M   OOOO   N    N   For online help type: h                        │
+│  NN   N  MM  MM  O    O  NN   N   For command line option help:                  │
+│  N N  N  M MM M  O    O  N N  N      quick-hint  nmon -?                         │
+│  N  N N  M    M  O    O  N  N N    full-details  nmon -h                         │
+│  N   NN  M    M  O    O  N   NN   To start nmon the same way every time?         │
+│  N    N  M    M   OOOO   N    N    set NMON ksh variable, for example:           │
+│  ------------------------------    export NMON=cmt                               │
+│    TOPAS_NMON                                                                    │
+│                               8 - CPUs currently                                 │
+│                               8 - CPUs configured                                │
+│                            1000 - MHz CPU clock rate (press 'r' for current MHz) │
+│                 PowerPC_POWER10 - Processor                                      │
+│                          64 bit - Hardware                                       │
+│                          64 bit - Kernel                                         │
+│         0,IBM AIX - IBM POWER10 - Logical Partition                              │
+│                  7.2.5.200 TL05 - AIX Kernel Version                             │
+│                       aix-ppc64 - Hostname                                       │
+│                       aix-ppc64 - Node/WPAR Name                                 │
+│                         bf-5cb7 - Serial Number                                  │
+│                    IBM,9080-HEX - Machine Type                                   │
+│                                                                                  │
+│                                                                                  │
+└──────────────────────────────────────────────────────────────────────────────────
+```
+After patch:
+```
+$ uname -u
+IBM,0678AB123
+
+$ nmon
+┌──────────────────────────────────────────────────────────────────────────────────┐
+│  ------------------------------                                                  │
+│  N    N  M    M   OOOO   N    N   For online help type: h                        │
+│  NN   N  MM  MM  O    O  NN   N   For command line option help:                  │
+│  N N  N  M MM M  O    O  N N  N      quick-hint  nmon -?                         │
+│  N  N N  M    M  O    O  N  N N    full-details  nmon -h                         │
+│  N   NN  M    M  O    O  N   NN   To start nmon the same way every time?         │
+│  N    N  M    M   OOOO   N    N    set NMON ksh variable, for example:           │
+│  ------------------------------    export NMON=cmt                               │
+│    TOPAS_NMON                                                                    │
+│                               8 - CPUs currently                                 │
+│                               8 - CPUs configured                                │
+│                            1000 - MHz CPU clock rate (press 'r' for current MHz) │
+│                 PowerPC_POWER10 - Processor                                      │
+│                          64 bit - Hardware                                       │
+│                          64 bit - Kernel                                         │
+│         0,IBM AIX - IBM POWER10 - Logical Partition                              │
+│                  7.2.5.200 TL05 - AIX Kernel Version                             │
+│                       aix-ppc64 - Hostname                                       │
+│                       aix-ppc64 - Node/WPAR Name                                 │
+│                         78AB123 - Serial Number                                  │
+│                    IBM,9080-HEX - Machine Type                                   │
+│                                                                                  │
+│                                                                                  │
+└──────────────────────────────────────────────────────────────────────────────────
+```
+Note first 6 characters of serial number are cropped by nmon ("IBM,06")
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1539 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1539
new file mode 100644
index 00000000..ecac0c76
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1539
@@ -0,0 +1,3 @@
+Support for SPC58NH92C5
+Additional information:
+
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1547 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1547
new file mode 100644
index 00000000..3819473c
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1547
@@ -0,0 +1,12 @@
+POWER9 emulation is broken when compiler optimizations are on (for gcc 11.3 and later)
+Description of problem:
+Comparing two floating point memory operands produces incorrect result
+Steps to reproduce:
+1. Unpack attached archive and change to test_p64 directory
+2. Build the source file with: powerpc64le-linux-gnu-g++ -O2 -static test.cpp -o test_p64
+3. Run with QEMU: qemu-ppc64le -cpu POWER9 test_p64 > output.txt
+4. Check the output text file output.txt (with pluma or any other text editor) to see the printouts
+Additional information:
+The pre-built binary and its output file are attached as test_p64.tar.gz[test_p64.tar.gz](/uploads/0e9dbc22e6841496efc15775e6aa624a/test_p64.tar.gz)
+
+The purpose of this report is to motivate the creation of a point release QEMU 6.2.1 for Ubuntu 22.04 LTS (which will be supported for years to come). Also cross-linking similar bug report for MIPS with exact same goal: https://gitlab.com/qemu-project/qemu/-/issues/1531
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1623 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1623
new file mode 100644
index 00000000..a504dc75
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1623
@@ -0,0 +1,9 @@
+vec_lde and vec_expte semi-randomly produce the wrong results
+Description of problem:
+I found that while implementing the Altivec support for the rust [stdarch](https://github.com/rust-lang/stdarch).
+Steps to reproduce:
+1. Install rust nightly (e.g. using https://rustup.rs/)
+2. `git clone https://github.com/rust-lang/stdarch`
+3. You need to either cross compile or compile and run the tests for `crates/core_arch`.
+Additional information:
+Both `valgrind` and running on power9 produce the correct results
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/168 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/168
new file mode 100644
index 00000000..ea3b3044
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/168
@@ -0,0 +1 @@
+ivshmem PCI device exposes wrong endianness on ppc64le
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1779 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1779
new file mode 100644
index 00000000..12d78ef2
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1779
@@ -0,0 +1,30 @@
+PowerPC AltiVec source vector subnormal values are not flushed to zero
+Description of problem:
+AltiVec specifies that source and result vectors are flushed to zero (in NJ mode).  Only result vectors are flushed to zero.
+Steps to reproduce:
+1. Compile the attached Rust program (e.g. `cargo +nightly build --target powerpc-unknown-linux-gnu`)
+2. Run the program and expect assertions to pass.
+3. See assertions fail.
+Additional information:
+See the offending Rust program:
+
+```
+#![feature(stdsimd, powerpc_target_feature)]
+
+use std::arch::powerpc::*;
+
+#[target_feature(enable = "altivec")]
+unsafe fn add(x: f32, y: f32) -> f32 {
+    let array: [f32; 4] = unsafe { std::mem::transmute(vec_add(vec_splats(x), vec_splats(y))) };
+    array[0]
+}
+
+pub fn main() {
+    let result = unsafe { add(-1.0857398e-38, 0.) };
+    assert_eq!(result, 0.);
+
+    // if the input is flushed, the result will be +0
+    // if only the output is flushed, the result is -0
+    assert!(result.is_sign_positive());
+}
+```
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1780 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1780
new file mode 100644
index 00000000..3ef1ce9e
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1780
@@ -0,0 +1,17 @@
+PowerPC mishandles xscmpudp instruction
+Description of problem:
+xscmpudp instruction is mishandled
+Steps to reproduce:
+1. Compile the attached program with VSX (e.g. `RUSTFLAGS=-Ctarget-feature=+vsx cargo build --target=powerpc64-unknown-linux-gnu`)
+2. Run the program and expect assertions to pass.
+3. See assertions fail.
+Additional information:
+When VSX is disabled, the `fcmpu` instruction is emitted instead (and handled properly).  See the offending program:
+```
+pub fn main() {
+    use std::hint::black_box;
+    assert!(black_box(f64::NAN)
+        .clamp(black_box(0f64), black_box(0f64))
+        .is_nan());
+}
+```
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1836 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1836
new file mode 100644
index 00000000..0f858140
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1836
@@ -0,0 +1 @@
+AIX no longer boots
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1917 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1917
new file mode 100644
index 00000000..b04e02b9
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1917
@@ -0,0 +1,51 @@
+cargo on ppc64 fails: invalid instruction: *EDIT*: on ntpdate as well
+Description of problem:
+Machine boots,
+but when compiling a rust library, the following issue appears:
+```
+cargo  build --release --manifest-path rust-src/Cargo.toml
+cargo[376]: illegal instruction (4) at 12e0933c0 nip 12e0933c0 lr 12dd7c768 code 1 in cargo[12dc10000+956000]
+cargo[376]: code: 00000000 00000000 00000000 7c0802a6 f8010010 f821ff11 fba100d8 60000000 
+cargo[376]: code: fbc100e0 8862cd50 28030000 418200d4 <104214c4> 38810070 3bc00000 7c4021ce 
+make: *** [Makefile:133: rust-src/target/release/libbcachefs_rust.a] Illegal instruction (core dumped)
+make: *** Waiting for unfinished jobs....
+ar[375]: illegal instruction (4) at 3fff9b2a4dac nip 3fff9b2a4dac lr 3fff9b2a4da4 code 1 in libLLVM-16.so.1[3fff99f10000+792f000]
+ar[375]: code: f87d0028 7fa3eb78 b29d0090 f89d0020 4810a8c1 60000000 7f83e378 7fa4eb78 
+ar[375]: code: 7fc5f378 49bfd3e1 e8410028 60000000 <104214c4> 38810070 fb610080 eba29fe0 
+make: *** [Makefile:129: libbcachefs.a] Illegal instruction (core dumped)
+make: *** Deleting file 'libbcachefs.a'
+```
+the core dump files of cargo and ar are attached
+
+~~I have no clue whether this is a rustc or qemu bug, so please let me know if this issue should be forwarded to rust devs~~
+EDIT: as this happens with ntpdate as well, I think it's an emulator issue:
+
+```
+ntpdig[1179]: illegal instruction (4) at 102382c4 nip 102382c4 lr 102382a8 code 1 in python3.11[10000000+63e000]
+ntpdig[1179]: code: 3d22ffdd c8094448 fc1e0000 41c2022c 4bde9b5d e8410028 3d42ffdd 39200000 
+ntpdig[1179]: code: c80a4450 91230000 fc1e0000 41c001a4 <ffe0f02c> fc1ff800 41c30280 3d22ffdd 
+```
+Steps to reproduce:
+1. create a debian ppc64 root image using debian sid & debootstrap
+2. install rust using rustup
+3. compile bcachefs-tools in ppc64
+
+2b. Install ntpdate using apt-get ntpdate
+3b. run ntpdate
+Additional information:
+Core dump command:
+```
+cat /proc/sys/kernel/core_pattern
+|/bin/cp --sparse=always /dev/stdin /host//repos/janpieter/linux/bcachefs/ktest-out/core.%e.PID%p.SIG%s.TIME%t
+```
+
+
+[core.ar.PID374.SIG4.TIME1696070088.xz](/uploads/6a540c4d13351871b1e22153ad87ab99/core.ar.PID374.SIG4.TIME1696070088.xz) AR core dump
+
+[core.ar.PID375.SIG4.TIME1696070088.xz](/uploads/7c314eba58c2190e3a9fbd88f8eb1242/core.ar.PID375.SIG4.TIME1696070088.xz) AR core dump
+
+[core.cargo.PID375.SIG4.TIME1696070087.xz](/uploads/0097d457eb2d25e0123874b59405647a/core.cargo.PID375.SIG4.TIME1696070087.xz) cargo core dump 
+
+[core.cargo.PID376.SIG4.TIME1696070087.xz](/uploads/53834fa9608036d6de9dafc3f778f165/core.cargo.PID376.SIG4.TIME1696070087.xz) cargo core dump
+
+[core.ntpdig.PID1171.SIG4.TIME1696070657.xz](/uploads/8a96d86338d7c6bebe39657a24f570d8/core.ntpdig.PID1171.SIG4.TIME1696070657.xz) ntpdig core dump
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1941 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1941
new file mode 100644
index 00000000..fdc15880
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1941
@@ -0,0 +1,102 @@
+ppc64: VSX vector float to integer conversion instructions do not always return expected results on QEMU 8.0.4 if source vector has NaN values
+Description of problem:
+The problem is that the VSX xvcvspsxws/xvcvdpsxws/xvcvspsxds/xvcvdpsxds/xvcvspuxws/xvcvdpuxds/xvcvspuxds/xvcvdpuxws instructions incorrectly convert the preceding non-NaN source values to the NaN to integer result instead of the expected non-NaN to integer conversion result with qemu-ppc64le 8.0.4.
+
+Here are the results of the VSX operations whose results differ from the expected results with QEMU 8.0.4 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 8.0.4):
+```
+xvcvspsxds ({1, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808}
+xvcvspsxds ({nan, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808}
+xvcvspsxds ({1, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808}
+xvcvspsxds ({nan, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808}
+
+xvcvspsxws ({1, nan, 3, 4}) = {-2147483648, -2147483648, 3, 4}
+xvcvspsxws ({1, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4}
+xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4}
+xvcvspsxws ({1, nan, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4}
+xvcvspsxws ({1, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648}
+xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648}
+xvcvspsxws ({1, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648}
+xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648}
+xvcvspsxws ({1, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648}
+xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648}
+xvcvspsxws ({1, nan, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648}
+
+xvcvspuxds ({1, 2, 3, nan}) = {0, 0}
+xvcvspuxds ({nan, 2, 3, nan}) = {0, 0}
+xvcvspuxds ({1, 2, nan, nan}) = {0, 0}
+xvcvspuxds ({nan, 2, nan, nan}) = {0, 0}
+
+xvcvspuxws ({1, nan, 3, 4}) = {0, 0, 3, 4}
+xvcvspuxws ({1, 2, nan, 4}) = {0, 0, 0, 4}
+xvcvspuxws ({nan, 2, nan, 4}) = {0, 0, 0, 4}
+xvcvspuxws ({1, nan, nan, 4}) = {0, 0, 0, 4}
+xvcvspuxws ({1, 2, 3, nan}) = {0, 0, 0, 0}
+xvcvspuxws ({nan, 2, 3, nan}) = {0, 0, 0, 0}
+xvcvspuxws ({1, nan, 3, nan}) = {0, 0, 0, 0}
+xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 0, 0}
+xvcvspuxws ({1, 2, nan, nan}) = {0, 0, 0, 0}
+xvcvspuxws ({nan, 2, nan, nan}) = {0, 0, 0, 0}
+xvcvspuxws ({1, nan, nan, nan}) = {0, 0, 0, 0}
+
+xvcvdpsxws ({1, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648}
+
+xvcvdpuxws ({1, nan}) = {0, 0, 0, 0}
+
+xvcvdpsxds ({1, nan}) = {-9223372036854775808, -9223372036854775808}
+
+xvcvdpuxds ({1, nan}) = {0, 0}
+```
+
+Here are the results of the same VSX conversion operations with QEMU 6.2.0 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 6.2.0):
+```
+xvcvspsxds ({1, 2, 3, nan}) = {2, -9223372036854775808}
+xvcvspsxds ({nan, 2, 3, nan}) = {2, -9223372036854775808}
+xvcvspsxds ({1, 2, nan, nan}) = {2, -9223372036854775808}
+xvcvspsxds ({nan, 2, nan, nan}) = {2, -9223372036854775808}
+
+xvcvspsxws ({1, nan, 3, 4}) = {1, -2147483648, 3, 4}
+xvcvspsxws ({1, 2, nan, 4}) = {1, 2, -2147483648, 4}
+xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, 2, -2147483648, 4}
+xvcvspsxws ({1, nan, nan, 4}) = {1, -2147483648, -2147483648, 4}
+xvcvspsxws ({1, 2, 3, nan}) = {1, 2, 3, -2147483648}
+xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, 2, 3, -2147483648}
+xvcvspsxws ({1, nan, 3, nan}) = {1, -2147483648, 3, -2147483648}
+xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, 3, -2147483648}
+xvcvspsxws ({1, 2, nan, nan}) = {1, 2, -2147483648, -2147483648}
+xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, 2, -2147483648, -2147483648}
+xvcvspsxws ({1, nan, nan, nan}) = {1, -2147483648, -2147483648, -2147483648}
+
+xvcvspuxds ({1, 2, 3, nan}) = {2, 0}
+xvcvspuxds ({nan, 2, 3, nan}) = {2, 0}
+xvcvspuxds ({1, 2, nan, nan}) = {2, 0}
+xvcvspuxds ({nan, 2, nan, nan}) = {2, 0}
+
+xvcvspuxws ({1, nan, 3, 4}) = {1, 0, 3, 4}
+xvcvspuxws ({1, 2, nan, 4}) = {1, 2, 0, 4}
+xvcvspuxws ({nan, 2, nan, 4}) = {0, 2, 0, 4}
+xvcvspuxws ({1, nan, nan, 4}) = {1, 0, 0, 4}
+xvcvspuxws ({1, 2, 3, nan}) = {1, 2, 3, 0}
+xvcvspuxws ({nan, 2, 3, nan}) = {0, 2, 3, 0}
+xvcvspuxws ({1, nan, 3, nan}) = {1, 0, 3, 0}
+xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 3, 0}
+xvcvspuxws ({1, 2, nan, nan}) = {1, 2, 0, 0}
+xvcvspuxws ({nan, 2, nan, nan}) = {0, 2, 0, 0}
+xvcvspuxws ({1, nan, nan, nan}) = {1, 0, 0, 0}
+
+xvcvdpsxws ({1, nan}) = {0, 1, 0, -2147483648}
+
+xvcvdpuxws ({1, nan}) = {0, 1, 0, 0}
+
+xvcvdpsxds ({1, nan}) = {1, -9223372036854775808}
+
+xvcvdpuxds ({1, nan}) = {1, 0}
+```
+Steps to reproduce:
+1. Compile the attached vsx_f2i_nan_test_program_101423.cpp with either `powerpc64le-linux-gnu-g++` or `clang --target=powerpc64le-linux-gnu`
+2. Run the compiled vsx_f2i_nan_test_program_101423.cpp program using qemu-ppc64le
+3. The vsx_f2i_nan_test_program_101423 program will return the results of the xvcvspsxws, xvcvdpsxws, xvcvspsxds, xvcvdpsxds, xvcvspuxws, xvcvdpuxds, xvcvspuxds, or xvcvdpuxws instruction.
+Additional information:
+Attachments:
+- [vsx_f2i_nan_test_program_101423.cpp](/uploads/749395aee2da1dcc86790804106d30ea/vsx_f2i_nan_test_program_101423.cpp)
+- [vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt](/uploads/c883c4d04730a9c5a7e301e5d487ae2b/vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 6.2.0
+- [vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt](/uploads/9451e3419f8a4f3ef2274b2ccc7ef22d/vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 8.0.4
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1955 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1955
new file mode 100644
index 00000000..a03f18ed
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1955
@@ -0,0 +1,26 @@
+powerpc instruction 'mffsl' not emulated on POWER8
+Description of problem:
+Since 2019, the function feenableexcept() in GNU libc makes use of the "mffsl" instruction.
+See https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/feenablxcpt.c;h=b111ceaa4e2e1864fcbe043ccda34e03e9f14062;hb=HEAD#l28
+and https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/fenv_libc.h;h=a2a12d914b47e99746003482b349a0675cc5ad34;hb=HEAD#l57
+
+In the emulated Debian system, executables that make use of this instruction crash with SIGILL.
+Likewise, under gdb (in the emulated system), there is a SIGILL at the 'mffsl' instruction.
+
+From the comments in the above glibc source, added by Paul A. Clarke <pc@us.ibm.com>:
+  "Nicely, it turns out that the 'mffsl' instruction will decode to
+   'mffs' on architectures older than "power9" because the additional
+   bits set for 'mffsl' are "don't care" for 'mffs'.  'mffs' is a superset
+   of 'mffsl'."
+
+This is indeed what I observe by compiling and running the attached program foo.c on a hardware machine with a POWER8 CPU: That program does not crash with a SIGILL.
+Steps to reproduce:
+1. Either run the attached 'test-fenv-except-tracking-5.ppc' (32-bit) program under qemu-system-ppc.
+2. Or run the the attached 'test-fenv-except-tracking-5.ppc64' (64-bit) program under qemu-system-ppc64 with -cpu POWER8.
+3. Or compile and run the attached foo.c and run it under QEMU.
+Additional information:
+[test-fenv-except-tracking-5.ppc.xz](/uploads/8222ebac115e8a865d5e520b25d423ff/test-fenv-except-tracking-5.ppc.xz)
+
+[test-fenv-except-tracking-5.ppc64.xz](/uploads/d0522723541a46e11ab55b8f45dfb574/test-fenv-except-tracking-5.ppc64.xz)
+
+[foo.c](/uploads/35d8b3b1e5b39ecb6a2a899132858ded/foo.c)
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1958 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1958
new file mode 100644
index 00000000..5586e228
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1958
@@ -0,0 +1,21 @@
+PPC msgsnd for DOORBELL CRITICAL masked by MSR[EE] instead of MSR[CE]
+Description of problem:
+When executing PPC instruction "msgsnd r3. with r3 = 0x08000001" an DOORBELL CRITICAL exception is raised on core number 1. But this exception is masked by MSR\[EE\] bit, the MSR\[EE\] should be set to 1 in core1 to get this exception. But the NXP E500MCRM.pdf reference manual indicates that MSR\[CE\] is the mask bit for DOORBELL_CRITICAL Exception.
+Additional information:
+In qemu-8.1.2/target/ppc/excp_helper.c i try to change in ppc_next_unmasked_interrupt_generic function:
+   
+```
+if (FIELD_EX64(env->msr, MSR, CE)) {
+    /* Critical doorbell */
+    if (env->pending_interrupts & PPC_INTERRUPT_CDOORBELL) {   <- move this part from (async_deliver != 0)
+        return PPC_INTERRUPT_CDOORBELL;
+     }
+     /* External critical interrupt */
+     if (env->pending_interrupts & PPC_INTERRUPT_CEXT) {
+         return PPC_INTERRUPT_CEXT;
+     }
+}
+```
+ 
+
+And it seems to work in my case.
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/1992 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1992
new file mode 100644
index 00000000..77f887f4
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/1992
@@ -0,0 +1,909 @@
+ReverseDebugging_ppc64 avocado test is not working reliably
+Description of problem:
+The tests/avocado/reverse_debugging.py:ReverseDebugging_ppc64.test_ppc64_powernv test is sometimes failing in the gitlab-CI. Looking at the logs, it seems like QEMU is dying early here, so this might be a real bug and not only an issue with the test. Full debug.log from the failing job:
+
+```
+08:28:31 DEBUG| PARAMS (key=arch, path=*, default=ppc64) => 'ppc64'
+08:28:31 DEBUG| PARAMS (key=cpu, path=*, default=None) => None
+08:28:31 DEBUG| PARAMS (key=qemu_bin, path=*, default=./qemu-system-ppc64) => './qemu-system-ppc64'
+08:28:31 DEBUG| PARAMS (key=machine, path=*, default=powernv) => 'powernv'
+08:28:31 INFO | creating qcow2 image for VM snapshots
+08:28:31 INFO | Running '/builds/thuth/qemu/build/qemu-img create -f qcow2 /builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/disk.qcow2 128M'
+08:28:31 DEBUG| [stdout] Formatting '/builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/disk.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=134217728 lazy_refcounts=off refcount_bits=16
+08:28:31 INFO | Command '/builds/thuth/qemu/build/qemu-img create -f qcow2 /builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/disk.qcow2 128M' finished with 0 after 0.024550681999926383s
+08:28:31 DEBUG| QEMUMachine "1646a50b-5d2a-405b-8636-45a38b5fde30" created
+08:28:31 DEBUG| QEMUMachine "1646a50b-5d2a-405b-8636-45a38b5fde30" temp_dir: /builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/qemu-machine-uq5k4nlc
+08:28:31 DEBUG| QEMUMachine "1646a50b-5d2a-405b-8636-45a38b5fde30" log_dir: /builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv
+08:28:31 INFO | recording the execution...
+08:28:31 DEBUG| Using selector: EpollSelector
+08:28:31 DEBUG| Registering <qemu.qmp.events.EventListener object at 0x7ff6584bae50>.
+08:28:31 DEBUG| VM launch command: './qemu-system-ppc64 -display none -vga none -chardev socket,id=mon,fd=5 -mon chardev=mon,mode=control -machine powernv -chardev socket,id=console,fd=19 -serial chardev:console -icount shift=7,rr=record,rrfile=/builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/replay.bin,rrsnapshot=init -net none -drive file=/builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/disk.qcow2,if=none'
+08:28:31 DEBUG| Transitioning from 'Runstate.IDLE' to 'Runstate.CONNECTING'.
+08:28:31 DEBUG| Connecting with existing socket: fd=12, family=<AddressFamily.AF_UNIX: 1>, type=<SocketKind.SOCK_STREAM: 1>
+08:28:31 DEBUG| Connected.
+08:28:31 DEBUG| Awaiting greeting ...
+08:28:31 DEBUG| <-- {
+  "QMP": {
+    "version": {
+      "qemu": {
+        "micro": 90,
+        "minor": 1,
+        "major": 8
+      },
+      "package": "v5.2.0-26508-gaf9264da80"
+    },
+    "capabilities": [
+      "oob"
+    ]
+  }
+}
+08:28:31 DEBUG| Negotiating capabilities ...
+08:28:31 DEBUG| --> {
+  "execute": "qmp_capabilities",
+  "arguments": {
+    "enable": [
+      "oob"
+    ]
+  }
+}
+08:28:31 DEBUG| <-- {
+  "return": {}
+}
+08:28:31 DEBUG| Transitioning from 'Runstate.CONNECTING' to 'Runstate.RUNNING'.
+08:28:31 DEBUG| Opening console socket
+08:28:31 DEBUG| --> {
+  "execute": "query-replay"
+}
+08:28:31 DEBUG| <-- {
+  "return": {
+    "icount": 5521801,
+    "mode": "record",
+    "filename": "/builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/replay.bin"
+  }
+}
+08:28:31 DEBUG| --> {
+  "execute": "query-replay"
+}
+08:28:31 DEBUG| [    0.230392217,5] OPAL v7.0 starting...
+08:28:31 DEBUG| [    0.230674939,7] initial console log level: memory 7, driver 5
+08:28:31 DEBUG| [    0.231048494,6] CPU: P9 generation processor (max 4 threads/core)
+08:28:31 DEBUG| [    0.231412547,7] CPU: Boot CPU PIR is 0x0000 PVR is 0x004e1202
+08:28:31 DEBUG| [    0.231857798,7] OPAL table
+08:28:31 DEBUG| <-- {
+  "return": {
+    "icount": 5655658,
+    "mode": "record",
+    "filename": "/builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/replay.bin"
+  }
+}
+08:28:31 DEBUG| Shutting down VM appliance; timeout=30
+08:28:31 DEBUG| Attempting graceful termination
+08:28:31 DEBUG| Closing console socket
+08:28:31 DEBUG| Politely asking QEMU to terminate
+08:28:31 DEBUG| --> {
+  "execute": "quit"
+}
+08:28:31 DEBUG| <-- {
+  "return": {}
+}
+08:28:31 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 453159
+  },
+  "event": "SHUTDOWN",
+  "data": {
+    "guest": false,
+    "reason": "host-qmp-quit"
+  }
+}
+08:28:31 DEBUG| disconnect() called.
+08:28:31 DEBUG| Transitioning from 'Runstate.RUNNING' to 'Runstate.DISCONNECTING'.
+08:28:31 DEBUG| Scheduling disconnect.
+08:28:31 DEBUG| Draining the outbound queue ...
+08:28:31 DEBUG| Flushing the StreamWriter ...
+08:28:31 DEBUG| Cancelling writer task.
+08:28:31 DEBUG| Cancelling reader task.
+08:28:31 DEBUG| Waiting for tasks to complete ...
+08:28:31 DEBUG| Task.Writer: cancelled.
+08:28:31 DEBUG| Task.Writer: exiting.
+08:28:31 DEBUG| Task.Reader: cancelled.
+08:28:31 DEBUG| Task.Reader: exiting.
+08:28:31 DEBUG| Closing StreamWriter.
+08:28:31 DEBUG| Waiting for StreamWriter to close ...
+08:28:31 DEBUG| StreamWriter closed.
+08:28:31 DEBUG| Disconnected.
+08:28:31 DEBUG| QMP Disconnected.
+08:28:31 DEBUG| Transitioning from 'Runstate.DISCONNECTING' to 'Runstate.IDLE'.
+08:28:31 DEBUG| Waiting (timeout=30) for QEMU process (pid=1580) to terminate
+08:28:31 DEBUG| Cleaning up after VM process
+08:28:31 INFO | recorded log with 5655658+ steps
+08:28:31 DEBUG| QEMUMachine "1dfa83ad-c638-4858-b96d-ec21870ab53a" created
+08:28:31 DEBUG| QEMUMachine "1dfa83ad-c638-4858-b96d-ec21870ab53a" temp_dir: /builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/qemu-machine-i11yz6dd
+08:28:31 DEBUG| QEMUMachine "1dfa83ad-c638-4858-b96d-ec21870ab53a" log_dir: /builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv
+08:28:31 INFO | replaying the execution...
+08:28:31 DEBUG| Registering <qemu.qmp.events.EventListener object at 0x7ff655d27700>.
+08:28:31 DEBUG| VM launch command: './qemu-system-ppc64 -display none -vga none -chardev socket,id=mon,fd=5 -mon chardev=mon,mode=control -machine powernv -chardev socket,id=console,fd=19 -serial chardev:console -gdb tcp::21192 -S -icount shift=7,rr=replay,rrfile=/builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/replay.bin,rrsnapshot=init -net none -drive file=/builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/disk.qcow2,if=none'
+08:28:31 DEBUG| Transitioning from 'Runstate.IDLE' to 'Runstate.CONNECTING'.
+08:28:31 DEBUG| Connecting with existing socket: fd=12, family=<AddressFamily.AF_UNIX: 1>, type=<SocketKind.SOCK_STREAM: 1>
+08:28:31 DEBUG| Connected.
+08:28:31 DEBUG| Awaiting greeting ...
+08:28:31 DEBUG| <-- {
+  "QMP": {
+    "version": {
+      "qemu": {
+        "micro": 90,
+        "minor": 1,
+        "major": 8
+      },
+      "package": "v5.2.0-26508-gaf9264da80"
+    },
+    "capabilities": [
+      "oob"
+    ]
+  }
+}
+08:28:31 DEBUG| Negotiating capabilities ...
+08:28:31 DEBUG| --> {
+  "execute": "qmp_capabilities",
+  "arguments": {
+    "enable": [
+      "oob"
+    ]
+  }
+}
+08:28:31 DEBUG| <-- {
+  "return": {}
+}
+08:28:31 DEBUG| Transitioning from 'Runstate.CONNECTING' to 'Runstate.RUNNING'.
+08:28:31 DEBUG| Opening console socket
+08:28:31 INFO | connecting to gdbstub
+08:28:31 INFO | stepping forward
+08:28:31 INFO | saving position 10
+08:28:31 INFO | saving position 14
+08:28:31 INFO | saving position 40
+08:28:31 INFO | saving position 44
+08:28:31 INFO | saving position 3008
+08:28:31 INFO | saving position 300c
+08:28:31 INFO | saving position 3010
+08:28:31 INFO | saving position 3014
+08:28:31 INFO | saving position 3018
+08:28:31 INFO | saving position 301c
+08:28:31 INFO | stepping backward
+08:28:31 INFO | found position 301c
+08:28:31 INFO | found position 3018
+08:28:31 INFO | found position 3014
+08:28:31 INFO | found position 3010
+08:28:31 INFO | found position 300c
+08:28:31 INFO | found position 3008
+08:28:31 INFO | found position 44
+08:28:31 INFO | found position 40
+08:28:32 INFO | found position 14
+08:28:32 INFO | found position 10
+08:28:32 INFO | stepping forward
+08:28:32 INFO | found position 10
+08:28:32 INFO | found position 14
+08:28:32 INFO | found position 40
+08:28:32 INFO | found position 44
+08:28:32 INFO | found position 3008
+08:28:32 INFO | found position 300c
+08:28:32 INFO | found position 3010
+08:28:32 INFO | found position 3014
+08:28:32 INFO | found position 3018
+08:28:32 INFO | found position 301c
+08:28:32 INFO | setting breakpoints
+08:28:32 INFO | continuing execution
+08:28:32 DEBUG| --> {
+  "execute": "replay-break",
+  "arguments": {
+    "icount": 5655657
+  }
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 630400
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 630738
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 630965
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 631155
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 631438
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 631653
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 631935
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 632127
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 632380
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 632593
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 632858
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 633051
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 633316
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 633517
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 633775
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 633973
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 634247
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 634437
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 634707
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 634910
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 681146
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 681795
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 722346
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 723103
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 764757
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 765468
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 806932
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 807686
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 849868
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 850664
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 892036
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 892734
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 934846
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 935520
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 976442
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555311,
+    "microseconds": 977155
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 29287
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 30093
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 74012
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 74271
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 74873
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 75471
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 75800
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 75987
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 76239
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 76423
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 76666
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 76861
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 77106
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 77321
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 77564
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 77760
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 77987
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 78176
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 78408
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 78598
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 78846
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 79033
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 79267
+  },
+  "event": "RESUME"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 79451
+  },
+  "event": "STOP"
+}
+08:28:32 DEBUG| <-- {
+  "return": {}
+}
+08:28:32 DEBUG| [    0.230392217,5] OPAL v7.0 starting...
+08:28:32 DEBUG| [    0.230674939,7] initial console log level: memory 7, driver 5
+08:28:32 DEBUG| [    0.231048494,6] CPU: P9 generation processor (max 4 threads/core)
+08:28:32 DEBUG| [
+08:28:32 DEBUG| [    0.231412547,7] CPU: Boot CPU PIR is 0x0000 PVR is 0x004e1202
+08:28:32 DEBUG| [
+08:28:32 ERROR| 
+08:28:32 ERROR| Reproduced traceback from: /builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/core/test.py:770
+08:28:32 ERROR| Traceback (most recent call last):
+08:28:32 ERROR|   File "/builds/thuth/qemu/build/tests/avocado/reverse_debugging.py", line 262, in test_ppc64_powernv
+08:28:32 ERROR|     self.reverse_debugging()
+08:28:32 ERROR|   File "/builds/thuth/qemu/build/tests/avocado/reverse_debugging.py", line 178, in reverse_debugging
+08:28:32 ERROR|     g.cmd(b'c')
+08:28:32 ERROR|   File "/builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/utils/gdb.py", line 783, in cmd
+08:28:32 ERROR|     response_payload = self.decode(result)
+08:28:32 ERROR|   File "/builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/utils/gdb.py", line 738, in decode
+08:28:32 ERROR|     raise InvalidPacketError
+08:28:32 ERROR| avocado.utils.gdb.InvalidPacketError
+08:28:32 ERROR| 
+08:28:32 DEBUG| Local variables:
+08:28:32 DEBUG|  -> self <class 'reverse_debugging.ReverseDebugging_ppc64'>: 79-tests/avocado/reverse_debugging.py:ReverseDebugging_ppc64.test_ppc64_powernv
+08:28:32 DEBUG| Shutting down VM appliance; timeout=30
+08:28:32 DEBUG| Attempting graceful termination
+08:28:32 DEBUG| Closing console socket
+08:28:32 DEBUG| Politely asking QEMU to terminate
+08:28:32 DEBUG| --> {
+  "execute": "quit"
+}
+08:28:32 DEBUG| <-- {
+  "timestamp": {
+    "seconds": 1700555312,
+    "microseconds": 86122
+  },
+  "event": "RESUME"
+}
+08:28:32 ERROR| Task.Reader: BrokenPipeError: [Errno 32] Broken pipe
+08:28:32 DEBUG| Task.Reader: failure:
+  | Traceback (most recent call last):
+  |   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 870, in _bh_loop_forever
+  |     await async_fn()
+  |   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 908, in _bh_recv_message
+  |     msg = await self._recv()
+  |   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 1009, in _recv
+  |     message = await self._do_recv()
+  |   File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 402, in _do_recv
+  |     msg_bytes = await self._readline()
+  |   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 973, in _readline
+  |     msg_bytes = await self._reader.readline()
+  |   File "/usr/lib64/python3.8/asyncio/streams.py", line 540, in readline
+  |     line = await self.readuntil(sep)
+  |   File "/usr/lib64/python3.8/asyncio/streams.py", line 632, in readuntil
+  |     await self._wait_for_data('readuntil')
+  |   File "/usr/lib64/python3.8/asyncio/streams.py", line 517, in _wait_for_data
+  |     await self._waiter
+  |   File "/usr/lib64/python3.8/asyncio/selector_events.py", line 910, in write
+  |     n = self._sock.send(data)
+  | BrokenPipeError: [Errno 32] Broken pipe
+
+08:28:32 DEBUG| Transitioning from 'Runstate.RUNNING' to 'Runstate.DISCONNECTING'.
+08:28:32 DEBUG| Scheduling disconnect.
+08:28:32 DEBUG| Task.Reader: exiting.
+08:28:32 DEBUG| Cancelling writer task.
+08:28:32 DEBUG| Waiting for tasks to complete ...
+08:28:32 DEBUG| Task.Writer: cancelled.
+08:28:32 DEBUG| Task.Writer: exiting.
+08:28:32 DEBUG| Waiting for StreamWriter to close ...
+08:28:32 DEBUG| Discarding Exception from wait_closed:
+  | Traceback (most recent call last):
+  |   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 834, in _bh_close_stream
+  |     await wait_closed(self._writer)
+  |   File "/builds/thuth/qemu/python/qemu/qmp/util.py", line 130, in wait_closed
+  |     await writer.wait_closed()
+  |   File "/usr/lib64/python3.8/asyncio/streams.py", line 359, in wait_closed
+  |     await self._protocol._get_close_waiter(self)
+  |   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 870, in _bh_loop_forever
+  |     await async_fn()
+  |   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 908, in _bh_recv_message
+  |     msg = await self._recv()
+  |   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 1009, in _recv
+  |     message = await self._do_recv()
+  |   File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 402, in _do_recv
+  |     msg_bytes = await self._readline()
+  |   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 973, in _readline
+  |     msg_bytes = await self._reader.readline()
+  |   File "/usr/lib64/python3.8/asyncio/streams.py", line 540, in readline
+  |     line = await self.readuntil(sep)
+  |   File "/usr/lib64/python3.8/asyncio/streams.py", line 632, in readuntil
+  |     await self._wait_for_data('readuntil')
+  |   File "/usr/lib64/python3.8/asyncio/streams.py", line 517, in _wait_for_data
+  |     await self._waiter
+  |   File "/usr/lib64/python3.8/asyncio/selector_events.py", line 910, in write
+  |     n = self._sock.send(data)
+  | BrokenPipeError: [Errno 32] Broken pipe
+
+08:28:32 DEBUG| StreamWriter closed.
+08:28:32 DEBUG| Disconnected.
+08:28:32 DEBUG| Cancelling pending executions
+08:28:32 DEBUG| Cancelling execution 'None'
+08:28:32 DEBUG| QMP Disconnected.
+08:28:32 DEBUG| disconnect() called.
+08:28:32 DEBUG| Transitioning from 'Runstate.DISCONNECTING' to 'Runstate.IDLE'.
+08:28:32 DEBUG| Graceful shutdown failed
+Traceback (most recent call last):
+  File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 574, in _soft_shutdown
+    self.qmp('quit')
+  File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 705, in qmp
+    ret = self._qmp.cmd_raw(cmd, args=qmp_args)
+  File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 208, in cmd_raw
+    return self.cmd_obj(qmp_cmd)
+  File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 186, in cmd_obj
+    self._sync(
+  File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 102, in _sync
+    return self._aloop.run_until_complete(
+  File "/usr/lib64/python3.8/asyncio/base_events.py", line 616, in run_until_complete
+    return future.result()
+  File "/usr/lib64/python3.8/asyncio/tasks.py", line 455, in wait_for
+    return await fut
+  File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 547, in _raw
+    return await self._execute(msg, assign_id=assign_id)
+  File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 496, in _execute
+    return await self._reply(exec_id)
+  File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 463, in _reply
+    raise result
+qemu.qmp.qmp_client.ExecInterruptedError: Disconnected
+
+During handling of the above exception, another exception occurred:
+
+Traceback (most recent call last):
+  File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 605, in _do_shutdown
+    self._soft_shutdown(timeout)
+  File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 577, in _soft_shutdown
+    self._close_qmp_connection()
+  File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 495, in _close_qmp_connection
+    self._qmp.close()
+  File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 281, in close
+    self._sync(
+  File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 102, in _sync
+    return self._aloop.run_until_complete(
+  File "/usr/lib64/python3.8/asyncio/base_events.py", line 616, in run_until_complete
+    return future.result()
+  File "/usr/lib64/python3.8/asyncio/tasks.py", line 455, in wait_for
+    return await fut
+  File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 399, in disconnect
+    await self._wait_disconnect()
+  File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 719, in _wait_disconnect
+    await all_defined_tasks  # Raise Exceptions from the bottom half.
+  File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 834, in _bh_close_stream
+    await wait_closed(self._writer)
+  File "/builds/thuth/qemu/python/qemu/qmp/util.py", line 130, in wait_closed
+    await writer.wait_closed()
+  File "/usr/lib64/python3.8/asyncio/streams.py", line 359, in wait_closed
+    await self._protocol._get_close_waiter(self)
+  File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 870, in _bh_loop_forever
+    await async_fn()
+  File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 908, in _bh_recv_message
+    msg = await self._recv()
+  File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 1009, in _recv
+    message = await self._do_recv()
+  File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 402, in _do_recv
+    msg_bytes = await self._readline()
+  File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 973, in _readline
+    msg_bytes = await self._reader.readline()
+  File "/usr/lib64/python3.8/asyncio/streams.py", line 540, in readline
+    line = await self.readuntil(sep)
+  File "/usr/lib64/python3.8/asyncio/streams.py", line 632, in readuntil
+    await self._wait_for_data('readuntil')
+  File "/usr/lib64/python3.8/asyncio/streams.py", line 517, in _wait_for_data
+    await self._waiter
+  File "/usr/lib64/python3.8/asyncio/selector_events.py", line 910, in write
+    n = self._sock.send(data)
+BrokenPipeError: [Errno 32] Broken pipe
+08:28:32 DEBUG| Falling back to hard shutdown
+08:28:32 DEBUG| Performing hard shutdown
+08:28:32 DEBUG| Cleaning up after VM process
+08:28:32 ERROR| 
+08:28:32 ERROR| Reproduced traceback from: /builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/core/test.py:796
+08:28:32 ERROR| Traceback (most recent call last):
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 574, in _soft_shutdown
+08:28:32 ERROR|     self.qmp('quit')
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 705, in qmp
+08:28:32 ERROR|     ret = self._qmp.cmd_raw(cmd, args=qmp_args)
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 208, in cmd_raw
+08:28:32 ERROR|     return self.cmd_obj(qmp_cmd)
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 186, in cmd_obj
+08:28:32 ERROR|     self._sync(
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 102, in _sync
+08:28:32 ERROR|     return self._aloop.run_until_complete(
+08:28:32 ERROR|   File "/usr/lib64/python3.8/asyncio/base_events.py", line 616, in run_until_complete
+08:28:32 ERROR|     return future.result()
+08:28:32 ERROR|   File "/usr/lib64/python3.8/asyncio/tasks.py", line 455, in wait_for
+08:28:32 ERROR|     return await fut
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 547, in _raw
+08:28:32 ERROR|     return await self._execute(msg, assign_id=assign_id)
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 496, in _execute
+08:28:32 ERROR|     return await self._reply(exec_id)
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 463, in _reply
+08:28:32 ERROR|     raise result
+08:28:32 ERROR| qemu.qmp.qmp_client.ExecInterruptedError: Disconnected
+08:28:32 ERROR| 
+08:28:32 ERROR| During handling of the above exception, another exception occurred:
+08:28:32 ERROR| 
+08:28:32 ERROR| Traceback (most recent call last):
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 605, in _do_shutdown
+08:28:32 ERROR|     self._soft_shutdown(timeout)
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 577, in _soft_shutdown
+08:28:32 ERROR|     self._close_qmp_connection()
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 495, in _close_qmp_connection
+08:28:32 ERROR|     self._qmp.close()
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 281, in close
+08:28:32 ERROR|     self._sync(
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 102, in _sync
+08:28:32 ERROR|     return self._aloop.run_until_complete(
+08:28:32 ERROR|   File "/usr/lib64/python3.8/asyncio/base_events.py", line 616, in run_until_complete
+08:28:32 ERROR|     return future.result()
+08:28:32 ERROR|   File "/usr/lib64/python3.8/asyncio/tasks.py", line 455, in wait_for
+08:28:32 ERROR|     return await fut
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 399, in disconnect
+08:28:32 ERROR|     await self._wait_disconnect()
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 719, in _wait_disconnect
+08:28:32 ERROR|     await all_defined_tasks  # Raise Exceptions from the bottom half.
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 834, in _bh_close_stream
+08:28:32 ERROR|     await wait_closed(self._writer)
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/util.py", line 130, in wait_closed
+08:28:32 ERROR|     await writer.wait_closed()
+08:28:32 ERROR|   File "/usr/lib64/python3.8/asyncio/streams.py", line 359, in wait_closed
+08:28:32 ERROR|     await self._protocol._get_close_waiter(self)
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 870, in _bh_loop_forever
+08:28:32 ERROR|     await async_fn()
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 908, in _bh_recv_message
+08:28:32 ERROR|     msg = await self._recv()
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 1009, in _recv
+08:28:32 ERROR|     message = await self._do_recv()
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 402, in _do_recv
+08:28:32 ERROR|     msg_bytes = await self._readline()
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 973, in _readline
+08:28:32 ERROR|     msg_bytes = await self._reader.readline()
+08:28:32 ERROR|   File "/usr/lib64/python3.8/asyncio/streams.py", line 540, in readline
+08:28:32 ERROR|     line = await self.readuntil(sep)
+08:28:32 ERROR|   File "/usr/lib64/python3.8/asyncio/streams.py", line 632, in readuntil
+08:28:32 ERROR|     await self._wait_for_data('readuntil')
+08:28:32 ERROR|   File "/usr/lib64/python3.8/asyncio/streams.py", line 517, in _wait_for_data
+08:28:32 ERROR|     await self._waiter
+08:28:32 ERROR|   File "/usr/lib64/python3.8/asyncio/selector_events.py", line 910, in write
+08:28:32 ERROR|     n = self._sock.send(data)
+08:28:32 ERROR| BrokenPipeError: [Errno 32] Broken pipe
+08:28:32 ERROR| 
+08:28:32 ERROR| The above exception was the direct cause of the following exception:
+08:28:32 ERROR| 
+08:28:32 ERROR| Traceback (most recent call last):
+08:28:32 ERROR|   File "/builds/thuth/qemu/build/tests/avocado/avocado_qemu/__init__.py", line 384, in tearDown
+08:28:32 ERROR|     vm.shutdown()
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 642, in shutdown
+08:28:32 ERROR|     self._do_shutdown(timeout)
+08:28:32 ERROR|   File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 612, in _do_shutdown
+08:28:32 ERROR|     raise AbnormalShutdown("Could not perform graceful shutdown") \
+08:28:32 ERROR| qemu.machine.machine.AbnormalShutdown: Could not perform graceful shutdown
+08:28:32 ERROR| 
+08:28:32 DEBUG| DATA (filename=output.expected) => NOT FOUND (data sources: variant, test, file)
+08:28:32 DEBUG| DATA (filename=stdout.expected) => NOT FOUND (data sources: variant, test, file)
+08:28:32 DEBUG| DATA (filename=stderr.expected) => NOT FOUND (data sources: variant, test, file)
+08:28:32 ERROR| Traceback (most recent call last):
+
+08:28:32 ERROR|   File "/builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/core/test.py", line 858, in _run_avocado
+    raise test_exception
+
+08:28:32 ERROR|   File "/builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/core/test.py", line 765, in _run_avocado
+    testMethod()
+
+08:28:32 ERROR|   File "/builds/thuth/qemu/build/tests/avocado/reverse_debugging.py", line 262, in test_ppc64_powernv
+    self.reverse_debugging()
+
+08:28:32 ERROR|   File "/builds/thuth/qemu/build/tests/avocado/reverse_debugging.py", line 178, in reverse_debugging
+    g.cmd(b'c')
+
+08:28:32 ERROR|   File "/builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/utils/gdb.py", line 783, in cmd
+    response_payload = self.decode(result)
+
+08:28:32 ERROR|   File "/builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/utils/gdb.py", line 738, in decode
+    raise InvalidPacketError
+
+08:28:32 ERROR| avocado.utils.gdb.InvalidPacketError
+
+08:28:32 ERROR| ERROR 79-tests/avocado/reverse_debugging.py:ReverseDebugging_ppc64.test_ppc64_powernv -> InvalidPacketError: 
+08:28:32 INFO | 
+```
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2108 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2108
new file mode 100644
index 00000000..c12f89e7
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2108
@@ -0,0 +1 @@
+ppc64 POWER10 machine-check caused by ifetch crashes qemu
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2185 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2185
new file mode 100644
index 00000000..5d1a9955
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2185
@@ -0,0 +1 @@
+spapr watchdog should honour watchdog-set-action etc monitor commands
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2236 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2236
new file mode 100644
index 00000000..74f00fc5
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2236
@@ -0,0 +1 @@
+32-bit PPC CPUs are reported based on 64-bit base CPU
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2246 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2246
new file mode 100644
index 00000000..a3435fe1
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2246
@@ -0,0 +1 @@
+ppc_hv_tests.py:HypervisorTest.test_hv_pseries test fails if xorriso is not present rather than skipping
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2297 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2297
new file mode 100644
index 00000000..39e2e0a6
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2297
@@ -0,0 +1 @@
+Incorrect String: PowerMAC (Media Access Control instead of Macintosh)
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2352 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2352
new file mode 100644
index 00000000..f622af97
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2352
@@ -0,0 +1 @@
+spapr-vlan hotplug
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2456 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2456
new file mode 100644
index 00000000..e0074feb
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2456
@@ -0,0 +1 @@
+check-tcg multi-threaded tests fail on ppc64 on clang-user CI job
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2522 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2522
new file mode 100644
index 00000000..9c157c2a
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2522
@@ -0,0 +1,17 @@
+[9.0.2] PPC: incorrect name filed in vmstate_tlbemb_entry, broken snapshot replay
+Description of problem:
+Fix commit: a90db15
+When using the Record/replay feature on ppc emulation (qemu-system-ppc binary), an error occurred during loading:
+```
+qemu-system-ppc: Missing section footer for cpu
+qemu-system-ppc: Error -22 while loading VM state
+qemu-system-ppc: Could not load snapshot for icount replay
+```
+I found a typo that led to this error
+
+more info in https://lists.nongnu.org/archive/html/qemu-devel/2024-08/msg02951.html
+Steps to reproduce:
+1. Run bare metal example from the attachment with the first command-line to create snapshot.
+2. Run bare metal example from the attachment with the second command-line to replay snapshot.
+Additional information:
+Use this example [ppc-e500.zip](/uploads/04e47528c74ed9a564c212a17c480a1d/ppc-e500.zip)
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2553 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2553
new file mode 100644
index 00000000..2e23231b
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2553
@@ -0,0 +1,82 @@
+Joining IP multicast fails when emulating 64-bit Linux
+Description of problem:
+I have some code that joins IP multicast groups and I'd like to use QEMU to test it on big-endian and/or 32-bit platforms. But when I compile it for 64-bit big-endian platforms (e.g. PowerPC64) and run it under QEMU user-mode emulation, the setsockopt(IP_ADD_MEMBERSHIP) call fails with ENODEV.
+
+This appears to refer to the imr_ifindex ("interface index") field in struct ip_mreqn not being valid, which in turn appears to be because it's not being correctly marshalled from the binary under emulation, to the host's *actual* setsockopt system call.
+
+I *think* this may be because linux-user/syscall_defs.h (https://github.com/qemu/qemu/blob/master/linux-user/syscall_defs.h) contains the following at line 210:
+ 
+```
+struct target_ip_mreqn {
+    struct target_in_addr imr_multiaddr;
+    struct target_in_addr imr_address;
+    abi_long imr_ifindex;
+};
+```
+
+but the actual Linux ip_mreqn has imr_ifindex as an int (32-bit everywhere) not a long (64-bit on PPC64); the size of this structure is 12 on all Linux platforms.
+
+I opted to submit an issue instead of just patching it, in case there was some wider context I hadn't seen?
+Steps to reproduce:
+1. take the following C program (distilled from a larger program):
+
+```
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
+#include <stdio.h>
+#include <stdlib.h>
+
+int main(int argc, char *argv[])
+{
+    int fd = socket(AF_INET, SOCK_DGRAM, 0);
+    if (fd < 0) {
+        perror("socket");
+        return 1;
+    }
+
+    struct ip_mreqn mreq;
+    mreq.imr_multiaddr.s_addr = inet_addr("239.255.255.250");
+    mreq.imr_address.s_addr = htonl(INADDR_ANY);
+    mreq.imr_ifindex = 1;
+    int size = sizeof(mreq);
+    printf("size=%u\n", size);
+    if (setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP,
+                   (char*) &mreq, sizeof(mreq)) < 0) {
+        perror("setsockopt");
+        return 1;
+    }
+    printf("OK\n");
+    return 0;
+}
+```
+
+2. confirm it works compiled native on amd64/x86_64:
+
+```
+[peter@amd64 misc]$ gcc mcast.c -o mcast
+[peter@amd64 misc]$ ./mcast
+size=12
+OK
+```
+
+3. watch it *not* work emulated:
+
+```
+[peter@amd64 misc]$ powerpc64-linux-gnu-gcc mcast.c -o mcast.ppc64
+[peter@amd64 misc]$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu qemu-ppc64 ./mcast.ppc64 
+size=12
+setsockopt: No such device
+```
+Additional information:
+If the target_ip_mreqn issue is real, the following code in syscall.c helped conceal it:
+
+            if (optlen < sizeof (struct target_ip_mreq) ||
+                optlen > sizeof (struct target_ip_mreqn)) {
+                return -TARGET_EINVAL;
+            }
+
+Should this instead be testing for size equal to target_ip_mreq or equal to target_ip_mreqn, not anywhere in between? in this case target_ip_mreq is 8 bytes, target_ip_mreqn is 16 bytes, but optlen is 12. The end result is that QEMU passes 4 bytes of uninitialised stack memory as imr_ifindex!
+
+The actual kernel behaviour appears to be: smaller than ip_mreq, EINVAL; between ip_mreq and ip_mreqn, silently treat as ip_mreq; larger or equal to ip_mreqn, silently treat as ip_mreqn. see https://github.com/torvalds/linux/blob/b31c4492884252a8360f312a0ac2049349ddf603/net/ipv4/ip_sockglue.c#L1234
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/266 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/266
new file mode 100644
index 00000000..7b47a4c1
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/266
@@ -0,0 +1 @@
+'mtfsf' instruction can clear FI incorrectly
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2661 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2661
new file mode 100644
index 00000000..b583ae28
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2661
@@ -0,0 +1,33 @@
+powerpc: MSR_LE implemented incorrectly for processors before PPC970
+Description of problem:
+qemu does not emulate MSR_LE correctly for CPUs prior to PPC970.
+
+The implementation used in this scenario appears to be correct for newer PowerPC CPUs, but not for earlier ones.
+
+When MSR_LE is enabled on PowerPC G4 and prior CPUs, big endian accesses are performed, with the lower address bits XORed by a constant derived from the size of the access (8-bit: XOR 7, 16-bit: XOR 6, 32-bit: XOR 4, 64-bit and above: no operation). This means that anything loaded in big-endian mode, when byteswapped as 64-bit values, appears in the correct place in little endian mode.
+
+Any unaligned access is dealt with at the same time. I have not verified exactly what the real hardware does, but the following appears to be correct for 16- and 32-bit accesses (and technically 8-bit accesses too given that all operations but the XOR do nothing in that case):
+```c
+// sizeof_access is the access size in bytes
+size_t temp = ea & (sizeof_access - 1); // get offset of unaligned access
+ea &= ~sizeof_access; // align the address
+ea ^= (sizeof(uint64_t) - sizeof_access); // perform MSR_LE swizzle
+ea -= temp; // correct the address for the unaligned access
+```
+
+Note that the algorithm can be run again on a swizzled address, which will compute the original non-swizzled address.
+
+Additionally, GDB memory accesses need to be performed byte-wise using the same algorithm. (there's probably a faster way to do this involving bswap64, though!)
+
+As for the rest of the system: different chipsets did different things. Some memory controllers (for example those used in early PReP systems) had an endianness swap bit that endianness swapped all of memory and MMIO correctly (given MSR_LE swizzled addresses); later systems with a PCI bus had an endianness swap bit in the PCI host controller (Apple "Bandit", Motorola MPC105/6/7) that endianness swapped PCI address space from the CPU side and provided a correct view of main memory from PCI DMA.
+
+I'm not sure how to implement any of that, hence testing with mac99, where the PCI host controller is big-endian only (there is a uni-north register to swap PCI endianness, but it isn't implemented in hardware and flipping it does nothing). On such systems, hardware access-related swapping must be handled in software.
+Steps to reproduce:
+Booting from the correct `nt_arcfw_mac99.iso` will crash on a black screen instead of running the ppcel stage2 bootloader.
+Additional information:
+The following patch is my implementation. This is my first attempt at QEMU TCG-related code; in some places it may be 'too' safe (running the swizzling algorithm again to revert it in case the EA is used again afterwards), and it also uses the "internal only" `tcg_temp_free_*` functions, to avoid wasting temporary variables. So hopefully some more experienced devs can improve it.
+
+[msr_le.patch](/uploads/3f829ac58d9943faa0cad7b817569f1d/msr_le.patch)
+
+The following ISO is the one used for testing.
+[nt_arcfw_mac99.iso](/uploads/16aa5406284bab55ada205d6598e399a/nt_arcfw_mac99.iso)
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2662 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2662
new file mode 100644
index 00000000..9a7811ad
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2662
@@ -0,0 +1,11 @@
+powerpc: MSR_ILE bit must not be restored in rfi
+Description of problem:
+On processors that implement the MSR_ILE bit (that is, G4 and prior), the MSR_ILE bit is not restored by the `rfi` instruction.
+
+qemu, however, does restore this bit from `srr1`.
+
+Some ppcel operating systems rely on MSR_ILE not being restored by `rfi`, for example, Windows NT when taking a syscall.
+Additional information:
+Patch provided: [rfi_msr_ile.patch](/uploads/aa661fc8bcbb47585ff63f8e4ebb38ba/rfi_msr_ile.patch)
+
+The correct behaviour for G4 and prior is performed for later processors too. Given PPC970 and later have that bit documented as reserved, this should not be a problem.
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2663 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2663
new file mode 100644
index 00000000..11c966ea
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2663
@@ -0,0 +1,7 @@
+powerpc: for 6xx,7xx,74xx msr and srr1 are not set correctly on exception
+Description of problem:
+When an exception is raised, qemu does not set bits in SRR1 and MSR correctly.
+
+This causes some operating systems to not work, in particular early little endian ones like Windows NT.
+Additional information:
+The following patch changes the MSR and SRR1 bit settings on exception to what is mentioned in the various user manuals for the 6xx, 7xx and 74xx series (6xx and 7xx are effectively identical, 74xx has some additional changes): [exception_msr.patch](/uploads/aae17dd35f0f0e72b831243fcfd0c416/exception_msr.patch)
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/269 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/269
new file mode 100644
index 00000000..e304c767
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/269
@@ -0,0 +1 @@
+AIX 7.2 TL4 SP1 cannot IPL with QEMU >2.11.2 ppc64-softmmu
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2741 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2741
new file mode 100644
index 00000000..a0f1a3af
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2741
@@ -0,0 +1,61 @@
+qemu-system-ppc no longer boots NetBSD/macppc
+Description of problem:
+Since commit 7419dc5b2b5bcc929d91e8920692041a8f6d1977, qemu no longer boots NetBSD/macppc.
+Steps to reproduce:
+```
+wget https://www.gson.org/bugs/qemu/macppc-20241221/boot.iso.gz
+wget https://www.gson.org/bugs/qemu/macppc-20241221/wd0.img.gz
+gunzip boot.iso.gz
+gunzip wd0.img.gz
+qemu-system-ppc \
+    -m 256 \
+    -nographic \
+    -drive file=wd0.img,format=raw,media=disk,snapshot=on \
+    -drive file=boot.iso,format=raw,media=cdrom,readonly=on,index=2 \
+    -prom-env boot-device=cd:,netbsd-GENERIC \
+    -M mac99 \
+    -prom-env qemu_boot_hack=y
+```
+
+At the "root device:" prompt, enter `wd0a`
+
+At the "dump device" prompt, just press enter
+
+At the "file system" prompt, just press enter
+
+At the "init path" prompt, just press enter
+
+Expected behavior: The guest system boots to a login prompt
+
+Observed behavior: qemu exits with the following error message:
+
+```
+qemu: fatal: Raised an exception without defined vector 94
+
+NIP fdb5d440   LR fdb5dc20 CTR fd62a340 XER 20000000 CPU#0
+MSR 0200d032 HID0 809400a4  HF 02004012 iidx 0 didx 0
+TB 00000000 831919972 DECR 105840
+GPR00 0000000000000125 00000000ffffe8b0 00000000fde90008 0000000000000000
+GPR04 0000000000000000 00000000fdcfebac 00000000fdcfeb48 0000000000000001
+GPR08 0000000000000000 00000000fde90008 00000000ffffe8b0 00000000fdb5dc14
+GPR12 0000000044004482 0000000000000000 00000000fdee0efc 00000000fdef57f0
+GPR16 00000000fdef57c8 0000000000000000 00000000ffffea94 00000000ffffeac8
+GPR20 00000000fdee0f3c 0000000001800114 0000000000000000 0000000000000001
+GPR24 0000000000000000 00000000fdef57e0 0000000000000001 00000000fdb5da2c
+GPR28 00000000ffffe9c0 00000000ffffe8f8 00000000fdcffb4c 00000000fdcfeb48
+CR 24004482  [ E  G  -  -  G  G  L  E  ]     RES 004@ffffffff
+FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPSCR 00000000
+ SRR0 fd62a360  SRR1 0200d032    PVR 000c0209 VRSAVE 00000000
+SPRG0 00c02bc0 SPRG1 44004482  SPRG2 fde90008  SPRG3 00000000
+SPRG4 00000000 SPRG5 00000000  SPRG6 00000000  SPRG7 00000000
+ SDR1 00e0001f   DAR cd538000  DSISR 42000000
+Aborted
+```
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2768 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2768
new file mode 100644
index 00000000..e028c8e4
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2768
@@ -0,0 +1,16 @@
+PowerPC e200 duplicate register definitions
+Description of problem:
+Registers DSRR0 and DSRR1 defined twice in the `target/ppc/cpu_init.c`:
+
+- in the common [`register_BookE_sprs()`](https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/cpu_init.c#L740-748)
+- and specific [`init_proc_e200()`](https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/cpu_init.c#L2735-2742)
+
+The second case should be removed.
+Steps to reproduce:
+1. run  `qemu-system-ppc -cpu e200z5`
+2. check output
+```
+**
+ERROR:../qemu-9.2.0/target/ppc/helper_regs.c:410:_spr_register: assertion failed: (spr->name == ((void *)0))
+Bail out! ERROR:../qemu-9.2.0/target/ppc/helper_regs.c:410:_spr_register: assertion failed: (spr->name == ((void *)0))
+```
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2864 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2864
new file mode 100644
index 00000000..adb6f08c
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2864
@@ -0,0 +1,9 @@
+qemu-system-ppc -M g3beige mouse/keyboard behave erraticaly at least since 9.0
+Description of problem:
+Mouse behaves very erraticaly, seemingly clicks on its own, moves auto-opened terminal window to the left
+Steps to reproduce:
+1. Get helenOS from https://www.helenos.org/wiki/Download
+2. Boot it (need 256 Mb)
+3. Try to move mouse or type anything in Terminal
+Additional information:
+Seemingly same issue present on netBSD (booted on qemu 9.0.4 due to regression in qemu), and macos X/9 when booted on this machine or -M mac99,via=cuda
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2911 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2911
new file mode 100644
index 00000000..aaffb90a
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2911
@@ -0,0 +1,65 @@
+G5/970 emulation not complete enough for OSX ?
+Description of problem:
+Leopard image that boots on G4 does not boot on G5
+Steps to reproduce:
+1. Find preinstalled hdd image on Archive.org: MacOSLeopard.img
+2. Try to boot it like above with -cpu 970, or 970FX
+3. Observe early hang
+Additional information:
+```
+cpus[0] = 0x7f794b3e3040 0x7f794b3e5bc0
+cpus[1] = 0x7f794afe3ec0 0x7f794afe6a40
+Trying to write invalid spr 276 (0x114) at 00000000000b6634
+Trying to read invalid spr 277 (0x115) at 00000000000b6638
+Trying to read invalid spr 276 (0x114) at 00000000000b663c
+Trying to write invalid spr 277 (0x115) at 00000000000b6658
+Trying to write invalid spr 276 (0x114) at 00000000000b665c
+Trying to read invalid spr 276 (0x114) at 00000000000b6660
+Trying to write invalid spr 277 (0x115) at 00000000000b670c
+Trying to write invalid spr 276 (0x114) at 00000000000b6710
+Trying to read invalid spr 276 (0x114) at 00000000000b6714
+invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 0000000000000000
+Trying to write invalid spr 304 (0x130) at 0000000000003e14
+Trying to read invalid spr 304 (0x130) at 0000000000003e38
+Trying to write invalid spr 304 (0x130) at 0000000000003e14
+Trying to read invalid spr 304 (0x130) at 0000000000003e38
+Trying to write invalid spr 304 (0x130) at 0000000000003e14
+Trying to read invalid spr 304 (0x130) at 0000000000003e38
+Trying to write invalid spr 304 (0x130) at 0000000000003e14
+Trying to read invalid spr 304 (0x130) at 0000000000003e38
+Trying to write invalid spr 304 (0x130) at 0000000000003e14
+Trying to read invalid spr 304 (0x130) at 0000000000003e38
+Trying to write invalid spr 304 (0x130) at 0000000000003e14
+Trying to read invalid spr 304 (0x130) at 0000000000003e38
+Trying to write invalid spr 304 (0x130) at 0000000000003e14
+Trying to read invalid spr 304 (0x130) at 0000000000003e38
+Trying to read invalid spr 304 (0x130) at 0000000000003e38
+Trying to read invalid spr 304 (0x130) at 0000000000003e38
+invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 0000000000000008
+
+last lin repeats infinitely.
+```
+
+from my email  to qemu-ppc list:
+
+SPR 304 was already in target/ppc/cpu_init.c
+
+but sadly after adding those it still dies early :(
+
+I looked at
+
+IBM PowerPC 970FX RISC Microprocessor 11.6 SCOM Facility
+
+but whole thing a bit more complex than pair of regs.
+
+====
+
+11.6.1 Processor Core SCOM SPR Access Each processor (core) has two special purpose registers (SPRs) used to access the SCOM interface: SCOMC and SCOMD. SCOMC and SCOMD are both 64-bit read/write SPRs and are used for SCOM Control and SCOM Data respectively. The interface is implemented as a direct connection to the parallel-to-serial converter, which handles the arbitration between the core and service processor. 
+
+11.6.2 Operating System Protocol to Access SCOM SPRs In the PowerPC 970FX, SCOMC and SCOMD are complete operations. They do not require a software protocol in order to function properly except to disable external (asynchronous) interrupts. Software must check the error bits after performing an SCOMC to ensure that the command successfully completed. Table 11-14 Operating System Code to Access SCOM outlines a general software protocol for using these registers.
+
+====
+
+Low level asm init for OSX XNU kernel seems to live at
+
+https://github.com/apple-oss-distributions/xnu/blob/xnu-1228/osfmk/ppc/start.s
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/2966 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2966
new file mode 100644
index 00000000..0d0bc8f9
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/2966
@@ -0,0 +1,27 @@
+KVM: Failed to create TCE64 table for liobn 0x80000001
+Description of problem:
+When rebooting the system we hit :
+   ```
+   KVM: Failed to create TCE64 table for liobn 0x80000001
+   qemu-system-ppc64: ../system/memory.c:2666: memory_region_add_subregion_common: Assertion `!subregion->container' failed.
+   Aborted (core dumped)
+   ```
+Steps to reproduce:
+1. Start the machine
+2. Reboot it
+ 
+   ```
+   curl -LO https://cloud.centos.org/centos/10-stream/ppc64le/images/CentOS-Stream-GenericCloud-10-20250512.0.ppc64le.qcow2
+   export LIBGUESTFS_BACKEND=direct
+   virt-customize -v -a CentOS-Stream-GenericCloud-10-20250512.0.ppc64le.qcow2 --root-password password:centos
+   qemu-system-ppc64 --enable-kvm -m 4096 -smp 8 -hda CentOS-Stream-GenericCloud-10-20250512.0.ppc64le.qcow2 -vga none -nographic -device qemu-xhci
+   # once logged into it
+   systemctl reboot
+   [...]
+   KVM: Failed to create TCE64 table for liobn 0x80000001
+   qemu-system-ppc64: ../system/memory.c:2666: memory_region_add_subregion_common: Assertion `!subregion->container' failed.
+   Aborted (core dumped)
+   ```
+Additional information:
+The issue was already reported on ML https://lists.nongnu.org/archive/html/qemu-devel/2025-03/msg05137.html  
+I also hit that issue while building a CoreOS CentOS Stream 10 image https://github.com/openshift/os/issues/1818. I was able to validate that the commit https://github.com/torvalds/linux/commit/6aa989ab2bd0d37540c812b4270006ff794662e7 introduced the bug.
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/374 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/374
new file mode 100644
index 00000000..4ce1f464
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/374
@@ -0,0 +1 @@
+Indentation should be done with spaces, not with TABs, in the PPC subsystem
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/426 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/426
new file mode 100644
index 00000000..636d9f37
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/426
@@ -0,0 +1 @@
+qemu linux-user doesn't translate host/target data for iovec I/O
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/519 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/519
new file mode 100644
index 00000000..4f3310e5
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/519
@@ -0,0 +1,33 @@
+xive: An extra '0x' prefix when printing hex values in the trace.
+Description of problem:
+The trace functions corresponding to the functions below print certain
+parameters with a double "0x" prefix, i.e., with "0x0x".
+
+
+- xive_source_esb_read
+- xive_source_esb_write
+- xive_tctx_tm_write
+- xive_tctx_tm_read
+Steps to reproduce:
+1. Execute the command line on a terminal
+2. Watch the terminal for the output.
+Additional information:
+Sample output:
+
+    xive_end_source_read END 0x0/0xf @0x0x1e0800
+    xive_source_esb_read @0x0x210c00 IRQ 0x10 val=0x0x1  
+    xive_tctx_tm_read @0x0x10038 sz=1 val=0x0
+    xive_tctx_tm_write @0x0x10038 sz=1 val=0x80
+    xive_tctx_tm_read @0x0x10038 sz=1 val=0x80
+    xive_end_source_read END 0x0/0xf @0x0x1e0800
+    xive_source_esb_read @0x0x210c00 IRQ 0x10 val=0x0x1
+    xive_tctx_tm_read @0x0x10038 sz=1 val=0x0
+    xive_tctx_tm_write @0x0x10038 sz=1 val=0x80
+    xive_tctx_tm_read @0x0x10038 sz=1 val=0x80
+
+The source lines at fault:
+
+    xive_source_esb_read(uint64_t addr, uint32_t srcno, uint64_t value) "@0x0x%"PRIx64" IRQ 0x%x val=0x0x%"PRIx64
+    xive_source_esb_write(uint64_t addr, uint32_t srcno, uint64_t value) "@0x0x%"PRIx64" IRQ 0x%x val=0x0x%"PRIx64
+    xive_tctx_tm_write(uint64_t offset, unsigned int size, uint64_t value) "@0x0x%"PRIx64" sz=%d val=0x%" PRIx64
+    xive_tctx_tm_read(uint64_t offset, unsigned int size, uint64_t value) "@0x0x%"PRIx64" sz=%d val=0x%" PRIx64
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/52 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/52
new file mode 100644
index 00000000..75729a30
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/52
@@ -0,0 +1 @@
+PowerPC64: tlbivax does not work for addresses above 4G
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/573 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/573
new file mode 100644
index 00000000..e050a92b
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/573
@@ -0,0 +1 @@
+maybe-uninitialized warning in pnv_phb3_translate_iommu()
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/584 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/584
new file mode 100644
index 00000000..9b52439f
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/584
@@ -0,0 +1,43 @@
+qemu-system-ppc: extra IPI interrupt on core0
+Description of problem:
+When I try to emit an IPI interrupt from core0 to another core via the MPIC controller(IPIDR1—Interprocessor interrupt dispatch register 1), core0 itself generates an unwanted IPI interrupt.
+Steps to reproduce:
+1. Prepare ISR routine, something like:
+
+    void ipi_handler (void)
+    {
+	int core_id = CORE_ID_GET(); 
+        myprintf("\n IPI interrupt triggered on core:%d\n",core_id);
+    }
+2. Create a task and bind it to core0. This task is mainly to write the MPIC controller to emit IPI interrupts to other cores.
+    MPIC_REG_WRITE(MPIC_BASE + IPIDR1, **0xe**);
+
+3. run the test task
+Additional information:
+/* Below test was tested on Qemu6.1 */
+
+IPI interrupts are emitted by core:0
+
+**IPI interrupt triggered on core:0** /* it's a bug, it should not trigger on core 0. */
+
+IPI interrupt triggered on core:1
+
+IPI interrupt triggered on core:2
+
+IPI interrupt triggered on core:3
+
+
+This bug only occurs when "emitting an IPIDR1 interrupt from **core0**".
+
+------------
+
+
+/* Below test was tested on real board(fsl_p4080ds) */
+
+IPI interrupts are emitted by core:0
+
+IPI interrupt triggered on core:1
+
+IPI interrupt triggered on core:2
+
+IPI interrupt triggered on core:3
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/622 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/622
new file mode 100644
index 00000000..6382e4b0
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/622
@@ -0,0 +1 @@
+Mac OS X Cheetah Virtual Machine booting back into Mac OS 9 for no reason
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/624 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/624
new file mode 100644
index 00000000..993abbae
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/624
@@ -0,0 +1,337 @@
+powerpc: halt and reboot via firmware via cuda fail
+Description of problem:
+Both shutdown and reboot cause errors preventing the action from occuring. With logging turned on as above, it can be seen that the issue is with CUDA. If the option `-M mac99,via=pmu` is given the action happens as expected.
+
+```
+# qemu-system-ppc -trace 'cuda_*' -d unimp,guest_errors -serial file:/dev/stdout -hda /tmp/grub-shell.CdAU68FI6P/grub.iso -boot c
+WARNING: Image format was not specified for '/tmp/grub-shell.CdAU68FI6P/grub.iso' and probing guessed raw.
+         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
+         Specify the 'raw' format explicitly to remove the restrictions.
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x00
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x00
+cuda_packet_send_data [2] 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x1f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x1f
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x02
+cuda_packet_send_data [2] 0x1f
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x1f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x2f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x2f
+cuda_packet_send length 4
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x00
+cuda_packet_send_data [2] 0x02
+cuda_packet_send_data [3] 0x01
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x01
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x2b
+cuda_delay_set_sr_int
+cuda_data_send send: 0x28
+cuda_delay_set_sr_int
+cuda_data_send send: 0xfe
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 4
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x2b
+cuda_packet_receive_data [2] 0x28
+cuda_packet_receive_data [3] 0xfe
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x00
+cuda_packet_send_data [2] 0x2b
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x2b
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x81
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x81
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x00
+cuda_packet_send_data [2] 0x81
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x81
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x2f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x2f
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x02
+cuda_packet_send_data [2] 0x2f
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x2f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x3f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x3f
+cuda_packet_send length 4
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x00
+cuda_packet_send_data [2] 0x03
+cuda_packet_send_data [3] 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x03
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x3b
+cuda_delay_set_sr_int
+cuda_data_send send: 0x29
+cuda_delay_set_sr_int
+cuda_data_send send: 0xfe
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 4
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x3b
+cuda_packet_receive_data [2] 0x29
+cuda_packet_receive_data [3] 0xfe
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x00
+cuda_packet_send_data [2] 0x3b
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x3b
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x91
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x91
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x00
+cuda_packet_send_data [2] 0x91
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x91
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x3f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x3f
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x02
+cuda_packet_send_data [2] 0x3f
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x3f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x4f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x4f
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x02
+cuda_packet_send_data [2] 0x4f
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x4f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x5f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x5f
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x02
+cuda_packet_send_data [2] 0x5f
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x5f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x7f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x7f
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x02
+cuda_packet_send_data [2] 0x7f
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x7f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+
+>> =============================================================
+>> OpenBIOS 1.1 [Aug 12 2021 13:35]
+>> Configuration device id QEMU version 1 machine id 2
+>> CPUs: 1
+>> Memory: 128M
+>> UUID: 00000000-0000-0000-0000-000000000000
+>> CPU type PowerPC,750
+milliseconds isn't unique.
+>> switching to new context:
+>> call-method block-size failed with error ffffffdf
+>> call-method block-size failed with error ffffffdf
+cuda_data_send send: 0x01
+cuda_delay_set_sr_int
+cuda_data_send send: 0x0a
+cuda_delay_set_sr_int
+cuda_data_send send: 0xfa
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 3
+cuda_packet_receive_data [0] 0x01
+cuda_packet_receive_data [1] 0x0a
+cuda_packet_receive_data [2] 0xfa
+cuda_receive_packet_cmd handling command POWERDOWN
+CUDA: POWERDOWN: wrong parameters 2
+cuda_packet_send length 4
+cuda_packet_send_data [0] 0x02
+cuda_packet_send_data [1] 0x05
+cuda_packet_send_data [2] 0x01
+cuda_packet_send_data [3] 0x0a
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x05
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x01
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x0a
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+>> interpret shut-down failed with error ffffffed
+>> interpret poweroff failed with error ffffffed
+```
+Steps to reproduce:
+1. Download attached iso file: [grub.iso.xz](/uploads/dea8f2bde4d90b9928f54bb9b73d76e9/grub.iso.xz)
+2. Decompress iso
+3. Run qemu as specified above
+Additional information:
+
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/651 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/651
new file mode 100644
index 00000000..c99d975f
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/651
@@ -0,0 +1 @@
+powerpc: Starting machine ref405ep fails with "Could not load PowerPC BIOS 'ppc405_rom.bin'"
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/672 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/672
new file mode 100644
index 00000000..9d1e58e3
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/672
@@ -0,0 +1,3 @@
+Slow emulation of mac99 (PowerPC G4) due to being single-threaded.
+Additional information:
+None
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/679 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/679
new file mode 100644
index 00000000..d685e8e0
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/679
@@ -0,0 +1 @@
+powerpc/e500: QEMU freeze without any output when kernel size is a bit big
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/720 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/720
new file mode 100644
index 00000000..f05751df
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/720
@@ -0,0 +1 @@
+The state of parameter DeviceState *dev in function spapr_get_fw_dev_path of PPC /spapr.c may cause a null pointer reference.
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/822 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/822
new file mode 100644
index 00000000..21be974c
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/822
@@ -0,0 +1,16 @@
+hw/ppc/vof.c:1033: undefined reference to `fdt_get_max_phandle' in qemu-6.1.1, qemu-6.2.0
+Description of problem:
+Compilation of the source code of 6.1.1 and 6.2.0 fails in the qemu-system-ppc target ath the linking stage. Specifically the error in both cases is 
+usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: libqemu-ppc-softmmu.fa.p/hw_ppc_vof.c.o: in function `vof_build_dt':
+/home/silviu/qemu-work/qemu-6.1.1/build/../hw/ppc/vof.c:1033: undefined reference to `fdt_get_max_phandle'
+
+(same error for 6.2.0)
+
+This system has qemu-5.2.0 installed, which is the default for Funtoo currently. There were no compilation errors with 5.2.0. 
+gcc is version 9.2.0
+Steps to reproduce:
+1. download qemu-6.1.1.tar.xz/qemu-6.2.0.tar.xz and uncompress
+2. configure
+3. make[error.txt](/uploads/c9a987870eff85e586ddb29a113f64a7/error.txt)
+Additional information:
+the final part of the build log attached as text
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/842 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/842
new file mode 100644
index 00000000..0d2870ce
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/842
@@ -0,0 +1,13 @@
+ppc64: hard lockup / hang in Linux kernel v5.17-rc1
+Description of problem:
+The kernel deterministically triggers a hard lockup / hang under QEMU since v5.17-rc1 (upgrading from v5.16).
+
+Bisecting points to the kernel's [0faf20a1ad16](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0faf20a1ad1647c0fc0f5a367c71e5e84deaf899) ("powerpc/64s/interrupt: Don't enable MSR[EE] in irq handlers unless perf is in use"). Reverting it on top of v5.17-rc1 fixes the issue.
+
+Reported to [linuxppc-dev](https://lore.kernel.org/linuxppc-dev/CANiq72n_FmDx=r-o9J8gYc6LpwRL5EGmhM6Xzwv27Xc7h1TNDw@mail.gmail.com/). Confirmed. Suspected QEMU modeling issue by Cédric Le Goater.
+Steps to reproduce:
+1. Build kernel v5.17-rc1 or commit 0faf20a1ad16 for ppc64le with the attached config (either GCC or Clang).
+2. Run it under QEMU with at least `-smp 2`.
+Additional information:
+[qemu-and-dmesg.log](/uploads/7cb5ce1cb70e06262800c16f4c800157/qemu-and-dmesg.log)
+[kernel.config](/uploads/327e9cec48a731abc9e44cb40db67de9/kernel.config)
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/859 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/859
new file mode 100644
index 00000000..860f3eaf
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/859
@@ -0,0 +1 @@
+PowerPC's Virtual Open Firmware uses an unsupported instruction in older CPUs
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/860 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/860
new file mode 100644
index 00000000..0ed94fd2
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/860
@@ -0,0 +1,310 @@
+Not able to launch guests in ppc64le P9 OPAL
+Description of problem:
+Not able to launch guests in ppc64le P9 OPAL
+Steps to reproduce:
+1. In a RHEL8 using 4.18.0-305.3.1.el8_4.ppc64le create a Fedora CoreOS VM using kernel-5.15.17-200.fc35.ppc64le. 
+2. Inside the FCOS vm run:
+```
+virt-install --import \
+    --name buildvm-ppc64le-fcos01.iad2.fedoraproject.org \
+    --memory=32768,maxmemory=32768                       \
+    --vcpus=16,maxvcpus=16                               \
+    --feature nested-hv=on                               \
+    --network bridge=br0,model=virtio,mac=RANDOM         \
+    --autostart                                          \
+    --memballoon virtio                                  \
+    --watchdog default                                   \
+    --rng /dev/random                                    \
+    --noautoconsole                                      \
+    --disk path=$PWD/fcos-ppc64le-builder.ign,format=raw,readonly=on,serial=ignition \
+    --disk bus=virtio,path=/dev/vg_guests/buildvm-ppc64le-fcos01.iad2.fedoraproject.org,cache=unsafe,io=threads
+```
+
+3. Try to run it again and you will get:
+
+```
+KVM: Failed to create TCE64 table for liobn 0x71000002
+KVM: Failed to create TCE64 table for liobn 0x80000000
+KVM: unknown exit, hardware reason ffffffffffffffc9
+NIP 0000000000000100   LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 CPU#0
+MSR 8000000000001000 HID0 0000000000000000  HF 6c000004 iidx 3 didx 3
+TB 00000000 00000000 DECR 0
+GPR00 0000000000000000 0000000000000000 0000000000000000 000000007fe00000
+GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+CR 00000000  [ -  -  -  -  -  -  -  -  ]             RES ffffffffffffffff
+ SRR0 0000000000000000  SRR1 0000000000000000    PVR 00000000004e1202 VRSAVE 0000000000000000
+SPRG0 0000000000000000 SPRG1 0000000000000000  SPRG2 0000000000000000  SPRG3 0000000000000000
+SPRG4 0000000000000000 SPRG5 0000000000000000  SPRG6 0000000000000000  SPRG7 0000000000000000
+HSRR0 0000000000000000 HSRR1 0000000000000000
+ CFAR 0000000000000000
+ LPCR 0000000000560413
+ PTCR 0000000000000000   DAR 0000000000000000  DSISR 0000000000000000
+```
+Additional information:
+Fedora xml:
+```
+<domain type='kvm' id='24'>
+  <name>buildvm-ppc64le-fcos01.iad2.fedoraproject.org</name>
+  <uuid>ed30c95e-b7c0-4c25-a6ba-b739459f101b</uuid>
+  <memory unit='KiB'>33554432</memory>
+  <currentMemory unit='KiB'>33554432</currentMemory>
+  <vcpu placement='static'>16</vcpu>
+  <resource>
+    <partition>/machine</partition>
+  </resource>
+  <os>
+    <type arch='ppc64le' machine='pseries-rhel8.3.0'>hvm</type>
+    <boot dev='hd'/>
+  </os>
+  <features>
+    <nested-hv state='on'/>
+  </features>
+  <cpu mode='custom' match='exact' check='none'>
+    <model fallback='forbid'>POWER9</model>
+  </cpu>
+  <clock offset='utc'/>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>destroy</on_crash>
+  <devices>
+    <emulator>/usr/libexec/qemu-kvm</emulator>
+    <disk type='block' device='disk'>
+      <driver name='qemu' type='raw' cache='unsafe' io='threads'/>
+      <source dev='/dev/vg_guests/buildvm-ppc64le-fcos01.iad2.fedoraproject.org' index='2'/>
+      <backingStore/>
+      <target dev='vda' bus='virtio'/>
+      <alias name='virtio-disk0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
+    </disk>
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='raw'/>
+      <source file='/tmp/fcos-ppc64le-builder.ign' index='1'/>
+      <backingStore/>
+      <target dev='vdb' bus='virtio'/>
+      <readonly/>
+      <serial>ignition</serial>
+      <alias name='virtio-disk1'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
+    </disk>
+    <controller type='usb' index='0' model='qemu-xhci' ports='15'>
+      <alias name='usb'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+    </controller>
+    <controller type='pci' index='0' model='pci-root'>
+      <model name='spapr-pci-host-bridge'/>
+      <target index='0'/>
+      <alias name='pci.0'/>
+    </controller>
+    <controller type='virtio-serial' index='0'>
+      <alias name='virtio-serial0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+    </controller>
+    <interface type='bridge'>
+      <mac address='52:54:00:c4:d2:aa'/>
+      <source bridge='br0'/>
+      <target dev='vnet23'/>
+      <model type='virtio'/>
+      <alias name='net0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
+    </interface>
+    <serial type='pty'>
+      <source path='/dev/pts/11'/>
+      <target type='spapr-vio-serial' port='0'>
+        <model name='spapr-vty'/>
+      </target>
+      <alias name='serial0'/>
+      <address type='spapr-vio' reg='0x30000000'/>
+    </serial>
+    <console type='pty' tty='/dev/pts/11'>
+      <source path='/dev/pts/11'/>
+      <target type='serial' port='0'/>
+      <alias name='serial0'/>
+      <address type='spapr-vio' reg='0x30000000'/>
+    </console>
+    <channel type='unix'>
+      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-24-buildvm-ppc64le-fcos/org.qemu.guest_agent.0'/>
+      <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/>
+      <alias name='channel0'/>
+      <address type='virtio-serial' controller='0' bus='0' port='1'/>
+    </channel>
+    <input type='tablet' bus='usb'>
+      <alias name='input0'/>
+      <address type='usb' bus='0' port='1'/>
+    </input>
+    <input type='keyboard' bus='usb'>
+      <alias name='input1'/>
+      <address type='usb' bus='0' port='2'/>
+    </input>
+    <graphics type='vnc' port='5910' autoport='yes' listen='127.0.0.1'>
+      <listen type='address' address='127.0.0.1'/>
+    </graphics>
+    <video>
+      <model type='vga' vram='16384' heads='1' primary='yes'/>
+      <alias name='video0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
+    </video>
+    <watchdog model='i6300esb' action='reset'>
+      <alias name='watchdog0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
+    </watchdog>
+    <memballoon model='virtio'>
+      <alias name='balloon0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
+    </memballoon>
+    <rng model='virtio'>
+      <backend model='random'>/dev/random</backend>
+      <alias name='rng0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
+    </rng>
+    <panic model='pseries'/>
+  </devices>
+  <seclabel type='dynamic' model='selinux' relabel='yes'>
+    <label>system_u:system_r:svirt_t:s0:c131,c913</label>
+    <imagelabel>system_u:object_r:svirt_image_t:s0:c131,c913</imagelabel>
+  </seclabel>
+  <seclabel type='dynamic' model='dac' relabel='yes'>
+    <label>+107:+107</label>
+    <imagelabel>+107:+107</imagelabel>
+  </seclabel>
+</domain>
+```
+
+Failure seen in journal when running `virt-ls`
+
+```
+Feb 04 16:19:39 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: KVMPPC-UVMEM: No support for secure guests
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: vcpu 000000004bd9d345 (0):
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: pc  = 0000000000000100  msr = 8000000000001000  trap = ffffffc9
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 0 = 0000000000000000  r16 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 1 = 0000000000000000  r17 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 2 = 0000000000000000  r18 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 3 = 000000003fe00000  r19 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 4 = 0000000000000000  r20 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 5 = 0000000000000000  r21 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 6 = 0000000000000000  r22 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 7 = 0000000000000000  r23 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 8 = 0000000000000000  r24 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 9 = 0000000000000000  r25 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r10 = 0000000000000000  r26 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r11 = 0000000000000000  r27 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r12 = 0000000000000000  r28 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r13 = 0000000000000000  r29 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r14 = 0000000000000000  r30 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r15 = 0000000000000000  r31 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: ctr = 0000000000000000  lr  = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: srr0 = 0000000000000000 srr1 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: sprg0 = 0000000000000000 sprg1 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: sprg2 = 0000000000000000 sprg3 = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: cr = 00000000  xer = 0000000000000000  dsisr = 00000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: dar = 0000000000000000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: fault dar = 0000000000000000 dsisr = 0c68f000
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: SLB (0 entries):
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: lpcr = 0040000000560413 sdr1 = 0000000000000000 last_inst = ffffffff
+Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: trap=0xffffffc9 | pc=0x100 | msr=0x8000000000001000
+```
+Running via qemu:
+```
+qemu-system-ppc64 -m 2048 -machine pseries,accel=kvm,kvm-type=HV -cpu host -nographic -snapshot -drive if=virtio,file=fedora-coreos-35.20220131.dev.0-qemu.ppc64le.qcow2
+
+KVM: unknown exit, hardware reason ffffffffffffffc9
+NIP 0000000000000100   LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 CPU#0
+MSR 8000000000001000 HID0 0000000000000000  HF 6c000004 iidx 3 didx 3
+TB 00000000 00000000 DECR 0
+GPR00 0000000000000000 0000000000000000 0000000000000000 000000007fe00000
+GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+CR 00000000  [ -  -  -  -  -  -  -  -  ]             RES ffffffffffffffff
+ SRR0 0000000000000000  SRR1 0000000000000000    PVR 00000000004e1202 VRSAVE 0000000000000000
+SPRG0 0000000000000000 SPRG1 0000000000000000  SPRG2 0000000000000000  SPRG3 0000000000000000
+SPRG4 0000000000000000 SPRG5 0000000000000000  SPRG6 0000000000000000  SPRG7 0000000000000000
+HSRR0 0000000000000000 HSRR1 0000000000000000
+ CFAR 0000000000000000
+ LPCR 0000000000560413
+ PTCR 0000000000000000   DAR 0000000000000000  DSISR 0000000000000000
+```
+libguestfs-test-tool also fails to launch guest
+
+```
+2022-02-04 18:10:02.355+0000: starting up libvirt version: 7.6.0, package: 5.fc35 (Fedora Project, 2021-12-16-17:58:25, ), qemu version: 6.1.0qemu-6.1.0-10.fc35, kernel: 5.15.17-200.fc35.ppc64le, hostname: buildvm-ppc64le-fcos01.iad2.fedoraproject.org
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
+HOME=/var/lib/libvirt/qemu/domain-1-guestfs-9ee177vxogzf \
+XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-1-guestfs-9ee177vxogzf/.local/share \
+XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-1-guestfs-9ee177vxogzf/.cache \
+XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-1-guestfs-9ee177vxogzf/.config \
+TMPDIR=/var/tmp \
+/usr/bin/qemu-system-ppc64 \
+-name guest=guestfs-9ee177vxogzfyj3v,debug-threads=on \
+-S \
+-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-1-guestfs-9ee177vxogzf/master-key.aes"}' \
+-machine pseries-6.1,accel=kvm,usb=off,dump-guest-core=off,memory-backend=ppc_spapr.ram \
+-cpu POWER9 \
+-m 1280 \
+-object '{"qom-type":"memory-backend-ram","id":"ppc_spapr.ram","size":1342177280}' \
+-overcommit mem-lock=off \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid 08cd47d3-91e1-4322-aa53-6665a9bc13c8 \
+-display none \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=22,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc,driftfix=slew \
+-no-reboot \
+-boot strict=on \
+-kernel /var/tmp/.guestfs-0/appliance.d/kernel \
+-initrd /var/tmp/.guestfs-0/appliance.d/initrd \
+-append 'panic=1 console=hvc0 console=ttyS0 edd=off udevtimeout=6000 udev.event-timeout=6000 no_timer_check printk.time=1 cgroup_disable=memory usbcore.nousb cryptomgr.notests tsc=reliable 8250.nr_uarts=1 root=UUID=0c185770-d5fc-4a67-acc9-3ea85178bda2 selinux=0 guestfs_verbose=1 TERM=screen' \
+-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x1 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x2 \
+-blockdev '{"driver":"file","filename":"/tmp/libguestfskYy342/scratch1.img","node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":true},"auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":false,"no-flush":true},"driver":"raw","file":"libvirt-2-storage"}' \
+-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=libvirt-2-format,id=scsi0-0-0-0,bootindex=1,write-cache=on \
+-blockdev '{"driver":"file","filename":"/var/tmp/.guestfs-0/appliance.d/root","node-name":"libvirt-3-storage","cache":{"direct":false,"no-flush":true},"auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-3-format","read-only":true,"cache":{"direct":false,"no-flush":true},"driver":"raw","file":"libvirt-3-storage"}' \
+-blockdev '{"driver":"file","filename":"/tmp/libguestfskYy342/overlay2.qcow2","node-name":"libvirt-1-storage","cache":{"direct":false,"no-flush":true},"auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":false,"no-flush":true},"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-3-format"}' \
+-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,device_id=drive-scsi0-0-1-0,drive=libvirt-1-format,id=scsi0-0-1-0,write-cache=on \
+-chardev socket,id=charserial0,path=/tmp/libguestfsFFWbf9/console.sock \
+-device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 \
+-chardev socket,id=charchannel0,path=/tmp/libguestfsFFWbf9/guestfsd.sock \
+-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 \
+-audiodev id=audio1,driver=none \
+-object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \
+-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x3 \
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
+KVM: unknown exit, hardware reason ffffffffffffffc9
+NIP 0000000000000100   LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 CPU#0
+MSR 8000000000001000 HID0 0000000000000000  HF 6c000004 iidx 3 didx 3
+TB 00000000 00000000 DECR 0
+GPR00 0000000000000000 0000000000000000 0000000000000000 000000003fe00000
+GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+CR 00000000  [ -  -  -  -  -  -  -  -  ]             RES ffffffffffffffff
+ SRR0 0000000000000000  SRR1 0000000000000000    PVR 00000000004e1202 VRSAVE 0000000000000000
+SPRG0 0000000000000000 SPRG1 0000000000000000  SPRG2 0000000000000000  SPRG3 0000000000000000
+SPRG4 0000000000000000 SPRG5 0000000000000000  SPRG6 0000000000000000  SPRG7 0000000000000000
+HSRR0 0000000000000000 HSRR1 0000000000000000
+ CFAR 0000000000000000
+ LPCR 0000000000560413
+ PTCR 0000000000000000   DAR 0000000000000000  DSISR 0000000000000000
+2022-02-04T18:19:47.323915Z qemu-system-ppc64: terminating on signal 15 from pid 1645 (<unknown process>)
+2022-02-04 18:19:47.524+0000: shutting down, reason=destroyed
+```
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/887 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/887
new file mode 100644
index 00000000..9758034c
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/887
@@ -0,0 +1 @@
+OSX Sorbet Leopard 10.5.9 on QEMU ?
diff --git a/gitlab/issues_text/target_ppc/host_missing/accel_missing/915 b/gitlab/issues_text/target_ppc/host_missing/accel_missing/915
new file mode 100644
index 00000000..3f75c1c3
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_missing/accel_missing/915
@@ -0,0 +1,379 @@
+could not build qemu 6.2.0 in PPC64le
+Description of problem:
+Qemu 6.2.0 is not building in PPC64le
+Additional information:
+```
+Build Qemu
+Using './build' as the directory for build output
+Submodule 'dtc' (https://gitlab.com/qemu-project/dtc.git) registered for path 'dtc'
+Submodule 'meson' (https://gitlab.com/qemu-project/meson.git) registered for path 'meson'
+Submodule 'ui/keycodemapdb' (https://gitlab.com/qemu-project/keycodemapdb.git) registered for path 'ui/keycodemapdb'
+Cloning into '/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/dtc'...
+Cloning into '/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/meson'...
+Cloning into '/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/ui/keycodemapdb'...
+The Meson build system
+Version: 0.59.3
+Source dir: /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu
+Build dir: /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/build
+Build type: native build
+Project name: qemu
+Project version: 6.2.0
+C compiler for the host machine: cc (gcc 9.4.0 "cc (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0")
+C linker for the host machine: cc ld.bfd 2.34
+Host machine cpu family: ppc64
+Host machine cpu: ppc64le
+Program sh found: YES (/usr/bin/sh)
+Program python3 found: YES (/usr/bin/python3)
+WARNING: Broken python installation detected. Python files installed by Meson might not be found by python interpreter.
+C++ compiler for the host machine: c++ (gcc 9.4.0 "c++ (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0")
+C++ linker for the host machine: c++ ld.bfd 2.34
+Program cgcc skipped: feature sparse disabled
+Library m found: YES
+Run-time dependency threads found: YES
+Library util found: YES
+Run-time dependency appleframeworks found: NO (tried framework)
+Found pkg-config: /usr/bin/pkg-config (0.29.1)
+Run-time dependency pixman-1 found: YES 0.38.4
+Run-time dependency zlib found: YES 1.2.11
+Library aio skipped: feature linux_aio disabled
+Run-time dependency liburing found: NO (tried pkgconfig)
+Dependency libxml-2.0 skipped: feature libxml2 disabled
+Dependency libnfs skipped: feature libnfs disabled
+Run-time dependency appleframeworks found: NO (tried framework)
+Run-time dependency libseccomp found: YES 2.5.1
+Has header "cap-ng.h" : YES 
+Library cap-ng found: YES
+Run-time dependency xkbcommon found: NO (tried pkgconfig)
+Library vdeplug skipped: feature vde disabled
+Run-time dependency libpulse found: NO (tried pkgconfig)
+Run-time dependency alsa found: NO (tried pkgconfig)
+Run-time dependency jack found: NO (tried pkgconfig)
+Run-time dependency spice-protocol found: NO (tried pkgconfig)
+Dependency spice-server skipped: feature spice disabled
+Library rt found: YES
+Dependency libiscsi skipped: feature libiscsi disabled
+Run-time dependency libzstd found: NO (tried pkgconfig)
+Dependency virglrenderer skipped: feature virglrenderer disabled
+Dependency libcurl skipped: feature curl disabled
+Dependency libudev skipped: feature libudev disabled
+Library brlapi skipped: feature brlapi disabled
+Dependency sdl2 skipped: feature sdl disabled
+Library rados found: YES
+Has header "rbd/librbd.h" : YES 
+Library rbd found: YES
+Dependency glusterfs-api skipped: feature glusterfs disabled
+Library bz2 skipped: feature bzip2 disabled
+Has header "lzfse.h" : NO 
+Has header "sys/soundcard.h" : YES 
+Run-time dependency gnutls found: NO (tried pkgconfig)
+Run-time dependency gnutls found: NO (tried pkgconfig)
+libgcrypt-config found: NO need ['>=1.8']
+Run-time dependency libgcrypt found: NO (tried config-tool)
+Dependency nettle skipped: feature nettle disabled
+Dependency gtk+-3.0 skipped: feature gtk disabled
+Library pam skipped: feature auth_pam disabled
+Library snappy skipped: feature snappy disabled
+Library lzo2 skipped: feature lzo disabled
+Dependency libcacard skipped: feature smartcard disabled
+Run-time dependency u2f-emu found: NO (tried pkgconfig)
+Dependency libusbredirparser-0.5 skipped: feature usb_redir disabled
+Dependency libusb-1.0 skipped: feature libusb disabled
+Dependency libpmem skipped: feature libpmem disabled
+Run-time dependency libdaxctl found: NO (tried pkgconfig)
+Run-time dependency libkeyutils found: NO (tried pkgconfig)
+Checking for function "gettid" : YES 
+Run-time dependency libselinux found: YES 3.0
+Run-time dependency fuse3 found: NO (tried pkgconfig)
+Run-time dependency libbpf found: NO (tried pkgconfig)
+Has header "sys/epoll.h" : YES 
+Has header "linux/magic.h" : YES 
+Has header "valgrind/valgrind.h" : NO 
+Has header "linux/btrfs.h" : YES 
+Has header "libdrm/drm.h" : NO 
+Has header "pty.h" : YES 
+Has header "sys/disk.h" : NO 
+Has header "sys/ioccom.h" : NO 
+Has header "sys/kcov.h" : NO 
+Checking for function "accept4" : YES 
+Checking for function "clock_adjtime" : YES 
+Checking for function "dup3" : YES 
+Checking for function "fallocate" : YES 
+Checking for function "posix_fallocate" : YES 
+Checking for function "posix_memalign" : YES 
+Checking for function "ppoll" : YES 
+Checking for function "preadv" : YES 
+Checking for function "sem_timedwait" with dependency threads: YES 
+Checking for function "sendfile" : YES 
+Checking for function "setns" : YES 
+Checking for function "unshare" : YES 
+Checking for function "syncfs" : YES 
+Checking for function "sync_file_range" : YES 
+Checking for function "timerfd_create" : YES 
+Checking for function "copy_file_range" : YES 
+Checking for function "openpty" with dependency -lutil: YES 
+Checking for function "strchrnul" : YES 
+Checking for function "system" : YES 
+Header <byteswap.h> has symbol "bswap_32" : YES 
+Header <sys/epoll.h> has symbol "epoll_create1" : YES 
+Header <unistd.h> has symbol "environ" : YES 
+Header <linux/falloc.h> has symbol "FALLOC_FL_PUNCH_HOLE" : YES 
+Header <linux/falloc.h> has symbol "FALLOC_FL_KEEP_SIZE" : YES 
+Header <linux/falloc.h> has symbol "FALLOC_FL_ZERO_RANGE" : YES 
+Has header "linux/fiemap.h" : YES 
+Header <linux/fs.h> has symbol "FS_IOC_FIEMAP" : YES 
+Checking for function "getrandom" : YES 
+Header <sys/random.h> has symbol "GRND_NONBLOCK" : YES 
+Header <sys/inotify.h> has symbol "inotify_init" : YES 
+Header <sys/inotify.h> has symbol "inotify_init1" : YES 
+Header <machine/bswap.h> has symbol "bswap32" : NO 
+Header <sys/prctl.h> has symbol "PR_SET_TIMERSLACK" : YES 
+Header <linux/rtnetlink.h> has symbol "IFLA_PROTO_DOWN" : YES 
+Header <sys/sysmacros.h> has symbol "makedev" : YES 
+Header <getopt.h> has symbol "optreset" : NO 
+Header <netinet/in.h> has symbol "IPPROTO_MPTCP" : NO 
+Checking whether type "struct sigevent" has member "sigev_notify_thread_id" : NO 
+Checking whether type "struct stat" has member "st_atim" : YES 
+Checking for type "struct iovec" : YES 
+Checking for type "struct utmpx" : YES 
+Checking for type "struct mmsghdr" : YES 
+Program scripts/minikconf.py found: YES (/usr/bin/python3 /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/minikconf.py)
+Configuring ppc64-softmmu-config-target.h using configuration
+Configuring ppc64-softmmu-config-devices.mak with command
+Reading depfile: /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/build/meson-private/ppc64-softmmu-config-devices.mak.d
+Configuring ppc64-softmmu-config-devices.h using configuration
+Library fdt found: NO
+Configuring config-host.h using configuration
+Program scripts/hxtool found: YES (/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/hxtool)
+Program scripts/shaderinclude.pl found: YES (/usr/bin/env perl /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/shaderinclude.pl)
+Program scripts/qapi-gen.py found: YES (/usr/bin/python3 /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/qapi-gen.py)
+Program scripts/qemu-version.sh found: YES (/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/qemu-version.sh)
+
+Executing subproject libvhost-user 
+
+libvhost-user| Project name: libvhost-user
+libvhost-user| Project version: undefined
+libvhost-user| C compiler for the host machine: cc (gcc 9.4.0 "cc (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0")
+libvhost-user| C linker for the host machine: cc ld.bfd 2.34
+libvhost-user| Dependency threads found: YES unknown (cached)
+libvhost-user| Dependency glib-2.0 found: YES 6.2.0 (overridden)
+libvhost-user| Build targets in project: 9
+libvhost-user| Subproject libvhost-user finished.
+
+Program cat found: YES (/usr/bin/cat)
+Program scripts/decodetree.py found: YES (/usr/bin/python3 /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/decodetree.py)
+Program ../scripts/modules/module_block.py found: YES (/usr/bin/python3 /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/block/../scripts/modules/module_block.py)
+Program ../scripts/block-coroutine-wrapper.py found: YES (/usr/bin/python3 /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/block/../scripts/block-coroutine-wrapper.py)
+Program scripts/modinfo-collect.py found: YES (/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/modinfo-collect.py)
+Program scripts/modinfo-generate.py found: YES (/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/modinfo-generate.py)
+Program nm found: YES
+Program scripts/undefsym.py found: YES (/usr/bin/python3 /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/undefsym.py)
+Program scripts/feature_to_c.sh found: YES (/bin/sh /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/feature_to_c.sh)
+Configuring 50-qemu-virtiofsd.json using configuration
+Program qemu-keymap found: NO
+Program cp found: YES (/usr/bin/cp)
+Program sphinx-build-3 sphinx-build skipped: feature docs disabled
+Program python3 found: YES (/usr/bin/python3)
+Program diff found: YES (/usr/bin/diff)
+Program dbus-daemon found: YES (/usr/bin/dbus-daemon)
+Program /usr/bin/gdbus-codegen found: YES (/usr/bin/gdbus-codegen)
+Program initrd-stress.sh found: YES (/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/tests/migration/initrd-stress.sh)
+Build targets in project: 395
+
+qemu 6.2.0
+
+  Directories
+    Install prefix               : /usr
+    BIOS directory               : share/qemu/qemu
+    firmware path                : /usr/share/qemu/qemu-firmware
+    binary directory             : bin
+    library directory            : lib/qemu
+    module directory             : lib/qemu/qemu
+    libexec directory            : libexec/qemu
+    include directory            : include
+    config directory             : /usr/etc
+    local state directory        : /usr/var
+    Manual directory             : share/man
+    Doc directory                : /usr/share/doc
+    Build directory              : /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/build
+    Source path                  : /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu
+    GIT submodules               : ui/keycodemapdb meson dtc
+
+  Host binaries
+    git                          : git
+    make                         : make
+    python                       : /usr/bin/python3 (version: 3.8)
+    sphinx-build                 : NO
+    gdb                          : /usr/bin/gdb
+    genisoimage                  : /usr/bin/genisoimage
+
+  Configurable features
+    Documentation                : NO
+    system-mode emulation        : YES
+    user-mode emulation          : NO
+    block layer                  : YES
+    Install blobs                : YES
+    module support               : NO
+    fuzzing support              : NO
+    Audio drivers                : oss
+    Trace backends               : log
+    QOM debugging                : NO
+    vhost-kernel support         : YES
+    vhost-net support            : YES
+    vhost-crypto support         : YES
+    vhost-scsi support           : YES
+    vhost-vsock support          : YES
+    vhost-user support           : YES
+    vhost-user-blk server support: YES
+    vhost-user-fs support        : YES
+    vhost-vdpa support           : YES
+    build guest agent            : NO
+
+  Compilation
+    host CPU                     : ppc64
+    host endianness              : little
+    C compiler                   : cc
+    Host C compiler              : cc
+    C++ compiler                 : c++
+    CFLAGS                       : -O2 -fno-semantic-interposition -falign-functions=32 -D_FORTIFY_SOURCE=2 -O2 -g
+    CXXFLAGS                     : -O2 -fno-semantic-interposition -falign-functions=32 -D_FORTIFY_SOURCE=2 -O2 -g
+    LDFLAGS                      : -O2 -fno-semantic-interposition -falign-functions=32 -D_FORTIFY_SOURCE=2 -z noexecstack -z relro -z now
+    QEMU_CFLAGS                  : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=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-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
+    QEMU_LDFLAGS                 : -Wl,--warn-common -Wl,-z,relro -Wl,-z,now  -fstack-protector-strong
+    profiler                     : NO
+    link-time optimization (LTO) : NO
+    PIE                          : YES
+    static build                 : NO
+    malloc trim support          : YES
+    membarrier                   : NO
+    debug stack usage            : NO
+    mutex debugging              : NO
+    memory allocator             : system
+    avx2 optimization            : NO
+    avx512f optimization         : NO
+    gprof enabled                : NO
+    gcov                         : NO
+    thread sanitizer             : NO
+    CFI support                  : NO
+    strip binaries               : YES
+    sparse                       : NO
+    mingw32 support              : NO
+
+  Targets and accelerators
+    KVM support                  : YES
+    HAX support                  : NO
+    HVF support                  : NO
+    WHPX support                 : NO
+    NVMM support                 : NO
+    Xen support                  : NO
+    TCG support                  : NO
+    target list                  : ppc64-softmmu
+    default devices              : YES
+    out of process emulation     : YES
+
+  Block layer support
+    coroutine backend            : ucontext
+    coroutine pool               : YES
+    Block whitelist (rw)         : 
+    Block whitelist (ro)         : 
+    Use block whitelist in tools : NO
+    VirtFS support               : YES
+    build virtiofs daemon        : YES
+    Live block migration         : NO
+    replication support          : NO
+    bochs support                : NO
+    cloop support                : NO
+    dmg support                  : NO
+    qcow v1 support              : NO
+    vdi support                  : NO
+    vvfat support                : NO
+    qed support                  : NO
+    parallels support            : NO
+    FUSE exports                 : NO
+
+  Crypto
+    TLS priority                 : "NORMAL"
+    GNUTLS support               : NO
+    libgcrypt                    : NO
+    nettle                       : NO
+    crypto afalg                 : NO
+    rng-none                     : NO
+    Linux keyring                : YES
+
+  Dependencies
+    SDL support                  : NO
+    SDL image support            : NO
+    GTK support                  : NO
+    pixman                       : YES 0.38.4
+    VTE support                  : NO
+    slirp support                : NO
+    libtasn1                     : NO
+    PAM                          : NO
+    iconv support                : NO
+    curses support               : NO
+    virgl support                : NO
+    curl support                 : NO
+    Multipath support            : NO
+    VNC support                  : NO
+    OSS support                  : YES
+    ALSA support                 : NO
+    PulseAudio support           : NO
+    JACK support                 : NO
+    brlapi support               : NO
+    vde support                  : NO
+    netmap support               : NO
+    l2tpv3 support               : YES
+    Linux AIO support            : NO
+    Linux io_uring support       : NO
+    ATTR/XATTR support           : YES
+    RDMA support                 : NO
+    PVRDMA support               : NO
+    fdt support                  : internal
+    libcap-ng support            : YES
+    bpf support                  : NO
+    spice protocol support       : NO
+    rbd support                  : YES
+    xfsctl support               : NO
+    smartcard support            : NO
+    U2F support                  : NO
+    libusb                       : NO
+    usb net redir                : NO
+    OpenGL support               : NO
+    GBM                          : NO
+    libiscsi support             : NO
+    libnfs support               : NO
+    seccomp support              : YES 2.5.1
+    GlusterFS support            : NO
+    TPM support                  : NO
+    libssh support               : NO
+    lzo support                  : NO
+    snappy support               : NO
+    bzip2 support                : NO
+    lzfse support                : NO
+    zstd support                 : NO
+    NUMA host support            : NO
+    libxml2                      : NO
+    capstone                     : NO
+    libpmem support              : NO
+    libdaxctl support            : NO
+    libudev                      : NO
+    FUSE lseek                   : NO
+    selinux                      : YES 3.0
+
+  Subprojects
+    libvhost-user                : YES
+
+Found ninja-1.10.0 at /usr/bin/ninja
+```
+
+```
+[1330/1767] Compiling C object libqemu-ppc64-softmmu.fa.p/target_ppc_excp_helper.c.o
+FAILED: libqemu-ppc64-softmmu.fa.p/target_ppc_excp_helper.c.o 
+cc -Ilibqemu-ppc64-softmmu.fa.p -I. -I.. -Itarget/ppc -I../target/ppc -I../dtc/libfdt -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/glib-2.0 -I/usr/lib/powerpc64le-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/linux-headers -isystem linux-headers -iquote . -iquote /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu -iquote /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/include -iquote /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/disas/libvixl -pthread -U_FORTIFY_SOURCE -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 -O2 -fno-semantic-interposition -falign-functions=32 -D_FORTIFY_SOURCE=2 -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="ppc64-softmmu-config-target.h"' '-DCONFIG_DEVICES="ppc64-softmmu-config-devices.h"' -MD -MQ libqemu-ppc64-softmmu.fa.p/target_ppc_excp_helper.c.o -MF libqemu-ppc64-softmmu.fa.p/target_ppc_excp_helper.c.o.d -o libqemu-ppc64-softmmu.fa.p/target_ppc_excp_helper.c.o -c ../target/ppc/excp_helper.c
+../target/ppc/excp_helper.c: In function ‘powerpc_excp’:
+../target/ppc/excp_helper.c:463:29: error: implicit declaration of function ‘cpu_ldl_code’ [-Werror=implicit-function-declaration]
+  463 |             uint32_t insn = cpu_ldl_code(env, env->nip);
+      |                             ^~~~~~~~~~~~
+../target/ppc/excp_helper.c:463:29: error: nested extern declaration of ‘cpu_ldl_code’ [-Werror=nested-externs]
+cc1: all warnings being treated as errors
+[1331/1767] Compiling C object libqemu-ppc64-softmmu.fa.p/hw_block_dataplane_virtio-blk.c.o
+```
diff --git a/gitlab/issues_text/target_ppc/host_ppc/accel_KVM/1559 b/gitlab/issues_text/target_ppc/host_ppc/accel_KVM/1559
new file mode 100644
index 00000000..383b4ee2
--- /dev/null
+++ b/gitlab/issues_text/target_ppc/host_ppc/accel_KVM/1559
@@ -0,0 +1,7 @@
+7.2 (regression?): ppc64 KVM-HV hangs during boot
+Description of problem:
+qemu 7.2.0 hangs at " * Mounting ZFS filesystem(s)  ..." whereas 7.1.0 would fully boot.
+
+Without -smp, sometimes gets further and hangs later on at " * Seeding random number generator ..."
+Additional information:
+7.1.0 used to work before upgrading to 7.2.0, but would hang randomly after booting (usually during my benchmark). Not sure if related. Unfortunately, after downgrading back to 7.1.0, it also now hangs the same way as 7.2.0 does.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1022 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1022
new file mode 100644
index 00000000..7fe466eb
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1022
@@ -0,0 +1,33 @@
+RISC-V: Simulation terminated with seg fault when encountering `vsra.vx`
+Description of problem:
+QEMU simulation terminated with segmentation fault. Here is the backtrace of the simulation
+
+```
+(gdb) r
+Starting program: qemu/build/qemu-riscv64 -cpu rv64,vext_spec=v1.0,v=true,Zfh=true,Zve32f=true,Zve64f=true,vlen=128 -B 0x100000 a.out
+Missing separate debuginfos, use: yum debuginfo-install glibc-2.28-164.el8_5.3.x86_64
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/lib64/libthread_db.so.1".
+[New Thread 0x7ffff4edd700 (LWP 3239772)]
+
+Thread 1 "qemu-riscv64" received signal SIGSEGV, Segmentation fault.
+0x00007fffe8004fad in code_gen_buffer ()
+Missing separate debuginfos, use: yum debuginfo-install glib2-2.56.4-156.el8.x86_64 gmp-6.1.2-10.el8.x86_64 gnutls-3.6.16-4.el8.x86_64 libffi-3.1-22.el8.x86_64 libidn2-2.2.0-1.el8.x86_64 libtasn1-4.13-3.el8.x86_64 libunistring-0.9.9-3.el8.x86_64 p11-kit-0.23.22-1.el8.x86_64 pcre-8.42-6.el8.x86_64
+(gdb) bt
+#0  0x00007fffe8004fad in code_gen_buffer ()
+#1  0x00005555556a0b9b in cpu_tb_exec (tb_exit=<synthetic pointer>, itb=<optimized out>, cpu=0x7fffe8005000 <code_gen_buffer+20435>) at ../accel/tcg/cpu-exec.c:358
+#2  cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=0x7fffe8005000 <code_gen_buffer+20435>) at ../accel/tcg/cpu-exec.c:848
+#3  cpu_exec (cpu=cpu@entry=0x555555eed3d0) at ../accel/tcg/cpu-exec.c:1007
+#4  0x00005555555e6d30 in cpu_loop (env=0x555555ef56f0) at ../linux-user/riscv/cpu_loop.c:37
+#5  0x00005555555df9f7 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../linux-user/main.c:909
+```
+Steps to reproduce:
+1. Checkout to QEMU's latest master (`ec11dc41eec5142b4776db1296972c6323ba5847`)
+2. `mkdir build ; cd build ; ../configure ; make -j24`
+3. `qemu-riscv64 -cpu rv64,vext_spec=v1.0,v=true,Zfh=true,Zve32f=true,Zve64f=true,vlen=128 -B 0x100000 ./a.out`
+Additional information:
+Attaching code (output.c) and binary (a.out)
+
+[a.out](/uploads/0ecfb436a439619527ef645bdc781a48/a.out)
+
+[output.c](/uploads/cd492b4c9468f0b48412e76e7f6fcf91/output.c)
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1028 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1028
new file mode 100644
index 00000000..d19df99b
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1028
@@ -0,0 +1,34 @@
+Assert fail for RISC-V RVV vmv.v.x for e64, vl == vl_max on RV32 guest
+Description of problem:
+assert message:
+qemu/tcg/tcg-op-gvec.c:1714: tcg_gen_gvec_dup_i32: Assertion `vece <= MO_32' failed.
+
+For a e64 vmv.v.x, in the file trans_rvv.c.inc, function "trans_vmv_v_x", when s->vl_eq_vlmax is true, then "tcg_gen_gvec_dup_tl" (it's defined to tcg_gen_gvec_dup_i32 for RV32) is called. In "tcg_gen_gvec_dup_i32" the assert "tcg_debug_assert(vece <= MO_32) will be triggered, since vece == MO_64 for e64.
+Steps to reproduce:
+1.enable cfg.Zve64f
+
+2.Prepare a problem as set e64, vl == vl_max and use vmv.v.x, maybe as below
+```
+  li t0, -1,
+  vsetvli x0, t0, e64,m1,tu,mu
+  li t1, -1
+  vmv.v.x v0, t1
+```
+Additional information:
+Below is a possible solution if it's appropriate.
+```
+#if TARGET_LONG_BITS == 32
+            if (s->sew == 3) {
+                TCGv_i64 s1_i64 = tcg_temp_new_i64();
+                tcg_gen_ext_tl_i64(s1_i64, s1);
+                tcg_gen_gvec_dup_i64(s->sew, vreg_ofs(s, a->rd),
+                                     MAXSZ(s), MAXSZ(s), s1_i64);
+                tcg_temp_free_i64(s1_i64);
+            } else {
+#endif
+            tcg_gen_gvec_dup_tl(s->sew, vreg_ofs(s, a->rd),
+                                MAXSZ(s), MAXSZ(s), s1);
+#if TARGET_LONG_BITS == 32
+            }
+#endif
+```
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1053 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1053
new file mode 100644
index 00000000..e8ec0f20
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1053
@@ -0,0 +1,9 @@
+Executable PMP regions of size less than 4K always trigger an instruction access fault
+Description of problem:
+When configuring a PMP region that is less than 4K in size (Page size), and then trying to execute instructions inside said region, TCG always throws a PMP exception, even though the area allows code execution.
+Additional information:
+I've debugged the issue already, and it's happening because of the following optimization in TCG:
+
+TCG uses `get_page_addr_code_hostp` in order to try and get the translation cached for a whole page of instructions; if this function is unable to translate a whole page, it's supposed to simply return `-1`, and then the caller is supposed to translate and execute on a per-instruction basis. In this case `get_page_addr_code_hostp` calls `tlb_fill`, which then calls `riscv_cpu_tlb_fill`, which then calls `get_physical_address_pmp` to perform the PMP access checks. When said instructions are covered by a PMP region which is smaller than a page, this check then fails, since PMP regions must cover the whole access in order to allow it. At this point `riscv_cpu_tlb_fill` will see that a PMP fault happened, and since `probe` is set to false by `get_page_addr_code_hostp`, it will throw a RISC-V access fault exception instead of just returning a failure that `get_page_addr_code_hostp` can handle (by only accessing the memory of the specific instruction instead, which will be fully covered by the PMP region).
+
+I haven't tried to fix it myself (my first idea is to simply make `get_page_addr_code_hostp` set the probe flag), since I'm not sure if changing that part of TCG will affect other architectures that I'm not aware of.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1060 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1060
new file mode 100644
index 00000000..8e3de169
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1060
@@ -0,0 +1,33 @@
+RISC-V: mtval/stval is not correctly set to the instruction itself on illegal instructions
+Description of problem:
+QEMU 7.0 claims to support `stval`/`mtval` for illegal instructions, but `mtval`/`stval` is actually set to `0`
+Steps to reproduce:
+1. Assemble and link `mtval-illegal.elf`. The code simply sets up a trap handler and generates an illegal instruction exception
+
+2. Start QEMU with:
+
+  ```
+  qemu-system-riscv64 -cpu rv64,h=off -bios mtval-illegal.elf -nographic -icount shift=0 -s -S
+  ```
+
+3. Attach with GDB:
+
+  ```
+  gdb mtval-illegal.elf
+
+  # Within GDB
+  target extended-remote :1234
+  break trap
+  disp $mtval
+
+  # Keep single stepping until breakpoint
+  stepi
+  ```
+
+4. When control flow reaches `trap`, `mtval` is written with `0` instead of the encoding of `csrw time, x0` (`0xc0101073`)
+Additional information:
+Writing `0` to `mtval` on a illegal instruction trap is allowed by the specs, but since the [changelog of QEMU 7.0][changelog] says it should be supported, I would consider it a bug.
+
+[changelog]: https://wiki.qemu.org/ChangeLog/7.0#RISC-V
+
+I encountered this when trying to figure out why my program worked with QEMU 6 but breaks with QEMU 7. It's more complicated, but in that case I managed to get `mtval` written with neither `0` nor the actual illegal instruction, but a different illegal instruction. I will try gathering up all the dependencies and write down the steps to reproduce if needed and if I find the time.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1155 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1155
new file mode 100644
index 00000000..842d36fd
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1155
@@ -0,0 +1,27 @@
+RISC-V: Instruction fetch exceptions can have invalid tval/epc combination
+Description of problem:
+Instruction page fault / guest-page fault / access fault exceptions can have invalid `epc`/`tval` combinations, for example as shown in the debug log:
+
+```
+riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000014, epc:0xffffffff802fec76, tval:0xffffffff802ff000, desc=guest_exec_page_fault
+riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000014, epc:0xffffffff80243fe6, tval:0xffffffff80244000, desc=guest_exec_page_fault
+```
+
+From the privileged spec:
+
+> If `mtval` is written with a nonzero value when an instruction access-fault or page-fault exception occurs on a system with variable-length instructions, then `mtval` will contain the virtual address of the portion of the instruction that caused the fault, while `mepc` will point to the beginning of the instruction.
+
+Currently RISC-V only has 32-bit and 16-bit instructions, so the difference `tval - epc` should be either `0` or `2`. In the examples above the differences are `906` and `26` respectively.
+
+Possibly notable: all occurrences of these invalid combinations to have `tval` aligned to a page-boundary.
+Steps to reproduce:
+This one only gives invalid `tval`/`epc` combinations with instruction guest-page faults, but I've found it to be the easiest reproducer to describe, since presumably running KVM in RISC-V QEMU is a standard setup. I have not otherwise been able to find a more minimal case.
+
+1. Start a QEMU-based `riscv64` machine
+2. Start a KVM-based virtual machine with QEMU inside it
+3. Do some stuff in the KVM-based virtual machine to increase the chance of page faults
+4. Look in the debug log of the outer QEMU for `guest_exec_page_fault` exceptions with `tval` ending in `000`, but `epc` ending in neither `000` nor `ffe`
+
+Everything in both layers of guests should otherwise work without issue, but other/future software that relies on the spec-mandated relationship of `epc`/`tval` may break.
+Additional information:
+
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1224 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1224
new file mode 100644
index 00000000..960dc2e9
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1224
@@ -0,0 +1,10 @@
+QEMU crashes with failed assertion when executing compressed instructions with C extension support disabled
+Description of problem:
+When executing compressed instructions with compressed instruction support disabled (c=off), the tcg riscv translations fails an assertion.
+```
+qemu-system-riscv64: qemu/accel/tcg/translate-all.c:1449: tb_gen_code: Assertion `tb->size != 0' failed.
+```
+
+I believe that the issue is caused due to the fact that the compressed instruction without RVC support branch of the `decode_opc` function does not update `ctx->pc_succ_insn`, which causes `ctx->base.pc_next` to not be updated in `riscv_tr_translate_insn`, which then finally triggers the assertion once the tcg generation returns to `tb_gen_code`.
+
+Side note, it also seems like the `gen_exception_illegal` call in the same if case is not needed, since we also call it again at the end of the function.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1339 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1339
new file mode 100644
index 00000000..8751228f
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1339
@@ -0,0 +1,16 @@
+RVV vfncvt.rtz.x.f.w Assertion failed
+Description of problem:
+when execute 
+``` 
+vsetvli        t0,       x0,         e16,      m1
+vfncvt.rtz.x.f.w v0, v4
+```
+report error:
+
+qemu-riscv64: ../target/riscv/translate.c:212: decode_save_opc: Assertion \`ctx->insn_start != NULL' failed. Segmentation fault (core dumped)
+Steps to reproduce:
+1. write the code
+2. compile
+3. excute
+Additional information:
+
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1353 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1353
new file mode 100644
index 00000000..0fdbdb2c
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1353
@@ -0,0 +1,175 @@
+QEMU crashes when executing a RISC-V compressed instruction with C extension disabled.
+Description of problem:
+When binaries are built with compressed instructions, but QEMU is launched with C extension disabled we get a crash instead of a trap that can be handled by the fault handler. It is quite possible that this only asserts if the compressed instruction is the first instruction after a new translation block due to the unconditional trap generated by:
+```
+         if (!has_ext(ctx, RVC)) {
+            gen_exception_illegal(ctx);
+        } else {
+```
+Although I would not expect the TB to be empty. Unfortunately it appears to crash before `-d op` prints any output.
+Steps to reproduce:
+1. Compile the following assembly code to an ELF32 binary: `clang --target=riscv32-none-elf -nostdlib -o crash.elf ./crash.S -Wl,--section-start=.text=0x80000000`
+```asm
+.text
+.global _start
+.type _start,@function
+_start:
+       # .4byte 0x300022f3  # csrr    t0,mstatus
+       # NB: compressed instruction, if we start qemu with c=false,
+       # this results in the following error:
+       # qemu-system-riscv32: ../../upstream-qemu/accel/tcg/translate-all.c:762: int setjmp_gen_code(CPUArchState *, TranslationBlock *, target_ulong, void *, int *, int64_t *): Assertion `tb->size != 0' failed.
+       bne t0, t1, .Lfoo  # This instruction is not strictly necessary, but it makes the debug output a bit more useful
+.Lfoo:
+       .2byte 0x6309      # lui     t1,0x2
+       j _start
+```
+2. `qemu-system-riscv32 -monitor none -serial none -machine virt,accel=tcg -cpu rv32,i=true,c=false -kernel crash.elf -nographic -bios none -d in_asm,op,op_opt,unimp`
+3. Assertion failure: `qemu-system-riscv32: ../../upstream-qemu/accel/tcg/translate-all.c:762: int setjmp_gen_code(CPUArchState *, TranslationBlock *, target_ulong, void *, int *, int64_t *): Assertion `tb->size != 0' failed.`
+Additional information:
+Here is the output of `-d in_asm,op,op_opt,unimp,nochain`:
+```
+----------------
+IN: 
+Priv: 3; Virt: 0
+0x00001000:  00000297          auipc                   t0,0                    # 0x1000
+0x00001004:  02828613          addi                    a2,t0,40
+0x00001008:  f1402573          csrrs                   a0,mhartid,zero
+
+OP:
+ ld_i32 tmp1,env,$0xfffffffffffffff0
+ brcond_i32 tmp1,$0x0,lt,$L0
+
+ ---- 00001000 00000000
+ mov_i32 x5/t0,$0x1000
+
+ ---- 00001004 00000000
+ add_i32 x12/a2,x5/t0,$0x28
+
+ ---- 00001008 f1402573
+ call csrr,$0x0,$1,x10/a0,env,$0xf14
+ mov_i32 pc,$0x100c
+ exit_tb $0x0
+ set_label $L0
+ exit_tb $0x7f5824000043
+
+OP after optimization and liveness analysis:
+ ld_i32 tmp1,env,$0xfffffffffffffff0      pref=0xffff
+ brcond_i32 tmp1,$0x0,lt,$L0              dead: 0 1
+
+ ---- 00001000 00000000                
+ mov_i32 x5/t0,$0x1000                    sync: 0  dead: 0 1  pref=0xffff
+
+ ---- 00001004 00000000                
+ mov_i32 x12/a2,$0x1028                   sync: 0  dead: 0 1  pref=0xffff
+
+ ---- 00001008 f1402573                
+ call csrr,$0x0,$1,x10/a0,env,$0xf14      sync: 0  dead: 0 1 2  pref=none
+ mov_i32 pc,$0x100c                       sync: 0  dead: 0 1  pref=0xffff
+ exit_tb $0x0                           
+ set_label $L0                          
+ exit_tb $0x7f5824000043                
+
+----------------
+IN: 
+Priv: 3; Virt: 0
+0x0000100c:  0202a583          lw                      a1,32(t0)
+0x00001010:  0182a283          lw                      t0,24(t0)
+0x00001014:  00028067          jr                      t0
+
+OP:
+ ld_i32 tmp1,env,$0xfffffffffffffff0
+ brcond_i32 tmp1,$0x0,lt,$L0
+
+ ---- 0000100c 00000000
+ add_i32 tmp1,x5/t0,$0x20
+ qemu_ld_i32 x11/a1,tmp1,leul,3
+
+ ---- 00001010 00000000
+ add_i32 tmp1,x5/t0,$0x18
+ qemu_ld_i32 x5/t0,tmp1,leul,3
+
+ ---- 00001014 00000000
+ mov_i32 pc,x5/t0
+ and_i32 pc,pc,$0xfffffffe
+ and_i32 tmp1,pc,$0x2
+ brcond_i32 tmp1,$0x0,ne,$L1
+ call lookup_tb_ptr,$0x6,$1,tmp6,env
+ goto_ptr tmp6
+ set_label $L1
+ st_i32 pc,env,$0x1228
+ mov_i32 pc,$0x1014
+ call raise_exception,$0x8,$0,env,$0x0
+ set_label $L0
+ exit_tb $0x7f5824000183
+
+OP after optimization and liveness analysis:
+ ld_i32 tmp1,env,$0xfffffffffffffff0      pref=0xffff
+ brcond_i32 tmp1,$0x0,lt,$L0              dead: 0
+
+ ---- 0000100c 00000000                
+ add_i32 tmp1,x5/t0,$0x20                 dead: 2  pref=0xff3f
+ qemu_ld_i32 x11/a1,tmp1,leul,3           sync: 0  dead: 0 1  pref=0xffff
+
+ ---- 00001010 00000000                
+ add_i32 tmp1,x5/t0,$0x18                 dead: 1 2  pref=0xff3f
+ qemu_ld_i32 x5/t0,tmp1,leul,3            sync: 0  dead: 1  pref=0xffff
+
+ ---- 00001014 00000000                
+ mov_i32 pc,x5/t0                         dead: 1  pref=0xffff
+ and_i32 pc,pc,$0xfffffffe                sync: 0  dead: 1 2  pref=0xffff
+ and_i32 tmp1,pc,$0x2                     dead: 1 2  pref=0xffff
+ brcond_i32 tmp1,$0x0,ne,$L1              dead: 0 1
+ call lookup_tb_ptr,$0x6,$1,tmp6,env      dead: 1  pref=none
+ goto_ptr tmp6                            dead: 0
+ set_label $L1                          
+ st_i32 pc,env,$0x1228                    dead: 0
+ mov_i32 pc,$0x1014                       sync: 0  dead: 0 1  pref=0xffff
+ call raise_exception,$0x8,$0,env,$0x0    dead: 0 1
+ set_label $L0                          
+ exit_tb $0x7f5824000183                
+
+----------------
+IN: 
+Priv: 3; Virt: 0
+0x80000000:  00629263          bne                     t0,t1,4                 # 0x80000004
+
+OP:
+ ld_i32 tmp1,env,$0xfffffffffffffff0
+ brcond_i32 tmp1,$0x0,lt,$L0
+
+ ---- 80000000 00000000
+ mov_i32 tmp1,x5/t0
+ mov_i32 tmp2,x6/t1
+ brcond_i32 tmp1,tmp2,ne,$L1
+ mov_i32 pc,$0x80000004
+ call lookup_tb_ptr,$0x6,$1,tmp4,env
+ goto_ptr tmp4
+ set_label $L1
+ mov_i32 pc,$0x80000004
+ call lookup_tb_ptr,$0x6,$1,tmp4,env
+ goto_ptr tmp4
+ set_label $L0
+ exit_tb $0x7f5824000383
+
+OP after optimization and liveness analysis:
+ ld_i32 tmp1,env,$0xfffffffffffffff0      pref=0xffff
+ brcond_i32 tmp1,$0x0,lt,$L0              dead: 0 1
+
+ ---- 80000000 00000000                
+ brcond_i32 x5/t0,x6/t1,ne,$L1            dead: 0 1
+ mov_i32 pc,$0x80000004                   sync: 0  dead: 0 1  pref=0xffff
+ call lookup_tb_ptr,$0x6,$1,tmp4,env      dead: 1  pref=none
+ goto_ptr tmp4                            dead: 0
+ set_label $L1                          
+ mov_i32 pc,$0x80000004                   sync: 0  dead: 0 1  pref=0xffff
+ call lookup_tb_ptr,$0x6,$1,tmp4,env      dead: 1  pref=none
+ goto_ptr tmp4                            dead: 0
+ set_label $L0                          
+ exit_tb $0x7f5824000383                
+
+----------------
+IN: 
+Priv: 3; Virt: 0
+
+qemu-system-riscv32: ../../upstream-qemu/accel/tcg/translate-all.c:762: int setjmp_gen_code(CPUArchState *, TranslationBlock *, target_ulong, void *, int *, int64_t *): Assertion `tb->size != 0' failed.
+```
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1441 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1441
new file mode 100644
index 00000000..d6a5659b
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1441
@@ -0,0 +1,34 @@
+Assertion failure when executing RISC-V vfncvt.rtz.x.f.w instruction
+Description of problem:
+When emulating the `vfncvt.rtz.x.f.w` instruction, QEMU crashes with an assertion failure at `target/riscv/translate.c:211`, complaining that ```decode_save_opc: Assertion `ctx->insn_start != NULL' failed.```
+
+It appears this problem first emerged with https://gitlab.com/qemu-project/qemu/-/commit/a9814e3e08d2aacbd9018c36c77c2fb652537848
+Steps to reproduce:
+The following C program triggers the assertion failure when built a sufficiently recent version of the Clang cross compiler (in my case 15.0.6):
+```
+/* test.c */
+#include <riscv_vector.h>
+
+#define LEN 4
+
+int main(int argc, char *argv[]) {
+  double in[LEN];
+  int out[LEN];
+
+  vfloat64m1_t vf = vle64_v_f64m1(in, LEN);
+  vint32mf2_t vi = vfncvt_rtz_x_f_w_i32mf2(vf, LEN);
+  vse32_v_i32mf2(out, vi, LEN);
+
+  return 0;
+}
+```
+
+The above `test.c` can be compiled and run as follows:
+```
+clang -O3 -march=rv64gcv -static test.c
+qemu-riscv64 -cpu "rv64,zba=true,zbb=true,zbc=true,zbs=true,v=true,vlen=512,elen=64,vext_spec=v1.0" a.out
+qemu-riscv64: ../target/riscv/translate.c:211: decode_save_opc: Assertion `ctx->insn_start != NULL' failed.
+Segmentation fault (core dumped)
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1555 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1555
new file mode 100644
index 00000000..e1de3262
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1555
@@ -0,0 +1,32 @@
+virt platform mrom
+Description of problem:
+qemu-system-riscv32 to emulated the lowrisc ibex simple system hello, when debug with riscv32-unknown-elf-gdb, there kept logging "Invalid read at addr 0x0, size 2, region '(null)', reason: rejected".  
+I saw qemu virt platform codes related to this error, it load reset_vec to 0x1000 called VIRT_MROM. I still not understand why this error happens.
+Steps to reproduce:
+1.git clone https://github.com/lowRISC/ibex.git  
+2.cd ibex  
+3.make -C examples/sw/simple_system/hello_test  
+4.using the qemu command line above  
+5.`riscv32-unknown-elf-gdb -ex target remote localhost:1234 examples/sw/simple_system/hello_test` in another terminal, type bt, the error happens.
+Additional information:
+```gdb
+(gdb) x/16i $pc 
+=> 0x1000:	auipc	t0,0x0
+   0x1004:	addi	a2,t0,40
+   0x1008:	csrr	a0,mhartid
+   0x100c:	lw	a1,32(t0)
+   0x1010:	lw	t0,24(t0)
+   0x1014:	jr	t0
+   0x1018:	unimp
+   0x101a:	.2byte	0x8000
+   0x101c:	unimp
+   0x101e:	unimp
+   0x1020:	unimp
+   0x1022:	.2byte	0x7fe0
+   0x1024:	unimp
+   0x1026:	unimp
+   0x1028:	.4byte	0x4942534f
+   0x102c:	c.slli64	zero
+(gdb) bt
+#0  0x00001000 in ?? ()
+```
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1587 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1587
new file mode 100644
index 00000000..c81d9c44
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1587
@@ -0,0 +1,25 @@
+Invalid memory access allowed (possibly due to TLB bypassing PMP after mret)
+Description of problem:
+A load instruction that should be blocked by PMP due to MPRV changing the effective privilege mode to U is allowed.  The sequence that I observed was:
+
+
+1. Be in machine mode.
+2. Set MPP to U (0).
+3. Set MPRV to 1.
+4. Enter an ISR, setting MPP to M (3).
+5. Load from address xxxx (populating the QEMU TLB).
+6. Execute mret, setting MPP back to U (0).
+7. Load from address xxxx, which should fail but succeeds without any TLB fill.
+Steps to reproduce:
+```
+git clone https://github.com/dreiss/qemu_pmp_repro
+cd qemu_pmp_repro
+./build_and_run.sh
+```
+The `build_and_run.sh` script expects `riscv-none-elf-gcc` and `qemu-system-riscv64` on PATH.  It will also attempt to run the reproducer with `spike`, the reference RISC-V emulator, which succeeds.
+Additional information:
+Adding a call to `tlb_flush` to `helper_mret` causes this test to pass in QEMU, but I don't know if that's a valid fix.
+
+Output from `build_and_run.sh`:
+
+[output.txt](/uploads/108547bcb160a8f0bfffe72ea77b215f/output.txt)
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1724 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1724
new file mode 100644
index 00000000..86201d90
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1724
@@ -0,0 +1,45 @@
+qemu-system-riscv64 can't break by gdb
+Description of problem:
+The qemu-system-riscv64 can't break by gdb.  
+( => The target is not responding to interrupt requests.  
+Stop debugging it? (y or n) Quit)  
+
+I using old qemu-system-risc64(7.2) don't has this issue.  
+
+This test case running simple OS(riscv-xv6).
+Steps to reproduce:
+1.qemu-system-riscv64 -machine virt -bios none -kernel kernel/kernel -m 128M -smp 3 -nographic -global   virtio-mmio.force-legacy=false -drive file=fs.img,if=none,format=raw,id=x0 -device virtio-blk-  device,drive=x0,bus=virtio-mmio-bus.0 -S -gdb tcp::26000  
+  
+  
+2.test@test-VirtualBox:~$ riscv64-unknown-linux-gnu-gdb -q                                                                                                                                                 
+(gdb) target remote :26000  
+Remote debugging using :26000  
+warning: No executable has been specified and target does not support  
+determining executable automatically.  Try using the "file" command.  
+0x0000000000001000 in ?? ()  
+(gdb) c  
+Continuing.  
+
+3.check xv6 is running.  
+xv6 kernel is booting  
+
+hart 2 starting  
+hart 1 starting  
+init: starting sh  
+$  
+
+4.Can't stop by GDB.  
+(gdb) c  
+Continuing.  
+^C^CThe target is not responding to interrupt requests.  
+Stop debugging it? (y or n) Quit  
+(gdb)
+Additional information:
+Test on new QEMU.  
+
+```
+commit cab35c73be9d579db105ef73fa8a60728a890098 (HEAD -> master, origin/staging, origin/master, origin/HEAD)
+Merge: 48ab886d3d d7ee93e243
+Author: Richard Henderson <richard.henderson@linaro.org>
+Date:   Tue Jun 20 10:26:53 2023 +0200
+```
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1823 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1823
new file mode 100644
index 00000000..35e83ead
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1823
@@ -0,0 +1,11 @@
+qemu-system-riscv64 Property 'virt-machine.aclint' not found
+Description of problem:
+
+Steps to reproduce:
+1.  run ./qemu-system-riscv64 -M virt,aclint=on
+2. command output: 
+```
+qemu-system-riscv64: Property 'virt-machine.aclint' not found
+```
+Additional information:
+The aclint property is registered in the virt_machine_class_init function and depends on the condition tcg_enabled(), but the initialization of tcg_enabled() is later than the call of virt_machine_class_init. This caused the aclint property to never be registered.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1961 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1961
new file mode 100644
index 00000000..879649c2
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1961
@@ -0,0 +1 @@
+Commit accel/tcg: Always require can_do_io breaks riscv64 bare metal firmware
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1976 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1976
new file mode 100644
index 00000000..47c4114e
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/1976
@@ -0,0 +1,49 @@
+SIGILL (ILL_OPC) on RISC-V Vector Operations, Bad MSTATUS_VS register
+Description of problem:
+When building AOSP Android and launching the public Cuttlefish RISC-V image, various binaries on the system will crash on boot with SIGILL, ILL_OPC. The crashes are random - binaries will crash largely at boot and then only crash infrequently after that. It is not always the case that the same binary will crash first, but if a binary crashes, it will always crash at the same location, usually the first vector instruction. At the time of writing, this is often the 'vsetvli' or 'vfirst.m' instruction.
+
+After building QEMU at head and intentionally triggering a SIGABRT prior to the ILL_OPC exception, I caught the following backtrace in gdb:
+
+```
+(gdb) bt
+#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
+#1  0x00007f8e570bb15f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
+#2  0x00007f8e5706d472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
+#3  0x00007f8e570574b2 in __GI_abort () at ./stdlib/abort.c:79
+#4  0x0000565536e817d7 in vs (env=<optimized out>, csrno=<optimized out>) at ../target/riscv/csr.c:101
+#5  vs (env=<optimized out>, csrno=<optimized out>) at ../target/riscv/csr.c:95
+#6  0x0000565536e83d5b in riscv_csrrw_check (write_mask=false, csrno=3106, env=0x7f8e4e2b0ed0) at ../target/riscv/csr.c:4286
+#7  riscv_csrrw (env=env@entry=0x7f8e4e2b0ed0, csrno=3106, ret_value=ret_value@entry=0x7f8bdedfbee0, new_value=new_value@entry=0, write_mask=write_mask@entry=0)
+    at ../target/riscv/csr.c:4366
+#8  0x0000565536e86b52 in helper_csrr (env=0x7f8e4e2b0ed0, csr=<optimized out>) at ../target/riscv/op_helper.c:54
+#9  0x00007f8de9f1af73 in code_gen_buffer ()
+#10 0x0000565536fa39cb in cpu_tb_exec (cpu=cpu@entry=0x7f8e4e2ae710, itb=itb@entry=0x7f8de9f1ab40 <code_gen_buffer+99724051>, tb_exit=tb_exit@entry=0x7f8bdedfc444)
+    at ../accel/tcg/cpu-exec.c:458
+#11 0x0000565536fa3ea1 in cpu_loop_exec_tb
+    (tb_exit=0x7f8bdedfc444, last_tb=<synthetic pointer>, pc=<optimized out>, tb=0x7f8de9f1ab40 <code_gen_buffer+99724051>, cpu=<optimized out>)
+    at ../accel/tcg/cpu-exec.c:920
+#12 cpu_exec_loop (cpu=cpu@entry=0x7f8e4e2ae710, sc=sc@entry=0x7f8bdedfc4f0) at ../accel/tcg/cpu-exec.c:1041
+#13 0x0000565536fa469d in cpu_exec_setjmp (cpu=cpu@entry=0x7f8e4e2ae710, sc=sc@entry=0x7f8bdedfc4f0) at ../accel/tcg/cpu-exec.c:1058
+#14 0x0000565536fa4c6b in cpu_exec (cpu=cpu@entry=0x7f8e4e2ae710) at ../accel/tcg/cpu-exec.c:1084
+#15 0x0000565536fbfedf in tcg_cpus_exec (cpu=cpu@entry=0x7f8e4e2ae710) at ../accel/tcg/tcg-accel-ops.c:76
+#16 0x0000565536fc0023 in mttcg_cpu_thread_fn (arg=arg@entry=0x7f8e4e2ae710) at ../accel/tcg/tcg-accel-ops-mttcg.c:95
+#17 0x0000565537144288 in qemu_thread_start (args=0x565538c01840) at ../util/qemu-thread-posix.c:541
+#18 0x00007f8e570b93ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
+#19 0x00007f8e57139a4c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+```
+
+Debugging in this path, it appears that the reason we're experiencing a SIGILL here is that when building a qemu-system-riscv64 binary (and thus !CONFIG_USER_ONLY), we check to see if 'riscv_cpu_vector_enabled(env)', which checks if `env->mstatus & MSTATUS_VS`.
+
+Interestingly, logging in this path confirms that the CPU environment of this thread does think the RVV extension is enabled (verified with `riscv_has_ext(env, RVV)`. My rough guess as to what's happening:
+
+1. We're not setting the MSTATUS_VS flag on initialization of the CPU, nor are we setting the mstatus_vs state to INITIALIZED. Without this, when a new thread is spawned for a vCPU, it's incorrectly determining that it can't handle vector instructions.
+2. It's working sometimes because in some of the 'write_*' calls in `riscv/csr.c`, we flip the MSTATUS_VS flag on, so if one of those calls occurs first, all subsequent vector operations work too. (To be honest, I'm not quite following why we make the decision to set MSTATUS in these calls, shouldn't this be configured at CPU initialization?)
+Steps to reproduce:
+Please forgive the poor reproduction case, I'm still trying to wrap my head around what's going on, so haven't been able to harden a smaller example yet that would reproduce. In theory, tip-of-tree QEMU + a stock Linux system with a program that triggers a call to QEMU's vlenb instruction ahead of all other vector instructions would be the ideal case, but I'm still figuring out how to go about doing that.
+
+My current reproduction case is as follows:
+
+1. Introduce a small hack in `target/riscv/csr.c`'s `vs` function - add an `abort` call here: https://github.com/qemu/qemu/blob/master/target/riscv/csr.c#L99
+2. Build tip-of-tree QEMU for qemu-system-riscv64.
+3. Use https://github.com/google/android-riscv64#can-i-try-it to build the Android RISC-V emulator. When launching the emulator, use the '-qemu_binary_dir' option to point to the directory containing the QEMU built in the previous step.
+4. In a few moments, the emulator will attempt to start but abort fairly quickly (I've got a 128-core machine, and it fails consistently in about 5 seconds).
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/2166 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/2166
new file mode 100644
index 00000000..28cc9b5c
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/2166
@@ -0,0 +1 @@
+RISC-V qemu has bug on the return value of function qemu_plugin_mem_size_shift()
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/2259 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/2259
new file mode 100644
index 00000000..fbc5dc5c
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/2259
@@ -0,0 +1,14 @@
+The cause code of a trap changes when qemu is nested in another qemu
+Description of problem:
+I am studying the feasibility of doing some practical work on RISCV plates. Since I don't have these boards yet, I'm emulating it with qemu. The practice in turn consists of launching with qemu a very small operating system with two tasks that make a series of system calls.
+
+When I run this practice on my host it works correctly, but when I run it on an Ubuntu emulated in riscv with qemu, the cause code for the trap changes (the first bit of the code).
+
+The demo can be found in this repository: https://github.com/Sft570/qemu-bug-report
+Steps to reproduce:
+1. Clone the repository on the host and run the demo with "make qemu"
+2. Emulate with qemu ubuntu in riscv, clone the repository and run the demo with "make qemu".
+
+The error displayed shows the change of the cause code bit. You can analyze its behavior in the trap.c file in the src folder.
+Additional information:
+
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/2371 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/2371
new file mode 100644
index 00000000..fc11ba17
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/2371
@@ -0,0 +1,52 @@
+A bug in RISC-V froundnx.h instruction
+Description of problem:
+According to the RISCV ISA manual, the froundnx.h instruction rounds a half-precision floating-point number in the source register to an integer and writes the integer, represented as a half-precision floating-point number, to the destination register. Because the values are stored in 64-bit width registers, they must be NaN-unboxed/boxed before/after the operation. When an input value lacks the proper form of NaN-boxing, it should be treated as a canonical NaN.
+However, when an incorrectly NaN-boxed value is passed to froundnx.h, QEMU produces 0 instead of the canonical NaN. This is because there is a typo in the definition of helper_froundnx_h:
+```
+// target/riscv/fpu_helper.c
+uint64_t helper_froundnx_h(CPURISCVState *env, uint64_t rs1)
+{
+    float16 frs1 = check_nanbox_s(env, rs1); // This should be check_nanbox_h.
+    frs1 = float16_round_to_int(frs1, &env->fp_status);
+    return nanbox_h(env, frs1);
+}
+```
+Steps to reproduce:
+1. Write `test.c`.
+```
+#include <stdio.h>
+
+char i_F6[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 };
+char o_F5[8];
+
+void __attribute__ ((noinline)) show_state() {
+    for (int i = 0; i < 8; i++) {
+        printf("%02x ", o_F5[i]);
+    }
+    printf("\n");
+}
+
+void __attribute__ ((noinline)) run() {
+    __asm__ (
+        "lui t5, %hi(i_F6)\n"
+        "addi t5, t5, %lo(i_F6)\n"
+        "fld ft6, 0(t5)\n"
+        ".insn 0x445372d3\n" // froundnx.h ft5, ft6
+        "lui t5, %hi(o_F5)\n"
+        "addi t5, t5, %lo(o_F5)\n"
+        "fsd ft5, 0(t5)\n"
+    );
+}
+
+int main(int argc, char **argv) {
+    run();
+    show_state();
+
+    return 0;
+}
+```
+2. Compile `test.bin` using this command: `riscv64-linux-gnu-gcc-12 -O2 -no-pie -march=rv64iv ./test.c -o ./test.bin`.
+3. Run QEMU using this command: `qemu-riscv64 -L /usr/riscv64-linux-gnu/ ./test.bin`.
+4. The program, runs on top of the buggy QEMU, prints `00 00 ff ff ff ff ff ff`. It should print `00 7e ff ff ff ff ff ff` after the bug is fixed.
+Additional information:
+
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/2820 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/2820
new file mode 100644
index 00000000..24c0401a
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/2820
@@ -0,0 +1,27 @@
+STOPI CSR Incorrect Value for Virtual Supervisor External Interrupt in QEMU (AIA Extension)
+Description of problem:
+We are developing a RISC-V core and have implemented tests for the AIA extension. One of these tests reveals a bug when running in QEMU in a bare-metal environment. The issue relates to the value of the STOPI CSR. Although the CSR behaves correctly in most cases, when a virtual supervisor external interrupt is generated using the IMSIC (i.e., both hip.vseip and hie.vseip are set to 1) while executing in supervisor mode with hideleg.vseip set to 0, the STOPI CSR always returns the value 0. However, according to the specifications, it should return 10, which is the major identity number for the virtual supervisor external interrupt.
+
+According to the RISC-V specs:
+
+> The value of stopi is zero unless: (a) there is an interrupt that is both pending in sip and enabled in
+sie, or, if the hypervisor extension is implemented, both pending in hip and enabled in hie; and (b)
+the interrupt is not delegated to a lower privilege level (by hideleg, if the hypervisor extension is
+implemented). When there is a pending-and-enabled major interrupt for supervisor level, field IID is
+the major identity number of the highest-priority interrupt, and field IPRIO indicates its priority.
+
+Upon reviewing the QEMU AIA code, I found the following snippet in `qemu/target/riscv/cpu_helper.c` that might be causing the problem:
+```
+int riscv_cpu_sirq_pending(CPURISCVState *env)
+{
+    uint64_t irqs = riscv_cpu_all_pending(env) & env->mideleg &
+                    ~(MIP_VSSIP | MIP_VSTIP | MIP_VSEIP);
+    uint64_t irqs_f = env->mvip & env->mvien & ~env->mideleg & env->sie;
+
+    return riscv_cpu_pending_to_irq(env, IRQ_S_EXT, IPRIO_DEFAULT_S,
+                                    irqs | irqs_f, env->siprio);
+}
+```
+It appears that virtual supervisor (VS) interrupts are being masked (via the `~(MIP_VSSIP | MIP_VSTIP | MIP_VSEIP)` operation) when they likely should not be, which could explain why the STOPI CSR does not reflect the correct value.
+
+Thank you for your time, and please let me know if any details require further clarification or if my interpretation is incorrect.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/285 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/285
new file mode 100644
index 00000000..bebf2ec1
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/285
@@ -0,0 +1 @@
+qemu-user child process hangs when forking due to glib allocation
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/2855 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/2855
new file mode 100644
index 00000000..347a8af9
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/2855
@@ -0,0 +1,29 @@
+masking mode field in mepc before mret
+Description of problem:
+I thought I found a bug in OpenSBI (https://github.com/riscv-software-src/opensbi/issues/391) but it actually is a QEMU bug.
+It is described here: https://lists.infradead.org/pipermail/opensbi/2025-March/008166.html
+Steps to reproduce:
+1. use an application with vectored mode enabled (The RISC-V Instruction Set Manual: Volume II: Privileged Architecture / chapter 10.1.2) in QEMU 
+2. trigger an illegal instruction interrupt (handle it in machine mode - not by medeleg)
+3. in a machine mode trap: Store STVEC in MEPC.
+4. do a mret 
+5. the first bits of mepc are not masked so the address in mepc (comming from (v)stvec) will be false after mret
+Additional information:
+My guess is that the instructions from the following quote (masking of lower bits in mepc) from the official spec must be implemented here:
+https://gitlab.com/qemu-project/qemu/-/blob/master/target/riscv/op_helper.c?ref_type=heads#L387
+Maybe also somewhere else. 
+
+> 3.1.14. Machine Exception Program Counter (mepc)
+> 
+> mepc is an MXLEN-bit read/write register formatted as shown in Figure 21. The low bit of mepc
+> (mepc[0]) is always zero. On implementations that support only IALIGN=32, the two low bits
+> (mepc[1:0]) are always zero.
+> 
+> If an implementation allows IALIGN to be either 16 or 32 (by changing CSR misa, for example), then,
+> whenever IALIGN=32, bit mepc[1] is masked on reads so that it appears to be 0. This masking occurs
+> also for the implicit read by the MRET instruction. Though masked, mepc[1] remains writable when
+> IALIGN=32.
+> 
+> mepc is a WARL register that must be able to hold all valid virtual addresses. It need not be capable of
+> holding all possible invalid addresses. Prior to writing mepc, implementations may convert an invalid
+> address into some other invalid address that mepc is capable of holding.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_TCG/594 b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/594
new file mode 100644
index 00000000..247e38ed
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_TCG/594
@@ -0,0 +1 @@
+faults due to a amo instruction result in load faults instead of store/amo faults
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1030 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1030
new file mode 100644
index 00000000..8dadb425
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1030
@@ -0,0 +1 @@
+Property 'rv32-riscv-cpu.x-v' not found
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1050 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1050
new file mode 100644
index 00000000..18be1c63
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1050
@@ -0,0 +1,72 @@
+[BUG] heap-buffer-overflow in sifive_plic_create
+Description of problem:
+I run check-qtest-riscv64 in ubuntu20.04, and got a heap-buffer-overflow report with address sanitizer   
+HEAD: 7077fcb9b68f058809c9dd9fd1dacae1881e886c
+Steps to reproduce:
+run 
+`G_TEST_DBUS_DAEMON=/root/o/sources/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=58 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_BINARY=./qemu-system-riscv64 /root/o/sources/qemu/build/tests/qtest/test-hmp --tap -k`
+Additional information:
+I think is because on some conditions when after `j++(hw/intc/sifive_plic.c:458)`, it accesses `plic->addr_config[j](hw/intc/sifive_plic.c:463)`  and results in heap-overflow.  
+I tried to modify `hw/intc/sifive_plic.c:463` to else-if, then the report gone.  
+Could you please have a check.  
+```
+==63425==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000031624 at pc 0x561afe157d54 bp 0x7ffcd8aef510 sp 0x7ffcd8aef500
+READ of size 4 at 0x602000031624 thread T0
+    #0 0x561afe157d53 in sifive_plic_create ../hw/intc/sifive_plic.c:463
+    #1 0x561afdc0ac7f in sifive_e_soc_realize ../hw/riscv/sifive_e.c:207
+    #2 0x561afe6698fb in device_set_realized ../hw/core/qdev.c:531
+    #3 0x561afe679b90 in property_set_bool ../qom/object.c:2273
+    #4 0x561afe681c7f in object_property_set ../qom/object.c:1408
+    #5 0x561afe68b763 in object_property_set_qobject ../qom/qom-qobject.c:28
+    #6 0x561afe682535 in object_property_set_bool ../qom/object.c:1477
+    #7 0x561afdc0a601 in sifive_e_machine_init ../hw/riscv/sifive_e.c:91
+    #8 0x561afd34d608 in machine_run_board_init ../hw/core/machine.c:1427
+    #9 0x561afda49697 in qemu_init_board ../softmmu/vl.c:2610
+    #10 0x561afda49697 in qmp_x_exit_preconfig ../softmmu/vl.c:2706
+    #11 0x561afda49697 in qmp_x_exit_preconfig ../softmmu/vl.c:2699
+    #12 0x561afda504ee in qemu_init ../softmmu/vl.c:3737
+    #13 0x561afd1cf4ae in qemu_main ../softmmu/main.c:35
+    #14 0x561afd1cf4ae in main ../softmmu/main.c:45
+    #15 0x7f9d13bf3082 in __libc_start_main ../csu/libc-start.c:308
+    #16 0x561afd1de78d in _start (/root/o/sources/qemu/build/qemu-system-riscv64+0x271378d)
+
+0x602000031624 is located 8 bytes to the right of 12-byte region [0x602000031610,0x60200003161c)
+allocated by thread T0 here:
+    #0 0x7f9d15026808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
+    #1 0x7f9d14a84e98 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e98)
+
+SUMMARY: AddressSanitizer: heap-buffer-overflow ../hw/intc/sifive_plic.c:463 in sifive_plic_create
+Shadow bytes around the buggy address:
+  0x0c047fffe270: fa fa 05 fa fa fa 07 fa fa fa 00 01 fa fa 07 fa
+  0x0c047fffe280: fa fa 05 fa fa fa 07 fa fa fa fd fa fa fa 02 fa
+  0x0c047fffe290: fa fa 00 01 fa fa fd fd fa fa fd fa fa fa fd fd
+  0x0c047fffe2a0: fa fa 00 02 fa fa 00 02 fa fa 05 fa fa fa 07 fa
+  0x0c047fffe2b0: fa fa 00 01 fa fa 07 fa fa fa 05 fa fa fa 07 fa
+=>0x0c047fffe2c0: fa fa 00 04[fa]fa 04 fa fa fa 00 00 fa fa 00 00
+  0x0c047fffe2d0: fa fa 00 00 fa fa fd fd fa fa 00 03 fa fa fd fd
+  0x0c047fffe2e0: fa fa 00 03 fa fa fd fd fa fa 00 03 fa fa fd fd
+  0x0c047fffe2f0: fa fa 00 03 fa fa fd fd fa fa 00 03 fa fa fd fd
+  0x0c047fffe300: fa fa 00 03 fa fa fd fd fa fa 00 03 fa fa fd fa
+  0x0c047fffe310: fa fa fd fd fa fa 00 03 fa fa fd fd fa fa 00 03
+Shadow byte legend (one shadow byte represents 8 application bytes):
+  Addressable:           00
+  Partially addressable: 01 02 03 04 05 06 07 
+  Heap left redzone:       fa
+  Freed heap region:       fd
+  Stack left redzone:      f1
+  Stack mid redzone:       f2
+  Stack right redzone:     f3
+  Stack after return:      f5
+  Stack use after scope:   f8
+  Global redzone:          f9
+  Global init order:       f6
+  Poisoned by user:        f7
+  Container overflow:      fc
+  Array cookie:            ac
+  Intra object redzone:    bb
+  ASan internal:           fe
+  Left alloca redzone:     ca
+  Right alloca redzone:    cb
+  Shadow gap:              cc
+==63425==ABORTING
+```
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1093 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1093
new file mode 100644
index 00000000..e7f74b5e
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1093
@@ -0,0 +1,33 @@
+RISC-V: signal frame is misaligned in signal handlers
+Description of problem:
+`qemu-user` misaligns the signal frame (to 4 bytes rather than 16 bytes) on RISC-V 64, e.g causing pointer misalignment diagnostics to be triggered by UBSan.
+Steps to reproduce:
+1. Create a C file with the following contents:
+```c
+#include <signal.h>
+#include <stdio.h>
+
+void handler(int sig, siginfo_t *info, void *context) {
+	printf("signal occurred, info: %p, context: %p\n", info, context);
+}
+
+int main() {
+	struct sigaction act;
+	act.sa_flags = SA_SIGINFO;
+	act.sa_sigaction = handler;
+	sigaction(SIGINT, &act, NULL);
+
+	// Deliberately misalign the stack
+	asm volatile ("addi sp, sp, -4");
+
+	while(1);
+	// Unreachable
+}
+```
+2. Compile with an appropriate RISC-V toolchain and run with `qemu-riscv64 ./a.out`.
+3. Send a `SIGINT` (e.g by hitting Ctrl-C), and observe that the signal frame will be misaligned:
+```
+signal occurred, info: 0x400080025c, context: 0x40008002dc
+```
+Additional information:
+This issue is alluded to in the source code, see https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/riscv/signal.c#L68-69. It should be sufficient to change that constant to 15.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1160 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1160
new file mode 100644
index 00000000..2e9af71a
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1160
@@ -0,0 +1 @@
+hw/riscv reset vector improvement
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1173 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1173
new file mode 100644
index 00000000..6a531c40
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1173
@@ -0,0 +1 @@
+is that `fsgnjn.s` will affect other bits except sign bit.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1178 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1178
new file mode 100644
index 00000000..e12d355f
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1178
@@ -0,0 +1 @@
+is that  riscv64 `feq.s` only should consider the lowest  32-bits.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1241 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1241
new file mode 100644
index 00000000..3cf1c768
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1241
@@ -0,0 +1,13 @@
+About showing the information of the csr
+Description of problem:
+cannot print the inforamtion after pulling the newest version of qemu
+E.g　info r csr 
+only fcsr frm fflags are shown. However , it should print out all the csrs such as mideleg mhartid etc in preivous version
+info r mip 
+(GDB) Invalid register `mip'
+Steps to reproduce:
+1.running riscv64-unknown-elf-gdb kernel 
+2.target remote to the port i set in the xv6 makefile
+3.type info r mip it shows the the probklem i mentioned above. I could use the print CSR in previous version of QEMU.
+Additional information:
+
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1259 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1259
new file mode 100644
index 00000000..36c877fb
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1259
@@ -0,0 +1 @@
+RISC-V csr
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1260 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1260
new file mode 100644
index 00000000..40446a04
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1260
@@ -0,0 +1 @@
+RISC-V sstatus register is missing in qemu console / gdb
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1281 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1281
new file mode 100644
index 00000000..f4975654
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1281
@@ -0,0 +1 @@
+xv6 kernel problem in single step mode
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1320 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1320
new file mode 100644
index 00000000..7f14ba0d
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1320
@@ -0,0 +1,12 @@
+qemu-system-riscv64: Unable to load the RISC-V firmware "opensbi-riscv64-virt-fw_jump.bin"
+Description of problem:
+qemu-system-riscv64: Unable to load the RISC-V firmware "opensbi-riscv64-virt-fw_jump.bin"
+Steps to reproduce:
+1. wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.15.79.tar.xz
+2. sudo apt-get install crossbuild-essential-riscv64
+3. make ARCH=riscv defconfig && make ARCH=riscv menuconfig 
+4. make -j4 ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- 
+5. trucate -s 128G rootfs.img && mkfs.ext4 rootfs.img
+6. sudo mount -o loop ./rootfs.img /mnt
+7. debootstrap --arch=riscv64 focal /mnt
+8. qemu-system-riscv64 -machine virt -bios default -m 512M -kernel ./linux-5.15.79/arch/riscv/boot/Image -drive file=./rootfs.img,format=raw
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1331 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1331
new file mode 100644
index 00000000..a35071f2
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1331
@@ -0,0 +1 @@
+risc-v sstatus bug
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1332 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1332
new file mode 100644
index 00000000..854c1c76
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1332
@@ -0,0 +1 @@
+qemu.log missing sstatus register on RISC-V
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1343 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1343
new file mode 100644
index 00000000..5f44ad64
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1343
@@ -0,0 +1,36 @@
+qemu-system-riscv64: It cannot initialize ramfb video adapter
+Description of problem:
+It looks like ramfb video adapter doesn't work in riscv64 architecture. But it works fine in aarch64 architecture.
+Steps to reproduce:
+1. Launch the [attached kernel](/uploads/43282fa1bd6959472af4f99646b447b9/kernel) with command:
+```
+qemu-system-riscv64 -machine virt -kernel kernel -device ramfb -bios none -serial stdio
+```
+2. You will get the messages in console:
+```
+guest fw_cfg dma-interface enabled 
+setup ramfb successfull
+```
+3. Video adapter will not initialize. QEMU window will continue display this message:
+```
+Guest has not initialized the display (yet).
+```
+Additional information:
+There is a useful project for aarch64 architecture - https://github.com/luickk/qemu-ramfb-aarch64-driver. This is a Bare metal driver for ramfb adapter. It works fine. I adapted it for riscv64 architecture - https://github.com/CityAceE/qemu-ramfb-riscv64-driver. I've successfully went through all problems. Driver compiles now and launches. But unfortunately ramfb doesn't initialize. I parallel traced aarch64 and riscv64. They works equal until initialization. Aarch64 changes revolution just after qemu_cfg_write_entry call, but nothing happened after qemu_cfg_write_entry call in riscv64 emulation. I spent a lot of time trying to resolve this problem, but it looks like a problem in qemu-system-riscv64.
+
+**UPDATE**
+
+Tested with Windows builds of QEMU:
+
+v 6.1 - The same situation as Ubuntu build 6.2.
+
+v 7.1.92 - Stopped with message:
+```
+c:\Program Files\qemu\qemu-system-riscv64.exe: -device ramfb: ramfb device requires fw_cfg with DMA
+```
+
+P.S. v 7.1.92 - qemu-system-aarch64.exe with [aarch64 kernel build](/uploads/0df1d440163913c25a1505032672e1c5/kernel) works fine.
+
+**UPDATE2**
+
+[QEMU emulator version 7.0.0 (v7.0.0-11902-g1d935f4a02-dirty)](https://qemu.weilnetz.de/w64/2022/qemu-w64-setup-20220419.exe) is the last Windows build which opens my riscv64 kernel without message about requirement of fw_cfg with DMA. Next build "QEMU emulator version 7.0.90 (v7.1.0-rc0-11915-g5f9b281b8a-dirty)" already has this issue.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1395 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1395
new file mode 100644
index 00000000..8dc3331b
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1395
@@ -0,0 +1,156 @@
+qemu-system-riscv32 cpu_transaction_failed cause Infinite loop when write mstatus ~"target: riscv"
+Description of problem:
+I wanna run FreeRTOS riscv, and use the FreeRTOS/Demo/RISC-V-Qemu-virt_GCC/Makefile to build elf.\
+When qemu execute to write mstatus as 0x1888(enable Interrupt, MIE:1, MIP:1, MPP:3), there is no response.\
+https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/portable/GCC/RISC-V/portASM.S\
+line 274: csrrw   x0, mstatus, x5                 /* Interrupts enabled from here! */\
+opcode is hex 30029073\n
+I use pstack to trace qemu thread, there is only one thread is active, and cpu loading is 100%.\
+then I use gdb attatch <pid> to trace the active thread, and it has a loop\
+cpu_loop_exit call siglongjmp and back to sigsetjmp in cpu_exec (cpu=cpu@entry=0x55e2294e4070) at ../accel/tcg/cpu-exec.c:936
+Steps to reproduce:
+1.download FreeRTOS and build FreeRTOS/Demo/RISC-V-Qemu-virt_GCC\
+2.run qemu with gdb\
+3.hang when writing mstatus
+Additional information:
+I find that my issue occur when mtvec is zero and timer interrupt occur when writing mstatus(riscv_cpu_do_interrupt)\
+Although it should jump to 0x0 rather then hanging in while loop.\
+expected flow :cpu_handle_interrupt->check_for_breakpoints->break\
+actually flow: cpu_handle_interrupt->check_for_breakpoints->infinite loop\
+Qemu build command: 
+```
+./configure --target-list=riscv32-softmmu && make
+```
+
+pstack for qemu (only need to debug Thread 3)
+```
+Thread 3 (Thread 0x7f83af6d3640 (LWP 5093) "qemu-system-ris"):
+#0  0x000055cb31b1769f in riscv_cpu_exec_interrupt ()
+#1  0x0000000000000000 in  ()
+Thread 2 (Thread 0x7f83b0119640 (LWP 5092) "qemu-system-ris"):
+#0  0x00007f83b0400a3d in syscall () at /lib/x86_64-linux-gnu/libc.so.6
+#1  0x000055cb31e0bd52 in qemu_event_wait ()
+#2  0x0000000000000000 in  ()
+Thread 1 (Thread 0x7f83b011ac00 (LWP 5090) "qemu-system-ris"):
+#0  0x00007f83b03fae7e in ppoll () at /lib/x86_64-linux-gnu/libc.so.6
+#1  0x00007f83b0752500 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
+#2  0x000055cb33241b30 in  ()
+#3  0x0000000000000005 in  ()
+#4  0x0000000000000000 in  ()
+```
+backtrace for the infinite loop
+```
+(gdb) bt
+#0  cpu_loop_exit (cpu=0x55e2294e4070) at ../accel/tcg/cpu-exec-common.c:65
+#1  0x000055e2274efde4 in cpu_loop_exit_restore (cpu=cpu@entry=0x55e2294e4070, pc=pc@entry=0)
+    at ../accel/tcg/cpu-exec-common.c:76
+#2  0x000055e22737fff1 in riscv_cpu_do_transaction_failed
+    (cs=0x55e2294e4070, physaddr=<optimized out>, addr=0, size=<optimized out>, access_type=MMU_INST_FETCH, mmu_idx=<optimized out>, attrs=..., response=2, retaddr=0)
+    at ../target/riscv/cpu_helper.c:1165
+#3  0x000055e2274fa4a7 in cpu_transaction_failed
+    (retaddr=0, response=2, attrs=..., mmu_idx=3, access_type=MMU_INST_FETCH, size=<optimized out>, addr=0, physaddr=<optimized out>, cpu=0x55e2294e4070) at ../accel/tcg/cputlb.c:1344
+#4  io_readx
+    (env=env@entry=0x55e2294e53d0, full=full@entry=0x7fd90c029410, mmu_idx=3, addr=addr@entry=0, retaddr=retaddr@entry=0, access_type=access_type@entry=MMU_INST_FETCH, op=MO_16)
+    at ../accel/tcg/cputlb.c:1380
+#5  0x000055e2274fba28 in load_helper
+    (full_load=<optimized out>, code_read=true, op=MO_16, retaddr=0, oi=19, addr=0, env=0x55e2294e53d0) at ../accel/tcg/cputlb.c:1970
+#6  full_lduw_code (env=env@entry=0x55e2294e53d0, addr=addr@entry=0, oi=19, retaddr=0)
+    at ../accel/tcg/cputlb.c:2606
+#7  0x000055e22750827b in cpu_lduw_code (env=env@entry=0x55e2294e53d0, addr=addr@entry=0)
+    at ../accel/tcg/cputlb.c:2612
+#8  0x000055e2274f87fa in translator_lduw
+    (env=env@entry=0x55e2294e53d0, db=db@entry=0x7fd913dfe5a0, pc=0)
+    at ../accel/tcg/translator.c:216
+#9  0x000055e2273e423a in riscv_tr_translate_insn (dcbase=0x7fd913dfe5a0, cpu=<optimized out>)
+    at ../target/riscv/translate.c:1158
+#10 0x000055e2274f83d3 in translator_loop
+    (cpu=cpu@entry=0x55e2294e4070, tb=tb@entry=0x7fd91c000240 <code_gen_buffer+531>, max_insns=<optim
+    ized out>, pc=pc@entry=0, host_pc=host_pc@entry=0x55e2274efe74 <tb_htable_lookup+84>, ops=ops@entry=0x55e227a75c80 <riscv_tr_ops>, db=0x7fd913dfe5a0) at ../accel/tcg/translator.c:96
+#11 0x000055e227411760 in gen_intermediate_code
+    (cs=cs@entry=0x55e2294e4070, tb=tb@entry=0x7fd91c000240 <code_gen_buffer+531>, max_insns=<optimized out>, pc=pc@entry=0, host_pc=host_pc@entry=0x55e2274efe74 <tb_htable_lookup+84>)
+    at ../target/riscv/translate.c:1240
+#12 0x000055e2274f6954 in setjmp_gen_code
+    (env=env@entry=0x55e2294e53d0, tb=tb@entry=0x7fd91c000240 <code_gen_buffer+531>, pc=pc@entry=0, host_pc=0x55e2274efe74 <tb_htable_lookup+84>, max_insns=max_insns@entry=0x7fd913dfe744, ti=<optimized out>) at ../accel/tcg/translate-all.c:761
+#13 0x000055e2274f7294 in tb_gen_code
+    (cpu=cpu@entry=0x55e2294e4070, pc=0, cs_base=0, flags=1085443, cflags=<optimized out>, 
+    cflags@entry=-16777216) at ../accel/tcg/translate-all.c:841
+#14 0x000055e2274f10cf in cpu_exec (cpu=cpu@entry=0x55e2294e4070) at ../accel/tcg/cpu-exec.c:1006
+#15 0x000055e22750a904 in tcg_cpus_exec (cpu=cpu@entry=0x55e2294e4070)
+    at ../accel/tcg/tcg-accel-ops.c:69
+#16 0x000055e22750aa57 in mttcg_cpu_thread_fn (arg=arg@entry=0x55e2294e4070)
+    at ../accel/tcg/tcg-accel-ops-mttcg.c:95
+#17 0x000055e227674b21 in qemu_thread_start (args=<optimized out>)
+    at ../util/qemu-thread-posix.c:505
+#18 0x00007fd9611a9b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
+#19 0x00007fd96123ba00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+```
+
+disassembly code 
+```
+80001ac6 <xPortStartFirstTask>:
+80001ac6:	85c1a103          	lw	sp,-1956(gp) # 800809fc <pxCurrentTCB>
+80001aca:	4102                	lw	sp,0(sp)
+80001acc:	4082                	lw	ra,0(sp)
+80001ace:	43c2                	lw	t2,16(sp)
+80001ad0:	4452                	lw	s0,20(sp)
+80001ad2:	44e2                	lw	s1,24(sp)
+80001ad4:	4572                	lw	a0,28(sp)
+80001ad6:	5582                	lw	a1,32(sp)
+80001ad8:	5612                	lw	a2,36(sp)
+80001ada:	56a2                	lw	a3,40(sp)
+80001adc:	5732                	lw	a4,44(sp)
+80001ade:	57c2                	lw	a5,48(sp)
+80001ae0:	5852                	lw	a6,52(sp)
+80001ae2:	58e2                	lw	a7,56(sp)
+80001ae4:	5972                	lw	s2,60(sp)
+80001ae6:	4986                	lw	s3,64(sp)
+80001ae8:	4a16                	lw	s4,68(sp)
+80001aea:	4aa6                	lw	s5,72(sp)
+80001aec:	4b36                	lw	s6,76(sp)
+80001aee:	4bc6                	lw	s7,80(sp)
+80001af0:	4c56                	lw	s8,84(sp)
+80001af2:	4ce6                	lw	s9,88(sp)
+80001af4:	4d76                	lw	s10,92(sp)
+80001af6:	5d86                	lw	s11,96(sp)
+80001af8:	5e16                	lw	t3,100(sp)
+80001afa:	5ea6                	lw	t4,104(sp)
+80001afc:	5f36                	lw	t5,108(sp)
+80001afe:	5fc6                	lw	t6,112(sp)
+80001b00:	52d6                	lw	t0,116(sp)
+80001b02:	0007f317          	auipc	t1,0x7f
+80001b06:	ea232303          	lw	t1,-350(t1) # 800809a4 <pxCriticalNesting>
+80001b0a:	00532023          	sw	t0,0(t1)
+80001b0e:	52e6                	lw	t0,120(sp)
+80001b10:	02a1                	addi	t0,t0,8
+80001b12:	30029073          	csrw	mstatus,t0  <--- hang on this line
+80001b16:	42a2                	lw	t0,8(sp)
+80001b18:	4332                	lw	t1,12(sp)
+80001b1a:	07c10113          	addi	sp,sp,124
+80001b1e:	8082                	ret
+```
+
+```
+(gdb) bt
+#0  cpu_loop_exit (cpu=cpu@entry=0x564cd884b070) at ../accel/tcg/cpu-exec-common.c:65
+#1  0x0000564cd6685631 in helper_lookup_tb_ptr (env=0x564cd884c3d0) at ../accel/tcg/cpu-exec.c:400
+#2  0x00007f55dc00014c in code_gen_buffer ()
+#3  0x0000564cd668521b in cpu_tb_exec
+    (cpu=cpu@entry=0x564cd884b070, itb=itb@entry=0x7f55dc000040 <code_gen_buffer+19>, tb_exit=tb_exit@entry=0x7f56235f67ec) at ../accel/tcg/cpu-exec.c:438
+#4  0x0000564cd6685cfb in cpu_loop_exec_tb
+    (tb_exit=0x7f56235f67ec, last_tb=<synthetic pointer>, pc=<optimized out>, tb=0x7f55dc000040 <code_gen_buffer+19>, cpu=0x564cd884b070) at ../accel/tcg/cpu-exec.c:868
+#5  cpu_exec (cpu=cpu@entry=0x564cd884b070) at ../accel/tcg/cpu-exec.c:1032
+#6  0x0000564cd669f904 in tcg_cpus_exec (cpu=cpu@entry=0x564cd884b070)
+    at ../accel/tcg/tcg-accel-ops.c:69
+#7  0x0000564cd669fa57 in mttcg_cpu_thread_fn (arg=arg@entry=0x564cd884b070)
+    at ../accel/tcg/tcg-accel-ops-mttcg.c:95
+#8  0x0000564cd6809b21 in qemu_thread_start (args=<optimized out>)
+    at ../util/qemu-thread-posix.c:505
+#9  0x00007f562429ab43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
+#10 0x00007f562432ca00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+```
+
+I also build a very simple elf for qemu-virt-platform, just contain boot-loader and write mstatus as 0x1888, it can't reproduce.\
+I also build different qemu version such v6.0.0, it still can reproduce.\
+I has modify the march to the most simple arch:rv32i, is still can reproduce.
+
+~"target: riscv"
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1447 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1447
new file mode 100644
index 00000000..dc178b08
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1447
@@ -0,0 +1,7 @@
+riscv: reset_vec uses CSR even when disabled causing inability to boot
+Steps to reproduce:
+1. Run any rv32 binary with `./qemu-system-riscv32 -cpu rv32,d=off,f=off,Zicsr=off`
+
+To view using GDB use `./qemu-system-riscv32 -cpu rv32,d=off,f=off,Zicsr=off -S -s`
+`gdb-multiarch --ex="target remote localhost:1234" -ex "layout asm"`
+then type `si` till $pc jumps to zero on `csrr   a0, mhartid`
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1449 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1449
new file mode 100644
index 00000000..ab952086
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1449
@@ -0,0 +1,5 @@
+RISCV: wrong check for vector extension ELEN value.
+Description of problem:
+When checking if the vector extension ELEN value is in the range [8, 64], the lower bound check uses the `vlen` field instead of the `elen` one: https://gitlab.com/qemu-project/qemu/-/blob/master/target/riscv/cpu.c#L885.
+Additional information:
+This is basically just a typo I found while reading the code, I do not have a real case scenario which resulted in this check to fail.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1542 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1542
new file mode 100644
index 00000000..0e41dcbd
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1542
@@ -0,0 +1,13 @@
+Non-Executable PMP regions of size less than 4K trigger instruction access faults non-deterministically
+Description of problem:
+When a non-executable PMP region of size less than 4K (page size) with a start address that is not 4K-aligned is created, QEMU will non-deterministically dispatch instruction access faults when instructions are executed from the PMP-covered region (will in some cases, won't in others, based on the current TLB state)
+Steps to reproduce:
+1. Create a PMP region of size less than 4K, that is not aligned to the start of the page, make it non-executable
+2. Flush TLB with `sfence.vma x0, x0`
+3. Jump to the start of the pmp-protected page and start executing instructions
+4. Notice that no instruction access fault is reported once we reach the protected region inside the page
+Additional information:
+@rth7680 I believe this is at least partially an unintentional result of this commit that you authored: 7e0d9973ea665bf459b2dbd173d0e51bc6ca5216, which modified the behavior of `get_page_addr_code_hostp` probes to probe a single byte, instead of a full page size (signaled by passing 0).
+This means that we initially probe the first byte of the page, see that no PMP faults are raised, and then assume that no other bytes in the page can cause a PMP fault.
+
+Note that I believe that simply changing this back to 0 from 1 is not enough, as this will likely simply reintroduce the issue I originally reported in #1053.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1556 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1556
new file mode 100644
index 00000000..c54e5f01
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1556
@@ -0,0 +1,35 @@
+RISCV HGATP CSR writes incorrect
+Description of problem:
+Issue with CSR writes/reads of SATP and HGATP. 
+Starting with SATP, in file `qemu/target/riscv/csr.c` the function write_satp has the following code snippet:
+
+```C
+    if (riscv_cpu_mxl(env) == MXL_RV32) {
+        vm = validate_vm(env, get_field(val, SATP32_MODE));
+        mask = (val ^ env->satp) & (SATP32_MODE | SATP32_ASID | SATP32_PPN);
+    } else {
+        vm = validate_vm(env, get_field(val, SATP64_MODE));
+        mask = (val ^ env->satp) & (SATP64_MODE | SATP64_ASID | SATP64_PPN);
+    }
+
+    if (vm && mask) {
+        if (env->priv == PRV_S && get_field(env->mstatus, MSTATUS_TVM)) {
+            return RISCV_EXCP_ILLEGAL_INST;
+```
+The potential problem I see in the code is that a CSR write which is either illegal or the same as what was previously in the CSR will not yield an illegal instruction. This potential issue could be simple to fix by simply moving the TVM check outside the vm && mask if-statement.
+EDIT: I haven't been able to replicate this. Maybe there is code somewhere else which guards against this situation, I'll leave this comment here anyway just to get an extra pair of eyes on this code.
+
+For writes to hgatp (in the same source file) the value provided to the function is simply written directly to hgatp.
+```
+static RISCVException write_hgatp(CPURISCVState *env, int csrno,
+                                  target_ulong val)
+{
+    env->hgatp = val;
+    return RISCV_EXCP_NONE;
+}
+```
+This can not be correct, the specification for example states `"A write to hgatp with an unsupported MODE value is not ignored as it is for satp. Instead, the fields of hgatp are WARL in the normal way, when so indicated."` Furthermore, there is also a restriction on the ppn field saying that ppn[1:0] must be 0. Finally when reading hgatp the tvm flag is not taken into consideration at all.
+Additional information:
+The provided binary should be able to replicate the issue. The error regarding num_unexp_trap can be disregarded in this case, normally I break a test directly on an assertion failure but I didn't this time which is why the counter is increasing.
+
+[main](/uploads/31ef3bc424d63097177cba3579d9b411/main)
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1606 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1606
new file mode 100644
index 00000000..9cd0bd25
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1606
@@ -0,0 +1,29 @@
+riscv: fence.i is not functional
+Description of problem:
+The attached user-level test is designed to do the following (in iteration):
+
+  - Thread P0 on CPU0 changes some text/code, while
+
+  - Thread P1 on CPU1 checks/reads the code, fence.i, then executes the same code.
+
+Results (in stdout) indicates that CPU1 has read the new code (1:x5=a009) but executed the old one (1:x7=1) (against the specification).
+Steps to reproduce:
+1. echo 2 > /proc/sys/vm/nr_hugepages
+2. ./CoRF+fence.i
+Additional information:
+Example output:
+```[CoRF+fence.i.c](/uploads/c150ca0910783cc4bfc3886789b64c28/CoRF+fence.i.c)
+Test CoRF+fence.i Allowed
+Histogram (4 states)
+25784  :>1:x5=0xa009; 1:x7=2;
+24207  *>1:x5=0xa009; 1:x7=1;   <--  THIS LINE
+8      :>1:x5=0xa019; 1:x7=1;
+1      :>1:x5=0xa019; 1:x7=2;
+Ok
+Witnesses
+Positive: 24207 Negative 25793
+Condition exists (1:x5=0xa009 /\ 1:x7=1) is  validated
+Observation CoRF+fence.i Sometimes 24207 25793
+Time CoRF+fence.i 0.85
+Hash=
+```
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1617 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1617
new file mode 100644
index 00000000..55771269
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1617
@@ -0,0 +1,62 @@
+RISC-V: VS external IRQ can be taken in M-mode
+Description of problem:
+The RISC-V specification states that `VS-level interrupts and guest external interrupts are always delegated past M-mode to HS mode.`
+I happened to come across a situation where QEMU takes the vs_external IRQ in machine mode.
+Steps to reproduce:
+1. Enable IRQs globally (mstatus, vsstatus)
+2. Set hstatus.VGEIN to a legal value
+3. Write -1 to mie
+4. Write -1 to hvip
+
+I included a binary that should be able to reproduce the issue.
+
+I use a vectored setup for mtvec and as soon as the VSEIP bit in hvip has been set the machine jumps to mtvec.vsei.
+To confirm that I actually went to mtvec and not somewhere with a faulty print I also performed an ecall and that was reported as an M mode ecall.
+Additional information:
+```
+TRACE: [hart_ctrl.c:35] STARTING CPU 0
+DEBUG: [trap_handling.c: 886] Setting up trap handlers
+DEBUG: [aia_ctrl.c: 377] Initializing interrupt controller
+TRACE: [main.c:31] Writing -1 to mie
+TRACE: [main.c:33] Writing -1 to hvip
+riscv_cpu_do_interrupt: hart:0, async:1, cause:000000000000000a, epc:0x0000000080000114, tval:0x0000000000000000, desc=vs_external
+ERROR: [trap_handling.c:280] mtvec_vsei should be unreachable
+mstatus = 0x0000000a000038a2    hstatus:         
+  SIE  = 1                        VSXL[1:0]   = 2
+  MIE  = 0                        VTSR        = 0
+  SPIE = 1                        VTW         = 0
+  UBE  = 0                        VTVM        = 0
+  MPIE = 1                        VGEIN[5:0]  = 1
+  SPP  = 0                        HU          = 0
+  VS   = 0                        SPVP        = 0
+  MPP  = 3                        SPV         = 0
+  FS   = 1                        GVA         = 0
+  MPRV = 0                        VSBE        = 0
+  SUM  = 0
+  MXR  = 0
+  TVM  = 0
+  TW   = 0
+  TSR  = 0
+  UXL  = 2
+  SXL  = 2
+  SBE  = 0
+  MBE  = 0
+  GVA  = 0
+  MPV  = 0
+mie                  mip                  mideleg                hvip                
+    ssie (1)   =  1      ssip (1)   =  0      ssi  (1)   =  0        ssip (1)   =  0 
+    vssie(2)   =  1      vssip(2)   =  1      vssi (2)   =  0        vssip(2)   =  1 
+    msie (3)   =  1      msip (3)   =  0      msi  (3)   =  0        msip (3)   =  0 
+    stie (5)   =  1      stip (5)   =  0      sti  (5)   =  0        stip (5)   =  0 
+    vstie(6)   =  1      vstip(6)   =  0      vsti (6)   =  0        vstip(6)   =  0 
+    mtie (7)   =  1      mtip (7)   =  0      mti  (7)   =  0        mtip (7)   =  0 
+    seie (9)   =  1      seip (9)   =  0      sei  (9)   =  0        seip (9)   =  0 
+    vseie(10)  =  1      vseip(10)  =  1      vsei (10)  =  0        vseip(10)  =  1 
+    meie (11)  =  1      meip (11)  =  0      mei  (11)  =  0        meip (11)  =  0 
+    sgeie(12)  =  1      sgeip(12)  =  0      sgei (12)  =  0        sgeip(12)  =  0 
+DEBUG: [trap_handling.c:  28] hart_ctrl.kill_hart = 0x8000a00c
+TRACE: [trap_handling.c:29] Program done, exiting
+QEMU: Terminated
+```
+Reproducer of the problem:
+[main](/uploads/26a5698ce948149ca9d34f6b3dfac6a4/main)
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1633 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1633
new file mode 100644
index 00000000..8c18bbb4
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1633
@@ -0,0 +1,68 @@
+[8.0.0] Broken icount support on RISC-V
+Description of problem:
+After https://gitlab.com/qemu-project/qemu/-/commit/5a4ae64cac49564354cd6f17598840e4af70e4f5 was merged, RISC-V VMs no longer run with -icount 1 specified in the QEMU arguments. Reverting this commit resolves the issue.
+Steps to reproduce:
+1. Download preinstalled Ubuntu 22.04.2 image from [here](https://cdimage.ubuntu.com/releases/22.04.2/release/ubuntu-22.04.2-preinstalled-server-riscv64+unmatched.img.xz)
+2. Download uboot from [here](http://security.ubuntu.com/ubuntu/pool/main/u/u-boot/u-boot-qemu_2022.01+dfsg-2ubuntu2.3_all.deb)
+3. Extract both.
+4. Run with the command-line specified above.
+Additional information:
+Reading Ubuntu wiki describing how to run RISC-V VMs can help: https://wiki.ubuntu.com/RISC-V/QEMU
+
+Full output:
+
+```
+% qemu-system-riscv64 \                     
+-machine virt -nographic -m 2048 -smp 4 \
+-kernel u-boot/qemu-riscv64_smode/uboot.elf \
+-device virtio-net-device,netdev=eth0 -netdev user,id=eth0 \
+-drive file=ubuntu-22.04.2-preinstalled-server-riscv64+unmatched.img,format=raw,if=virtio -icount 1
+
+OpenSBI v1.2
+   ____                    _____ ____ _____
+  / __ \                  / ____|  _ \_   _|
+ | |  | |_ __   ___ _ __ | (___ | |_) || |
+ | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
+ | |__| | |_) |  __/ | | |____) | |_) || |_
+  \____/| .__/ \___|_| |_|_____/|____/_____|
+        | |
+        |_|
+
+Platform Name             : riscv-virtio,qemu
+Platform Features         : medeleg
+Platform HART Count       : 4
+Platform IPI Device       : aclint-mswi
+Platform Timer Device     : aclint-mtimer @ 10000000Hz
+Platform Console Device   : uart8250
+Platform HSM Device       : ---
+Platform PMU Device       : ---
+Platform Reboot Device    : sifive_test
+Platform Shutdown Device  : sifive_test
+Firmware Base             : 0x80000000
+Firmware Size             : 236 KB
+Runtime SBI Version       : 1.0
+
+Domain0 Name              : root
+Domain0 Boot HART         : 0
+Domain0 HARTs             : 0*,1*,2*,3*
+Domain0 Region00          : 0x0000000002000000-0x000000000200ffff (I)
+Domain0 Region01          : 0x0000000080000000-0x000000008003ffff ()
+Domain0 Region02          : 0x0000000000000000-0xffffffffffffffff (R,W,X)
+Domain0 Next Address      : 0x0000000080200000
+Domain0 Next Arg1         : 0x00000000bfe00000
+Domain0 Next Mode         : S-mode
+Domain0 SysReset          : yes
+
+Boot HART ID              : 0
+Boot HART Domain          : root
+Boot HART Priv Version    : v1.12
+Boot HART Base ISA        : rv64imafdch
+Boot HART ISA Extensions  : time,sstc
+Boot HART PMP Count       : 16
+Boot HART PMP Granularity : 4
+Boot HART PMP Address Bits: 54
+Boot HART MHPM Count      : 16
+Boot HART MIDELEG         : 0x0000000000001666
+Boot HART MEDELEG         : 0x0000000000f0b509
+qemu-system-riscv64: Bad icount read
+```
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1636 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1636
new file mode 100644
index 00000000..6549bff4
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1636
@@ -0,0 +1,102 @@
+RISCV: Interrupt not cleared correctly (supervisor external IRQ)
+Description of problem:
+
+Steps to reproduce:
+1. Set mie -> 0
+2. Assert all interrupt sources which can be taken in M-mode (i.e. set mei, msi, mti, sei, ssi, sti)
+3. I'm using the imsic for the external interrupts and the clint for timer interrupts.
+4. Once all IRQs are pending set mie -> 0xFFFF
+5. IRQs are taken one by one, all M-level IRQs are cleared without issues.
+6. The issue occurs when trying to clear the S-external IRQ, when writing stopei to clear the IRQ mip is not updated correctly.
+
+I believe I have located the issue in target/riscv/cpu.c:1314 
+
+**Old code:**
+```
+riscv_cpu_update_mip(cpu, 1 << irq,
+     BOOL_TO_MASK(level | env->software_seip));
+```
+**Changed code:**
+```
+riscv_cpu_update_mip(cpu, 1 << irq,
+     BOOL_TO_MASK(level));
+```
+
+When we reach the next code snippet (cpu_helper.c:628) we enter cpu_interrupt instead of cpu_reset_interrupt and thus end up in an infinite loop since the imsic message from that point on will be 0. It looks weird to me to use env->software_seip and not env->external_seip, in any case I changed it to BOOL_TO_MASK(level) and I now see the behavior I expect from my test program. 
+
+```c
+    env->mip = (env->mip & ~mask) | (value & mask);
+
+    if (env->mip | vsgein | vstip) {
+        cpu_interrupt(cs, CPU_INTERRUPT_HARD);
+    } else {
+        cpu_reset_interrupt(cs, CPU_INTERRUPT_HARD);
+    }
+
+```
+Additional information:
+Log when getting the error.
+```
+TRACE: [src/hart_ctrl.c:35] STARTING CPU 0
+DEBUG: [src/trap_handling.c: 938] Setting up trap handlers
+TRACE: [src/page_tables.c:341] Setting up page tables between 0x80000000 -> 0x81c00000
+TRACE: [src/page_tables.c:355] Setting up page tables for UART 0x10000000
+TRACE: [src/page_tables.c:365] Setting up page tables for CLINT 0x2000000
+DEBUG: [src/page_tables.c: 383] Mapping IMISIC 0x24000000
+DEBUG: [src/page_tables.c: 383] Mapping IMISIC 0x28000000
+DEBUG: [src/page_tables.c: 383] Mapping IMISIC 0x28001000
+DEBUG: [src/util_fn.c: 339] Setting satp: 0x8000100000081017 
+DEBUG: [src/util_fn.c: 342] Setting hgatp: 0x8000000000081014 
+TRACE: [src/main.c:40] Asserting M-level interrupts simultaneously
+DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause machine external interrupt
+DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause machine software interrupt
+DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause machine timer interrupt
+DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause supervisor external interrupt
+DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause supervisor software interrupt
+DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause supervisor timer interrupt
+riscv_cpu_do_interrupt: hart:0, async:1, cause:000000000000000b, epc:0x0000000080004d80, tval:0x0000000000000000, desc=m_external
+DEBUG: [src/trap_handling.c: 315] mtvec_mei
+DEBUG: [src/trap_handling.c:  65] Cause to check is currently Cause machine external interrupt
+DEBUG: [src/trap_handling.c:  76] Cause machine external interrupt exception: MEPC = 0x80004d80, MTVAL = 0x0
+DEBUG: [src/aia_ctrl.c: 352] Popped IMSIC message = 1
+riscv_cpu_do_interrupt: hart:0, async:1, cause:0000000000000003, epc:0x0000000080004d80, tval:0x0000000000000000, desc=m_software
+DEBUG: [src/trap_handling.c:  65] Cause to check is currently Cause machine software interrupt
+DEBUG: [src/trap_handling.c:  76] Cause machine software interrupt exception: MEPC = 0x80004d80, MTVAL = 0x0
+riscv_cpu_do_interrupt: hart:0, async:1, cause:0000000000000007, epc:0x0000000080004d80, tval:0x0000000000000000, desc=m_timer
+DEBUG: [src/trap_handling.c:  65] Cause to check is currently Cause machine timer interrupt
+DEBUG: [src/trap_handling.c:  76] Cause machine timer interrupt exception: MEPC = 0x80004d80, MTVAL = 0x0
+riscv_cpu_do_interrupt: hart:0, async:1, cause:0000000000000009, epc:0x0000000080004d80, tval:0x0000000000000000, desc=s_external
+DEBUG: [src/trap_handling.c: 296] mtvec_sei
+DEBUG: [src/trap_handling.c:  65] Cause to check is currently Cause supervisor external interrupt
+DEBUG: [src/trap_handling.c:  76] Cause supervisor external interrupt exception: MEPC = 0x80004d80, MTVAL = 0x0
+mip
+    ssip (1)   =  1
+    vssip(2)   =  0
+    msip (3)   =  0
+    stip (5)   =  1
+    vstip(6)   =  0
+    mtip (7)   =  0
+    seip (9)   =  1
+    vseip(10)  =  0
+    meip (11)  =  0
+    sgeip(12)  =  0
+DEBUG: [src/aia_ctrl.c: 339] Writing stopei -> 0
+DEBUG: [src/aia_ctrl.c: 344] stopei = 0x0000000000000000 
+DEBUG: [src/aia_ctrl.c: 352] Popped IMSIC message = 1
+mip
+    ssip (1)   =  1
+    vssip(2)   =  0
+    msip (3)   =  0
+    stip (5)   =  1
+    vstip(6)   =  0
+    mtip (7)   =  0
+    seip (9)   =  1
+    vseip(10)  =  0
+    meip (11)  =  0
+    sgeip(12)  =  0
+riscv_cpu_do_interrupt: hart:0, async:1, cause:0000000000000009, epc:0x0000000080004d80, tval:0x0000000000000000, desc=s_external
+DEBUG: [src/trap_handling.c: 296] mtvec_sei
+DEBUG: [src/trap_handling.c:  65] Cause to check is currently Cause supervisor software interrupt
+DEBUG: [src/trap_handling.c:  76] Cause supervisor external interrupt exception: MEPC = 0x80004d80, MTVAL = 0x0
+ERROR: [src/trap_handling.c:121] The following assert failed: masked_cause == cause2check
+masked_cause = 9
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1647 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1647
new file mode 100644
index 00000000..c608599e
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1647
@@ -0,0 +1,12 @@
+Potential Bug in RISCV Hypervisor Extension: Timer Interrupt Handling in QEMU v8.0.0-rc1
+Steps to reproduce:
+1. Build and run a simple hypervisor on QEMU v8.0.0-rc1 with the hypervisor extension feature of RISCV.
+2. Set up hideleg, henvcfg, etc., in hypervisor and run the Linux kernel.
+3. Observe the issue of infinite loop caused by the pending timer interrupt.
+Additional information:
+Linux version: riscv_aia_v1 from github.com/avpatel/linux
+OpenSBI version: Modified 1.1
+
+I would greatly appreciate it if you could kindly provide some guidance. Is this behavior expected or could this be a bug? I've tried to provide a detailed analysis of my observations, but I'm not 100% certain if my understanding is correct.
+
+Thank you for your time and consideration.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1649 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1649
new file mode 100644
index 00000000..67d58bf4
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1649
@@ -0,0 +1,17 @@
+"slli" instruction before "la" and "csrw" sequence leads to failure in setting the cs register
+Description of problem:
+slli a0, a0, 8 (1)
+    la a0, mtimvec (2)
+    csrw mtvec, a0 (3)
+    mtimvec:       (4)
+
+For the above assembly snippet, the mtvec could be successfully set to the value of a0 
+without the presence of the line (1) or with the shift amount being zero. However, 
+the mtvec can never be set successfully with the presence of line (1).
+Steps to reproduce:
+1. Create a test.s file and put these 4 lines of assembly into the file
+2. In terminal, run: "riscv64-unknown-elf-gcc -Ttext 0x80000000 -c test.s -o test", "riscv64-unknown-elf-objcopy test -S -O binary test", and "qemu-system-riscv64 test -s -S"
+3. In another terminal window, run [riscv64-unknown-elf-gdb -ex "target remote localhost:1234" -ex "layout asm"]. Keep running si command in gdb until you are at 0x80000000 where you shall see the first instruction as shown in line (1). Then keep going till you have stepped over the instruction shown in line (3). Now, run "p $mtvec" in gdb, you shall see its value being 0.
+4. Redo the above steps without line (1), you shall see mtvec loaded successfully with the correct value.
+Additional information:
+
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1671 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1671
new file mode 100644
index 00000000..272054e2
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1671
@@ -0,0 +1,1357 @@
+segfault/errors in gdbstub with linux userspace emulator (qemu-riscv64), from racy behavior with singal handler?
+Description of problem:
+Often, qemu segfaults, sometimes GDB just spits out a wall of "Ignoring packet error, continuing..." and ~hangs: I don't get a GDB command prompt quickly, if at all, and when I ctrl-c I see "The target is not responding to GDB commands. Stop debugging it? (y or n)".
+Steps to reproduce:
+1. Run the `testb3` binary from below as described
+2. Connect via GDB and `continue`
+3. Multiple threads (independently) SIGABRT themselves when they fail their test(s), which happens quickly on my machine (which has 16 physical cores)
+Additional information:
+From the coredump, it looks like there's a lot of cooks in the gdbstub kitchen:
+
+```
+  Id   Target Id                           Frame 
+* 1    Thread 0x7febc02ef6c0 (LWP 3922802) gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282
+  2    Thread 0x7febc06db6c0 (LWP 3922792) safe_syscall_base ()
+    at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+  3    Thread 0x7febc03b26c0 (LWP 3922799) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+  4    Thread 0x7febc0f5d6c0 (LWP 3922751) 0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6
+  5    Thread 0x7febc0f5ebc0 (LWP 3922750) safe_syscall_base ()
+    at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+  6    Thread 0x7febc01696c0 (LWP 3922808) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  7    Thread 0x7febc04f76c0 (LWP 3922794) 0x00007febc16f1d4c in send () from /usr/lib/libc.so.6
+  8    Thread 0x7febc026d6c0 (LWP 3922804) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  9    Thread 0x7febc01aa6c0 (LWP 3922807) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  10   Thread 0x7febc075c6c0 (LWP 3922793) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  11   Thread 0x7febc04756c0 (LWP 3922796) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+  12   Thread 0x7febc01eb6c0 (LWP 3922806) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  13   Thread 0x7febc022c6c0 (LWP 3922805) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+  14   Thread 0x7febc03f36c0 (LWP 3922798) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  15   Thread 0x7febc04346c0 (LWP 3922797) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  16   Thread 0x7febc03716c0 (LWP 3922800) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+  17   Thread 0x7febc04b66c0 (LWP 3922795) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  18   Thread 0x7febc02ae6c0 (LWP 3922803) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  19   Thread 0x7febc03306c0 (LWP 3922801) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+```
+
+Each of those `read` and `send` threads look something similar to this one:
+
+```
+Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+```
+
+Which, at a guess, seems like there's maybe 20 different concurrent processes fighting over the singular [gdbstub state](https://gitlab.com/qemu-project/qemu/-/blob/master/gdbstub/gdbstub.c#L57)? Specifically, they're all stomping on each other by writing to the same [buffer](https://gitlab.com/qemu-project/qemu/-/blob/master/gdbstub/user.c#L136) and advancing the [current CPU list pointer](https://gitlab.com/qemu-project/qemu/-/blob/master/gdbstub/gdbstub.c#L1422), which causes the "bad packet" cross-talk and the segfault respectively.
+
+<details><summary>full backtrace</summary>
+
+```
+(gdb) thread apply all bt full
+
+Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 18 (Thread 0x7febc02ae6c0 (LWP 3922803)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 17 (Thread 0x7febc04b66c0 (LWP 3922795)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 16 (Thread 0x7febc03716c0 (LWP 3922800)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 15 (Thread 0x7febc04346c0 (LWP 3922797)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 14 (Thread 0x7febc03f36c0 (LWP 3922798)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 13 (Thread 0x7febc022c6c0 (LWP 3922805)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 12 (Thread 0x7febc01eb6c0 (LWP 3922806)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 11 (Thread 0x7febc04756c0 (LWP 3922796)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 10 (Thread 0x7febc075c6c0 (LWP 3922793)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 9 (Thread 0x7febc01aa6c0 (LWP 3922807)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 8 (Thread 0x7febc026d6c0 (LWP 3922804)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 7 (Thread 0x7febc04f76c0 (LWP 3922794)):
+#0  0x00007febc16f1d4c in send () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a994a in gdb_put_buffer () at ../qemu-8.0.0/gdbstub/user.c:82
+No locals.
+#2  0x00005582273aad23 in gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:161
+No locals.
+#3  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#4  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#5  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#6  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#7  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#8  0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#9  0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#10 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#11 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#12 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#13 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#14 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#15 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#16 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#17 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#18 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 6 (Thread 0x7febc01696c0 (LWP 3922808)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 5 (Thread 0x7febc0f5ebc0 (LWP 3922750)):
+#0  safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+No locals.
+#1  0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678
+No locals.
+#2  do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804
+No locals.
+#3  do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891
+No locals.
+#4  0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476
+No locals.
+#5  0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375
+No locals.
+#6  0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55
+No locals.
+#7  0x000055822728bfa1 in main () at ../qemu-8.0.0/linux-user/main.c:962
+No locals.
+
+Thread 4 (Thread 0x7febc0f5d6c0 (LWP 3922751)):
+#0  0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273cdcb3 in qemu_futex_wait () at /usr/src/debug/qemu/qemu-8.0.0/include/qemu/futex.h:29
+No locals.
+#2  qemu_event_wait () at ../qemu-8.0.0/util/qemu-thread-posix.c:464
+No locals.
+#3  0x00005582273d83ad in call_rcu_thread () at ../qemu-8.0.0/util/rcu.c:261
+No locals.
+#4  0x00005582273cde58 in qemu_thread_start () at ../qemu-8.0.0/util/qemu-thread-posix.c:541
+No locals.
+#5  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#6  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 3 (Thread 0x7febc03b26c0 (LWP 3922799)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 2 (Thread 0x7febc06db6c0 (LWP 3922792)):
+#0  safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+No locals.
+#1  0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678
+No locals.
+#2  do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804
+No locals.
+#3  do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891
+No locals.
+#4  0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476
+No locals.
+#5  0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375
+No locals.
+#6  0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55
+No locals.
+#7  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#8  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#9  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 1 (Thread 0x7febc02ef6c0 (LWP 3922802)):
+#0  gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282
+No locals.
+#1  0x00005582273ab774 in handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1411
+No locals.
+#2  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#3  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#4  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#5  0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#6  0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#7  gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#8  gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#9  0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#10 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#11 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#12 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#13 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#14 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#15 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+(gdb) thread apply all bt 
+
+Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 18 (Thread 0x7febc02ae6c0 (LWP 3922803)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 17 (Thread 0x7febc04b66c0 (LWP 3922795)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 16 (Thread 0x7febc03716c0 (LWP 3922800)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 15 (Thread 0x7febc04346c0 (LWP 3922797)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 14 (Thread 0x7febc03f36c0 (LWP 3922798)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 13 (Thread 0x7febc022c6c0 (LWP 3922805)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 12 (Thread 0x7febc01eb6c0 (LWP 3922806)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 11 (Thread 0x7febc04756c0 (LWP 3922796)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 10 (Thread 0x7febc075c6c0 (LWP 3922793)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 9 (Thread 0x7febc01aa6c0 (LWP 3922807)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 8 (Thread 0x7febc026d6c0 (LWP 3922804)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 7 (Thread 0x7febc04f76c0 (LWP 3922794)):
+#0  0x00007febc16f1d4c in send () from /usr/lib/libc.so.6
+#1  0x00005582273a994a in gdb_put_buffer () at ../qemu-8.0.0/gdbstub/user.c:82
+#2  0x00005582273aad23 in gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:161
+#3  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+#4  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+#5  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#6  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+#7  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+#8  0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#9  0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+#10 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+#11 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+#12 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+#13 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#14 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#15 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#16 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#17 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#18 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 6 (Thread 0x7febc01696c0 (LWP 3922808)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 5 (Thread 0x7febc0f5ebc0 (LWP 3922750)):
+#0  safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+#1  0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678
+#2  do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804
+#3  do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891
+#4  0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476
+#5  0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375
+#6  0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55
+#7  0x000055822728bfa1 in main () at ../qemu-8.0.0/linux-user/main.c:962
+
+Thread 4 (Thread 0x7febc0f5d6c0 (LWP 3922751)):
+#0  0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6
+#1  0x00005582273cdcb3 in qemu_futex_wait () at /usr/src/debug/qemu/qemu-8.0.0/include/qemu/futex.h:29
+#2  qemu_event_wait () at ../qemu-8.0.0/util/qemu-thread-posix.c:464
+#3  0x00005582273d83ad in call_rcu_thread () at ../qemu-8.0.0/util/rcu.c:261
+#4  0x00005582273cde58 in qemu_thread_start () at ../qemu-8.0.0/util/qemu-thread-posix.c:541
+#5  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#6  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 3 (Thread 0x7febc03b26c0 (LWP 3922799)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 2 (Thread 0x7febc06db6c0 (LWP 3922792)):
+#0  safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+#1  0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678
+#2  do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804
+#3  do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891
+#4  0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476
+#5  0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375
+#6  0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55
+#7  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#8  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#9  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 1 (Thread 0x7febc02ef6c0 (LWP 3922802)):
+#0  gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282
+#1  0x00005582273ab774 in handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1411
+#2  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#3  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+#4  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+#5  0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#6  0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+#7  gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+#8  gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+#9  0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+#10 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#11 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#12 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#13 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#14 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#15 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+(gdb) thread apply all bt full
+
+Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 18 (Thread 0x7febc02ae6c0 (LWP 3922803)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 17 (Thread 0x7febc04b66c0 (LWP 3922795)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 16 (Thread 0x7febc03716c0 (LWP 3922800)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 15 (Thread 0x7febc04346c0 (LWP 3922797)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 14 (Thread 0x7febc03f36c0 (LWP 3922798)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 13 (Thread 0x7febc022c6c0 (LWP 3922805)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 12 (Thread 0x7febc01eb6c0 (LWP 3922806)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 11 (Thread 0x7febc04756c0 (LWP 3922796)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 10 (Thread 0x7febc075c6c0 (LWP 3922793)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 9 (Thread 0x7febc01aa6c0 (LWP 3922807)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 8 (Thread 0x7febc026d6c0 (LWP 3922804)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 7 (Thread 0x7febc04f76c0 (LWP 3922794)):
+#0  0x00007febc16f1d4c in send () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a994a in gdb_put_buffer () at ../qemu-8.0.0/gdbstub/user.c:82
+No locals.
+#2  0x00005582273aad23 in gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:161
+No locals.
+#3  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#4  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#5  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#6  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#7  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#8  0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#9  0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#10 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#11 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#12 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#13 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#14 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#15 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#16 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#17 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#18 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 6 (Thread 0x7febc01696c0 (LWP 3922808)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 5 (Thread 0x7febc0f5ebc0 (LWP 3922750)):
+#0  safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+No locals.
+#1  0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678
+No locals.
+#2  do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804
+No locals.
+#3  do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891
+No locals.
+#4  0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476
+No locals.
+#5  0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375
+No locals.
+#6  0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55
+No locals.
+#7  0x000055822728bfa1 in main () at ../qemu-8.0.0/linux-user/main.c:962
+No locals.
+
+Thread 4 (Thread 0x7febc0f5d6c0 (LWP 3922751)):
+#0  0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273cdcb3 in qemu_futex_wait () at /usr/src/debug/qemu/qemu-8.0.0/include/qemu/futex.h:29
+No locals.
+#2  qemu_event_wait () at ../qemu-8.0.0/util/qemu-thread-posix.c:464
+No locals.
+#3  0x00005582273d83ad in call_rcu_thread () at ../qemu-8.0.0/util/rcu.c:261
+No locals.
+#4  0x00005582273cde58 in qemu_thread_start () at ../qemu-8.0.0/util/qemu-thread-posix.c:541
+No locals.
+#5  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#6  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 3 (Thread 0x7febc03b26c0 (LWP 3922799)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 2 (Thread 0x7febc06db6c0 (LWP 3922792)):
+#0  safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+No locals.
+#1  0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678
+No locals.
+#2  do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804
+No locals.
+#3  do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891
+No locals.
+#4  0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476
+No locals.
+#5  0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375
+No locals.
+#6  0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55
+No locals.
+#7  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#8  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#9  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 1 (Thread 0x7febc02ef6c0 (LWP 3922802)):
+#0  gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282
+No locals.
+#1  0x00005582273ab774 in handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1411
+No locals.
+#2  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#3  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#4  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#5  0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#6  0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#7  gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#8  gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#9  0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#10 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#11 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#12 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#13 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#14 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#15 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+```
+
+</details>
+
+
+
+- coredump
+    - [core.qemu-riscv64.1000.efb558e6104b4cc5bfa37605fc9af294.3922750.1685497956000000.zst](/uploads/071fc96520ca4008941044802c176d6a/core.qemu-riscv64.1000.efb558e6104b4cc5bfa37605fc9af294.3922750.1685497956000000.zst)
+    - [qemu-riscv64](/uploads/f203d5aed8559d80c2d66e439bb4dddf/qemu-riscv64) (the binary the coredump was generated from)
+    - download both, extract corefile, use `DEBUGINFOD_URLS=https://debuginfod.archlinux.org gdb /path/to/qemu-riscv64 -c /tmp/coredump` to debug
+- reproducer
+    - [testb3.tar.xz](/uploads/84bdbb547e01527c3d804e0d88c6c9fe/testb3.tar.xz) (includes testb3 + sysroot to work with command line above)
+    - This binary is a cross-compiled `testb3` from [WebKit](https://github.com/WebKit/WebKit/blob/9755847ab1d40841374b2467b3036d943b723183/Source/JavaScriptCore/b3/testb3_1.cpp#L927) ; sorry, that's about all I know about it so far
+    - A GDB you might use to connect is [SiFive's](https://static.dev.sifive.com/dev-tools/riscv64-unknown-elf-gcc-8.1.0-2019.01.0-x86_64-linux-ubuntu14.tar.gz). I got more consistent segfaults with a more recent gdb (12.1), but I'm not sure how to tell you how to get that `gdb` besides "creating a riscv64 poky distribution" (what I did), which is likely not helpful.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1688 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1688
new file mode 100644
index 00000000..1a94e698
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1688
@@ -0,0 +1,33 @@
+target/riscv KVM_RISCV_SET_TIMER macro is not configured correctly
+Description of problem:
+When riscv kvm vm state changed, guest virtual time would stop/continue. But KVM_RISCV_SET_TIMER is wrong, qemu-kvm can only set 'time'.
+Steps to reproduce:
+1.start host kernel
+2.start qemu-kvm
+Additional information:
+Below code has some probelm:
+```
+===================================================================
+#define KVM_RISCV_SET_TIMER(cs, env, name, reg) \
+    do { \
+        int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(env, time), &reg); \
+
+===================================================================
+```
+I think it should be like this:
+
+```
+diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
+index 30f21453d6..0c567f668c 100644
+--- a/target/riscv/kvm.c
++++ b/target/riscv/kvm.c
+@@ -99,7 +99,7 @@ static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t type,
+
+ #define KVM_RISCV_SET_TIMER(cs, env, name, reg) \
+     do { \
+-        int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(env, time), &reg); \
++        int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(env, name), &reg); \
+         if (ret) { \
+             abort(); \
+         } \
+```
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1708 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1708
new file mode 100644
index 00000000..7ffa6f10
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1708
@@ -0,0 +1,67 @@
+RISCV: Illegal instruction delegated to VS mode sets the wrong vscause value
+Description of problem:
+When delegating an illegal instruction exception caused in VS-mode to VS-mode, the vscause value for an illegal instruction is set incorrectly.
+
+Steps to reproduce:
+1. Delegate 2(,6,10) in medeleg and hedeleg.
+2. Enter VS-mode
+3. Cause an illegal instruction fault, cause 6 can't happen in QEMU since there is misaligned support and 10 can't be delegated to VS mode.
+4. The (v)scause CSR is then set to 1, i.e. instruction access fault which isn't correct.
+
+I have located the issue in the code @ cpu_helper.c:1703
+```
+if ((cause == IRQ_VS_TIMER || cause == IRQ_VS_SOFT ||
+    cause == IRQ_VS_EXT)) {
+    cause = cause - 1;
+}
+```
+
+The if statement should include a check for the async otherwise the cause shouldn't be altered. The patch I propose is simply to **and** the current statement with async.
+```
+if (async & (cause == IRQ_VS_TIMER || cause == IRQ_VS_SOFT ||
+    cause == IRQ_VS_EXT)) {
+    cause = cause - 1;
+}
+```
+Additional information:
+Log where the incorrect cause is set. Note this line: `DEBUG: [src/trap_handling.c: 105] Instruction access fault exception: SEPC = 0x80008850, STVAL = 0x0`
+```
+TRACE: [src/hart_ctrl.c:35] STARTING CPU 0
+TRACE: [src/page_tables.c:343] Setting up page tables between 0x80000000 -> 0x81c00000
+TRACE: [src/page_tables.c:359] Setting up page tables between 0x81c01000 -> 0x81c02000
+TRACE: [src/page_tables.c:374] Setting up page tables for UART 0x10000000
+TRACE: [src/page_tables.c:386] Setting up page tables for CLINT 0x2000000
+DEBUG: [src/page_tables.c: 406] Mapping IMISIC 0x24000000
+DEBUG: [src/page_tables.c: 406] Mapping IMISIC 0x28000000
+DEBUG: [src/page_tables.c: 406] Mapping IMISIC 0x28001000
+TRACE: [src/main.c:32] STARTING HYPERVISOR TESTS
+DEBUG: [src/util_fn.c:1175] pmpcfg0 = 0x00000000000f000f 
+DEBUG: [src/util_fn.c:1176] pmpcfg2 = 0x0000000000000000 
+PMP Entry     : 0
+Low Address   : 0x0
+High Address  : 0x81c00000
+Address Range : 0x0 - 0x81c00000
+Mode          : TOR
+Executable    : Yes
+Writable      : Yes
+Readable      : Yes
+Locked        : No
+--------------------------------------
+PMP Entry     : 2
+Low Address   : 0x82000000
+High Address  : 0xfffffffffffffffc
+Address Range : 0x82000000 - 0xfffffffffffffffc
+Mode          : TOR
+Executable    : Yes
+Writable      : Yes
+Readable      : Yes
+Locked        : No
+--------------------------------------
+DEBUG: [src/trap_trigger.c:  85] Switching mode to VS
+riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000002, epc:0x00000000800062a4, tval:0x0000000000000000, desc=illegal_instruction
+DEBUG: [src/trap_handling.c: 102] Illegal instruction exception: MEPC = 0x800062a4, MTVAL = 0x0
+TRACE: [src/util_fn.c:374] Done switching mode
+riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000002, epc:0x0000000080008850, tval:0x0000000000000000, desc=illegal_instruction
+DEBUG: [src/trap_handling.c: 105] Instruction access fault exception: SEPC = 0x80008850, STVAL = 0x0
+ERROR: [src/trap_handling.c:158] The following assert failed: mask_cause == cause2check
+mask_cause = 0x1
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1733 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1733
new file mode 100644
index 00000000..2e36dafb
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1733
@@ -0,0 +1,3 @@
+[riscv-pmp]: PMP_is_locked function has redundant top pmp check
+Additional information:
+
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1735 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1735
new file mode 100644
index 00000000..49883186
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1735
@@ -0,0 +1,29 @@
+[riscv-pmp] Pmp_hart_has_privs local variable name easily misunderstood
+Additional information:
+```c
+// int => bool 
+static int pmp_is_in_range(CPURISCVState *env, int pmp_index,
+                           target_ulong addr);
+
+bool pmp_hart_has_privs(CPURISCVState *env, target_ulong addr,
+                        target_ulong size, pmp_priv_t privs,
+                        pmp_priv_t *allowed_privs, target_ulong mode)
+{
+    int i = 0;
+    int pmp_size = 0;
+    // easily misunderstood local variable 
+    target_ulong s = 0;
+    target_ulong e = 0;
+
+    for (i = 0; i < MAX_RISCV_PMPS; i++) {
+        s = pmp_is_in_range(env, i, addr);
+        e = pmp_is_in_range(env, i, addr + pmp_size - 1);
+
+        /* partially inside */
+        if ((s + e) == 1) {
+          
+        }
+
+        /* fully inside */
+        if ((s + e) == 2) {
+```
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1749 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1749
new file mode 100644
index 00000000..20bdd650
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1749
@@ -0,0 +1,20 @@
+[Riscv-fu540] UEFI cannot be started with gdb on sifive fu540 platform？
+Description of problem:
+Using qemu start UEFI on sifive fu540 platform with option： -S -s.
+```
+qemu-system-riscv64                                            \
+                -cpu sifive-u54 -machine sifive_u               \
+                -bios U540.fd                                   \
+                -m 2048 -nographic -smp cpus=2,maxcpus=2        \
+                -S -s
+```
+UEFI url is： https://github.com/tianocore/edk2.git
+Steps to reproduce:
+1. start qemu with -S -s param in one terminal
+2. riscv64-unknown-linux-gnu-gdb in other terminal
+3. in gdb terminal:
+```
+       target remove :1234
+       c
+```
+4. in qemu terminal, there has no any output ?
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1752 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1752
new file mode 100644
index 00000000..797bf10b
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1752
@@ -0,0 +1,22 @@
+QEMU bug: csrw `MIE_MEIE | MIE_MSIE | MIE_MTIE` to sie changes mie
+Description of problem:
+QEMU bug: csrw `MIE_MEIE | MIE_MSIE | MIE_MTIE` to sie changes mie.
+
+**Only csrw causes this bug. csrs/csrc have no effect.**
+Steps to reproduce:
+output from my test program: 
+```
+[firmware_main] Clear mie
+[firmware_main] mie is 0x0
+[firmware_main] sie is 0x0
+[firmware_main] Set MIE_SEIE | MIE_STIE | MIE_SSIE | MIE_MEIE for mie
+[firmware_main] mie is 0xa22
+[firmware_main] sie is 0x0
+[firmware_main] mideleg is 0x0
+[firmware_main] Set MIE_SEIE | MIE_STIE | MIE_SSIE for mideleg
+[firmware_main] mie is 0xa22
+[firmware_main] sie is 0x222
+[firmware_main] Set MIE_SSIE for sie
+[firmware_main] mie is 0x800
+[firmware_main] sie is 0x0
+```
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1793 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1793
new file mode 100644
index 00000000..ff880bfa
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1793
@@ -0,0 +1,35 @@
+getauxval(AT_HWCAP) returns different value under qemu-system-riscv64 and qemu-riscv64
+Description of problem:
+I have a test program that checks for the presence of the RISC-V Vector extension (RVV) via getauxval().
+
+```c
+#include <sys/auxv.h>
+#include <stdio.h>
+
+#define ISA_V_HWCAP (1 << ('v' - 'a'))
+
+void main() {
+  unsigned long hw_cap = getauxval(AT_HWCAP);
+  printf("RVV %s\n", hw_cap & ISA_V_HWCAP ? "detected" : "not found");
+}
+```
+
+When run inside `qemu-system-riscv64` with a 6.5-rc3 kernel where `CONFIG_RISCV_ISA_V=y` and `CONFIG_RISCV_ISA_V_DEFAULT_ENABLE=y` it correctly shows:
+
+```
+$ ./hwcap
+RVV detected
+```
+
+However when executed with `qemu-riscv64` it does not return the V bit set:
+
+```
+$ qemu-riscv64 hwcap
+RVV not found
+```
+Steps to reproduce:
+1. Boot 6.5-rc3 kernel with `CONFIG_RISCV_ISA_V=y` and `CONFIG_RISCV_ISA_V_DEFAULT_ENABLE=y`
+2. In guest run test program hwcap (source above)
+3. On host run `qemu-riscv64 hwcap`
+Additional information:
+
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1908 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1908
new file mode 100644
index 00000000..b67b8311
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1908
@@ -0,0 +1,49 @@
+8.1.0 regression: abnormal segfault in qemu-riscv64-static
+Description of problem:
+loading_from_clipboard_test of Cockatrice segfaults in qemu-riscv64-static.
+Steps to reproduce:
+1. Setup an Arch Linux riscv64 qemu-user container: https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-Development-Environment
+2. Start the container: `sudo systemd-nspawn -D ./archriscv -a -U`
+3. Build cockatrice 2.9.0 with tests in the container: https://github.com/Cockatrice/Cockatrice/releases/tag/2023-09-14-Release-2.9.0
+4. Run tests/loading_from_clipboard/loading_from_clipboard_test in the container
+Additional information:
+I have done bisection and find out that this commit caused the regression: 2d708164e0475064e0e2167bd73e8570e22df1e0
+
+qemu built from HEAD(494a6a2) is still affected by this bug.
+
+Backtrace:
+
+```
+#0  0x00007fffe849f133 in code_gen_buffer ()
+#1  0x00007ffff7b3a433 in cpu_tb_exec (cpu=0x7ffff7f71010, itb=0x7fffe849f040 <code_gen_buffer+4845587>,
+tb_exit=0x7fffffffde20) at ../qemu/accel/tcg/cpu-exec.c:457
+#2  0x00007ffff7b3aeac in cpu_loop_exec_tb (cpu=0x7ffff7f71010, tb=0x7fffe849f040 <code_gen_buffer+4845587>,
+pc=46912625654024, last_tb=0x7fffffffde30, tb_exit=0x7fffffffde20) at ../qemu/accel/tcg/cpu-exec.c:919
+#3  0x00007ffff7b3b0e0 in cpu_exec_loop (cpu=0x7ffff7f71010, sc=0x7fffffffdeb0) at ../qemu/accel/tcg/cpu-exec.c:1040
+#4  0x00007ffff7b3b19e in cpu_exec_setjmp (cpu=0x7ffff7f71010, sc=0x7fffffffdeb0)
+at ../qemu/accel/tcg/cpu-exec.c:1057
+#5  0x00007ffff7b3b225 in cpu_exec (cpu=0x7ffff7f71010) at ../qemu/accel/tcg/cpu-exec.c:1083
+#6  0x00007ffff7a53707 in cpu_loop (env=0x7ffff7f71330) at ../qemu/linux-user/riscv/cpu_loop.c:37
+#7  0x00007ffff7b5d0e0 in main (argc=4, argv=0x7fffffffe768, envp=0x7fffffffe790) at ../qemu/linux-user/main.c:999
+```
+
+```
+0x7fffe849f105 <code_gen_buffer+4845784>        jl     0x7fffe849f265 <code_gen_buffer+4846136>                                                                                                                                        │
+│    0x7fffe849f10b <code_gen_buffer+4845790>        mov    0x50(%rbp),%rbx                                                                                                                                                                 │
+│    0x7fffe849f10f <code_gen_buffer+4845794>        mov    %rbx,%r12                                                                                                                                                                       │
+│    0x7fffe849f112 <code_gen_buffer+4845797>        mov    %r12,0x70(%rbp)                                                                                                                                                                 │
+│    0x7fffe849f116 <code_gen_buffer+4845801>        movabs $0x2aaaaf9bb000,%r13                                                                                                                                                            │
+│    0x7fffe849f120 <code_gen_buffer+4845811>        mov    %r13,0x38(%rbp)                                                                                                                                                                 │
+│    0x7fffe849f124 <code_gen_buffer+4845815>        movq   $0xffffffffaf9bb000,0x60(%rbp)                                                                                                                                                  │
+│    0x7fffe849f12c <code_gen_buffer+4845823>        mov    $0xffffffffaf9bb4e0,%r13                                                                                                                                                        │
+│  > 0x7fffe849f133 <code_gen_buffer+4845830>        movzwl 0x0(%r13),%r13d                                                                                                                                                                 │
+│    0x7fffe849f138 <code_gen_buffer+4845835>        and    $0x7f,%ebx                                                                                                                                                                      │
+│    0x7fffe849f13b <code_gen_buffer+4845838>        shl    $0x7,%r13                                                                                                                                                                       │
+│    0x7fffe849f13f <code_gen_buffer+4845842>        add    %r13,%rbx                                                                                                                                                                       │
+│    0x7fffe849f142 <code_gen_buffer+4845845>        mov    %rbx,0x50(%rbp)                                                                                                                                                                 │
+│    0x7fffe849f146 <code_gen_buffer+4845849>        shl    %rbx                                                                                                                                                                            │
+│    0x7fffe849f149 <code_gen_buffer+4845852>        mov    %rbx,0x38(%rbp)                                                                                                                                                                 │
+│    0x7fffe849f14d <code_gen_buffer+4845856>        movabs $0x2aaaaf9a88e0,%r13                                                                                                                                                            │
+│    0x7fffe849f157 <code_gen_buffer+4845866>        add    %r13,%rbx                                                                                                                                                                       │
+│    0x7fffe849f15a <code_gen_buffer+4845869>        mov    %rbx,0x60(%rbp)                            
+```
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1925 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1925
new file mode 100644
index 00000000..3b8fde1f
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1925
@@ -0,0 +1,11 @@
+RISC-V 64 System Emulator fdt imporperly created after machine init is done
+Description of problem:
+In commit 49554856 the creation of FDT is moved to `virt_machine_done()`
+However, adding guest loader device requires the presence of fdt at `hw/core/guest-loader.c:50` when the fdt ptr is still 0x0.
+Thus adding of guest loader device will fail.
+Steps to reproduce:
+1. Compile Qemu with riscv64 system emulator target
+2. Compile Xen hypervisor platform (not necessary)
+3. Instruct Qemu start with virt machine and any valid guest-loader device specification.
+Additional information:
+Commit that changes order of fdt creation: 49554856f0b6f622ab6afdcc275d4ab2ecb3625c
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1945 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1945
new file mode 100644
index 00000000..0b12c8c9
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1945
@@ -0,0 +1 @@
+More than 8 cores for RISC-V generic `virt` machine
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1965 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1965
new file mode 100644
index 00000000..ebfe8d8c
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1965
@@ -0,0 +1 @@
+riscv64 semihosting not working
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1978 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1978
new file mode 100644
index 00000000..1ff6d1ca
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1978
@@ -0,0 +1,5 @@
+sifive_e : erroneous CLINT frequency
+Description of problem:
+CLINT's `mtime` updates at a clock frequency of [10 MHz](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/riscv/sifive_e.c?ref_type=heads#L228), whereas [SiFive documentation](https://cdn.sparkfun.com/assets/7/f/0/2/7/fe310-g002-manual-v19p05.pdf?_gl=1*w2ieef*_ga*MTcyNDI2MjM0Ny4xNjk2ODcwNTM3*_ga_T369JS7J9N*MTY5Njg3MDUzNy4xLjAuMTY5Njg3MDUzNy42MC4wLjA.) shows that its clock frequency is 32.768 kHz (i.e., the RTC clock).
+
+This difference leads to unexpected timing behavior. Due to the difference, it can even trigger multiple nested interrupts as the IRQ routine is not able to return before a new timer interrupt is triggered.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/1981 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1981
new file mode 100644
index 00000000..c955b369
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/1981
@@ -0,0 +1,10 @@
+wrong address of pmpaddr13 and pmpaddr14 CSRs
+Description of problem:
+In qemu\disas\riscv.c lines 2119 & 2120 it seems that there is a confusion about the correct address of the pmpaddr13 and pmpaddr14 CSRs 
+```
+line 2117   case 0x03bb: return "pmpaddr11";
+line 2118    case 0x03bc: return "pmpaddr12";
+**line 2119    case 0x03bd: return "pmpaddr14";  <--- pmpaddr13 should be here
+line 2120    case 0x03be: return "pmpaddr13";  <--- pmpaddr14 should be here**
+line 2121    case 0x03bf: return "pmpaddr15";
+```
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2074 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2074
new file mode 100644
index 00000000..7470beb4
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2074
@@ -0,0 +1,20 @@
+riscv64  cannot use the mret instruction to jump to the address corresponding to s mode
+Description of problem:
+I use coreboot to boot my linux kernel.The kernel is copied at 0x82200000,I set reg mepc 0x82200000,and set reg mstatus a00000800.
+and I use "mret" instruction so that qemu can jump to 0x82200000 and enter S mode.But some errors happened.
+It shows:
+[DEBUG]  Exception:          Instruction access fault
+[DEBUG]  Hart ID:            0
+[DEBUG]  Previous mode:      machine
+[DEBUG]  Bad instruction pc: 0x8103f7c0
+[DEBUG]  Bad address:        0x00000000
+[DEBUG]  Stored ra:          0x8103f7b8
+[DEBUG]  Stored sp:          0x82032f08
+Bad instruction pc: 0x8103f7c0 in my elf file instruction is "mret".
+So I can not jump to my kernel's load address.
+I think when I use -bios option,my qemu should in M mode.How could I can jump to my mepc address?
+Steps to reproduce:
+1.download qemu
+2.download coreboot
+Additional information:
+When I enter qemu with -bios option,I find that the reg mstatus is 0xa0000000.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2107 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2107
new file mode 100644
index 00000000..4079abfa
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2107
@@ -0,0 +1 @@
+target/riscv: zve32x/zve64x are not supported
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2114 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2114
new file mode 100644
index 00000000..75b4217b
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2114
@@ -0,0 +1 @@
+hw/char/riscv_htif.c and hw/char/sifive_uart call qemu_chr_fe_write() and ignore return value
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2137 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2137
new file mode 100644
index 00000000..c560711f
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2137
@@ -0,0 +1 @@
+RISC-V Vector Slowdowns
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2145 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2145
new file mode 100644
index 00000000..e7f3e4ea
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2145
@@ -0,0 +1,37 @@
+Issue with Graphical Interface on RISC-V Emulation in QEMU
+Description of problem:
+I am facing an issue when attempting to run Ubuntu on RISC-V architecture in QEMU with a graphical interface. Specifically, when executing the following command without the -nographic option, the operating system fails to start:
+
+```bash
+qemu-system-riscv64 -machine virt -m 2048 -smp 4 -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.bin -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf -drive file=ubuntu-22.04.3-preinstalled-server-riscv64+unmatched.img,format=raw,if=virtio
+```
+
+I have not found any examples online where QEMU is used with RISC-V architecture without the -nographic option, which raises uncertainty about the feasibility of running it with a graphical interface.
+
+Interestingly, when I run a similar command for x86_64 architecture, the operating system starts successfully with a graphical interface:
+
+```bash
+qemu-system-x86_64 -enable-kvm -m 2G -drive file=ubuntu-22.04.3-desktop-amd64.iso,format=raw -boot c -cpu host -vga std -device virtio-net-pci -device virtio-rng-pci
+```
+Steps to reproduce:
+Execute QEMU with RISC-V architecture without the -nographic option.
+
+```bash
+qemu-system-riscv64 -machine virt -m 2048 -smp 4 -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.bin -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf -drive file=ubuntu-22.04.3-preinstalled-server-riscv64+unmatched.img,format=raw,if=virtio
+```
+
+(The above command fails to start with a graphical interface)
+
+Execute QEMU with RISC-V architecture and the -nographic option.
+
+```bash
+qemu-system-riscv64 -machine virt -nographic -m 2048 -smp 4 -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.bin -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf -drive file=ubuntu-22.04.3-preinstalled-server-riscv64+unmatched.img,format=raw,if=virtio
+```
+(The above command works, but without a graphical interface)
+
+Execute QEMU with x86_64 architecture.
+
+```bash
+qemu-system-x86_64 -enable-kvm -m 2G -drive file=ubuntu-22.04.3-desktop-amd64.iso,format=raw -boot c -cpu host -vga std -device virtio-net-pci -device virtio-rng-pci
+```
+(The above command works and starts with a graphical interface)
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2203 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2203
new file mode 100644
index 00000000..6a4e7de1
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2203
@@ -0,0 +1 @@
+RISC-V RVV fractional LMUL check is wrong
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2223 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2223
new file mode 100644
index 00000000..65ef023e
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2223
@@ -0,0 +1,35 @@
+Weird behavior on RISC-V code running on QEMU
+Description of problem:
+I am currently facing some weird problems on a RISC-V project meant to run on the QEMU environment and thought that maybe someone here could give me a light on the subject. The goal is to run a project built on top of one of FreeRTOS' official demo ports that target the 'virt' QEMU board. I ran across a few weird behaviors where code execution would just hang at some point (QEMU would keep execution but the expected terminal output would never come up). I don't have sufficient knowledge to tell whether the issue is with the FreeRTOS port, the RISC-V gnu toolchain or QEMU itself, hence why I am raising my hand for help on all related channels.
+
+This [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/) contains more details and a sample project that illustrates well one of the problems I've been getting lately (I also give more context about it [here](https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1434)). It basically goes like this: the program **executes fine** when a certain code snippet is encapsulated **within a function**, but "**crashes**" (i.e. hangs) when the same snippet is placed **directly in the main code**:
+
+```c
+for(int i=0; i < NUMBER_OF_ITEMS; i++){
+    createAndPushItem(i);
+
+    // the function above does the exact same thing as the commented code below
+    // yet, the commented code does not work and will crash the program. but why??
+        
+    // int index = priorities[i];                                               
+    // void *value = (void *) getValue(i + 1);
+    // LinkedListItem_t *item = createItem(index, value);                          
+    // if(item){
+    //     push(item, &list);
+    // }
+}
+```
+
+The scope shouldn't matter at all here, since there is no local variable being used or anything like that. I have tested workarounds like removing compiling optimization (i.e. changing -Os for -O0) and using regular malloc() instead of FreeRTOS' dynamic allocation API, but all without success.  Note that even though the project is build on top of the FreeRTOS demo port, no RTOS functionality is used within this code to make it as simple as it gets.
+Steps to reproduce:
+1. clone this [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/)
+2. follow the readme to install the toolchain
+3. follow the readme to compile the program and run it
+Additional information:
+The expected output is supposed to be:
+
+![image](/uploads/462aa1a7872262df8f2588ee92dd5879/image.png)
+
+but when one decides to use the commented snippet instead of the function, the program hangs right before sorting the linked list for the first time:
+
+![image](/uploads/d2f7cc5614b293a5953e6fffa535aaca/image.png)
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2245 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2245
new file mode 100644
index 00000000..a9592084
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2245
@@ -0,0 +1 @@
+RISC-V Extensions query for QEMU System
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2262 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2262
new file mode 100644
index 00000000..23aba765
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2262
@@ -0,0 +1,199 @@
+linux-user riscv32: wait4/waitpid returns wrong value
+Description of problem:
+Background job started by bash shell in riscv32 chroot environment under qemu linux-user emulation hangs indefinitely.
+
+strace shows repeated waitid flood `waitid(P_ALL, -1, {}, WNOHANG|WEXITED|WSTOPPED|WCONTINUED, NULL) = 0`.
+Steps to reproduce:
+1. cross compile a riscv32 environment with crossdev on gentoo or other way and chroot into it.
+2. run `sleep 1000 &`
+3. run `ls`
+4. infinite hangs
+
+I have a small reproducer that I think may uncover the issue, but I am not 100% sure. I also tried running qemu with sanitizers enabled, but it produces no warning. Happy to provide a tar bar of my riscv32 rootfs if needed.
+
+<details><summary>simple_shell.c</summary>
+
+```
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <string.h>
+#include <sys/wait.h>
+#include <signal.h>
+
+#define MAX_LINE 80 /* The maximum length command */
+
+#define BACKGROUND 0
+#define FOREGROUND 1
+
+struct Job {
+    pid_t pid;
+    char command[MAX_LINE];
+    int state; // 0 for background, 1 for foreground
+};
+
+struct Job jobs[10]; // Maximum 10 background jobs
+int num_jobs = 0;
+
+void handle_signal(int signum) {
+    // Do nothing for now
+}
+
+int launch_process(char **args, int state) {
+    pid_t pid;
+    int status;
+
+    pid = fork();
+    if (pid == 0) {
+        // Child process
+        if (execvp(args[0], args) == -1) {
+            perror("Error in execvp");
+            exit(EXIT_FAILURE);
+        }
+    } else if (pid < 0) {
+        // Error forking
+        perror("Error forking");
+    } else {
+        // Parent process
+        if (state == FOREGROUND) {
+            // Wait for the child process to finish if it's foreground
+            do {
+                wait4(pid, &status, WUNTRACED, NULL);
+            } while (!WIFEXITED(status) && !WIFSIGNALED(status));
+        } else {
+            // Background process, add to jobs list
+            jobs[num_jobs].pid = pid;
+            strcpy(jobs[num_jobs].command, args[0]);
+            jobs[num_jobs].state = BACKGROUND;
+            num_jobs++;
+        }
+    }
+    return 1;
+}
+
+void bg_command(int job_number) {
+    // Send SIGCONT signal to a background job
+    if (kill(jobs[job_number].pid, SIGCONT) == -1) {
+        perror("kill");
+    } else {
+        jobs[job_number].state = BACKGROUND;
+    }
+}
+
+void fg_command(int job_number) {
+    // Bring a background job to foreground
+    if (kill(jobs[job_number].pid, SIGCONT) == -1) {
+        perror("kill");
+    } else {
+        jobs[job_number].state = FOREGROUND;
+        int status;
+        wait4(jobs[job_number].pid, &status, WUNTRACED, NULL);
+    }
+}
+
+int main(void) {
+    char *args[MAX_LINE/2 + 1]; /* command line arguments */
+    int should_run = 1; /* flag to determine when to exit program */
+    char command[MAX_LINE]; /* buffer to hold the command */
+    char *token; /* token for parsing the command */
+
+    signal(SIGINT, handle_signal); /* Ignore SIGINT for now */
+    signal(SIGTSTP, handle_signal); /* Ignore SIGTSTP for now */
+
+    while (should_run) {
+        printf("Shell> ");
+        fflush(stdout);
+        fgets(command, MAX_LINE, stdin); /* read command from stdin */
+        command[strcspn(command, "\n")] = '\0'; /* remove newline character */
+
+        if (strcmp(command, "exit") == 0) {
+            should_run = 0; /* exit the shell */
+            continue;
+        }
+
+        if (strcmp(command, "") == 0) {
+            continue; /* skip empty commands */
+        }
+
+        if (strcmp(command, "cd") == 0) {
+            char *home = getenv("HOME");
+            chdir(home);
+            continue;
+        }
+
+        if (strcmp(command, "bg") == 0) {
+            // Run the most recent background job in the background
+            bg_command(num_jobs - 1);
+            continue;
+        }
+
+        if (strcmp(command, "fg") == 0) {
+            // Bring the most recent background job to foreground
+            fg_command(num_jobs - 1);
+            continue;
+        }
+
+        token = strtok(command, " ");
+        int i = 0;
+        while (token != NULL) {
+            args[i] = token;
+            token = strtok(NULL, " ");
+            i++;
+        }
+        args[i] = NULL;
+
+        if (strcmp(args[i-1], "&") == 0) {
+            args[i-1] = NULL;
+            launch_process(args, BACKGROUND);
+        } else {
+            launch_process(args, FOREGROUND);
+        }
+
+        pid_t tmp;
+        // Check if any background jobs have finished
+        for (int j = 0; j < num_jobs; j++) {
+            if ((tmp = wait4(jobs[j].pid, NULL, WNOHANG, NULL)) > 0) {
+                printf("[%d] Done\t%s\n", j, jobs[j].command);
+                // Remove job from list
+                for (int k = j; k < num_jobs - 1; k++) {
+                    jobs[k] = jobs[k + 1];
+                }
+                num_jobs--;
+            }
+            printf("wait4 ret: %d\n", tmp);
+        }
+    }
+    return 0;
+}
+```
+
+</details>
+
+<details><summary>loop.c</summary>
+int main() {while(1){}}
+</details>
+
+1. compile simple_shell.c, statically for simplicity. `riscv32-unknown-gnu-gcc simple_shell.c --static -o shell_riscv32`
+2. compile loop.c to riscv32 or x86_64 (x86_64 is simpler with same result) `gcc loop.c --static -o loop`
+3. run shell with qemu user
+```
+qemu-user-riscv32 ./shell_riscv32
+shell> ./loop &
+[0] Done        ./sleep_riscv32
+wait4 ret: 98298
+```
+where it is supposed to return 0 on riscv64 or x86
+Additional information:
+More context:
+This was found on the side when I was trying to track down a riscv32 infinite loop issue with linux-user emulation that has been blocking riscv32 gentoo bootstrap. I am not certain if my reproducer does reproduced that issue, but feels it is close. strace attached to the process repeats,
+```
+waitid(P_ALL, -1, {}, WNOHANG|WEXITED, NULL) = 0
+rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0
+rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0
+rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
+rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0
+rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0
+rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
+waitid(P_ALL, -1, ^Cstrace: Process 237805 detached
+```
+It appears to be first mentioned here <https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg05475.html>.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2269 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2269
new file mode 100644
index 00000000..cd522369
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2269
@@ -0,0 +1,41 @@
+RISC-V exit via sifive_test does not work in scripts with -serial stdio
+Description of problem:
+
+Steps to reproduce:
+1. Create assembly file `hello.s`:
+```as
+.section .text
+.globl _start
+_start: csrr t0, mhartid
+        bnez t0, _start
+        li t0, 0x100000
+        li t1, 0x5555
+        sw t1, 0(t0)
+halt:   j halt
+```
+2. Create linker script `link.ld`:
+```ld
+OUTPUT_ARCH( "riscv" )
+ENTRY(_start)
+SECTIONS
+{
+    . = 0x80000000;
+}
+```
+3. Create runner script `./run.sh` (don't forget to `chmod +x`)
+```sh
+#!/usr/bin/env bash
+timeout 10 qemu-system-riscv64 -M virt -display none -serial stdio -bios none -kernel hello
+```
+4. Compile into executable:
+```sh
+riscv64-unknown-elf-gcc -c -mcmodel=medany -fvisibility=hidden -nostartfiles -march=rv64g -mabi=lp64 -o hello.o hello.s
+riscv64-unknown-elf-ld hello.o -nostdlib -T link.ld -o hello
+```
+5. Dot-source the script - it will immediately exit cleanly
+6. Execute the script - it will timeout with exit code 124
+7. Execute the script with redirected stdin, e.g. `./run.sh < ./run.sh` or `echo | ./run.sh` - it will immediately exit cleanly
+Additional information:
+This issue happens only with `-serial stdio`. Using `chardev:file` or `chardev:null` does not reproduce the issue. Process substitution like `<(echo 'test')` does not seem to work. `cat | ./run.sh` will wait until any line is send, then exit cleanly. This is mainly an issue when using helper test scripts which want to interact with user, as proper CI/UT would redirect serial anyways.
+
+I have noticed similar behavior with other RISC-V UART device - when running from scripts, there is no output, as if QEMU was waiting for something, even if there is only UART TX, not RX. It does not matter if I actually type in anything or not.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2286 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2286
new file mode 100644
index 00000000..3909158f
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2286
@@ -0,0 +1 @@
+QEMU RISC-V TCG: amo insn fault does not throw AMO fault
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2332 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2332
new file mode 100644
index 00000000..a7779754
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2332
@@ -0,0 +1,29 @@
+Riscv semihosting arguments parsing issue
+Description of problem:
+When executing a bare metal kernel in semihosting mode with "argv" arguments provided through "-append" or "-semihostgin-config", recovering the arguments will read out-of-bound memory in the guest and often make the emulation crash through a hard fault.
+Steps to reproduce:
+1. Compile the simplest "kernel" in semihosting mode, e.g. test.c containing:
+
+   `#include <stdio.h>` 
+
+   `#include <stdlib.h>`
+
+   `int main(int argc, char *argv[])` 
+
+   `{ unsigned int i; printf("[+] Test OK!\n"); for(i = 0; i < argc; i++){ printf("Arg %d is '%s'\n", i, argv[i]); } return 0; }` 
+2. One can compile the previous example under Debian with 
+
+   `riscv64-unknown-elf-gcc -static -fPIC -march=rv64imac -mabi=lp64 -specs=picolibc.specs --crt0=semihost --oslib=semihost -Triscv_layout.ld test.c -o test`
+
+   This supposes the bare metal cross-toolchain `binutils-riscv64-unknown-elf` to be installed, as well as the standard library picolibc `picolibc-riscv64-unknown-elf` that supports semihosting.
+
+   The `riscv_layout`.ld file contains:
+
+   `__flash = 0x80000000; __flash_size = 0x00080000; __ram = 0x80080000; __ram_size = 0x40000; __stack_size = 1k; INCLUDE picolibc.ld`
+3. Execute the command line:
+   - `qemu-system-riscv64 -semihosting-config enable=on -monitor none -serial none -nographic -machine sifive_u,accel=tcg -no-reboot -bios none -kernel /tmp/test -append "10 20"`
+4. Observe the following as an example of the bug:
+
+   `[+] Test OK! Arg rg A is '/tmp/test0' Arg Arg 2 is 'RISCV fault x0 -2146959259z' ero 0x0000000000000000 x1 ra 0x0000000080000e94 x2 sp 0x00000000800bfea0 x3 gp 0x0000000080080820 x4 tp 0x0000000080080028 x5 t0 0x00000000800019a2 x6 t1 0x000000000000002a x7`
+Additional information:
+The same bug seems to affect risv32 and riscv64 system emulators. The semihosting part seems to work well when there is no access to the "argv" arguments.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2422 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2422
new file mode 100644
index 00000000..ac63657f
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2422
@@ -0,0 +1,69 @@
+`vill` not set after reserved `vsetvli` instruction usage
+Description of problem:
+The ["AVL encoding" section of the RISC-V V Spec 1.0](https://github.com/riscv/riscv-isa-manual/blob/main/src/v-st-ext.adoc#avl-encoding) states that a `vsetvli  x0,x0,...` that changes VLMAX is reserved and "Implementations may set `vill`" in this case. QEMU does not set `vill` in this case. Doing so would help detect code generation issues and non-portable code.
+
+Here is the quote from the spec:
+
+> When `rs1=x0` and `rd=x0`, the instruction operates as if the current
+> vector length in `vl` is used as the AVL, and the resulting value is
+> written to `vl`, but not to a destination register.  This form can
+> only be used when VLMAX and hence `vl` is not actually changed by the
+> new SEW/LMUL ratio.  Use of the instruction with a new SEW/LMUL ratio
+> that would result in a change of VLMAX is reserved.
+> Use of the instruction is also reserved if `vill` was 1 beforehand.
+> Implementations may set `vill` in either case.
+
+Note, I have not checked QEMU's behaviour for the other case mentioned in the quote: "Use of the instruction is also reserved if `vill` was 1 beforehand".
+Steps to reproduce:
+1. Create `test.c`
+```C
+#include <assert.h>
+
+/* Position of vill in vtype.  */
+
+#define VILL_BIT (__riscv_xlen - 1)
+
+/* Return true if vill is 1.  */
+
+int vill_set_p ()
+{
+  __UINT64_TYPE__ vtype;
+  asm volatile ("csrr %0, vtype" : "=r"(vtype));
+
+  return (vtype >> VILL_BIT) & 1;
+}
+
+/* Return true if vill is 0.  */
+
+int vill_clear_p ()
+{
+  return !vill_set_p ();
+}
+
+int main ()
+{
+  int vl;
+
+  assert (vill_clear_p ());
+
+  /* Valid: vl = VLMAX.  */
+  asm volatile ("vsetvli %0,zero,e64,m8,ta,ma\n" : "=r"(vl));
+  assert (vill_clear_p ());
+
+  /* Valid: vl and VLMAX not changed.  */
+  asm volatile ("vsetvli zero,zero,e64,m8,ta,ma\n");
+  assert (vill_clear_p ());
+
+  /* Reserved: Reduce VLMAX.  */
+  asm volatile ("vsetvli zero,zero,e64,m1,ta,ma\n");
+  assert (vill_set_p ());
+
+  return 0;
+}
+```
+2. Build `test.c` with `riscv32-unknown-elf-gcc test.c -o test -march=rv64gcv -mabi=lp64d`
+3. Run qemu with `qemu-riscv64 -cpu rv64,v=true test`
+4. The final assertion fails because executing the reserved `vsetvli` did not set `vill`
+```
+assertion "vill_set_p ()" failed: file "test.c", line 40, function: main
+```
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2462 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2462
new file mode 100644
index 00000000..18381389
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2462
@@ -0,0 +1,39 @@
+QEMU SIFIVE reading from stdin hangs
+Description of problem:
+I have a simple test program (C and ASM) that reads from stdin.  When i was using the qemu provided by Ubuntu, QEMU emulator version 8.0.4 (Debian 1:8.0.4+dfsg-1ubuntu3.23.10.5), my test was working, and was able to read bytes from stdin.
+
+Using the latest Qemu from git, breaks my test.  I can still print, but now reading hangs, like its always waiting for input but never getting it.
+
+My guess is that this commit breaks my code:
+https://github.com/qemu/qemu/commit/6ee7ba1b8a10bd8eb1d3b918eaaf9f832a51adb4
+
+Before the above commit, `qemu_chr_fe_set_handlers` was being called, and that is what allowed the default behavior of reading from stdin is on by default?
+
+from sifive_uart.c
+```
+    qemu_chr_fe_set_handlers(&s->chr, sifive_uart_can_rx, sifive_uart_rx,
+                             sifive_uart_event, sifive_uart_be_change, s,
+                             NULL, true);
+```
+Steps to reproduce:
+1. compile simple C program that calls `read` reading a single byte from stdin
+2. do not initialize UART options
+3. run in QEMU, send input, hangs.
+Additional information:
+Other examples online, like riscv-probe, use a uart init function like below:
+```
+static void sifive_uart_init()
+{
+    uart = (int *)(void *)getauxval(SIFIVE_UART0_CTRL_ADDR);
+    uint32_t uart_freq = getauxval(UART0_CLOCK_FREQ);
+    uint32_t baud_rate = getauxval(UART0_BAUD_RATE);
+    uint32_t divisor = uart_freq / baud_rate - 1;
+    uart[UART_REG_DIV] = divisor;
+    uart[UART_REG_TXCTRL] = UART_TXEN;
+    uart[UART_REG_RXCTRL] = UART_RXEN;
+    uart[UART_REG_IE] = 0;
+}
+```
+
+However, when I was using QEMU 8.0.4, i did not have to write a function like above to init UART, because stdin and stdout were working out of the box.
+Below is my C and ASM:
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2463 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2463
new file mode 100644
index 00000000..f00ca2d5
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2463
@@ -0,0 +1,9 @@
+allow sifive_e to use more RAM
+Description of problem:
+For users like me that are still learning RISC bare-metal assembly, searching online you will find many tutorials and examples using sifive_e with Qemu, so it is the easy way to get started.
+
+I quickly ran into crashes with my tests because I did not realize that sifive_e is limited to 16K of RAM.
+I realize the 16K limit is hard coded so that it matches the real hardware, but that makes it very hard to run a variety of tests.
+Additional information:
+My fork of Qemu changes sifive_e to allow 256MB.
+https://github.com/panjea/qemu/commit/97cb89d778ebe3407a969b8282e2e7adb4be2971
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2467 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2467
new file mode 100644
index 00000000..ca27d51f
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2467
@@ -0,0 +1,31 @@
+OpenSBI 1.5 packaged in QEMU 9.0.50 fails to support poweroff with 'spike' board
+Steps to reproduce:
+Build upstream U-Boot:
+
+- git clone https://source.denx.de/u-boot/u-boot.git
+- cd u-boot
+- make qemu-riscv64_smode_defconfig
+- CROSS_COMPILE=riscv64-linux-gnu- make
+
+Run U-Boot and execute poweroff command
+
+- qemu-system-riscv64 -kernel u-boot.bin
+- poweroff
+
+Poweroff fails.
+
+When building upstream OpenSBI v1.5 with 
+
+- git clone https://github.com/riscv-software-src/opensbi.git
+- cd opensbi
+- git reset --hard v1.5
+- CROSS_COMPILE=riscv64-linux-gnu- make PLATFORM=generic
+
+and then running
+
+- qemu-system-riscv64 -bios fw_dynamic.bin -kernel u-boot.bin
+- poweroff
+
+poweroff succeeds.
+
+Please, distribute an unpatched OpenSBI v1.5 with QEMU.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2486 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2486
new file mode 100644
index 00000000..6ae208c8
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2486
@@ -0,0 +1,12 @@
+RISC-V Regression: QEMU_CPU=f=false,zfinx=true gives misleading error message
+Description of problem:
+The f extension looks like it should be toggle-able using qemu_cpu since it doesn't throw error messages when specified.
+Disabling the extension using f=false does not actually disable it as shown by the zfinx error message.
+Eg. Unsupported extension is explicitly rejected
+```
+> QEMU_CPU=rv64,j=false ./qemu-riscv64 test.out
+qemu-riscv64: can't apply global rv64-riscv-cpu.j=false: Property 'rv64-riscv-cpu.j' not found
+```
+Steps to reproduce:
+1. Compile any riscv binary like: `int main() {}`
+2. Execute using `QEMU_CPU=rv64,zfinx=true,f=false ./qemu-riscv64 test.out`
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2543 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2543
new file mode 100644
index 00000000..f1390661
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2543
@@ -0,0 +1,11 @@
+QEMU UEFI for riscv64 failed to load my DIY bootloader due to unknown reason
+Steps to reproduce:
+1. [ProblematicBootLoader.zip](/uploads/21fcff0052dc2dd95bf4bba3f6ec8fb8/ProblematicBootLoader.zip) unpack this zipped file,create a fat.img which contains FAT32 file system,and then move the unpacked file in the zip to /EFI/BOOT/bootriscv64.efi.After that using xorriso to pack it.
+2. Load the cdrom in libvirt(virt-manager) using SCSI/USB
+3. Then wait for seconds and error will show(I don't why STORE_ACCESS_PAGE_FAULT occurs)
+Additional information:
+My full source code is in https://github.com/TYDQSoft/UEFIPascalOS.
+
+You can get the instruction in the github to compile this problematic bootloader for testing.
+
+x64,AArch64 was tested successfully,but riscv64 is always problematic in evert test times.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2558 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2558
new file mode 100644
index 00000000..9d2c676b
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2558
@@ -0,0 +1,65 @@
+riscv64: Ubuntu doesn't boot with EDK2, although it boots with u-boot
+Description of problem:
+Ubuntu doesn't boot with `edk2-riscv-code.fd`:
+
+```bash
+wget https://cloud-images.ubuntu.com/noble/20240822/noble-server-cloudimg-riscv64.img
+
+qemu-system-riscv64 -M virt -m 2048 -nographic -hda noble-server-cloudimg-riscv64.img \
+  -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/qemu/edk2-riscv-code.fd
+```
+
+
+```
+Loading Linux 6.8.0-41-generic ...
+Loading initial ramdisk ...
+InstallProtocolInterface: 4006C0C1-FCB3-403E-996D-4A6C8724E06D FDB3F3C8
+InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B FDB3F380
+[Security] 3rd party image[0] can be loaded after EndOfDxe: MemoryMapped(0x2,0xF9CC4000,0xFC194000).
+InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B FF29C2C0
+Loading driver at 0x000F732C000 EntryPoint=0x000F817FEA6 
+InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF FF29CC18
+ProtectUefiImageCommon - 0xFF29C2C0
+  - 0x00000000F732C000 - 0x0000000002598000
+SetUefiImageMemoryAttributes - 0x00000000F732C000 - 0x0000000000001000 (0x0000000000004000)
+SetUefiImageMemoryAttributes - 0x00000000F732D000 - 0x0000000000FFF000 (0x0000000000020000)
+SetUefiImageMemoryAttributes - 0x00000000F832C000 - 0x0000000001598000 (0x0000000000004000)
+TimerDriverSetTimerPeriod(0x0)
+SetUefiImageMemoryAttributes - 0x00000000FFEC7000 - 0x000000000000C000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFEBC000 - 0x000000000000B000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFEAC000 - 0x0000000000010000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFEA1000 - 0x000000000000B000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFE84000 - 0x000000000001D000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFE79000 - 0x000000000000B000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFE6E000 - 0x000000000000B000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFE63000 - 0x000000000000B000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFE59000 - 0x000000000000A000 (0x0000000000000000)
+(hangs here)
+```
+
+The same disk image still boots when `uboot.elf` is specified as the kernel image:
+
+```bash
+wget https://github.com/lima-vm/u-boot-qemu-mirror/releases/download/2023.07%2Bdfsg-1/qemu-riscv64_smode_uboot.elf
+
+qemu-system-riscv64 -M virt -m 2048 -nographic -hda noble-server-cloudimg-riscv64.img \
+  -kernel qemu-riscv64_smode_uboot.elf
+```
+
+```
+Loading Linux 6.8.0-41-generic ...
+Loading initial ramdisk ...
+syscon-poweroff poweroff: pm_power_off already claimed for sbi_srst_power_off
+-.mount
+etc-machine\x2did.mount
+systemd-journald.service
+dev-hugepages.mount
+...
+Ubuntu 24.04 LTS ubuntu ttyS0
+
+ubuntu login:
+```
+Steps to reproduce:
+See above
+Additional information:
+
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2573 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2573
new file mode 100644
index 00000000..5b61b240
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2573
@@ -0,0 +1,9 @@
+RISC-V: Executing floating point instruction in VS mode under KVM acceleration leads to crash
+Description of problem:
+Executing `fcvt.d.w fa5,a5` in VS mode leads to crash.
+Steps to reproduce:
+1. Download the Ubuntu 24.10 image https://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/oracular-preinstalled-server-riscv64.img.xz
+2. On your amd64 system launch a VM using -accel tcg
+3. Inside the VM launch a new VM using -accel kvm with the payload mentioned above
+Additional information:
+For more details see https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2077731
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2627 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2627
new file mode 100644
index 00000000..a79fc580
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2627
@@ -0,0 +1 @@
+Possible incorrect exception order in RISC-V
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2655 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2655
new file mode 100644
index 00000000..f23243e2
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2655
@@ -0,0 +1,39 @@
+A problem in target/riscv/vector_helper.c: vext_ldff()
+Description of problem:
+I‘m confused about a behavior in function vext_ldff() in target/riscv/vector_helper.c:
+```
+static inline void
+vext_ldff(...)
+{
+...
+    for (i = env->vstart; i < env->vl; i++) {
+...
+        if (i == 0) {
+            probe_pages(env, addr, nf << log2_esz, ra, MMU_DATA_LOAD);
+        } else {
+...
+                flags = probe_access_flags(env, addr, offset, MMU_DATA_LOAD,
+                                           mmu_index, true, &host, 0);
+...
+                if (flags & ~TLB_WATCHPOINT) {
+                    vl = i;
+                    goto ProbeSuccess;
+                }
+...
+        }
+    }
+ProbeSuccess:
+...
+}
+```
+If the current instruction has a memory callback by plugin, the function probe_access_flags() will return TLB_MMIO when the page is exist.
+
+In this case, the function will always set vl to 1, goto ProbeSuccess, and only load the first element. Does it meet expectations? 
+
+This problem occurred in both linux-user mode and full-system mode.
+
+Maybe we can add extra parameter to probe_access_flags(), in order to change the behavior of inner functions.
+Steps to reproduce:
+1. Make a binary with instruction vle(x)ff.v, what I am using is https://github.com/chipsalliance/riscv-vector-tests.
+2. Write a plugin to add memory callbacks.
+3. Observe the behavior of the function.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2672 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2672
new file mode 100644
index 00000000..9f5bd845
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2672
@@ -0,0 +1,20 @@
+Skipping a jal instruction in riscv64 baremetal emulation
+Description of problem:
+The binary contains an illegal instruction after a jal. Normally the jal should be taken but the illegal instructi[aia_tests2.elf](/uploads/b8b646b01d7bcc15b51c36ddbffacac7/aia_tests2.elf)on next to the jal is executed generating and illegal instruction exception:
+
+```
+0x80006070:  00200513          addi                    a0,zero,2
+0x80006074:  89cff0ef          jal                     ra,-3940                # 0x80005110
+
+----------------
+IN: _Z15int_switch_modehh
+0x80006078:  0000              illegal                 
+
+----------------
+IN: mtvec_table
+0x8000e600:  64d0406f          j                       20044                   # 0x8001344c
+```
+Steps to reproduce:
+1. Execute the same binary with QEMU.
+Additional information:
+
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2673 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2673
new file mode 100644
index 00000000..68da4fd9
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2673
@@ -0,0 +1,5 @@
+qemu-system-riscv32 does not pass official riscv-tests
+Description of problem:
+I run riscv-tests using the above command and find qemu raises Illegalinstruction when `sret` in the machine mode.Therefore qemu cannot pass the rv32ui-v-and test.
+Additional information:
+The tests https://github.com/riscv-software-src/riscv-tests
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2730 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2730
new file mode 100644
index 00000000..b8960d50
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2730
@@ -0,0 +1,10 @@
+riscv Calculation error！
+Steps to reproduce:
+The following command will produce an error output
+
+```asm
+	lui s0, 0x80000
+	lw a1, -48(s0)
+```
+The value of a1 becomes 0xffffffff
+![qemu-error](/uploads/76a580b5b9acf1f8aea90880ed8deb9e/qemu-error.gif)
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2763 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2763
new file mode 100644
index 00000000..99f463f5
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2763
@@ -0,0 +1,24 @@
+RISC-V APLIC emulation: interrupt pending state of direct-delivery level-triggered interrupts is wrong after masking
+Description of problem:
+According to the APLIC specification, the interrupt pending state of a level-triggered interrupt in direct delivery mode should always match the (rectified) input signal:
+
+> When an interrupt domain is in direct delivery mode, the pending bit for a level-sensitive source is always just a copy of the rectified input value.
+
+(From Section 4.7 "Precise effects on interrupt-pending bits" of the specification. See also the more detailed paragraph starting with "If the 
+ source mode is Level1 or Level0 and the interrupt domain is configured in direct delivery mode [...]".)
+
+However, **this is not true in Qemu's emulation**. In particular, in some situations, **a level-triggered interrupt in direct delivery mode can be raised even though the rectified input signal is off**.
+Steps to reproduce:
+1. Set `-machine virt,acpi=off,aia=aplic` to use AIA without IMSIC.
+2. Program APLIC to direct delivery. Program some level triggered interrupt (e.g., an interrupt of a PCIe ECAM controller).
+4. Wait until the IRQ is raised by a device (i.e., `claimi` returns the IRQ).
+5. Mask the interrupt by writing to `clrie`.
+6. Clear the interrupt at the device level.
+7. The state of Qemu's APLIC registers is now:
+   ```
+   Rectified input = 0 (correct)
+   Pending = 1 (incorrect)
+   topi = 0 (correct)
+   ```
+
+Furthermore, if `setie` is written to unmask the IRQ in this situation, the IRQ is raised (in `topi` / `claimi`) despite the signal being off.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2787 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2787
new file mode 100644
index 00000000..a403a165
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2787
@@ -0,0 +1,13 @@
+Opentitan timer layout incorrect
+Description of problem:
+It looks as if some of the timer register offsets here are incorrect:
+
+https://gitlab.com/qemu-project/qemu/-/blob/master/hw/timer/ibex_timer.c?ref_type=heads#L37
+
+Compare with:
+
+https://opentitan.org/book/hw/ip/rv_timer/doc/registers.html
+
+I suspect they're out of date. The documentation link on line 7 is not working anymore - the current documentation URL for Opentitan is the one just given.
+
+It might also make sense to rename this file `opentitan_timer.c`, instead of  `ibex_timer.c`. The timer is an Opentitan hardware IP block, rather than a feature of the Ibex CPU.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2796 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2796
new file mode 100644
index 00000000..07f66a8c
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2796
@@ -0,0 +1,7 @@
+Opentitan Timer ignores COMPARE_UPPER0/COMPARE_LOWER0
+Description of problem:
+In a bare metal application, running on an emulated Opentitan board, if you set a timer interrupt threshold by writing to `rv_timer.COMPARE_UPPER0` and `rv_timer.COMPARE_LOWER0` before writing to `rv_timer.CTRL` to start the timer, then the interrupt does not fire. If you write to the `COMPARE_*` registers *after* starting the timer by writing to `CTRL`, then the interrupt fires correctly.
+
+I think the explanation is that [ibex_timer_update_irqs](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/timer/ibex_timer.c?ref_type=heads#L61) has an early return if `rv_timer.CTRL` is not set. As a result, although writes to `COMPARE_*` always call `ibex_timer_update_irqs`, they don't have their intended side-effects before `CTRL` is unset.
+Steps to reproduce:
+Write to `rv_timer.COMPARE_UPPER0` and `rv_timer.COMPARE_LOWER0` before you have set `rv_timer.CTRL`. Observe that no timer interrupt occurs.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2808 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2808
new file mode 100644
index 00000000..0782f1a6
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2808
@@ -0,0 +1 @@
+Links to the RISC-V IOMMU Architecture Specification are broken in the docs
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2828 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2828
new file mode 100644
index 00000000..0c17ead3
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2828
@@ -0,0 +1,3 @@
+Potential issues at Interrupt filtering and virtual interrupts for supervisor level (RISC-V AIA)
+Description of problem:
+I am working on RISC-V Advanced Interrupt Architecture (AIA) compliance tests for our RISC-V core. These tests pass on our hardware implementation but fail when running on QEMU. There are several points where the tests fail while running in QEMU:
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2885 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2885
new file mode 100644
index 00000000..b2876daa
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2885
@@ -0,0 +1 @@
+Unable to increase CPU's for existing RISCV VM
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2930 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2930
new file mode 100644
index 00000000..1dcf88bf
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2930
@@ -0,0 +1 @@
+Versions after QEMU9.0 cannot boot vxworks on sifive_u
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/2957 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2957
new file mode 100644
index 00000000..a15e2427
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/2957
@@ -0,0 +1,28 @@
+qemu-system-riscv32: Some ROM regions are overlapping
+Description of problem:
+Booting the image produces:
+```
+qemu-system-riscv32: Some ROM regions are overlapping
+These ROM regions might have been loaded by direct user request or by default.
+They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory.
+Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses.
+
+The following two regions overlap (in the memory address space):
+  output/images/fw_jump.elf ELF program header segment 1 (addresses 0x0000000000000000 - 0x00000000000278cc)
+  mrom.reset (addresses 0x0000000000001000 - 0x0000000000001028)
+```
+Steps to reproduce:
+1. `make qemu_riscv32_virt_defconfig`
+2. `make`
+3. `qemu-system-riscv32 \
+-M virt -nographic \
+-bios output/images/fw_jump.elf \
+-kernel output/images/Image \
+-append "root=/dev/vda ro" \
+-drive file=output/images/rootfs.ext2,format=raw,id=hd0 \
+-device virtio-blk-device,drive=hd0 \
+-netdev user,id=net0 -device virtio-net-device,netdev=net0`
+Additional information:
+Changing `-bios output/images/fw_jump.elf` to `-bios output/images/fw_jump.bin` or `-bios output/images/fw_dynamic.bin` resolves the issue.
+
+Similar issue observed elsewhere, e.g. here [https://github.com/riscv-software-src/opensbi/issues/372](https://github.com/riscv-software-src/opensbi/issues/372)
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/435 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/435
new file mode 100644
index 00000000..86169da4
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/435
@@ -0,0 +1 @@
+RISC-V: Support more cores
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/47 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/47
new file mode 100644
index 00000000..e73bd255
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/47
@@ -0,0 +1 @@
+A typo in target/riscv/insn32-64.decode
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/493 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/493
new file mode 100644
index 00000000..6af1faa6
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/493
@@ -0,0 +1,7 @@
+RISC-V: Setting mtimecmp to -1 immediately triggers an interrupt
+Description of problem:
+When setting mtimecmp to -1, which should set a timer infinitely far in the future, a timer interrupt is triggered immediately. This happens for most values over 2^61. It is the same for both 32-bit and 64-bit, and for M-mode writing to mtimecmp directly and S-mode using OpenSBI.
+
+I have looked through the source code, and the problem is in the function `sifive_clint_write_mtimecmp`, in the file `/hw/intc/sifive_clint.c`. First, the muldiv64 multiplies diff with 100, causing an overflow (at least for -M virt, other machines might use a different timebase_freq). Then, the unsigned `next` is passed to `timer_mod`, which takes a signed integer. In `timer_mod_ns_locked` the value is set to `MAX(next, 0)`, which means that if the MSB of `next` was set, the interrupt happens immediately. This means that it is impossible to set timers more than 2^63 nanoseconds in the future.
+
+This problem basically only affects programs which disable timer interrupts by setting the next one infinitely far in the future. However, the SBI doc specifically says that this is a valid approach, so it should be supported. Using the MSB doesn't work without changing code functionality in QEMU, but it should be sufficient to cap `next` at the maximum signed value.
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/529 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/529
new file mode 100644
index 00000000..093ecf9d
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/529
@@ -0,0 +1,4 @@
+qemu-system-riscv64 hard lockup on non-stdio serial output
+Additional information:
+u-boot pre-compiled firmware: (directory contains all git revisions, build flags, etc)
+https://github.com/haiku/firmware/tree/master/u-boot/riscv64/qemu
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/53 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/53
new file mode 100644
index 00000000..5702528e
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/53
@@ -0,0 +1 @@
+RISC-V Disassembler/translator instruction decoding disagreement
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/585 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/585
new file mode 100644
index 00000000..860f3efa
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/585
@@ -0,0 +1 @@
+mret trigger exception when pmp equals false
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/639 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/639
new file mode 100644
index 00000000..9fd9e280
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/639
@@ -0,0 +1 @@
+Crash using riscv.shakti.cclass.soc device
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/783 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/783
new file mode 100644
index 00000000..fed16efa
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/783
@@ -0,0 +1,3 @@
+risc-v: provide CPU without MMU
+Additional information:
+
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/836 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/836
new file mode 100644
index 00000000..ddee36ec
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/836
@@ -0,0 +1,85 @@
+qemu-riscv32: Syscall LSEEK returns -14 (EFAULT)
+Description of problem:
+The lseek() system call returns -14 (EFAULT) if the file descriptor is correct,
+which it should never do (According to the lseek(2) man page).
+
+Here is some demonstrative code:
+```
+/* System Call numbers, according to https://github.com/riscv-software-src/riscv-pk/blob/master/pk/syscall.h */
+.set SYS_OPENAT,  0x38
+.set SYS_CLOSE,   0x39
+.set SYS_LSEEK,   0x3e
+.set SYS_READ,    0x3f
+.set SYS_WRITE,   0x40
+.set SYS_EXIT,    0x5d
+
+.set SEEK_CUR,    1
+
+/* According to https://elixir.bootlin.com/linux/v5.16.2/C/ident/AT_FDCWD */
+.set AT_FDCWD,    (-100)
+
+.section .text
+.global _start
+_start:
+
+/* Open the file with SYS_OPENAT, because SYS_OPEN does not exist on riscv32 for some reason.
+   Effectively:
+   s0 = open(argv[1], 0, 0644); */
+li a7, SYS_OPENAT
+li a0, AT_FDCWD
+lw a1, 8(sp)
+li a2, 0
+li a3, 0644
+ecall
+
+/* Error checking. This succeeds. */
+blt a0, zero, unrelated_error
+
+mv s0, a0
+
+/* The broken lseek() call.
+   Same also happens no matter the position in the file.
+   Effectively:
+   lseek(s0, 0, SEEK_CUR); */
+li a7, SYS_LSEEK
+mv a0, s0
+li a1, 0
+li a2, SEEK_CUR
+ecall
+
+/* XXX: lseek() returns -14 */
+blt a0, zero, lseek_error
+
+/* Close the file. */
+li a7, SYS_CLOSE
+mv a0, s0
+ecall
+
+/* Error checking. This also succeeds. */
+blt a0, zero, unrelated_error
+
+/* exit(0); */
+li a7, SYS_EXIT
+li a0, 0
+ecall
+
+/* exit(-return_value); */
+lseek_error:
+li a7, SYS_EXIT
+sub a0, zero, a0
+ecall
+
+unrelated_error:
+li a7, SYS_EXIT
+li a0, 128
+ecall
+```
+Steps to reproduce:
+1. riscv32-unknown-linux-gnu-as test.s -o test.o
+2. riscv32-unknown-linux-gnu-ld test.o
+3. qemu-riscv32 ./a.out test
+4. echo $? # This returns 14
+Additional information:
+Complete test setup:
+
+[test.tgz](/uploads/af68c9a5236628a9c6f31f2ce94e2f04/test.tgz)
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/904 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/904
new file mode 100644
index 00000000..440aaf90
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/904
@@ -0,0 +1,16 @@
+RISC-V: Cannot set SEIP bit of mip csr register in M mode
+Description of problem:
+
+Steps to reproduce:
+1.   run assembly instructions **in M mode**: 
+```
+not t0, x0    // set t0 to 0b11..11
+csrs mip, t0  // write mip with t0, mip registers are WARL(Write Any Values, Reads Legal Values)
+csrr t1, mip  // read value from mip to t1
+```
+2.   GDB enters the command `display/z $t1` to see that the content of the t1 register is 0x466, which means that the SEIP bit of mip is not set.
+3.   According to page 47 of [riscv-privileged-20211203](https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf), `SEIP is writable in mip`.
+4.   According to page 81 of the same manual,`If implemented, SEIP is read-only in sip`.
+5.   However, the above code and results show that the SEIP bit of mip cannot be set by software **in M mode**.
+Additional information:
+
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/942 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/942
new file mode 100644
index 00000000..5c08a561
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/942
@@ -0,0 +1 @@
+No TPM support for riscv64 in QEMU
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/955 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/955
new file mode 100644
index 00000000..71714d67
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/955
@@ -0,0 +1 @@
+support multiple UARTs in qemu-riscv-virt by default
diff --git a/gitlab/issues_text/target_riscv/host_missing/accel_missing/992 b/gitlab/issues_text/target_riscv/host_missing/accel_missing/992
new file mode 100644
index 00000000..9452adce
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_missing/accel_missing/992
@@ -0,0 +1,20 @@
+qemu-system-riscv64: Some ROM regions are overlapping When memory set <= 16
+Description of problem:
+
+Steps to reproduce:
+1. Build the qemu
+2. run `./build/riscv64-softmmu/qemu-system-riscv64 --nographic -machine virt -m 16`
+3. got error message:
+```
+qemu-system-riscv64: Some ROM regions are overlapping
+These ROM regions might have been loaded by direct user request or by default.
+They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory.
+Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses.
+
+The following two regions overlap (in the memory address space):
+  /home/shiroko/Developments/qemu/build/pc-bios/opensbi-riscv64-generic-fw_dynamic.bin (addresses 0x0000000080000000 - 0x0000000080019b50)
+  fdt (addresses 0x0000000080000000 - 0x0000000080100000)
+```
+Additional information:
+Using `./build/riscv64-softmmu/qemu-system-riscv64 --nographic -machine virt -m 17` could bootup and seen OpenSBI messages.
+This problem appears on qemu-system-riscv32 too.
diff --git a/gitlab/issues_text/target_riscv/host_x86/accel_missing/1911 b/gitlab/issues_text/target_riscv/host_x86/accel_missing/1911
new file mode 100644
index 00000000..07fb1109
--- /dev/null
+++ b/gitlab/issues_text/target_riscv/host_x86/accel_missing/1911
@@ -0,0 +1,40 @@
+abnormal segfaults inside qemu-system-riscv64
+Description of problem:
+3 tests of Cockatrice segfaults in qemu-system-riscv64 emulator. This is similar to a regression of qemu-riscv64-static I reported: #1908.
+But for qemu-system-riscv64, it doesn't looks like a recent regression because qemu 7.2.1 also fails.
+Steps to reproduce:
+To save the time on reproducing this bug, [I uploaded the zstd compressed qcow2 image to google drive](https://drive.google.com/file/d/1-2Wtmq4MlGvTLjmQ7P5vAvNlWg8--jjT/view?usp=sharing). It contains the whole environment, cockatrice source code and built tests.
+
+The password of the root user is `archriscv`.
+
+1. Setup Arch Linux riscv environment: https://github.com/CoelacanthusHex/archriscv-scriptlet https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-using-qemu-system
+2. Start it(with the commandline above, in the boot menu, choose `2:      Linux linux (fallback initramfs)`) and building cockatrice with tests in it. 
+3. Run tests (/root/Cockatrice/build/tests/loading_from_clipboard/loading_from_clipboard_test, /root/Cockatrice/build/tests/carddatabase/filter_string_test, /root/Cockatrice/build/tests/carddatabase/carddatabase_test)
+4. The tests segfault, which is unexpected.
+Additional information:
+The tests segfault at exactly the same instruction as in #1908:
+
+```
+┌──────────────────────────────────────────────────────────────────────────────┐
+│  > 0x7ffff2cba928  lhu     a2,1248(a2)                                       │
+│    0x7ffff2cba92c  and     a0,a0,127                                         │
+│    0x7ffff2cba930  sll     a2,a2,0x7                                         │
+│    0x7ffff2cba934  add     a0,a0,a2                                          │
+│    0x7ffff2cba938  lui     t2,0xf8000                                        │
+│    0x7ffff2cba93c  lui     a2,0xf5de2                                        │
+│    0x7ffff2cba940  add     a2,a2,-1824                                       │
+│    0x7ffff2cba944  sll     t2,t2,0x14                                        │
+│    0x7ffff2cba948  xor     a2,a2,t2                                          │
+│    0x7ffff2cba94c  sll     t2,a0,0x1                                         │
+│    0x7ffff2cba950  add     a2,a2,t2                                          │
+│    0x7ffff2cba954  lhu     a2,0(a2)                                          │
+│    0x7ffff2cba958  sll     a0,a2,0x3                                         │
+└──────────────────────────────────────────────────────────────────────────────┘
+multi-thre Thread 0x7ffff2cbe0 In:                     L??   PC: 0x7ffff2cba928
+(gdb) bt
+#0  0x00007ffff2cba928 in  ()
+```
+
+It might suggest that 2d708164e0475064e0e2167bd73e8570e22df1e0 is not the true cause of #1908 and this bug shares the same underlying cause with #1908.
+
+Commit 2d708164e0475064e0e2167bd73e8570e22df1e0 LGTM, although it seems that it is copied from the loongarch one and the author forgot to update [the file header](https://gitlab.com/qemu-project/qemu/-/blob/2d708164e0475064e0e2167bd73e8570e22df1e0/linux-user/riscv/target_mman.h#L1-6).
diff --git a/gitlab/issues_text/target_rx/host_missing/accel_missing/2453 b/gitlab/issues_text/target_rx/host_missing/accel_missing/2453
new file mode 100644
index 00000000..dab8b89e
--- /dev/null
+++ b/gitlab/issues_text/target_rx/host_missing/accel_missing/2453
@@ -0,0 +1,9 @@
+qemu-system-rx aborts when trying to run the u-boot binary
+Description of problem:
+I tried to run the tests/avocado/machine_rx_gdbsim.py:RxGdbSimMachine.test_uboot test (which is not run by default since it is marked as flaky), but seems like QEMU now always aborts when trying to run with the u-boot bios.
+Steps to reproduce:
+1. wget https://acc.dl.osdn.jp/users/23/23888/u-boot.bin.gz
+2. gunzip u-boot.bin.gz
+3. qemu-system-rx -nographic -M gdbsim-r5f562n8 -bios u-boot.bin
+Additional information:
+Aborts with: ``qemu-system-rx: ../../devel/qemu/accel/tcg/translator.c:286: translator_ld: Assertion `((base ^ pc) & TARGET_PAGE_MASK) == 0' failed.``
diff --git a/gitlab/issues_text/target_rx/host_missing/accel_missing/2691 b/gitlab/issues_text/target_rx/host_missing/accel_missing/2691
new file mode 100644
index 00000000..723121bd
--- /dev/null
+++ b/gitlab/issues_text/target_rx/host_missing/accel_missing/2691
@@ -0,0 +1,27 @@
+Renesas: test_rx_gdbsim.py test sometime timeouts
+Description of problem:
+```make check-functional``` runs sometime fail with : 
+
+```
+160/164 qemu:func-thorough+func-rx-thorough+thorough / func-rx-rx_gdbsim                                            TIMEOUT          90.03s   killed by signal 15 SIGTERM
+```
+Steps to reproduce:
+1. ./configure --target-list=rx-softmmu
+2. make -j 20
+3. while [ 1 ]; do PYTHONPATH=python:tests/functional QEMU_TEST_QEMU_BINARY=build/qemu-system-rx build/pyvenv/bin/python3 tests/functional/test_rx_gdbsim.py ; done 
+
+It hangs after a few iterations.
+Additional information:
+The test console log file contains:
+   ```
+...
+2024-11-19 11:03:04,123: Run /bin/sh as init process
+2024-11-19 11:03:04,136: 
+2024-11-19 11:03:04,137: Sash command shell (version 1.1.1)
+2024-11-19 11:03:04,137: 
+2024-11-19 11:03:04,145: />sh-sci 88240.serial: overrun error
+2024-11-19 11:03:04,150: sh-sci 88240.serial: frame error
+2024-11-19 11:03:04,156: sh-sci 88240.serial: parity error
+   ```
+
+These errors appear to reflect some problems in the renesas_sci model.
diff --git a/gitlab/issues_text/target_rx/host_missing/accel_missing/2842 b/gitlab/issues_text/target_rx/host_missing/accel_missing/2842
new file mode 100644
index 00000000..b9e2a6ac
--- /dev/null
+++ b/gitlab/issues_text/target_rx/host_missing/accel_missing/2842
@@ -0,0 +1 @@
+RX System emulator boot, kernel images and device tree blob are missing
diff --git a/gitlab/issues_text/target_rx/host_missing/accel_missing/507 b/gitlab/issues_text/target_rx/host_missing/accel_missing/507
new file mode 100644
index 00000000..4a502e8f
--- /dev/null
+++ b/gitlab/issues_text/target_rx/host_missing/accel_missing/507
@@ -0,0 +1,56 @@
+rx / gdbsim-r5f562n7 / serial errors
+Description of problem:
+Test hangs (about once every two executions) because the console emits an error and expected content is not found.  Console content on a failed test execution:
+
+```
+15:49:05 DEBUG| Linux version 4.19.0+ (yo-satoh@yo-satoh-debian) (gcc version 9.0.0 20181105 (experimental) (GCC)) #137 Wed Feb 20 23:20:02 JST 2019
+15:49:05 DEBUG| Built 1 zonelists, mobility grouping on.  Total pages: 8128
+15:49:05 DEBUG| Kernel command line:
+15:49:05 DEBUG| Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
+15:49:05 DEBUG| Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
+15:49:05 DEBUG| Memory: 14648K/32768K available (871K kernel code, 95K rwdata, 140K rodata, 96K init, 175K bss, 18120K reserved, 0K cma-reserved)
+15:49:05 DEBUG| NR_IRQS: 256
+15:49:05 DEBUG| rx-cmt: used for periodic clock events
+15:49:05 DEBUG| clocksource: rx-tpu: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1274173631191 ns
+15:49:05 DEBUG| 96.00 BogoMIPS (lpj=480000)
+15:49:05 DEBUG| pid_max: default: 4096 minimum: 301
+15:49:05 DEBUG| Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
+15:49:05 DEBUG| Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
+15:49:05 DEBUG| clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+15:49:05 DEBUG| clocksource: Switched to clocksource rx-tpu
+15:49:05 DEBUG| workingset: timestamp_bits=30 max_order=12 bucket_order=0
+15:49:05 DEBUG| SuperH (H)SCI(F) driver initialized
+15:49:05 DEBUG| 88240.serial: ttySC0 at MMIO 0x88240 (irq = 215, base_baud = 0) is a sci
+15:49:05 DEBUG| console [ttySC0] enabled
+15:49:05 DEBUG| 88248.serial: ttySC1 at MMIO 0x88248 (irq = 219, base_baud = 0) is a sci
+15:49:05 DEBUG| random: get_random_bytes called from 0x01002e48 with crng_init=0
+15:49:05 DEBUG| Freeing unused kernel memory: 96K
+15:49:05 DEBUG| This architecture does not have kernel memory protection.
+15:49:05 DEBUG| Run /sbin/init as init process
+15:49:05 DEBUG| Run /etc/init as init process
+15:49:05 DEBUG| Run /bin/init as init process
+15:49:05 DEBUG| Run /bin/sh as init process
+15:49:05 DEBUG| Sash command shell (version 1.1.1)
+15:49:05 DEBUG| />sh-sci 88240.serial: overrun error
+15:49:05 DEBUG| sh-sci 88240.serial: frame error
+15:49:05 DEBUG| sh-sci 88240.serial: parity error
+15:49:09 DEBUG| random: fast init done
+```
+
+Instead of the last 4 lines seen here, a successful test contains:
+
+```
+20:59:53 DEBUG| Sash command shell (version 1.1.1)
+20:59:53 DEBUG| /> printenv
+20:59:53 DEBUG| HOME=/
+20:59:53 DEBUG| TERM=linux
+20:59:53 DEBUG| >>> {'execute': 'quit'}
+20:59:53 DEBUG| <<< {'return': {}}
+```
+
+It was also observed that the test is much more prone to fail when it runs restricted to a single CPU (with taskset).  It's not clear to me if this is a Kernel or QEMU issue.
+Steps to reproduce:
+1. ./configure --target-list=rx-softmmu
+2. meson compile
+3. make check-venv
+4. ./tests/venv/bin/avocado run tests/acceptance/machine_rx_gdbsim.py:RxGdbSimMachine.test_linux_sash
diff --git a/gitlab/issues_text/target_s390x/host_aarch64/accel_TCG/2169 b/gitlab/issues_text/target_s390x/host_aarch64/accel_TCG/2169
new file mode 100644
index 00000000..9c414a5b
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_aarch64/accel_TCG/2169
@@ -0,0 +1,393 @@
+qemu-system-s390x crashes with s390_swap_bfp_rounding_mode: code should not be reached
+Description of problem:
+Ubuntu 23.10 was installed on a s390x emulated platform some time ago. The system was setup, an open source project was built and tested. The system rebooted several times.
+
+Several days later, qemu crashed while the command `apt update` was running in the guest. The error was:
+```
+ERROR:../target/s390x/tcg/fpu_helper.c:449:s390_swap_bfp_rounding_mode: code should not be reached
+Bail out! ERROR:../target/s390x/tcg/fpu_helper.c:449:s390_swap_bfp_rounding_mode: code should not be reached
+Abort trap: 6
+```
+
+Now, each time the virtual machine is booted, qemu immediately crashes all the time at the end of the boot with the same error. The virtual machine is no longer usable.
+Steps to reproduce:
+1. Run the above command.
+2. It crashes at the end of the boot.
+Additional information:
+The disk image `disk.qcow2` is 3.7 GB large, too large to be attached here.
+
+Full boot log:
+```
+qemu-system-s390x -machine s390-ccw-virtio -cpu max,zpci=on -smp 8 -m 8192 -nographic \
+    -drive file=disk.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none \
+    -device virtio-blk-ccw,devno=fe.0.0002,drive=drive-virtio-disk0,bootindex=1 \
+    -nic user,hostfwd=tcp::2222-:22
+LOADPARM=[        ]
+Using virtio-blk.
+Using SCSI scheme.
+.........
+KASLR disabled: CPU has no PRNG
+KASLR disabled: CPU has no PRNG
+[    0.561037] Linux version 6.5.0-14-generic (buildd@bos02-s390x-003) (s390x-linux-gnu-gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.41) #14-Ubuntu SMP Tue Nov 14 14:16:58 UTC 2023 (Ubuntu 6.5.0-14.14-generic 6.5.3)
+[    0.562868] setup: Linux is running under KVM in 64-bit mode
+[    0.601125] setup: The maximum memory size is 8192MB
+[    0.601577] setup: Relocating AMODE31 section of size 0x00003000
+[    0.603756] cpu: 8 configured CPUs, 0 standby CPUs
+[   34.401410] Write protected kernel read-only data: 22272k
+[   34.548843] Zone ranges:
+[   34.548873]   DMA      [mem 0x0000000000000000-0x000000007fffffff]
+[   34.549570]   Normal   [mem 0x0000000080000000-0x00000001ffffffff]
+[   34.549609] Movable zone start for each node
+[   34.549633] Early memory node ranges
+[   34.549664]   node   0: [mem 0x0000000000000000-0x00000001ffffffff]
+[   34.549979] Initmem setup node 0 [mem 0x0000000000000000-0x00000001ffffffff]
+[   34.619124] percpu: Embedded 31 pages/cpu s87552 r8192 d31232 u126976
+[   34.621042] Kernel command line: root=/dev/disk/by-path/ccw-0.0.0002-part1
+[   34.622253] random: crng init done
+[   34.624460] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
+[   34.625511] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
+[   34.626568] Fallback order for Node 0: 0 
+[   34.627026] Built 1 zonelists, mobility grouping on.  Total pages: 2064384
+[   34.627069] Policy zone: Normal
+[   34.627356] mem auto-init: stack:all(zero), heap alloc:on, heap free:off
+[   34.669390] Memory: 8169740K/8388608K available (14780K kernel code, 3496K rwdata, 7492K rodata, 6376K init, 1312K bss, 218868K reserved, 0K cma-reserved)
+[   34.677279] SLUB: HWalign=256, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
+[   34.678165] ftrace: allocating 38640 entries in 151 pages
+[   34.967308] ftrace: allocated 151 pages with 5 groups
+[   34.977052] rcu: Hierarchical RCU implementation.
+[   34.977093] rcu: 	RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=8.
+[   34.977196] 	Rude variant of Tasks RCU enabled.
+[   34.977209] 	Tracing variant of Tasks RCU enabled.
+[   34.977329] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
+[   34.977360] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8
+[   35.023854] NR_IRQS: 3, nr_irqs: 3, preallocated irqs: 3
+[   35.026445] rcu: srcu_init: Setting srcu_struct sizes based on contention.
+[   35.027768] clocksource: tod: mask: 0xffffffffffffffff max_cycles: 0x3b0a9be803b0a9, max_idle_ns: 1805497147909793 ns
+[   35.032313] Console: colour dummy device 80x25
+[   35.036054] printk: console [ttysclp0] enabled
+[   35.038867] pid_max: default: 32768 minimum: 301
+[   35.044407] LSM: initializing lsm=lockdown,capability,landlock,yama,apparmor,integrity
+[   35.044879] landlock: Up and running.
+[   35.044911] Yama: becoming mindful.
+[   35.046994] AppArmor: AppArmor initialized
+[   35.048281] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
+[   35.048366] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
+[   35.079199] RCU Tasks Rude: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1.
+[   35.079584] RCU Tasks Trace: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1.
+[   35.081422] rcu: Hierarchical SRCU implementation.
+[   35.081465] rcu: 	Max phase no-delay instances is 1000.
+[   35.087248] smp: Bringing up secondary CPUs ...
+[   35.109842] smp: Brought up 1 node, 8 CPUs
+[   35.133520] devtmpfs: initialized
+[   35.143534] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+[   35.143848] futex hash table entries: 2048 (order: 7, 524288 bytes, linear)
+[   35.155409] NET: Registered PF_NETLINK/PF_ROUTE protocol family
+[   35.158309] audit: initializing netlink subsys (disabled)
+[   35.160126] audit: type=2000 audit(1708008415.080:1): state=initialized audit_enabled=0 res=1
+[   35.162149] Spectre V2 mitigation: execute trampolines
+[   35.218877] iommu: Default domain type: Translated
+[   35.218963] iommu: DMA domain TLB invalidation policy: strict mode
+[   35.221010] SCSI subsystem initialized
+[   35.221925] pps_core: LinuxPPS API ver. 1 registered
+[   35.221953] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
+[   35.233495] NetLabel: Initializing
+[   35.233538] NetLabel:  domain hash size = 128
+[   35.233569] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
+[   35.234452] NetLabel:  unlabeled traffic allowed by default
+[   35.490582] VFS: Disk quotas dquot_6.6.0
+[   35.490828] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
+[   35.492088] hugetlbfs: disabling because there are no supported hugepage sizes
+[   35.494605] AppArmor: AppArmor Filesystem Enabled
+[   35.537129] NET: Registered PF_INET protocol family
+[   35.538412] IP idents hash table entries: 131072 (order: 8, 1048576 bytes, linear)
+[   35.553748] tcp_listen_portaddr_hash hash table entries: 4096 (order: 4, 65536 bytes, linear)
+[   35.554033] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
+[   35.554241] TCP established hash table entries: 65536 (order: 7, 524288 bytes, linear)
+[   35.555185] TCP bind hash table entries: 65536 (order: 9, 2097152 bytes, linear)
+[   35.555971] TCP: Hash tables configured (established 65536 bind 65536)
+[   35.558027] MPTCP token hash table entries: 8192 (order: 5, 196608 bytes, linear)
+[   35.558386] UDP hash table entries: 4096 (order: 5, 131072 bytes, linear)
+[   35.558715] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes, linear)
+[   35.560408] NET: Registered PF_UNIX/PF_LOCAL protocol family
+[   35.560888] NET: Registered PF_XDP protocol family
+[   35.566276] Trying to unpack rootfs image as initramfs...
+[   35.583376] kvm-s390: SIE is not available
+[   35.584037] hypfs: The hardware system does not support hypfs
+[   35.686516] Initialise system trusted keyrings
+[   35.688015] Key type blacklist registered
+[   35.689131] workingset: timestamp_bits=45 max_order=21 bucket_order=0
+[   35.689516] zbud: loaded
+[   35.693314] squashfs: version 4.0 (2009/01/31) Phillip Lougher
+[   35.695879] fuse: init (API version 7.38)
+[   35.699171] integrity: Platform Keyring initialized
+[   35.808827] Key type asymmetric registered
+[   35.808973] Asymmetric key parser 'x509' registered
+[   35.809365] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)
+[   35.810660] io scheduler mq-deadline registered
+[   35.816790] hvc_iucv: The z/VM IUCV HVC device driver cannot be used without z/VM
+[   35.846919] loop: module loaded
+[   35.851530] tun: Universal TUN/TAP device driver, 1.6
+[   35.853032] device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
+[   35.853186] device-mapper: uevent: version 1.0.3
+[   35.854080] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@redhat.com
+[   35.854360] drop_monitor: Initializing network drop monitor service
+[   35.963712] NET: Registered PF_INET6 protocol family
+[   36.335556] Freeing initrd memory: 23592K
+[   36.587317] Segment Routing with IPv6
+[   36.587633] In-situ OAM (IOAM) with IPv6
+[   36.588291] NET: Registered PF_PACKET protocol family
+[   36.589147] Key type dns_resolver registered
+[   36.590364] cio: Channel measurement facility initialized using format extended (mode autodetected)
+[   36.592594] sclp_sd: Store Data request failed (eq=2, di=3, response=0x40f0, flags=0x00, status=0, rc=-5)
+[   36.593406] ap: The hardware system does not support AP instructions
+[   36.599059] virtio_blk virtio0: 1/0/0 default/read/poll queues
+[   36.604778] virtio_blk virtio0: [vda] 62914560 512-byte logical blocks (32.2 GB/30.0 GiB)
+[   36.621065] registered taskstats version 1
+[   36.623865]  vda: vda1
+[   36.630114] Loading compiled-in X.509 certificates
+[   36.639995] Loaded X.509 cert 'Build time autogenerated kernel key: ffca65de79457ba2128edde155db56e4bec9b799'
+[   36.642859] Loaded X.509 cert 'Canonical Ltd. Live Patch Signing: 14df34d1a87cf37625abec039ef2bf521249b969'
+[   36.646267] Loaded X.509 cert 'Canonical Ltd. Kernel Module Signing: 88f752e560a1e0737e31163a466ad7b70a850c19'
+[   36.646336] blacklist: Loading compiled-in revocation X.509 certificates
+[   36.647551] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing: 61482aa2830d0ab2ad5af10b7250da9033ddcef0'
+[   36.647791] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2017): 242ade75ac4a15e50d50c84b0d45ff3eae707a03'
+[   36.648026] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (ESM 2018): 365188c1d374d6b07c3c8f240f8ef722433d6a8b'
+[   36.648252] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2019): c0746fd6c5da3ae827864651ad66ae47fe24b3e8'
+[   36.648455] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2021 v1): a8d54bbb3825cfb94fa13c9f8a594a195c107b8d'
+[   36.648669] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2021 v2): 4cf046892d6fd3c9a5b03f98d845f90851dc6a8c'
+[   36.648876] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2021 v3): 100437bb6de6e469b581e61cd66bce3ef4ed53af'
+[   36.649092] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (Ubuntu Core 2019): c1d57b8f6b743f23ee41f4f7ee292f06eecadfb9'
+[   36.679176] Key type .fscrypt registered
+[   36.679250] Key type fscrypt-provisioning registered
+[   36.788001] Key type encrypted registered
+[   36.788125] AppArmor: AppArmor sha1 policy hashing enabled
+[   36.788580] ima: No TPM chip found, activating TPM-bypass!
+[   36.788676] Loading compiled-in module X.509 certificates
+[   36.791454] Loaded X.509 cert 'Build time autogenerated kernel key: ffca65de79457ba2128edde155db56e4bec9b799'
+[   36.791525] ima: Allocated hash algorithm: sha1
+[   36.793195] ima: No architecture policies found
+[   36.793649] evm: Initialising EVM extended attributes:
+[   36.793691] evm: security.selinux
+[   36.793729] evm: security.SMACK64
+[   36.793751] evm: security.SMACK64EXEC
+[   36.793772] evm: security.SMACK64TRANSMUTE
+[   36.793792] evm: security.SMACK64MMAP
+[   36.793817] evm: security.apparmor
+[   36.793837] evm: security.ima
+[   36.793857] evm: security.capability
+[   36.793882] evm: HMAC attrs: 0x1
+[   36.814426] Freeing unused kernel image (initmem) memory: 6376K
+[   36.855771] Write protected read-only-after-init data: 144k
+[   38.034069] Checked W+X mappings: passed, no unexpected W+X pages found
+[   38.034295] Run /init as init process
+Loading, please wait...
+Starting systemd-udevd version 253.5-1ubuntu6.1
+[   41.012145] virtio_net virtio1 enc0: renamed from eth0
+Begin: Starting firmware auto-configuration ... done.
+Begin: Loading essential drivers ... [   48.602928] raid6: vx128x8  gen()  3084 MB/s
+[   48.603058] raid6: using algorithm vx128x8 gen() 3084 MB/s
+[   48.773302] raid6: .... xor() 1800 MB/s, rmw enabled
+[   48.773433] raid6: using s390xc recovery algorithm
+[   48.783956] xor: automatically using best checksumming function   xc        
+done.
+Begin: Running /scripts/init-premount ... done.
+Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
+Begin: Running /scripts/local-premount ... [   49.837645] Btrfs loaded, zoned=yes, fsverity=yes
+Scanning for Btrfs filesystems
+done.
+Begin: Will now check root file system ... fsck from util-linux 2.39.1
+[/usr/sbin/fsck.ext4 (1) -- /dev/vda1] fsck.ext4 -a -C0 /dev/vda1 
+/dev/vda1: recovering journal
+/dev/vda1: clean, 123948/1966080 files, 1902224/7863808 blocks
+done.
+[   50.624887] EXT4-fs (vda1): mounted filesystem b33ae246-95a1-494e-b967-9ab636fd714d ro with ordered data mode. Quota mode: none.
+done.
+Begin: Running /scripts/local-bottom ... done.
+Begin: Running /scripts/init-bottom ... done.
+[   52.531666] systemd[1]: systemd 253.5-1ubuntu6.1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
+[   52.531979] systemd[1]: Detected virtualization kvm.
+[   52.532228] systemd[1]: Detected architecture s390x.
+
+Welcome to Ubuntu 23.10!
+
+[   52.545927] systemd[1]: Hostname set to <vms390x>.
+[   52.738383] systemd[1]: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set
+[   54.251527] (sd-execu[322]: /usr/lib/systemd/system-generators/s390-cpi-vars failed with exit status 1.
+[   56.207233] systemd[1]: Queued start job for default target graphical.target.
+[   56.324910] systemd[1]: Created slice system-modprobe.slice - Slice /system/modprobe.
+[  OK  ] Created slice system-modpr…lice - Slice /system/modprobe.
+[   56.342133] systemd[1]: Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty.
+[  OK  ] Created slice system-seria… - Slice /system/serial-getty.
+[   56.354987] systemd[1]: Created slice user.slice - User and Session Slice.
+[  OK  ] Created slice user.slice - User and Session Slice.
+[   56.359125] systemd[1]: Started systemd-ask-password-wall.path - Forward Password Requests to Wall Directory Watch.
+[  OK  ] Started systemd-ask-passwo… Requests to Wall Directory Watch.
+[   56.370074] systemd[1]: Set up automount proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File System Automount Point.
+[  OK  ] Set up automount proc-sys-…rmats File System Automount Point.
+[   56.373118] systemd[1]: Reached target integritysetup.target - Local Integrity Protected Volumes.
+[  OK  ] Reached target integrityse…Local Integrity Protected Volumes.
+[   56.374764] systemd[1]: Reached target slices.target - Slice Units.
+[  OK  ] Reached target slices.target - Slice Units.
+[   56.375999] systemd[1]: Reached target snapd.mounts-pre.target - Mounting snaps.
+[  OK  ] Reached target snapd.mounts-pre.target - Mounting snaps.
+[   56.377421] systemd[1]: Reached target veritysetup.target - Local Verity Protected Volumes.
+[  OK  ] Reached target veritysetup… - Local Verity Protected Volumes.
+[   56.381860] systemd[1]: Listening on dm-event.socket - Device-mapper event daemon FIFOs.
+[  OK  ] Listening on dm-event.sock… Device-mapper event daemon FIFOs.
+[   56.388375] systemd[1]: Listening on lvm2-lvmpolld.socket - LVM2 poll daemon socket.
+[  OK  ] Listening on lvm2-lvmpolld…ket - LVM2 poll daemon socket.
+[   56.394056] systemd[1]: Listening on multipathd.socket - multipathd control socket.
+[  OK  ] Listening on multipathd.so…t - multipathd control socket.
+[   56.399560] systemd[1]: Listening on syslog.socket - Syslog Socket.
+[  OK  ] Listening on syslog.socket - Syslog Socket.
+[   56.404487] systemd[1]: Listening on systemd-fsckd.socket - fsck to fsckd communication Socket.
+[  OK  ] Listening on systemd-fsckd…sck to fsckd communication Socket.
+[   56.407621] systemd[1]: Listening on systemd-initctl.socket - initctl Compatibility Named Pipe.
+[  OK  ] Listening on systemd-initc… initctl Compatibility Named Pipe.
+[   56.414642] systemd[1]: Listening on systemd-journald-dev-log.socket - Journal Socket (/dev/log).
+[  OK  ] Listening on systemd-journ…t - Journal Socket (/dev/log).
+[   56.421162] systemd[1]: Listening on systemd-journald.socket - Journal Socket.
+[  OK  ] Listening on systemd-journald.socket - Journal Socket.
+[   56.429706] systemd[1]: Listening on systemd-networkd.socket - Network Service Netlink Socket.
+[  OK  ] Listening on systemd-netwo… - Network Service Netlink Socket.
+[   56.436982] systemd[1]: Listening on systemd-udevd-control.socket - udev Control Socket.
+[  OK  ] Listening on systemd-udevd….socket - udev Control Socket.
+[   56.443136] systemd[1]: Listening on systemd-udevd-kernel.socket - udev Kernel Socket.
+[  OK  ] Listening on systemd-udevd…l.socket - udev Kernel Socket.
+[   56.450850] systemd[1]: dev-hugepages.mount - Huge Pages File System was skipped because of an unmet condition check (ConditionPathExists=/sys/kernel/mm/hugepages).
+[   56.516995] systemd[1]: Mounting dev-mqueue.mount - POSIX Message Queue File System...
+         Mounting dev-mqueue.mount…OSIX Message Queue File System...
+[   56.554312] systemd[1]: Mounting sys-kernel-debug.mount - Kernel Debug File System...
+         Mounting sys-kernel-debug.… - Kernel Debug File System...
+[   56.589207] systemd[1]: Mounting sys-kernel-tracing.mount - Kernel Trace File System...
+         Mounting sys-kernel-tracin… - Kernel Trace File System...
+[   56.651284] systemd[1]: Starting systemd-journald.service - Journal Service...
+         Starting systemd-journald.service - Journal Service...
+[   56.683040] systemd[1]: Starting keyboard-setup.service - Set the console keyboard layout...
+         Starting keyboard-setup.se…Set the console keyboard layout...
+[   56.729933] systemd[1]: Starting kmod-static-nodes.service - Create List of Static Device Nodes...
+         Starting kmod-static-nodes…ate List of Static Device Nodes...
+[   56.765378] systemd[1]: Starting lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling...
+         Starting lvm2-monitor.serv…ng dmeventd or progress polling...
+[   56.768638] systemd[1]: lxd-agent.service - LXD - agent was skipped because of an unmet condition check (ConditionPathExists=/dev/virtio-ports/org.linuxcontainers.lxd).
+[   56.806941] systemd[1]: Starting modprobe@configfs.service - Load Kernel Module configfs...
+         Starting modprobe@configfs…m - Load Kernel Module configfs...
+[   56.852266] systemd[1]: Starting modprobe@dm_mod.service - Load Kernel Module dm_mod...
+         Starting modprobe@dm_mod.s…[0m - Load Kernel Module dm_mod...
+[   56.907919] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm...
+         Starting modprobe@drm.service - Load Kernel Module drm...
+[   56.962524] systemd[1]: Starting modprobe@efi_pstore.service - Load Kernel Module efi_pstore...
+         Starting modprobe@efi_psto…- Load Kernel Module efi_pstore...
+[   57.014414] systemd[1]: Starting modprobe@fuse.service - Load Kernel Module fuse...
+         Starting modprobe@fuse.ser…e - Load Kernel Module fuse...
+[   57.069081] systemd-journald[352]: Collecting audit messages is disabled.
+[   57.076472] systemd[1]: Starting modprobe@loop.service - Load Kernel Module loop...
+         Starting modprobe@loop.ser…e - Load Kernel Module loop...
+[   57.085874] systemd[1]: netplan-ovs-cleanup.service - OpenVSwitch configuration for cleanup was skipped because of an unmet condition check (ConditionFileIsExecutable=/usr/bin/ovs-vsctl).
+[   57.095668] systemd[1]: systemd-fsck-root.service - File System Check on Root Device was skipped because of an unmet condition check (ConditionPathExists=!/run/initramfs/fsck-root).
+[   57.168905] systemd[1]: Starting systemd-modules-load.service - Load Kernel Modules...
+         Starting systemd-modules-l…rvice - Load Kernel Modules...
+[   57.226498] systemd[1]: Starting systemd-remount-fs.service - Remount Root and Kernel File Systems...
+         Starting systemd-remount-f…nt Root and Kernel File Systems...
+[   57.287754] systemd[1]: Starting systemd-udev-trigger.service - Coldplug All udev Devices...
+         Starting systemd-udev-trig…[0m - Coldplug All udev Devices...
+[   57.419867] systemd[1]: Mounted dev-mqueue.mount - POSIX Message Queue File System.
+[  OK  ] Mounted dev-mqueue.mount…OSIX Message Queue File System.
+[   57.432129] systemd[1]: Mounted sys-kernel-debug.mount - Kernel Debug File System.
+[  OK  ] Mounted sys-kernel-debug.m…nt - Kernel Debug File System.
+[   57.443392] systemd[1]: Mounted sys-kernel-tracing.mount - Kernel Trace File System.
+[  OK  ] Mounted sys-kernel-tracing…nt - Kernel Trace File System.
+[   57.455168] systemd[1]: Finished kmod-static-nodes.service - Create List of Static Device Nodes.
+[  OK  ] Finished kmod-static-nodes…reate List of Static Device Nodes.
+[   57.466903] systemd[1]: Started systemd-journald.service - Journal Service.
+[  OK  ] Started systemd-journald.service - Journal Service.
+[  OK  ] Finished modprobe@configfs…[0m - Load Kernel Module configfs.
+[   57.555558] EXT4-fs (vda1): re-mounted b33ae246-95a1-494e-b967-9ab636fd714d r/w. Quota mode: none.
+[  OK  ] Finished modprobe@dm_mod.s…e - Load Kernel Module dm_mod.
+[  OK  ] Finished modprobe@efi_psto…m - Load Kernel Module efi_pstore.
+[  OK  ] Finished modprobe@fuse.service - Load Kernel Module fuse.
+[  OK  ] Finished modprobe@loop.service - Load Kernel Module loop.
+[  OK  ] Finished systemd-modules-l…service - Load Kernel Modules.
+[  OK  ] Finished systemd-remount-f…ount Root and Kernel File Systems.
+         Activating swap swap.img.swap - /swap.img...
+         Mounting sys-fs-fuse-conne… - FUSE Control File System...
+[   57.885897] Adding 4085756k swap on /swap.img.  Priority:-2 extents:7 across:4388860k FS
+         Mounting sys-kernel-config…ernel Configuration File System...
+         Starting multipathd.servic…per Multipath Device Controller...
+         Starting systemd-journal-f…h Journal to Persistent Storage...
+         Starting systemd-random-se… - Load/Save OS Random Seed...
+         Starting systemd-sysctl.se…ce - Apply Kernel Variables...
+         Starting systemd-sysusers.…rvice - Create System Users...
+[  OK  ] Activated swap swap.img.swap - /swap.img.
+[   58.206094] systemd-journald[352]: Received client request to flush runtime journal.
+[   58.228283] systemd-journald[352]: File /var/log/journal/accea1250e0f4fe291f8c3b31e7720d7/system.journal corrupted or uncleanly shut down, renaming and replacing.
+[  OK  ] Finished lvm2-monitor.serv…sing dmeventd or progress polling.
+[  OK  ] Finished modprobe@drm.service - Load Kernel Module drm.
+[  OK  ] Mounted sys-fs-fuse-connec…nt - FUSE Control File System.
+[  OK  ] Mounted sys-kernel-config.… Kernel Configuration File System.
+[  OK  ] Finished systemd-random-se…ce - Load/Save OS Random Seed.
+[  OK  ] Finished systemd-sysctl.service - Apply Kernel Variables.
+[  OK  ] Reached target swap.target - Swaps.
+[  OK  ] Finished systemd-sysusers.service - Create System Users.
+         Starting systemd-tmpfiles-…ate Static Device Nodes in /dev...
+[  OK  ] Finished systemd-journal-f…ush Journal to Persistent Storage.
+[  OK  ] Finished keyboard-setup.se…- Set the console keyboard layout.
+[  OK  ] Started multipathd.service…apper Multipath Device Controller.
+[  OK  ] Finished systemd-tmpfiles-…reate Static Device Nodes in /dev.
+[  OK  ] Reached target local-fs-pr…reparation for Local File Systems.
+         Mounting snap-core22-865.m…t unit for core22, revision 865...
+         Mounting snap-lxd-25850.mo…nt unit for lxd, revision 25850...
+         Mounting snap-snapd-20294.… unit for snapd, revision 20294...
+         Mounting snap-snapd-20676.… unit for snapd, revision 20676...
+         Starting systemd-udevd.ser…ger for Device Events and Files...
+[  OK  ] Mounted snap-core22-865.mo…unt unit for core22, revision 865.
+[  OK  ] Mounted snap-lxd-25850.mou…ount unit for lxd, revision 25850.
+[  OK  ] Mounted snap-snapd-20294.m…nt unit for snapd, revision 20294.
+[  OK  ] Mounted snap-snapd-20676.m…nt unit for snapd, revision 20676.
+[  OK  ] Reached target snapd.mounts.target - Mounted snaps.
+[  OK  ] Reached target local-fs.target - Local File Systems.
+         Starting apparmor.service - Load AppArmor profiles...
+         Starting console-setup.ser…m - Set console font and keymap...
+         Starting finalrd.service…me dir for shutdown pivot root...
+         Starting plymouth-read-wri…mouth To Write Out Runtime Data...
+         Starting systemd-binfmt.se…et Up Additional Binary Formats...
+         Starting systemd-tmpfiles-… Volatile Files and Directories...
+         Starting ufw.service - Uncomplicated firewall...
+[  OK  ] Finished systemd-udev-trig…e - Coldplug All udev Devices.
+[  OK  ] Finished console-setup.ser…[0m - Set console font and keymap.
+[  OK  ] Finished finalrd.service…time dir for shutdown pivot root.
+[  OK  ] Finished plymouth-read-wri…lymouth To Write Out Runtime Data.
+[  OK  ] Finished ufw.service - Uncomplicated firewall.
+[  OK  ] Reached target network-pre…get - Preparation for Network.
+         Mounting proc-sys-fs-binfm…utable File Formats File System...
+[  OK  ] Mounted proc-sys-fs-binfmt…ecutable File Formats File System.
+[  OK  ] Finished systemd-binfmt.se… Set Up Additional Binary Formats.
+[  OK  ] Started systemd-udevd.serv…nager for Device Events and Files.
+[  OK  ] Started systemd-ask-passwo…quests to Console Directory Watch.
+[  OK  ] Reached target cryptsetup.…get - Local Encrypted Volumes.
+         Starting systemd-networkd.…ice - Network Configuration...
+[  OK  ] Finished systemd-tmpfiles-…te Volatile Files and Directories.
+         Starting systemd-resolved.…e - Network Name Resolution...
+         Starting systemd-timesyncd… - Network Time Synchronization...
+         Starting systemd-update-ut…rd System Boot/Shutdown in UTMP...
+[  OK  ] Finished systemd-update-ut…cord System Boot/Shutdown in UTMP.
+[  OK  ] Found device dev-ttysclp0.device - /dev/ttysclp0.
+[  OK  ] Started systemd-networkd.service - Network Configuration.
+         Starting systemd-networkd-…it for Network to be Configured...
+[  OK  ] Started systemd-timesyncd.…0m - Network Time Synchronization.
+[  OK  ] Reached target time-set.target - System Time Set.
+[  OK  ] Finished systemd-networkd-…Wait for Network to be Configured.
+[  OK  ] Finished apparmor.service - Load AppArmor profiles.
+         Starting snapd.apparmor.se…les managed internally by snapd...
+[  OK  ] Started systemd-resolved.s…ice - Network Name Resolution.
+[  OK  ] Reached target network.target - Network.
+[  OK  ] Reached target network-online.target - Network is Online.
+[  OK  ] Reached target nss-lookup.…m - Host and Network Name Lookups.
+[  OK  ] Reached target remote-fs-p…eparation for Remote File Systems.
+[  OK  ] Reached target remote-fs.target - Remote File Systems.
+[  OK  ] Finished blk-availability.…m - Availability of block devices.
+**
+ERROR:../target/s390x/tcg/fpu_helper.c:449:s390_swap_bfp_rounding_mode: code should not be reached
+Bail out! ERROR:../target/s390x/tcg/fpu_helper.c:449:s390_swap_bfp_rounding_mode: code should not be reached
+Abort trap: 6
+```
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_TCG/1248 b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/1248
new file mode 100644
index 00000000..2e06819a
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/1248
@@ -0,0 +1,11 @@
+s390x: glibc widestring algorithms broken
+Description of problem:
+Several wide-string functions from glibc are broken und qemu user emulation.
+Affected are at least: `wcsbrk()`, `wcsspn()` and `wcscspn()`. All of these are implemented in optimized assembler in glibc.
+
+Unfortunately I don't have access to the real hardware to check the behavior there. But it would probably been detected by now.
+Also I don't know which instructions exactly don't work, as I don't have any knowledge about s390x assembler.
+Steps to reproduce:
+1. Compile the test program above
+2. Run the program
+3. Output is `0`, should be `1`.
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_TCG/1865 b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/1865
new file mode 100644
index 00000000..15253de4
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/1865
@@ -0,0 +1,24 @@
+ERROR:../target/s390x/tcg/cc_helper.c:128:cc_calc_addu: assertion failed: (carry_out <= 1)
+Description of problem:
+Installation progresses OK, but QEMU asserts during post-installation setup tasks:
+
+Performing post-installation setup tasks
+**
+ERROR:../target/s390x/tcg/cc_helper.c:128:cc_calc_addu: assertion failed: (carry_out <= 1)
+Bail out! ERROR:../target/s390x/tcg/cc_helper.c:128:cc_calc_addu: assertion failed: (carry_out <= 1)
+./install.sh: line 25: 158224 Aborted                 (core dumped) $QEMU/qemu-system-s390x -M s390-ccw-virtio -smp 1 -m 4G 
+-nographic -display none -serial mon:stdio -device virtio-scsi -drive file=$ISO,format=raw,if=none,id=c1 -device scsi-cd,dri
+ve=c1 -hda $DISK -kernel $KERNEL -initrd $INITRD -net nic,model=virtio,netdev=net1 -netdev user,id=net1 -D debug.log
+Steps to reproduce:
+1. Download ClefOS 7.7 ISO from [sinenomine](https://download.sinenomine.net/clefos)
+2. Download Fedora 27 ISO and extract kernel.img and initrd.img, for boot purposes
+3. Boot ClefOS ISO using Fedora kernel/initrd
+4. Go through a minimal install, observe crash during post-installation setup tasks
+Additional information:
+See script log and install.sh attached. [install-and-output.zip](/uploads/87eb8484344402ea9c68784f89ea3339/install-and-output.zip)
+
+I have tried QEMU 7.2.5 and 8.1 on my Fedora 38 AMD host.
+
+My goal is to create RHEL7, SLES12, Ubuntu20 (or compatible) VMs for s390x software builds.
+So far only Ubuntu20 has been successful.
+RHEL7 fails due to kernel issues described in QEMU issue 906, so I'm trying ClefOS (CentOS for z) based on a procedure [here](https://www.linuxquestions.org/questions/linux-server-73/install-clefos-7-5-an-open-source-version-of-rhel-7-5-s390x-using-qemu-4175658710/)
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_TCG/281 b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/281
new file mode 100644
index 00000000..58abaf1a
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/281
@@ -0,0 +1 @@
+External modules retreval using Go1.15 on s390x appears to have checksum and ECDSA verification issues
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_TCG/319 b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/319
new file mode 100644
index 00000000..d84e3f74
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/319
@@ -0,0 +1 @@
+Openjdk11+ fails to install on s390x
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_TCG/616 b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/616
new file mode 100644
index 00000000..cf769c76
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/616
@@ -0,0 +1,107 @@
+overflow condition code determined incorrectly after addition on s390x
+Description of problem:
+The following program foo.c
+[foo.c](/uploads/78f5f799af6e3c400a6a42634f3f0e63/foo.c)
+
+```
+#include <stdio.h>
+
+int overflow_32 (int x, int y)
+{
+  int sum;
+  return ! __builtin_add_overflow (x, y, &sum);
+}
+
+int overflow_64 (long long x, long long y)
+{
+  long sum;
+  return ! __builtin_add_overflow (x, y, &sum);
+}
+
+int a1 = -2147483648;
+int b1 = -2147483648;
+long long a2 = -9223372036854775808L;
+long long b2 = -9223372036854775808L;
+
+int main ()
+{
+  {
+    int a = a1;
+    int b = b1;
+    printf ("a = 0x%x, b = 0x%x\n", a, b);
+    printf ("no_overflow = %d\n", overflow_32 (a, b));
+  }
+  {
+    long long a = a2;
+    long long b = b2;
+    printf ("a = 0x%llx, b = 0x%llx\n", a, b);
+    printf ("no_overflow = %d\n", overflow_64 (a, b));
+  }
+}
+```
+
+should print
+
+```
+a = 0x80000000, b = 0x80000000
+no_overflow = 0
+a = 0x8000000000000000, b = 0x8000000000000000
+no_overflow = 0
+```
+
+However, when compiled as an s390x program and executed through
+qemu 6.1.0 (Linux user-mode), it prints 'no_overflow = 1' twice.
+
+```
+$ s390x-linux-gnu-gcc-10 --version
+s390x-linux-gnu-gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0
+```
+
+```
+$ s390x-linux-gnu-gcc-10 -static foo.c
+$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out
+a = 0x80000000, b = 0x80000000
+no_overflow = 1
+a = 0x8000000000000000, b = 0x8000000000000000
+no_overflow = 1
+```
+
+```
+$ s390x-linux-gnu-gcc-10 -O2 -static foo.c
+$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out
+a = 0x80000000, b = 0x80000000
+no_overflow = 1
+a = 0x8000000000000000, b = 0x8000000000000000
+no_overflow = 1
+```
+
+The code generated by 's390x-linux-gnu-gcc-10 -O2' makes use of the
+'o' (overflow / ones) condition code:
+
+```
+overflow_64:
+        lgr     %r1,%r2    ;; copy a into %r1
+        lghi    %r2,0
+        agr     %r1,%r3    ;; add a and b
+        bnor    %r14       ;; if no overflow, return %r2 = 0
+        lghi    %r2,1
+        br      %r14       ;; otherwise, return %r2 = 1
+```
+
+Either the bug is in GCC, that is, GCC produces code that uses the CPU's
+overflow condition code when it shouldn't.
+
+Or the bug is in QEMU, that is, QEMU does not set the overflow condition
+code correctly.
+
+This can be decided by running the above program on real Linux/s390x hardware
+(to which I don't have access).
+Steps to reproduce:
+[foo.static.s390x](/uploads/ac41abf4c54baf9ca96ba82d75a24ad6/foo.static.s390x)
+(foo.static.s390x is attached, the result of "s390x-linux-gnu-gcc-10 -static -O2 foo.c -o foo.static.s390x")
+
+1. `qemu-s390x foo.static.s390x`
+Additional information:
+If the bug is really in QEMU, the attached patch fixes it.
+
+[0001-s390x-Fix-determination-of-overflow-condition-code-a.patch](/uploads/552917079ccd25f1861d682fc9dee3e8/0001-s390x-Fix-determination-of-overflow-condition-code-a.patch)
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_TCG/618 b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/618
new file mode 100644
index 00000000..1551834d
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/618
@@ -0,0 +1,95 @@
+overflow condition code determined incorrectly after subtraction on s390x
+Description of problem:
+Paul Eggert found this bug, just by taking a look at the file `qemu/target/s390x/tcg/cc_helper.c`.
+
+The following program
+[foo.c](/uploads/c1f425684fd661c4437950d7d8ddf31d/foo.c)
+```
+#include <stdio.h>
+
+int overflow_32 (int x, int y)
+{
+  int sum;
+  return __builtin_sub_overflow (x, y, &sum);
+}
+
+int overflow_64 (long long x, long long y)
+{
+  long sum;
+  return __builtin_sub_overflow (x, y, &sum);
+}
+
+int a1 = 0;
+int b1 = -2147483648;
+long long a2 = 0L;
+long long b2 = -9223372036854775808L;
+
+int main ()
+{
+  {
+    int a = a1;
+    int b = b1;
+    printf ("a = 0x%x, b = 0x%x\n", a, b);
+    printf ("no_overflow = %d\n", ! overflow_32 (a, b));
+  }
+  {
+    long long a = a2;
+    long long b = b2;
+    printf ("a = 0x%llx, b = 0x%llx\n", a, b);
+    printf ("no_overflow = %d\n", ! overflow_64 (a, b));
+  }
+}
+```
+should print
+```
+a = 0x0, b = 0x80000000
+no_overflow = 0
+a = 0x0, b = 0x8000000000000000
+no_overflow = 0
+```
+However, when compiled as an s390x program and executed through qemu 6.1.0 (Linux user-mode), it prints 'no_overflow = 1' twice.
+```
+$ s390x-linux-gnu-gcc-10 --version
+s390x-linux-gnu-gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0
+```
+
+```
+$ s390x-linux-gnu-gcc-10 -static foo.c
+$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out
+a = 0x0, b = 0x80000000
+no_overflow = 1
+a = 0x0, b = 0x8000000000000000
+no_overflow = 1
+```
+
+```
+$ s390x-linux-gnu-gcc-10 -O2 -static foo.c
+$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out
+a = 0x0, b = 0x80000000
+no_overflow = 1
+a = 0x0, b = 0x8000000000000000
+no_overflow = 1
+```
+
+The code generated by 's390x-linux-gnu-gcc-10 -O2' makes use of the 'o' (overflow / ones) condition code:
+```
+overflow_64:
+        lgr     %r1,%r2    ;; copy a into %r1
+        lghi    %r2,0
+        sgr     %r1,%r3    ;; subtract b from a
+        bnor    %r14       ;; if no overflow, return %r2 = 0
+        lghi    %r2,1
+        br      %r14       ;; otherwise, return %r2 = 1
+```
+
+The condition code and the overflow bit are defined in the z/Architecture Principles of Operation (POP) http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr011.pdf page 7-5 / 7-6 / 7-388 : "In mathematical terms, signed addition and subtraction produce a fixed-point overflow when the result is outside the range of representation for signed binary integers."
+
+I conclude that the bug is in QEMU: QEMU does not set the overflow condition code correctly.
+Steps to reproduce:
+[foo.static.s390x](/uploads/e4b79b019db590f3a4b13cac41e57ba6/foo.static.s390x)
+(the result of "s390x-linux-gnu-gcc-10 -static -O2 foo.c -o foo.static.s390x")
+
+1. `qemu-s390x foo.static.s390x`
+Additional information:
+The attached patch fixes it.
+[0002-s390x-Fix-determination-of-overflow-condition-code-a.patch](/uploads/8d414f84fe0ed36bf07bd28f5e7836ab/0002-s390x-Fix-determination-of-overflow-condition-code-a.patch)
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_TCG/655 b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/655
new file mode 100644
index 00000000..df8dce17
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/655
@@ -0,0 +1,32 @@
+Java crashes on s390x VM with SIGILL/ILL_PRVOPC at '__kernel_getcpu+0x8'
+Description of problem:
+The `java` command fails with the following message:
+
+```console
+$ /usr/lib/jvm/java-17-openjdk-s390x/bin/java --version
+#
+# A fatal error has been detected by the Java Runtime Environment:
+#
+# SIGILL (0x4) at pc=0x000003ff9e4fe6f4, pid=2883, tid=2884
+#
+# JRE version: (17.0+35) (build )
+# Java VM: OpenJDK 64-Bit Server VM (17+35-Ubuntu-120.04, mixed
+# mode, sharing, tiered, compressed oops, compressed class ptrs,
+# serial gc, linux-s390x)
+# Problematic frame:
+# C [linux-vdso64.so.1+0x6f8] __kernel_getcpu+0x8
+#
+# Core dump will be written. Default location: Core dumps may
+# be processed with "/usr/share/apport/apport %p %s %c %d %P %E"
+# (or dumping to /home/ubuntu/core.2883)
+#
+# An error report file with more information is saved as:
+# /home/ubuntu/hs_err_pid2883.log
+#
+#
+Aborted (core dumped)
+```
+Steps to reproduce:
+1. Run `java --version`
+Additional information:
+The corresponding log file is attached as the file [hs_err_pid2883.log](/uploads/1631b6a0f0aad2f77c4928ed6bb540c6/hs_err_pid2883.log).
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_TCG/737 b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/737
new file mode 100644
index 00000000..0b6a0ffe
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/737
@@ -0,0 +1,3 @@
+s390x/tcg: Implement Miscellaneous-Instruction-Extensions Facility 3 for the s390x
+Additional information:
+http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_TCG/738 b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/738
new file mode 100644
index 00000000..f4a17fff
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/738
@@ -0,0 +1,3 @@
+s390x/tcg: Implement Vector-Enhancements Facility 2 for s390x
+Additional information:
+http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_TCG/902 b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/902
new file mode 100644
index 00000000..a5827ef2
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/902
@@ -0,0 +1 @@
+BootLinuxS390X test failing due to a TCG bug
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_TCG/979 b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/979
new file mode 100644
index 00000000..ed1db479
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_TCG/979
@@ -0,0 +1,7 @@
+s390x floating point conversion functions broken
+Description of problem:
+While collecting additional reference files for float_convs (and float_convd) I noticed that the s390x handling of some cases is broken. See diff for details:
+
+```
+ diff -y tests/tcg/s390x-linux-user/float_convs.out ../../tests/tcg/s390x/float_convs.ref
+#
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_missing/1398 b/gitlab/issues_text/target_s390x/host_missing/accel_missing/1398
new file mode 100644
index 00000000..43e0d63d
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_missing/1398
@@ -0,0 +1,6 @@
+Kernel Fault in primary space mode while using user ASCE emulating s390x with AlmaLinux release 9.1 (Lime Lynx)
+Description of problem:
+Happens twice during startup, however the system keeps running.
+Steps to reproduce:
+1. Install Alma Linux s390x on in KVM on x86_64
+2. Start KVM
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_missing/1668 b/gitlab/issues_text/target_s390x/host_missing/accel_missing/1668
new file mode 100644
index 00000000..21da2aaa
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_missing/1668
@@ -0,0 +1,45 @@
+Fedora 38 build of clang 16 fails when run under s390x emulation (both system & linux-user)
+Description of problem:
+Spawn a Fedora 38 container using `s390x` linux-user based emulation
+
+```
+$ podman run -it --platform linux/s390x fedora:latest
+```
+
+Install clang inside it
+
+```
+sh-5.2# dnf -y install clang
+```
+
+Try to run clang
+
+```
+sh-5.2# clang --version
+clang version 16.0.4 (Fedora 16.0.4-1.fc38)
+Target: s390x-redhat-linux-gnu
+Thread model: posix
+InstalledDir: /usr/bin
+sh-5.2# clang --help   
+clang-16: error: unsupported option '--help'; did you mean '--help'?
+clang-16: error: no input files
+```
+
+Notice the nonsense error message when requesting `--help`. With Fedora 37 build of clang 15 (compiled with gcc 12), under s390x emulation, `--help` will correctly print the help.  In fact all options except for `--version` appear to be broken:
+
+```
+sh-5.2# echo "void foo(void) {}" > foo.c
+sh-5.2# clang -c foo.c
+clang-16: error: unknown argument: '-c'
+```
+
+
+IOW, there appears to be something in the clang 16 (compiled with gcc 13) in Fedora 38 that is tripping up s390x emulation.
+
+It is unclear whether the trigger was from building clang 16 with a newer gcc 13, or whether something changed from clang 15 -> 16.
+
+Originally reported with qemu-user-static-7.2.1-1.fc38.x86_64, but I've reproduced with QEMU upstream 7.1.0 release and QEMU upstream git master (v8.0.0-394-gc2b7158455)
+
+This was originally reported in Fedora at
+
+  https://bugzilla.redhat.com/show_bug.cgi?id=2209635
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_missing/1854 b/gitlab/issues_text/target_s390x/host_missing/accel_missing/1854
new file mode 100644
index 00000000..9ae566f4
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_missing/1854
@@ -0,0 +1,18 @@
+s390x: qemu-user: ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached
+Description of problem:
+The nolibc-test program from the Linux kernel crashes since 5f4e5b34092556ab1577e25d1262bd5975b26980 .
+Reverting that commit fixes the issue.
+Steps to reproduce:
+1. Build `nolibc-test` for s390x from Linux kernel tree. (from `tools/testing/selftests/nolibc/`). EDIT: compiled binary is uploaded below.
+2. Run it under qemu-s390x.
+
+```
+ ./qemu-s390x nolibc-test
+**
+ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached
+Bail out! ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached
+Aborted (core dumped)
+
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_missing/197 b/gitlab/issues_text/target_s390x/host_missing/accel_missing/197
new file mode 100644
index 00000000..4e2ad029
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_missing/197
@@ -0,0 +1 @@
+Unpredictable behaviour resulting in User process faults
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_missing/2704 b/gitlab/issues_text/target_s390x/host_missing/accel_missing/2704
new file mode 100644
index 00000000..ade2e1e0
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_missing/2704
@@ -0,0 +1,302 @@
+Error when migrating s390x VM from QEMU 9.0 to 9.1: Unknown savevm section or instance 's390_css'
+Description of problem:
+I have been working on merging QEMU 9.1.1 (directly from Debian unstable), and I'm seeing this problem when trying to migrate an s390x VM from an Oracular host (which runs QEMU 9.0.2) to a Plucky host (which runs QEMU 9.1.1).
+
+The problem only happens on s390x (host and guest), and only when attempting to migrate from Oracular to Plucky.  Migrations between Oracular guests work fine, as well as migrations between Plucky guests.
+
+This is the error I see after invoking `virsh migrate`:
+
+```
+error: internal error: QEMU unexpectedly closed the monitor (vm='kvmguest-jammy-normal'):
+2024-11-27T21:13:43.745625Z qemu-system-s390x: Unknown savevm section or instance 's390_css' 0. Make sure that your current VM setup matches your saved VM setup, including any hotplugged devices
+2024-11-27T21:13:43.746914Z qemu-system-s390x: load of migration failed: Invalid argument
+```
+Steps to reproduce:
+I only have one s390x machine available, so I am resorting to creating two LXD containers that are KVM-capable.  One of the containers runs Oracular, the other runs Plucky.  Please let me know if you would instructions on how to create such containers.
+
+Inside the Oracular container, using `uvt-kvm` to simplify the process of creating the VM:
+
+```
+# uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=s390x label=daily release=oracular
+# cat > guesttemplate.xml << _EOF_
+<domain type='kvm'>
+  <os>
+    <type>hvm</type>
+    <boot dev='hd'/>
+  </os>
+  <devices>
+    <interface type='network'>
+      <source network='default'/>
+      <model type='virtio'/>
+    </interface>
+    <console type='pty' tty='/dev/pts/3'>
+      <source path='/dev/pts/3'/>
+      <target type='sclp' port='0'/>
+      <alias name='console0'/>
+    </console>
+    <channel type='unix'>
+      <target type='virtio' name='org.qemu.guest_agent.0'/>
+    </channel>
+  </devices>
+</domain>
+_EOF_
+# uvt-kvm create --template /root/guesttemplate.xml --machine-type s390-ccw-virtio-9.0 --password=ubuntu --ssh-public-key-file /home/ubuntu/.ssh/authorized_keys kvmguest-oracular-upstream-cpu release=oracular arch=s390x label=daily
+```
+
+Wait a moment for the VM to boot, use `virsh list` to make sure it's running.  Note that we force the machine type to be `s390-ccw-virtio-9.0`; this is necessary because Ubuntu overrides the default machine type with its own definition, and we want to make sure to use upstream's type here.
+
+Make sure you're running QEMU 9.1.1 at least on the Plucky container.  Plucky currently ships with QEMU 9.0.2, which doesn't have the problem.  If needed, my QEMU 9.1.1 build can be found at https://launchpad.net/~sergiodj/+archive/ubuntu/qemu.
+
+After everything is in place, try to migrate the machine:
+
+```
+# virsh migrate --unsafe --live kvmguest-oracular-upstream-cpu qemu+ssh://plucky-container-IP-here/system
+error: internal error: QEMU unexpectedly closed the monitor (vm='kvmguest-oracular-upstream-cpu'): 2024-11-29T22:28:21.417201Z qemu-system-s390x: Unknown savevm section or instance 's390_css' 0. Make sure that your current VM setup matches your saved VM setup, including any hotplugged devices
+2024-11-29T22:28:21.417496Z qemu-system-s390x: load of migration failed: Invalid argument
+```
+Additional information:
+libvirt log from Oracular (QEMU 9.0.2):
+
+```
+LC_ALL=C \                                                                                                                                                                                                                                           [2/1817]
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/snap/bin \                                                                                                                                                                                           
+USER=root \                                                                                                                                                                                                                                                  
+HOME=/var/lib/libvirt/qemu/domain-3-kvmguest-oracular-up \
+XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-3-kvmguest-oracular-up/.local/share \
+XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-3-kvmguest-oracular-up/.cache \
+XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-3-kvmguest-oracular-up/.config \
+/usr/bin/qemu-system-s390x \
+-name guest=kvmguest-oracular-upstream-cpu,debug-threads=on \
+-S \
+-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-3-kvmguest-oracular-up/master-key.aes"}' \
+-machine s390-ccw-virtio-9.0,usb=off,dump-guest-core=off,memory-backend=s390.ram \
+-accel kvm \
+-cpu z13.2-base,aen=on,aefsi=on,diag318=on,msa5=on,msa4=on,msa3=on,msa2=on,msa1=on,sthyi=on,edat=on,ri=on,edat2=on,vx=on,ipter=on,cei=on,ap=on,gpereh=on,esop=on,ib=on,siif=on,ibs=on,apqi=on,apft=on,els=on,sief2=on,apqci=on,cte=on,ais=on,bpb=on,64bscao=on,ctop=on,ppa15=on,zpci=on,sea_esop2=on,te=on,cmm=on,gsls=on \
+-m size=524288k \
+-object '{"qom-type":"memory-backend-ram","id":"s390.ram","size":536870912}' \
+-overcommit mem-lock=off \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid fa8bcf1a-8982-47ab-9766-ebbb695008e3 \
+-display none \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=38,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot strict=on \
+-device '{"driver":"virtio-serial-ccw","id":"virtio-serial0","devno":"fe.0.0003"}' \
+-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MjQuMTA6czM5MHggMjAyNDExMjY=","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-3-format","read-only":true,"driver":"qcow2","file":"libvirt-3-storage","backing":null}' \
+-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu.qcow","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":"libvirt-3-format"}' \
+-device '{"driver":"virtio-blk-ccw","devno":"fe.0.0000","drive":"libvirt-2-format","id":"virtio-disk0","bootindex":1}' \
+-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu-ds.qcow","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \
+-device '{"driver":"virtio-blk-ccw","devno":"fe.0.0001","drive":"libvirt-1-format","id":"virtio-disk1"}' \
+-netdev '{"type":"tap","fd":"39","id":"hostnet0"}' \
+-device '{"driver":"virtio-net-ccw","netdev":"hostnet0","id":"net0","mac":"52:54:00:d8:f0:5c","devno":"fe.0.0002"}' \
+-chardev socket,id=charchannel0,fd=36,server=on,wait=off \
+-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \
+-chardev pty,id=charconsole0 \
+-device '{"driver":"sclpconsole","chardev":"charconsole0","id":"console0"}' \
+-audiodev '{"id":"audio1","driver":"none"}' \
+-device '{"driver":"virtio-balloon-ccw","id":"balloon0","devno":"fe.0.0004"}' \
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
+char device redirected to /dev/pts/3 (label charconsole0)
+2024-11-28 20:56:00.522+0000: initiating migration
+2024-11-28T20:56:01.114894Z qemu-system-s390x: Sibling indicated error 1
+warning: old compression is deprecated; use multifd compression methods instead
+warning: old compression is deprecated; use multifd compression methods instead
+warning: old compression is deprecated; use multifd compression methods instead
+warning: block migration is deprecated; use blockdev-mirror with NBD instead
+```
+
+libvirt log from Plucky (QEMU 9.1.1):
+
+```
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/snap/bin \
+USER=root \
+HOME=/var/lib/libvirt/qemu/domain-4-kvmguest-oracular-up \
+XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-4-kvmguest-oracular-up/.local/share \
+XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-4-kvmguest-oracular-up/.cache \
+XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-4-kvmguest-oracular-up/.config \
+/usr/bin/qemu-system-s390x \
+-name guest=kvmguest-oracular-upstream-cpu,debug-threads=on \
+-S \
+-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-4-kvmguest-oracular-up/master-key.aes"}' \
+-machine s390-ccw-virtio-9.0,usb=off,dump-guest-core=off,memory-backend=s390.ram \
+-accel kvm \
+-cpu z13.2-base,aen=on,aefsi=on,diag318=on,msa5=on,msa4=on,msa3=on,msa2=on,msa1=on,sthyi=on,edat=on,ri=on,edat2=on,vx=on,ipter=on,cei=on,ap=on,gpereh=on,esop=on,ib=on,siif=on,ibs=on,apqi=on,apft=on,els=on,sief2=on,apqci=on,cte=on,ais=on,bpb=on,64bscao=on,ctop=on,ppa15=on,zpci=on,sea_esop2=on,te=on,cmm=on,gsls=on \
+-m size=524288k \
+-object '{"qom-type":"memory-backend-ram","id":"s390.ram","size":536870912}' \
+-overcommit mem-lock=off \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid fa8bcf1a-8982-47ab-9766-ebbb695008e3 \
+-display none \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=35,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot strict=on \
+-device '{"driver":"virtio-serial-ccw","id":"virtio-serial0","devno":"fe.0.0003"}' \
+-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MjQuMTA6czM5MHggMjAyNDExMjY=","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-3-format","read-only":true,"driver":"qcow2","file":"libvirt-3-storage","backing":null}' \
+-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu.qcow","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":"libvirt-3-format"}' \
+-device '{"driver":"virtio-blk-ccw","devno":"fe.0.0000","drive":"libvirt-2-format","id":"virtio-disk0","bootindex":1}' \
+-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu-ds.qcow","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \
+-device '{"driver":"virtio-blk-ccw","devno":"fe.0.0001","drive":"libvirt-1-format","id":"virtio-disk1"}' \
+-netdev '{"type":"tap","fd":"36","id":"hostnet0"}' \
+-device '{"driver":"virtio-net-ccw","netdev":"hostnet0","id":"net0","mac":"52:54:00:d8:f0:5c","devno":"fe.0.0002"}' \
+-chardev socket,id=charchannel0,fd=34,server=on,wait=off \
+-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \
+-chardev pty,id=charconsole0 \
+-device '{"driver":"sclpconsole","chardev":"charconsole0","id":"console0"}' \
+-audiodev '{"id":"audio1","driver":"none"}' \
+-incoming defer \
+-device '{"driver":"virtio-balloon-ccw","id":"balloon0","devno":"fe.0.0004"}' \
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
+char device redirected to /dev/pts/3 (label charconsole0)
+2024-11-29T22:28:21.417201Z qemu-system-s390x: Unknown savevm section or instance 's390_css' 0. Make sure that your current VM setup matches your saved VM setup, including any hotplugged devices
+2024-11-29T22:28:21.417496Z qemu-system-s390x: load of migration failed: Invalid argument
+```
+
+Domain XML:
+
+```xml
+<domain type='kvm' id='3'>
+  <name>kvmguest-oracular-upstream-cpu</name>
+  <uuid>fa8bcf1a-8982-47ab-9766-ebbb695008e3</uuid>
+  <metadata>
+    <uvt:ssh_known_hosts xmlns:uvt="https://launchpad.net/uvtool/libvirt/1">ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDhWPh2Wfm2Ouh/W+H9IXJGFHfH4UVCB6+EBI0PwuDXR2Ocl4hTTSNPSX2LVS4MfVn9pgl5BK9MUVsMPfFjhmEhpNNt+rmaCelrDT8A7v/RoBY4IGEBFMhAkiwlI7pk3BrFoHEKtiijNLEWczdjMigZvhTs2amn8cUotFIsQSTpM7+7IX+m7clxfe6p59mVPjfMzBhwDG0GyV7CXdMpvsGlE2mPSacWWZ/baWIoFjKcmyQtTjSQleH1qSthI8rD5F7EyYd1Oa8Bo7vZ9j1/DPeGQRJPkebO81hPjm/1x1H5pTITIzARdNuBkM0yuDyqMQLP/u65WGinvXJYm20gEvMbiHGaT3il1QKKNEGmNGtY/SedRE8XQ58n090IBLz/3WJtjgQCY/SRgHUv7nMYYenmshvBfdue9kExJTjwWTRtT2R2UdkxS5UVye4vvDAY0DFuqX13wyvIeCU28MU+HpmnE31m9uXlVXXZxDuqGUBJ1PrDc4a40bvj9yTZTn9NEOs= root@localhost
+ssh-dss AAAAB3NzaC1kc3MAAACBAKqzgDKUGk6P/h6N5X4nJoHPr+MQzzXkotN8XEihvtWwvV1KYK+ioT69nA7ThEAZ6rPEjWPt7X4Sy6BcNd4j3kzlaXYLkrMJm3nohqbqQBDxCv8bhozy6HS/VDu95vrpnNFSiMRCfbBye0zyKfZsuRaPaKfHQ+8MnsBqSPxKajFrAAAAFQDuG3ZoanC+oZwMRYZ/am0vhfD+EwAAAIEAixSzoZr03kYZE+LcusyrasvZIqKF3P4M2vtzvFBPpPccFB5XoaqhWI4PvSxGYxZxlj9vRmSc8Yv56jdn8oDPIhFfgZVbDIkvpB2jQdb5VaRVWj7XwUcHB7B117Dr9qA6+6HJtBLRTDdTXzMQ+NhdFp42XCF+1qRefH9VPL9FoxwAAACAJa+u/YvaiGwT0DXBtTz4PgyFYmNHPvXBOVhDAw0likajBiuOdn8oL4KuWTafCq5ReDxXFaMML0OuT86+lSVt2naX0idyHjuSPkgmatozlpcz0kWYhuBl1B1sa3kr8xjDOUJlxkybqpdGJ5aoW+kRO+bpJLEzuXtu6Xshw5fOBZw= root@localhost
+ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHI8u/wAvZLJqIpAd5YSpu9VEaRQOxy0FKzyryeb3kjahkryKPhSX65miZ9Lx7oz5nORFsdeS2xR56ZQj+8HpqM= root@localhost
+ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDXY+MW1SikusLdkhPrni76LlaZB042p/DVItVeHRCCa root@localhost
+</uvt:ssh_known_hosts>
+  </metadata>
+  <memory unit='KiB'>524288</memory>
+  <currentMemory unit='KiB'>524288</currentMemory>
+  <vcpu placement='static'>1</vcpu>
+  <resource>
+    <partition>/machine</partition>
+  </resource>
+  <os>
+    <type arch='s390x' machine='s390-ccw-virtio-9.0'>hvm</type>
+    <boot dev='hd'/>
+  </os>
+  <cpu mode='custom' match='exact' check='partial'>
+    <model fallback='forbid'>z13.2-base</model>
+    <feature policy='require' name='aen'/>
+    <feature policy='require' name='aefsi'/>
+    <feature policy='require' name='diag318'/>
+    <feature policy='require' name='msa5'/>
+    <feature policy='require' name='msa4'/>
+    <feature policy='require' name='msa3'/>
+    <feature policy='require' name='msa2'/>
+    <feature policy='require' name='msa1'/>
+    <feature policy='require' name='sthyi'/>
+    <feature policy='require' name='edat'/>
+    <feature policy='require' name='ri'/>
+    <feature policy='require' name='edat2'/>
+    <feature policy='require' name='vx'/>
+    <feature policy='require' name='ipter'/>
+    <feature policy='require' name='cei'/>
+    <feature policy='require' name='ap'/>
+    <feature policy='require' name='gpereh'/>
+    <feature policy='require' name='esop'/>
+    <feature policy='require' name='ib'/>
+    <feature policy='require' name='siif'/>
+    <feature policy='require' name='ibs'/>
+    <feature policy='require' name='apqi'/>
+    <feature policy='require' name='apft'/>
+    <feature policy='require' name='els'/>
+    <feature policy='require' name='sief2'/>
+    <feature policy='require' name='apqci'/>
+    <feature policy='require' name='cte'/>
+    <feature policy='require' name='ais'/>
+    <feature policy='require' name='bpb'/>
+    <feature policy='require' name='64bscao'/>
+    <feature policy='require' name='ctop'/>
+    <feature policy='require' name='ppa15'/>
+    <feature policy='require' name='zpci'/>
+    <feature policy='require' name='sea_esop2'/>
+    <feature policy='require' name='te'/>
+    <feature policy='require' name='cmm'/>
+    <feature policy='require' name='gsls'/>
+  </cpu>
+  <clock offset='utc'/>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>destroy</on_crash>
+  <devices>
+    <emulator>/usr/bin/qemu-system-s390x</emulator>
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2'/>
+      <source file='/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu.qcow' index='2'/>
+      <backingStore type='file' index='3'>
+        <format type='qcow2'/>
+        <source file='/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MjQuMTA6czM5MHggMjAyNDExMjY='/>
+        <backingStore/>
+      </backingStore>
+      <target dev='vda' bus='virtio'/>
+      <alias name='virtio-disk0'/>
+      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0000'/>
+    </disk>
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2'/>
+      <source file='/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu-ds.qcow' index='1'/>
+      <backingStore/>
+      <target dev='vdb' bus='virtio'/>
+      <alias name='virtio-disk1'/>
+      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/>
+    </disk>
+    <controller type='pci' index='0' model='pci-root'>
+      <alias name='pci.0'/>
+    </controller>
+    <controller type='virtio-serial' index='0'>
+      <alias name='virtio-serial0'/>
+      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0003'/>
+    </controller>
+    <interface type='network'>
+      <mac address='52:54:00:d8:f0:5c'/>
+      <source network='default' portid='8b9c05f0-9534-4e05-afff-ec73e4a55b9c' bridge='virbr0'/>
+      <target dev='vnet1'/>
+      <model type='virtio'/>
+      <alias name='net0'/>
+      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0002'/>
+    </interface>
+    <console type='pty' tty='/dev/pts/3'>
+      <source path='/dev/pts/3'/>
+      <target type='sclp' port='0'/>
+      <alias name='console0'/>
+    </console>
+    <channel type='unix'>
+      <source mode='bind' path='/run/libvirt/qemu/channel/3-kvmguest-oracular-up/org.qemu.guest_agent.0'/>
+      <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/>
+      <alias name='channel0'/>
+      <address type='virtio-serial' controller='0' bus='0' port='1'/>
+    </channel>
+    <audio id='1' type='none'/>
+    <memballoon model='virtio'>
+      <alias name='balloon0'/>
+      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0004'/>
+    </memballoon>
+    <panic model='s390'/>
+  </devices>
+  <seclabel type='dynamic' model='apparmor' relabel='yes'>
+    <label>libvirt-fa8bcf1a-8982-47ab-9766-ebbb695008e3</label>
+    <imagelabel>libvirt-fa8bcf1a-8982-47ab-9766-ebbb695008e3</imagelabel>
+  </seclabel>
+  <seclabel type='dynamic' model='dac' relabel='yes'>
+    <label>+64055:+993</label>
+    <imagelabel>+64055:+993</imagelabel>
+  </seclabel>
+</domain>
+```
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_missing/449 b/gitlab/issues_text/target_s390x/host_missing/accel_missing/449
new file mode 100644
index 00000000..b8ca5ae9
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_missing/449
@@ -0,0 +1,68 @@
+s390x linux-user assertion fires in vector asm on master
+Description of problem:
+Seeing a assert being fired when running this go program that executes vector instructions:
+
+[ecdsaexample.go](/uploads/f5162a12747f93f060cfcabaea786d92/ecdsaexample.go)
+
+```
+qemu-s390x-static: ../qemu/target/s390x/translate.c:1063: get_field1: Assertion `have_field1(s, o)' failed.
+SIGABRT: abort
+PC=0x5b660 m=0 sigcode=4294967290
+
+goroutine 1 [running]:
+runtime.sigpanic()
+        /home/jalbrecht/s390x/15/go/src/runtime/signal_unix.go:723 fp=0xc000198998 sp=0xc000198998 pc=0x5b660
+crypto/elliptic.p256SqrInternalVMSL()
+        /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1488 fp=0xc0001989a0 sp=0xc0001989a0 pc=0xda600
+p256SqrInternal()
+        /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1695 +0x18 fp=0xc0001989d8 sp=0xc0001989a0 pc=0xd95b8
+crypto/elliptic.p256SqrAsm(0xc000198bc0, 0x20, 0x20, 0xc000198ce0, 0x20, 0x20, 0x0, 0xc, 0x30, 0x4000802560, ...)
+        /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1849 +0x3c fp=0xc0001989e0 sp=0xc0001989d8 pc=0xdaa6c
+crypto/elliptic.p256Sqr(...)
+        /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:81
+crypto/elliptic.p256Inverse(0xc000198bc0, 0x20, 0x20, 0xc000198ce0, 0x20, 0x20)
+        /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:324 +0x66 fp=0xc000198b28 sp=0xc0001989e0 pc=0xd7da6
+crypto/elliptic.initTable()
+        /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:436 +0x192 fp=0xc000198d00 sp=0xc000198b28 pc=0xd87d2
+crypto/elliptic.initP256Arch(...)
+        /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:57
+crypto/elliptic.initP256()
+        /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256.go:40 +0x2c0 fp=0xc000198d38 sp=0xc000198d00 pc=0xd2960
+crypto/elliptic.initAll()
+        /home/jalbrecht/s390x/15/go/src/crypto/elliptic/elliptic.go:397 +0x24 fp=0xc000198d40 sp=0xc000198d38 pc=0xd1ab4
+sync.(*Once).doSlow(0x2168e8, 0x122be8)
+        /home/jalbrecht/s390x/15/go/src/sync/once.go:66 +0x12c fp=0xc000198d98 sp=0xc000198d40 pc=0x7ee5c
+sync.(*Once).Do(...)
+        /home/jalbrecht/s390x/15/go/src/sync/once.go:57
+crypto/elliptic.P256(...)
+        /home/jalbrecht/s390x/15/go/src/crypto/elliptic/elliptic.go:433
+main.main()
+        /home/jalbrecht/s390x/ecdsaexample.go:17 +0x7de fp=0xc000198f80 sp=0xc000198d98 pc=0xe4a2e
+runtime.main()
+        /home/jalbrecht/s390x/15/go/src/runtime/proc.go:204 +0x214 fp=0xc000198fd8 sp=0xc000198f80 pc=0x472e4
+runtime.goexit()
+        /home/jalbrecht/s390x/15/go/src/runtime/asm_s390x.s:779 +0x2 fp=0xc000198fd8 sp=0xc000198fd8 pc=0x77c52
+
+r0   0x0        r1   0xc000198bc0
+r2   0xc000198ce0       r3   0xc000198ce0
+r4   0x1401a0   r5   0xc000198be0
+r6   0xc000198bc0       r7   0x1c00f0
+r8   0xda600    r9   0xc0001989a8
+r10  0x217810   r11  0x0
+r12  0x4000800378       r13  0xc000000180
+r14  0xda600    r15  0xc000198998
+pc   0x5b660    link 0xda600
+exit status 2
+```
+Steps to reproduce:
+On an amd64 linux host:
+1. Download attached ecdsaexample.go file
+2. Download and untar an s390x go distro (1.15 and 1.16 both show this issue): https://golang.org/dl/go1.15.13.linux-s390x.tar.gz 
+3. Build a qemu-s390x-static from current master
+4. qemu-s390x-static -E PATH=/path/to/s390x/15/go/bin -L /usr/s390x-linux-gnu /path/to/s390x/15/go/bin/go run ecdsaexample.go
+Additional information:
+@davidhildenbrand could you have a look? I tracked it down to this series of patches: https://lore.kernel.org/qemu-devel/20210608092337.12221-1-david@redhat.com/. I tried reverting just this series from current master and then the program runs with no issues.
+
+This crash is seen whenever eg. certificates are checked when connecting via https so it is likely to happen in real programs.
+
+cc: @ruixinbao
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_missing/457 b/gitlab/issues_text/target_s390x/host_missing/accel_missing/457
new file mode 100644
index 00000000..1bf6fdd6
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_missing/457
@@ -0,0 +1 @@
+qemu-system-s390x segfaults in do_tb_phys_invalidate at ../accel/tcg/translate-all.c:1482
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_missing/572 b/gitlab/issues_text/target_s390x/host_missing/accel_missing/572
new file mode 100644
index 00000000..fdd979bf
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_missing/572
@@ -0,0 +1 @@
+s390-pci-bus.h:85: warning: "PAGE_SIZE" redefined
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_missing/893 b/gitlab/issues_text/target_s390x/host_missing/accel_missing/893
new file mode 100644
index 00000000..9eb6eac4
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_missing/893
@@ -0,0 +1 @@
+Cannot boot and set rhel7 or 8 s390x on Redhat 8(Host OS) using qemu-system-s390x
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_missing/897 b/gitlab/issues_text/target_s390x/host_missing/accel_missing/897
new file mode 100644
index 00000000..2c66ae53
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_missing/897
@@ -0,0 +1 @@
+Warning with "qemu-s390x -cpu max"
diff --git a/gitlab/issues_text/target_s390x/host_missing/accel_missing/906 b/gitlab/issues_text/target_s390x/host_missing/accel_missing/906
new file mode 100644
index 00000000..edb50ff6
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_missing/accel_missing/906
@@ -0,0 +1 @@
+Cannot IPL this ISO image
diff --git a/gitlab/issues_text/target_s390x/host_s390/accel_KVM/2469 b/gitlab/issues_text/target_s390x/host_s390/accel_KVM/2469
new file mode 100644
index 00000000..a438135a
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_s390/accel_KVM/2469
@@ -0,0 +1 @@
+/s390x/migration/precopy/tcp/plain/switchover-ack may hang
diff --git a/gitlab/issues_text/target_s390x/host_s390/accel_TCG/2054 b/gitlab/issues_text/target_s390x/host_s390/accel_TCG/2054
new file mode 100644
index 00000000..b5ba2839
--- /dev/null
+++ b/gitlab/issues_text/target_s390x/host_s390/accel_TCG/2054
@@ -0,0 +1,42 @@
+chacha20-s390 broken in 8.2.0 in TCG on s390x
+Description of problem:
+When running linux guest in qemu-system-s390x in TCG mode, it fails at selftests of crypto algorithms, namely at chacha20:
+```
+[   10.546690] alg: skcipher: chacha20-s390 encryption test failed (wrong result) on test vector 1, cfg="in-place (one sglist)"
+[   10.546914] alg: self-tests for chacha20 using chacha20-s390 failed (rc=-22)
+[   10.546969] ------------[ cut here ]------------
+[   10.546998] alg: self-tests for chacha20 using chacha20-s390 failed (rc=-22)
+[   10.547182] WARNING: CPU: 1 PID: 109 at crypto/testmgr.c:5936 alg_test+0x55a/0x5b8
+[   10.547510] Modules linked in: net_failover chacha_s390(+) libchacha virtio_blk(+) failover
+[   10.547854] CPU: 1 PID: 109 Comm: cryptomgr_test Not tainted 6.5.0-5-s390x #1  Debian 6.5.13-1
+[   10.548002] Hardware name: QEMU 8561 QEMU (KVM/Linux)
+[   10.548101] Krnl PSW : 0704c00180000000 00000000005df8fe (alg_test+0x55e/0x5b8)
+[   10.548207]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
+[   10.548291] Krnl GPRS: 0000000000000000 0000000001286408 00000000005df8fa 0000000001286408
+[   10.548337]            000000000014bf14 00000000001c6ba8 0000000001838b3c 0000000000000005
+[   10.548475]            00000000025a4880 00000000025a4800 ffffffffffffffea 00000000ffffffea
+[   10.548521]            000000003e649200 00000000ffffffff 00000000005df8fa 000003800016bcf8
+[   10.549504] Krnl Code: 00000000005df8ee: c020003b5828    larl    %r2,0000000000d4a93e
+[   10.549504]            00000000005df8f4: c0e5ffdb62d2    brasl    %r14,000000000014be98
+[   10.549504]           #00000000005df8fa: af000000        mc    0,0
+[   10.549504]           >00000000005df8fe: a7f4fee6        brc    15,00000000005df6ca
+[   10.549504]            00000000005df902: b9040042        lgr    %r4,%r2
+[   10.549504]            00000000005df906: b9040039        lgr    %r3,%r9
+[   10.549504]            00000000005df90a: c020003b57df    larl    %r2,0000000000d4a8c8
+[   10.549504]            00000000005df910: 18bd        lr    %r11,%r13
+[   10.550004] Call Trace:
+[   10.550375]  [<00000000005df8fe>] alg_test+0x55e/0x5b8
+[   10.550467] ([<00000000005df8fa>] alg_test+0x55a/0x5b8)
+[   10.550489]  [<00000000005d9fbc>] cryptomgr_test+0x34/0x60
+[   10.550514]  [<000000000017d004>] kthread+0x124/0x130
+[   10.550539]  [<0000000000103124>] __ret_from_fork+0x3c/0x50
+[   10.550562]  [<0000000000b1dfca>] ret_from_fork+0xa/0x30
+[   10.550611] Last Breaking-Event-Address:
+[   10.550626]  [<000000000014bf20>] __warn_printk+0x88/0x110
+[   10.550723] ---[ end trace 0000000000000000 ]--- 
+```
+An interesting issue here - it does not happen on, say, amd64 host running qemu-system-s390x, but happens on s390x host.  I haven't tried other hosts though.
+
+Bisection points at v8.1.0-2627-gab84dc398b commit, "tcg/optimize: Optimize env memory operations".
+
+https://lore.kernel.org/qemu-devel/d5e8f88b-1d19-4e00-8dc2-b20e0cd34931@tls.msk.ru/T/#u is the original report on qemu-devel.
diff --git a/gitlab/issues_text/target_sh4/host_missing/accel_missing/2317 b/gitlab/issues_text/target_sh4/host_missing/accel_missing/2317
new file mode 100644
index 00000000..920b01b6
--- /dev/null
+++ b/gitlab/issues_text/target_sh4/host_missing/accel_missing/2317
@@ -0,0 +1,38 @@
+SH4:  ADDV instruction not emulated properly
+Description of problem:
+ADDV opcode is emulated incorrectly.
+
+The documentation says:
+
+`ADDV Rm, Rn        Rn + Rm -> Rn, overflow -> T`
+
+What Qemu actually emulates:
+
+`ADDV Rm, Rn        Rn + Rm -> Rm, overflow -> T`
+Steps to reproduce:
+```c
+#include <stdio.h>
+
+int main(void)
+{
+	register unsigned int a asm("r8") = 0x7fffffff;
+	register unsigned int b asm("r9") = 1;
+	register unsigned int c asm("r10");
+
+	asm volatile("clrt\n"
+		     "addv %2,%0\n"
+		     "movt %1\n"
+		     : "+r"(a), "=r"(c) : "r"(b) :);
+
+	printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c);
+
+	return 0;
+}
+
+```
+Additional information:
+Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints:
+`Values: a=0x80000000 b=0x1 c=0x1`
+
+Running with Qemu (and GCC 13.0), the same program prints:
+`Values: a=0x7fffffff b=0x80000000 c=0x1`
diff --git a/gitlab/issues_text/target_sh4/host_missing/accel_missing/2318 b/gitlab/issues_text/target_sh4/host_missing/accel_missing/2318
new file mode 100644
index 00000000..28438fb5
--- /dev/null
+++ b/gitlab/issues_text/target_sh4/host_missing/accel_missing/2318
@@ -0,0 +1,34 @@
+SH4: SUBV instruction not emulated properly
+Description of problem:
+SUBV opcode is emulated incorrectly.
+
+The documentation says:
+
+`SUBV Rm, Rn        Rn - Rm -> Rn, underflow -> T`
+
+Qemu seems to perform the subtraction correctly, but will not detect an underflow.
+Steps to reproduce:
+```c
+#include <stdio.h>
+
+int main(void)
+{
+	register unsigned int a asm("r8") = 0x80000001;
+	register unsigned int b asm("r9") = 0x2;
+	register unsigned int c asm("r10");
+
+	asm volatile("subv %2,%0\n"
+		     "movt %1\n"
+		     : "+r"(a), "=r"(c) : "r"(b) :);
+
+	printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c);
+
+	return 0;
+}
+```
+Additional information:
+Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints:
+`Values: a=0x7fffffff b=0x2 c=0x1`
+
+Running with Qemu (and GCC 13.0), the same program prints:
+`Values: a=0x7fffffff b=0x2 c=0x0`
diff --git a/gitlab/issues_text/target_sh4/host_missing/accel_missing/376 b/gitlab/issues_text/target_sh4/host_missing/accel_missing/376
new file mode 100644
index 00000000..90cd482a
--- /dev/null
+++ b/gitlab/issues_text/target_sh4/host_missing/accel_missing/376
@@ -0,0 +1 @@
+Indentation should be done with spaces, not with TABs, in the SH4 subsystem
diff --git a/gitlab/issues_text/target_sh4/host_missing/accel_missing/570 b/gitlab/issues_text/target_sh4/host_missing/accel_missing/570
new file mode 100644
index 00000000..bc9ee8c1
--- /dev/null
+++ b/gitlab/issues_text/target_sh4/host_missing/accel_missing/570
@@ -0,0 +1 @@
+linux-user/sh4/termbits.h:276: warning: "TIOCSER_TEMT" redefined
diff --git a/gitlab/issues_text/target_sh4/host_missing/accel_missing/856 b/gitlab/issues_text/target_sh4/host_missing/accel_missing/856
new file mode 100644
index 00000000..69ad12d0
--- /dev/null
+++ b/gitlab/issues_text/target_sh4/host_missing/accel_missing/856
@@ -0,0 +1,61 @@
+Occasional deadlock in linux-user (sh4) when running threadcount test
+Description of problem:
+
+Steps to reproduce:
+1. docker run --rm -it -u (id -u) -v $HOME:$HOME -w (pwd) qemu/debian-all-test-cross /bin/bash
+2. '../../configure' '--cc=clang' '--cxx=clang++' '--disable-system' '--target-list-exclude=microblazeel-linux-user,aarch64_be-linux-user,i386-linux-user,m68k-linux-user,mipsn32el-linux-user,xtensaeb-linux-user' '--extra-cflags=-fsanitize=undefined' '--extra-cflags=-fno-sanitize-recover=undefined'
+3. make; make build-tcg
+4. retry.py -n 400 -c -- timeout --foreground 90 ./qemu-sh4 -plugin ./tests/plugin/libinsn.so -d plugin ./tests/tcg/sh4-linux-user/threadcount
+
+Failure rate on hackbox:
+
+```
+Results summary:
+0: 397 times (99.25%), avg time 0.686 (0.00 varience/0.01 deviation)
+124: 3 times (0.75%), avg time 90.559 (0.00 varience/0.01 deviation)
+```
+
+It seems to fail more frequently on Gitlabs CI
+Additional information:
+Without the timeout you end up with a deadlock. The following backtrace was found, stepping in gdb unwedges the hang:
+
+```
+(gdb) info threads
+  Id   Target Id         Frame 
+* 1    LWP 15894 "qemu-sh4" safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75
+  2    LWP 15994 "qemu-sh4" 0x00007f956b800f59 in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
+  3    LWP 15997 "qemu-sh4" safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75
+(gdb) bt
+#0  safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75
+#1  0x0000560ee17196e4 in safe_futex (uaddr=0x58e8, op=-513652411, val=<optimized out>, timeout=0xf0, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:681
+#2  do_safe_futex (uaddr=0x58e8, op=-513652411, val=<optimized out>, timeout=0xf0, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:7757
+#3  0x0000560ee170c8d9 in do_syscall1 (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=22760, arg4=<optimized out>, arg5=<optimized out>, arg6=240, arg7=0, arg8=0) at /home/alex.bennee/lsrc/qemu.git/include/exec/cpu_ldst.h:90
+#4  0x0000560ee170220c in do_syscall (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>, arg5=<optimized out>, arg6=<optimized out>, arg7=<optimized out>, arg8=<optimized out>) at ../../linux-user/syscall.c:13239
+#5  0x0000560ee1626111 in cpu_loop (env=0x560ee294b028) at ../../linux-user/sh4/cpu_loop.c:43
+#6  0x0000560ee16ee37d in main (argc=-493657104, argv=0x7ffdcaf52028, envp=<optimized out>) at ../../linux-user/main.c:883
+(gdb) thread 2
+[Switching to thread 2 (LWP 15994)]
+#0  0x00007f956b800f59 in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
+(gdb) bt
+#0  0x00007f956b800f59 in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
+#1  0x0000560ee1847bd6 in qemu_futex_wait (f=<optimized out>, val=<optimized out>) at /home/alex.bennee/lsrc/qemu.git/include/qemu/futex.h:29
+#2  qemu_event_wait (ev=0x560ee2738974 <rcu_call_ready_event>) at ../../util/qemu-thread-posix.c:481
+#3  0x0000560ee18539a2 in call_rcu_thread (opaque=<optimized out>) at ../../util/rcu.c:261
+#4  0x0000560ee1847f17 in qemu_thread_start (args=0x560ee2933eb0) at ../../util/qemu-thread-posix.c:556
+#5  0x00007f956b8f6fa3 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
+#6  0x00007f956b8064cf in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
+(gdb) thread 3
+[Switching to thread 3 (LWP 15997)]
+#0  safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75
+75              cmp     $-4095, %rax
+(gdb) bt
+#0  safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75
+#1  0x0000560ee17196e4 in safe_futex (uaddr=0x2, op=-513652411, val=<optimized out>, timeout=0x3f7fcdc4, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:681
+#2  do_safe_futex (uaddr=0x2, op=-513652411, val=<optimized out>, timeout=0x3f7fcdc4, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:7757
+#3  0x0000560ee170c8d9 in do_syscall1 (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=2, arg4=<optimized out>, arg5=<optimized out>, arg6=1065340356, arg7=0, arg8=0) at /home/alex.bennee/lsrc/qemu.git/include/exec/cpu_ldst.h:90
+#4  0x0000560ee170220c in do_syscall (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>, arg5=<optimized out>, arg6=<optimized out>, arg7=<optimized out>, arg8=<optimized out>) at ../../linux-user/syscall.c:13239
+#5  0x0000560ee1626111 in cpu_loop (env=0x560ee2a2c2d8) at ../../linux-user/sh4/cpu_loop.c:43
+#6  0x0000560ee171728f in clone_func (arg=<optimized out>) at ../../linux-user/syscall.c:6608
+#7  0x00007f956b8f6fa3 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
+#8  0x00007f956b8064cf in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
+```
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/1771 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/1771
new file mode 100644
index 00000000..971b0ce1
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/1771
@@ -0,0 +1,33 @@
+Missing CASA instruction handling for SPARC qemu-user
+Description of problem:
+Qemu-sparc does not handle the CASA instruction, even if the selected CPU (in this case, LEON3) support it.
+Steps to reproduce:
+1. Launch a program that use CASA instruction (any program, also "ls" on a recent glibc [>=2.31])
+2. qemu-sparc will raise "Illegal instruction"
+Additional information:
+The following patch remove the missing handling, but it needs asi load/store that is not implemented for sparc32 user-space.
+
+```
+diff -urp qemu-20230327.orig/target/sparc/translate.c qemu-20230327/target/sparc/translate.c
+--- qemu-20230327.orig/target/sparc/translate.c 2023-03-27 15:41:42.000000000 +0200
++++ qemu-20230327/target/sparc/translate.c      2023-04-01 15:24:18.293176711 +0200
+@@ -5521,7 +5522,7 @@ static void disas_sparc_insn(DisasContex
+                 case 0x37: /* stdc */
+                     goto ncp_insn;
+ #endif
+-#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64)
++//#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64)
+                 case 0x3c: /* V9 or LEON3 casa */
+ #ifndef TARGET_SPARC64
+                     CHECK_IU_FEATURE(dc, CASA);
+@@ -5529,8 +5530,8 @@ static void disas_sparc_insn(DisasContex
+                     rs2 = GET_FIELD(insn, 27, 31);
+                     cpu_src2 = gen_load_gpr(dc, rs2);
+                     gen_cas_asi(dc, cpu_addr, cpu_src2, insn, rd);
++//#endif
+                     break;
+-#endif
+                 default:
+                     goto illegal_insn;
+                 }
+```
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2385 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2385
new file mode 100644
index 00000000..9e7869cf
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2385
@@ -0,0 +1,107 @@
+sparc: SIGILL stepping over `std` in gdb
+Description of problem:
+Certain cases of single-stepping thru the `std` store double-word instruction causes SIGILL fatal trap, while normal execution of the program is fine. Unfortunately I do not have access to real SPARC hardware so I cannot attest whether this is an emulation issue or not.
+
+My previous bugfix #2281 fixed any single-stepping in a debugger from panicking the kernel, associated with the `lda` on ASI_USERTXT in the `default_fuword32` function. I suspect further bugs like this could be related somehow. Perhaps a different instruction is used for the 64-bit access that needs a similar fix.
+
+This problem was experienced while testing some shell-spawning assembly:
+```
+-bash-4.3$ cat test.s
+.section ".text"
+.global main
+main:   
+        sethi  %hi(0x2f626800), %l6
+        or  %l6, 0x16e, %l6     ! 0x2f62696e
+        sethi  %hi(0x2f6b7000), %l7
+        or  %l7, 0x368, %l7     ! 0x2f6b7368
+        and  %sp, %sp, %o0
+        add  %sp, 0xc, %o1
+        xor  %o2, %o2, %o2
+        add  %sp, 0x14, %sp
+        std  %l6, [ %sp + -20 ]
+        clr  [ %sp + -12 ]
+        st  %sp, [ %sp + -8 ]
+        clr  [ %sp + -4 ]
+        mov  0x3b, %g1
+        ta  8
+        xor  %o7, %o7, %o0
+        mov  1, %g1
+        ta  8
+```
+
+```
+-bash-4.3$ gcc test.s -o test
+-bash-4.3$ ./test
+$ echo HELLO
+HELLO
+$ exit
+```
+
+As you can see the program works when ran directly from the shell, but when single-stepping in gdb, a SIGILL (illegal instruction) trap occurs
+```
+-bash-4.3$ gdb test
+GNU gdb (GDB) 7.4.1
+[...]
+(gdb) disas main
+Dump of assembler code for function main:
+   0x0001061c <+0>:     sethi  %hi(0x2f626800), %l6
+   0x00010620 <+4>:     or  %l6, 0x16e, %l6     ! 0x2f62696e
+   0x00010624 <+8>:     sethi  %hi(0x2f6b7000), %l7
+   0x00010628 <+12>:    or  %l7, 0x368, %l7     ! 0x2f6b7368
+   0x0001062c <+16>:    and  %sp, %sp, %o0
+   0x00010630 <+20>:    add  %sp, 0xc, %o1
+   0x00010634 <+24>:    xor  %o2, %o2, %o2
+   0x00010638 <+28>:    add  %sp, 0x14, %sp
+   0x0001063c <+32>:    std  %l6, [ %sp + -20 ]
+   0x00010640 <+36>:    clr  [ %sp + -12 ]
+   0x00010644 <+40>:    st  %sp, [ %sp + -8 ]
+   0x00010648 <+44>:    clr  [ %sp + -4 ]
+   0x0001064c <+48>:    mov  0x3b, %g1
+   0x00010650 <+52>:    ta  8
+   0x00010654 <+56>:    xor  %o7, %o7, %o0
+   0x00010658 <+60>:    mov  1, %g1
+   0x0001065c <+64>:    ta  8
+End of assembler dump.
+(gdb) b main
+Breakpoint 1 at 0x1061c
+(gdb) r
+Starting program: /export/home/bazz/iob/test 
+
+Breakpoint 1, 0x0001061c in main ()
+(gdb) si
+0x00010620 in main ()
+(gdb) 
+0x00010624 in main ()
+[...]
+Program received signal SIGILL, Illegal instruction.
+0x0001063c in main ()
+```
+
+However, if I continue execution _over_ the `std` instruction, the SIGILL does not occur. it will get to the usual SIGTRAP after execve,
+but then complains about memory accesses that I've never seen before.
+```
+(gdb) r
+Starting program: /export/home/bazz/iob/test 
+
+Breakpoint 1, 0x0001061c in main ()
+(gdb) c
+Continuing.
+
+Program received signal SIGTRAP, Trace/breakpoint trap.
+0xef783af4 in _rt_boot () from /usr/lib/ld.so.1
+(gdb) c
+Continuing.
+Cannot access memory at address 0x2800007
+Cannot access memory at address 0x2800003
+(gdb) c
+Continuing.
+Cannot access memory at address 0x2800007
+Cannot access memory at address 0x2800003
+(gdb) c
+Continuing.
+$ 
+```
+
+It does eventually get a shell though.
+
+On mdb, instead of single-stepping into a SIGILL, everything goes unresponsive after stepping the `std` instruction. Then I have to kill mdb.
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2773 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2773
new file mode 100644
index 00000000..1e1d8be9
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2773
@@ -0,0 +1,60 @@
+qemu-system-sparc64 sometimes generates endless loops
+Description of problem:
+Sometimes emulation "stops" in a busy loop hogging 1 cpu completely.
+gdb says:
+
+```
+0x00007d5805460ac5 in code_gen_buffer ()
+(gdb) info thread
+  Id   Target Id                     Frame 
+* 1    LWP 9166 of process 12669 ""  0x00007d5805460ac5 in code_gen_buffer ()
+  2    LWP 19293 of process 12669 "" 0x00007d584680803a in ____sigtimedwait50
+    () from /usr/lib/libc.so.12
+  3    LWP 20202 of process 12669 "" 0x00007d58468249ba in ___lwp_park60 ()
+   from /usr/lib/libc.so.12
+  4    LWP 12669 of process 12669 "" 0x00007d58467b72ca in _sys___pollts50 ()
+   from /usr/lib/libc.so.12
+(gdb) up
+#1  0x00000000007b3a0f in cpu_tb_exec (cpu=cpu@entry=0x7d58041ac680, 
+    itb=<optimized out>, tb_exit=tb_exit@entry=0x7d58037ffde8)
+    at ../accel/tcg/cpu-exec.c:458
+458	    ret = tcg_qemu_tb_exec(cpu_env(cpu), tb_ptr);
+
+(gdb) down
+#0  0x00007d5805460ac5 in code_gen_buffer ()
+(gdb) x/16i $pc
+=> 0x7d5805460ac5 <code_gen_buffer+19401368>:	mov    %r15,0x68(%rbp)
+   0x7d5805460ac9 <code_gen_buffer+19401372>:	xor    %r12,%r14
+   0x7d5805460acc <code_gen_buffer+19401375>:	mov    %r14,0x80(%rbp)
+   0x7d5805460ad3 <code_gen_buffer+19401382>:	mov    %r12,%rbx
+   0x7d5805460ad6 <code_gen_buffer+19401385>:	mov    %rbx,0x70(%rbp)
+   0x7d5805460ada <code_gen_buffer+19401389>:	mov    %r12,0x78(%rbp)
+   0x7d5805460ade <code_gen_buffer+19401393>:	mov    %r14,%r12
+   0x7d5805460ae1 <code_gen_buffer+19401396>:	shr    $0x20,%r12
+   0x7d5805460ae5 <code_gen_buffer+19401400>:	and    $0x1,%r12d
+   0x7d5805460ae9 <code_gen_buffer+19401404>:	dec    %r12
+   0x7d5805460aec <code_gen_buffer+19401407>:	and    %rbx,%r12
+   0x7d5805460aef <code_gen_buffer+19401410>:	mov    %r12d,%ebx
+   0x7d5805460af2 <code_gen_buffer+19401413>:	movb   $0x1,-0x4(%rbp)
+   0x7d5805460af6 <code_gen_buffer+19401417>:	cmp    %r13,%rbx
+   0x7d5805460af9 <code_gen_buffer+19401420>:	
+    je     0x7d5805460b20 <code_gen_buffer+19401459>
+   0x7d5805460aff <code_gen_buffer+19401426>:	
+    jmp    0x7d5805460b04 <code_gen_buffer+19401431>
+(gdb) list
+453	    if (qemu_loglevel_mask(CPU_LOG_TB_CPU | CPU_LOG_EXEC)) {
+454	        log_cpu_exec(log_pc(cpu, itb), cpu, itb);
+455	    }
+456	
+457	    qemu_thread_jit_execute();
+458	    ret = tcg_qemu_tb_exec(cpu_env(cpu), tb_ptr);
+459	    cpu->neg.can_do_io = true;
+460	    qemu_plugin_disable_mem_helpers(cpu);
+461	    /*
+462	     * TODO: Delay swapping back to the read-write region of the TB
+```
+Steps to reproduce:
+Unfortunately I have not been able to find a way to reliably reproduce this.
+Happens "often" to me, but not always.
+
+If you have any idea (like: what traces to enable) how to debug this I'll try to gather more information
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2775 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2775
new file mode 100644
index 00000000..f6b025c3
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2775
@@ -0,0 +1,134 @@
+internal assertion failure in sparc64 codegen: translate.c:5695:sparc_tr_insn_start: code should not be reached
+Description of problem:
+qemu crashes with internal assertion:
+
+ERROR:../target/sparc/translate.c:5695:sparc_tr_insn_start: code should not be reached
+Steps to reproduce:
+1. boot emulated NetBSD/sparc64 system
+2. cd /usr/tests && atf-run|atf-report
+
+not 100% reproducable, but happens often
+Additional information:
+last output:
+```
+IN: 
+0x4102ce80:  sethi  %hi(0x29e0000), %g1
+0x4102ce84:  b,a   0x40d78220
+
+----------------
+IN: 
+0x41029fc0:  sethi  %hi(0x1e30000), %g1
+0x41029fc4:  b,a   0x40e9ccc0
+
+----------------
+IN: 
+0x4102b5e0:  sethi  %hi(0x23b8000), %g1
+0x4102b5e4:  b,a   0x40e9dc20
+
+----------------
+IN: 
+0x4102a6e0:  sethi  %hi(0x1ff8000), %g1
+0x4102a6e4:  b,a   0x40e9cbc0
+
+----------------
+IN: 
+0x410230e0:  sethi  %hi(0x278000), %g1
+0x410230e4:  b,a   0x40e25d60
+
+----------------
+IN: 
+0x41026920:  sethi  %hi(0x1088000), %g1
+0x41026924:  b,a   0x40d77da0
+
+----------------
+IN: 
+0x41024140:  sethi  %hi(0x690000), %g1
+0x41024144:  b,a   0x40e25f00
+
+----------------
+IN: 
+0x00245c20:  sethi  %hi(0xc8000), %g1
+0x00245c24:  sethi  %hi(0x40d77c00), %g1
+0x00245c28:  jmp  %g1 + 0x1a0	! 0x40d77da0
+0x00245c2c:  nop 
+
+----------------
+IN: 
+0x00245ba0:  sethi  %hi(0xa8000), %g1
+0x00245ba4:  b,a   %xcc, 0x245920
+
+----------------
+IN: 
+0x00245ba0:  sethi  %hi(0xa8000), %g1
+0x00245ba4:  sethi  %hi(0x40d76c00), %g1
+0x00245ba8:  jmp  %g1 + 0x80	! 0x40d76c80
+0x00245bac:  nop 
+
+----------------
+IN: 
+0x00245e60:  sethi  %hi(0x158000), %g1
+0x00245e64:  b,a   %xcc, 0x245920
+
+----------------
+IN: 
+0x00245e60:  sethi  %hi(0x158000), %g1
+0x00245e64:  sethi  %hi(0x40d76400), %g1
+0x00245e68:  jmp  %g1 + 0x260	! 0x40d76660
+0x00245e6c:  nop 
+
+----------------
+IN: 
+0x002465a0:  sethi  %hi(0x328000), %g1
+0x002465a4:  sethi  %hi(0x40d69000), %g1
+0x002465a8:  jmp  %g1 + 0x198	! 0x40d69198
+0x002465ac:  nop 
+
+**
+ERROR:../target/sparc/translate.c:5695:sparc_tr_insn_start: code should not be reached
+```
+
+gdb says:
+```
+#0  0x000079343d6ebbfa in _lwp_kill () from /usr/lib/libc.so.12
+#1  0x000079343d6f7034 in abort ()
+    at /home/martin/current/src/lib/libc/stdlib/abort.c:74
+#2  0x000079343e06a03a in g_assertion_message[cold] ()
+   from /usr/pkg/lib/libglib-2.0.so.0
+#3  0x000079343e03c719 in g_assertion_message_expr ()
+   from /usr/pkg/lib/libglib-2.0.so.0
+#4  0x0000000000a23345 in sparc_tr_insn_start (dcbase=<optimized out>, 
+    cs=<optimized out>) at ../target/sparc/translate.c:5695
+#5  0x0000000000aa932f in translator_loop (cpu=cpu@entry=0x7933fac3be40, 
+    tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, 
+    max_insns=max_insns@entry=0x7933fa5d3d44, pc=pc@entry=1206519, 
+    host_pc=host_pc@entry=0x7933f52a58f7, 
+    ops=ops@entry=0xfac3c0 <sparc_tr_ops>, db=db@entry=0x7933fa5d3b80)
+    at ../accel/tcg/translator.c:152
+#6  0x0000000000a368ca in gen_intermediate_code (cs=cs@entry=0x7933fac3be40, 
+    tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, 
+    max_insns=max_insns@entry=0x7933fa5d3d44, pc=pc@entry=1206519, 
+    host_pc=host_pc@entry=0x7933f52a58f7) at ../target/sparc/translate.c:5816
+#7  0x0000000000aa7e90 in setjmp_gen_code (env=env@entry=0x7933fac3e5e0, 
+    tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, 
+    pc=pc@entry=1206519, host_pc=0x7933f52a58f7, 
+    max_insns=max_insns@entry=0x7933fa5d3d44, ti=<optimized out>)
+    at ../accel/tcg/translate-all.c:278
+#8  0x0000000000aa835d in tb_gen_code (cpu=cpu@entry=0x7933fac3be40, 
+    pc=pc@entry=1206519, cs_base=cs_base@entry=1206523, flags=2181038080, 
+    cflags=cflags@entry=-16777216) at ../accel/tcg/translate-all.c:358
+#9  0x0000000000aa135b in cpu_exec_loop (cpu=cpu@entry=0x7933fac3be40, 
+    sc=sc@entry=0x7933fa5d3e80) at ../accel/tcg/cpu-exec.c:993
+#10 0x0000000000aa1788 in cpu_exec_setjmp (cpu=cpu@entry=0x7933fac3be40, 
+    sc=sc@entry=0x7933fa5d3e80) at ../accel/tcg/cpu-exec.c:1039
+#11 0x0000000000aa1f8d in cpu_exec (cpu=cpu@entry=0x7933fac3be40)
+    at ../accel/tcg/cpu-exec.c:1065
+#12 0x0000000000abb53d in tcg_cpu_exec (cpu=cpu@entry=0x7933fac3be40)
+    at ../accel/tcg/tcg-accel-ops.c:78
+#13 0x0000000000abb6ae in mttcg_cpu_thread_fn (arg=arg@entry=0x7933fac3be40)
+    at ../accel/tcg/tcg-accel-ops-mttcg.c:95
+#14 0x0000000000c7f750 in qemu_thread_start (args=0x79343aef7520)
+    at ../util/qemu-thread-posix.c:541
+#15 0x000079343d98c145 in pthread__create_tramp (cookie=0x79343c583000)
+    at /home/martin/current/src/lib/libpthread/pthread.c:595
+#16 0x000079343d5d1310 in ?? () from /usr/lib/libc.so.12
+```
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2802 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2802
new file mode 100644
index 00000000..c77e9a5f
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2802
@@ -0,0 +1,26 @@
+Sparc: fdtox/fqtox instructions incorrectly select destination register
+Description of problem:
+This bug report is mostly for informational purposes as I will be posting a fix for the bug.
+
+The `fdtox` and `fqtox` instructions incorrectly select the destination register when the destination register is higher than `f31`.
+Steps to reproduce:
+1. Install Sparc cross compiler `gcc-12-sparc64-linux-gnu`(in Debian)
+2. Compile the test program using `sparc64-linux-gnu-gcc-12 -m64 -o test_program -static test_program.c`
+3. Run the test program using `qemu-sparc64-static ./test_program`
+4. Expected output is 60. Prints 0 instead.
+Additional information:
+Test program to test the issue:
+
+```c
+#include <stdio.h>
+
+int main(int argc, char** argv) {
+    long long truncated = 0;
+    __asm__("fdtox %0,%%f32\n\t" :: "f"(60.0));
+    __asm__("fmovd %%f32,%0\n\t" : "=f"(truncated));
+    printf("%lld\n", truncated);
+    return 0;
+}
+```
+
+The issue is caused by the commit 0bba7572d4. Where certain changes were made in the way destination registers are selected(moving the DFPREG/QFPREG to decodetree).
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/740 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/740
new file mode 100644
index 00000000..30fa2936
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/740
@@ -0,0 +1,27 @@
+on single core Raspberry Pi, qemu-system-sparc appears to hang in bios
+Description of problem:
+I suspect it to be a race condition related to running on the slow single core Raspberry Pi, as I haven't managed to reproduce on x86 even when using taskset to tie qemu to a single core.
+
+The problem occurs about 4 out of 5 runs on qemu 5.2 (raspbian bullseye) and so far 100% of the time on qemu 6.1.
+
+About five seconds after start the sparc bios gets as far as `ttya initialized` and then appears to hang indefinitely.
+
+Instead, it should continue after about 3 more seconds with:
+```
+Probing Memory Bank #0 32 Megabytes
+Probing Memory Bank #1 Nothing there
+Probing Memory Bank #2 Nothing there
+Probing Memory Bank #3 Nothing there
+```
+
+See below for workaround.
+Steps to reproduce:
+1. Need a single core Raspberry Pi running raspbian, such as Raspberry Pi 1 or Zero
+2. Download ss5.bin from https://github.com/andarazoroflove/sparc/raw/master/ss5.bin
+3. Run the command:
+```
+qemu-system-sparc -m 32 -bios ss5.bin -nographic
+```
+After about 5 seconds of output it hangs at `ttya initialized`
+Additional information:
+##
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/847 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/847
new file mode 100644
index 00000000..38a2e4c2
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/847
@@ -0,0 +1,30 @@
+rdhpr %htstate unimplemented in translator
+Description of problem:
+I accidentally mixed up a copy of T1 and T2 sun4v firmwares and was able to trigger the following TCG assert ``tcg_reg_alloc_mov: Assertion `ts->val_type == TEMP_VAL_REG' failed.`` upon boot.
+
+Having discovered my mistake I was expecting the guest to crash at some point but without triggering an
+assert.
+Steps to reproduce:
+1. Download the attached file bug.tar.gz and extract it
+
+2. Apply the following diff to update the UART address for the T2 firmware
+
+```
+diff --git a/hw/sparc64/niagara.c b/hw/sparc64/niagara.c
+index ccad2c43a3..7af64bd50f 100644
+--- a/hw/sparc64/niagara.c
++++ b/hw/sparc64/niagara.c
+@@ -51,7 +51,7 @@ typedef struct NiagaraBoardState {
+ 
+ #define NIAGARA_PARTITION_RAM_BASE 0x80000000ULL
+ 
+-#define NIAGARA_UART_BASE   0x1f10000000ULL
++#define NIAGARA_UART_BASE   0xfff0c2c000ULL
+ 
+ #define NIAGARA_NVRAM_BASE  0x1f11000000ULL
+ #define NIAGARA_NVRAM_SIZE  0x2000
+```
+
+3. Run `./qemu-system-sparc64 -M niagara -L ./bug/ -m 256 -nographic`
+Additional information:
+
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1058 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1058
new file mode 100644
index 00000000..ee8d189e
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1058
@@ -0,0 +1,8 @@
+NetBSD Sparc 8.2 OS doesn't seem to accept keyboard input (-nographic)
+Description of problem:
+The NetBSD appears to boot to the login prompt successfully, but when the login prompt appears, the system doesn't appear to recognize keyboard input and so I cannot login (I can't seem to boot into single user mode for the same reason). I can see the characters being typed on the terminal, but pressing the Enter key to submit input results in nothing.
+
+I've confirmed that this is an issue with NetBSD because I also attempted to spin up a Solaris 8 VM and a Solaris 2.6 VM with the `-nographic` flag turned on, and I was able to log in and interact with both of those virtual machines.
+Steps to reproduce:
+1. Use RHEL 8.6 as the base OS (**Update:** I've discovered that this error occurs under a different host OS too (Ubuntu 20.04 LTS in my case)
+2. Start the NetBSD VM running the command as specified above
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1127 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1127
new file mode 100644
index 00000000..918d9737
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1127
@@ -0,0 +1,129 @@
+Various problems with running SunOS 4.1.4
+Description of problem:
+Yes, I know, SunOS 4.1.4 is ancient, but I happened to find an original Solaris 1.1.2/SunOS 4.1.4 installation CD, and nostalgia got the better of me.
+
+It used to be possible to run SunOS 4.1.4 in QEMU 5.0.0, but starting with 6.0.0, whenever you try to boot, you see the following whenever SunOS tries to access a SCSI disk:
+
+```
+ok boot disk
+Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0  File and args: 
+root on /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@3,0:a fstype 4.2
+Boot: vmunix
+Size: 1548288+463688+225704 bytes
+SuperSPARC: PAC ENABLED
+SunOS Release 4.1.4 (GENERIC) #2: Fri Oct 14 11:09:47 PDT 1994
+Copyright (c) 1983-1993, Sun Microsystems, Inc.
+cpu = SUNW,SPARCstation-20
+mod0 = TI,TMS390Z50 (mid = 8)
+mem = 523836K (0x1ff8f000)
+avail mem = 510947328
+cpu0 at Mbus 0x8 0x240000
+entering uniprocessor mode
+Ethernet address = 52:54:0:12:34:56
+espdma0 at  SBus slot f 0x400000
+esp0 at  SBus slot f 0x800000 pri 4 (onboard)
+esp0:   data transfer overrun
+        State=DATA Last State=DATA_DONE
+        Latched stat=0x11<XZERO,IO> intr=0x10<BUS> fifo 0x0
+        last msg out: EXTENDED; last msg in: COMMAND COMPLETE
+        DMA csr=0xa4240030<FLSH,INTEN>
+        addr=fff00034 last=fff00010 last_count=24
+        Cmd dump for Target 3 Lun 0:
+        cdb=[ 0x12 0x0 0x0 0x0 0x24 0x0 ]
+        pkt_state 0xf<XFER,CMD,SEL,ARB> pkt_flags 0x9 pkt_statistics 0x0
+        cmd_flags=0x5 cmd_timeout 0
+        Mapped Dma Space:
+                Base = 0x10 Count = 0x24
+        Transfer History:
+                Base = 0x10 Count = 0x24
+        current phase 0x26=DATAIN       stat=0x11       0x24
+        current phase 0x1=CMD_START     stat=0x12       0x12
+        current phase 0x60=SELECT_SNDMSG        stat=0x7        0x3     0x0
+        current phase 0x23=SYNCHOUT     stat=0x7        0x19    0xf
+        current phase 0xb=CMD_CMPLT     stat=0x7        0x0
+        current phase 0x27=STATUS       stat=0x7        0x0
+        current phase 0xb=CMD_CMPLT     stat=0x13
+        current phase 0x80=SEL_NO_ATN   stat=0x0        0x3     0x0
+        current phase 0x1=CMD_START     stat=0x0        0x0     0x80
+        current phase 0x1c=RESET        stat=0x0        0x1f
+```
+
+This causes SunOS to ignore the disk, and later it tries to boot via ethernet instead.
+
+After some digging, I *think* I tracked down the problem.
+
+This commit seems to be what did it:
+
+commit 799d90d818ba38997e9f5de2163bbfc96256ac0b
+Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
+Date:   Thu Mar 4 22:10:58 2021 +0000
+
+    esp: transition to message out phase after SATN and stop command
+    
+    The SCSI bus should remain in the message out phase after the SATN and stop
+    command rather than transitioning to the command phase. A new ESPState variable
+    cmdbuf_cdb_offset is added which stores the offset of the CDB from the start
+    of cmdbuf when accumulating extended message out phase data.
+    
+    Currently any extended message out data is discarded in do_cmd() before the CDB
+    is processed in do_busid_cmd().
+    
+    Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
+    Reviewed-by: Laurent Vivier <laurent@vivier.eu>
+    Message-Id: <20210304221103.6369-38-mark.cave-ayland@ilande.co.uk>
+
+I determined this by rummaging through the changes to the esp.c driver between 5.0.0 and 6.0.0 until I stumbled across this one. I can make the problem go away with this simple change:
+
+```
+--- esp.c.orig  2022-04-19 12:10:27.000000000 -0700
++++ esp.c       2022-07-25 19:57:06.602665000 -0700
+@@ -433,7 +433,7 @@
+         trace_esp_handle_satn_stop(fifo8_num_used(&s->cmdfifo));
+         s->do_cmd = 1;
+         s->cmdfifo_cdb_offset = 1;
+-        s->rregs[ESP_RSTAT] = STAT_MO;
++        s->rregs[ESP_RSTAT] = STAT_TC | STAT_CD /*STAT_MO*/;
+         s->rregs[ESP_RINTR] |= INTR_BS | INTR_FC;
+         s->rregs[ESP_RSEQ] = SEQ_MO;
+         esp_raise_irq(s);
+```
+
+NOTE: I am not sure if this is a proper fix, as I don't know enough about SCSI or the esp controller. All I know is putting this back the way it was makes SunOS happy again. Unfortunately it may also break something else, so somebody more knowledgeable than I should investigate further.
+
+If you're worried that reproducing this will be difficult, don't be. I prepared detailed instructions, scripts and all the images you should need to create a virtual SunOS disk and install the OS on it. This includes the OpenProm images and installation ISO. 
+
+You can find everything here (consult readme.txt for details):
+
+http://people.freebsd.org/~wpaul/sunos-qemu
+
+The quick install option is very simple. Once you finish writing the OS to the disk and try to boot off it the first time, you should encounter the error above.
+
+But wait, there's more.
+
+SunOS 4 has this quirk where it only works with CD-ROM drives that report a block size of 512 bytes, instead of the default of 2048. Now, I realize that just recently, there was a change committed that allows the guest to change the block size with the MODE SELECT command. However this doesn't seem to be good enough for SunOS (I tried it, it still hates the drive). Note that scsi-disk.c hard codes the block size for CD-ROMs to 2058 in scsi_cd_realize(). What would be really nice is if was possible to override this from the command line, and that addresses the problem quite nicely.
+
+At the same URL above, I also provided a small patch to scsi-disk.c which implements this feature. This allows the user to set the initial block size with logical_block_size=512 when specifying the device parameters. The qemu_sparc5.sh and qemu_sparc20.sh scripts show an example of this.
+
+One more thing: I wanted to simulate a SPARCstation 20, but I found that SunOS 4 would panic when I tried to boot it with this configuration, even if I used the correct SS20 OpenProm image. The problem here has to do with the SUNW,DBRIe device. QEMU doesn't simulate this device, but it creates dummy resources for it, including a PROM space. The problem is that this space is empty. This causes the OpenProm to create a node with an empty "name" property, which is a condition the SunOS kernel doesn't expect. The result is that the kernel tries to dereference a NULL pointer and panics. (The OpenProm code itself seems to let it slide.)
+
+To work around this, I patched the sun4m.c code to create the SUNW,DBRIe device such that its PROM space can actually be populated with an FCode image, and I created a simple one with a valid name property so that the kernel doesn't panic. SunOS complains later that it can't find the audio device because it's not actually implemented, but at least it doesn't crash.
+
+I don't know how this would actually be addressed in QEMU proper since the existing FCode images that QEMU uses come from OpenBios.
+
+Finally, one thing I haven't figured out is that using the -smp flag with SunOS 4 never seems to work. The OpenProms and the SunOS kernel only ever seem to detect one CPU. I am not that broken up about this though, because SunOS 4 never really did SMP very well to begin with.
+Steps to reproduce:
+Download all the files at:
+
+http://people.freebsd.org/~wpaul/sunos-qemu
+
+You can download just:
+
+http://people.freebsd.org/~wpaul/sunos-qemu/sunos-qemu.tar.gz
+
+if you want everything in one shot.
+
+Read the readme.txt file. This will walk you through trying to create a bootable SunOS system. You should apply the CD-ROM patch to scsi-disk.c and use the qemu_sparc5.sh script initially. This should allow you to install the miniroot from the CD image onto the virtual hard drive, but it will fail booting due to the esp controller problem. The qemu_sparc20.sh script will only boot successfully if you apply the sun4m.c patch and copy QEMU,dbri.bin to the QEMU firmware directory.
+Additional information:
+I'm not planning to provide a pull request for any of this. As I said, I'm not sure if my fixes are necessarily correct (especially the esp.c one). I'm satisfied that they work for me, but I want to leave it to the appropriate maintainers do decide how to best deal with these things.
+
+I would be happy to answer questions and test candidate fixes though.
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1132 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1132
new file mode 100644
index 00000000..9bea199f
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1132
@@ -0,0 +1,115 @@
+[SPARC/Leon3] Application compiled by RCC 1.2 won't start
+Description of problem:
+Even simple "hello world" application compiled by Gaisler RCC 1.2 compiler ("space-certified" GCC 4.4.6 with RTEMS OS) for Leon3 CPU won't start on QEMU - QEMU silently exits before getting into `Init`.
+
+In real hardware it works.
+
+(I know that the GCC 4.4.6 is quite ancient now, usage of this toolchain is forced)
+Steps to reproduce:
+Steps provided for Windows system, but I suspect it works exactly the same in Linux system.
+
+1. Get `sparc-rtems-4.10-gcc-4.4.6-1.2.25-mingw` GCC from here: https://www.gaisler.com/anonftp/rcc/rcc-1.2/1.2.25/
+2. Unpack it to `c:\opt` (it doesn't work from other directories. `/opt` for Linux)
+3. Create simple "Hello world" RTEMS application.
+4. Run it by `qemu-system-sparc -machine leon3_generic -nographic -monitor null -serial stdio -m 64M -kernel fail.elf`
+5. Result is exiting before getting into `Init`.
+
+Simple example attached (with ELF). It should print `It works. Exiting.` and exit.
+
+[leon3-rcc-start-fail.zip](/uploads/69d79dcc496e86bb07d5c69212d94ced/leon3-rcc-start-fail.zip)
+Additional information:
+Log:
+
+```
+...
+
+----------------
+IN: ambapp_for_each_dev
+0x40005430:  clr  %o0   ! 0x0
+0x40005434:  ret
+0x40005438:  restore  %g0, %o0, %o0
+
+----------------
+IN: amba_initialize
+0x40003aa8:  cmp  %o0, 0
+0x40003aac:  be  0x40003b4c
+0x40003ab0:  nop
+
+----------------
+IN: amba_initialize
+0x40003b4c:  mov  1, %g1
+0x40003b50:  ta  0
+
+     1: Trap Instruction (v=80)
+pc: 40003b50  npc: 40003b54
+%g0-7: 00000000 00000001 00000000 00000000 00000000 00000000 400007c0 00000000
+%o0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe60 40003aa0
+%l0-7: 40025800 00000000 00000000 00000000 00000000 00000000 00000000 00000000
+%i0-7: 00000000 00000000 00000000 00000000 00000000 00000000 43fffec0 40002b78
+psr: f3400fe5 (icc: -Z-- SPE: SPE) wim: 00000002
+fsr: 00000000 y: ffffffff
+
+----------------
+IN:
+0x40003a18:  cmp  %g1, 3
+0x40003a1c:  bne  0x40003a34
+0x40003a20:  and  %i0, 0xf00, %l4
+
+----------------
+IN:
+0x40003a34:  ta  0
+
+     2: Trap Instruction (v=80)
+pc: 40003a34  npc: 40003a38
+%g0-7: 00000000 00000001 00000000 00000000 00000000 00000000 400007c0 00000000
+%o0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe00 40005470
+%l0-7: f3400fc4 40003b50 40003b54 00000080 00000000 40026ab8 00000000 fffff800
+%i0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe60 40003aa0
+psr: f3900fc4 (icc: N--C SPE: SP-) wim: 00000002
+fsr: 00000000 y: ffffffff
+
+     3: Trap Instruction (v=80)
+pc: 40003a34  npc: 40003a38
+%g0-7: 00000000 00000001 00000000 00000000 00000000 00000000 400007c0 00000000
+%o0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe00 40005470
+%l0-7: f3400fc4 40003b50 40003b54 00000080 00000000 40026ab8 00000000 fffff800
+%i0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe60 40003aa0
+psr: f3900fc4 (icc: N--C SPE: SP-) wim: 00000002
+fsr: 00000000 y: ffffffff
+
+// repeating until sudden and quiet exit from QEMU
+```
+
+After digging it seems that target code requires byte access to GRLIB APB PNP registers that is not implemented in QEMU now. 
+Adding code supporting byte access seems to help.
+
+The quick patch is:
+
+```
+--- a/hw/misc/grlib_ahb_apb_pnp.c
++++ b/hw/misc/grlib_ahb_apb_pnp.c
+@@ -249,6 +249,11 @@ static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr offset, unsigned size)
+     val = apb_pnp->regs[offset >> 2];
+     trace_grlib_apb_pnp_read(offset, val);
+ 
++    if (size == 1) {
++        val >>= (24 - (offset & 3) * 8);
++        val &= 0x0ff;
++    }
++
+     return val;
+ }
+ 
+@@ -263,7 +268,7 @@ static const MemoryRegionOps grlib_apb_pnp_ops = {
+     .write      = grlib_apb_pnp_write,
+     .endianness = DEVICE_BIG_ENDIAN,
+     .impl = {
+-        .min_access_size = 4,
++        .min_access_size = 1,
+         .max_access_size = 4,
+     },
+ };
+
+```
+
+The custom compiled QEMU with this patch is used in project for over half a year and it works fine, but I don't know if it is a proper fix.
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1163 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1163
new file mode 100644
index 00000000..8a1640fb
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1163
@@ -0,0 +1,11 @@
+qemu doesn't boot Solaris 2.2
+Description of problem:
+Booting from the CDROM hangs
+Steps to reproduce:
+1. Run the command line above with a fresh disk image
+2. The console contains:
+```
+Trying cdrom:d...
+(is ?
+```
+3. No further progress
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1166 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1166
new file mode 100644
index 00000000..9e82affa
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1166
@@ -0,0 +1,25 @@
+Solaris 2.6 panic when debugging with gdb
+Description of problem:
+Running gdb with a breakpoint that gets hit triggers a panic:
+```
+non parity synchronous error ctx=fa va=ef7d97c pa=c1a47c
+```
+
+One time I got of the following messages as well
+```
+processor level 12 onboard interrupt not serviced
+processor level 12 onboard interrupt not serviced
+...
+```
+Steps to reproduce:
+1. Install Solaris 2.6 using https://learn.adafruit.com/build-your-own-sparc-with-qemu-and-solaris?view=all
+2. Install https://archive.org/details/sun26gnu
+3. Install http://download.nust.na/pub3/solaris/sunfreeware/pub/unixpackages/sparc/5.6/gdb-6.8-sol26-sparc-local.gz
+4. Install http://download.nust.na/pub3/solaris/sunfreeware/pub/unixpackages/sparc/5.6/gcc-2.95.3-sol26-sparc-local.gz
+5. Build a simple hello world program with debugging information
+6.
+```
+gdb ./hello
+(gdb) break main
+(gdb) run
+```
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1394 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1394
new file mode 100644
index 00000000..d27361e1
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1394
@@ -0,0 +1,61 @@
+Byte-swapping issue in getresuid on qemu-user-sparc64
+Description of problem:
+When calling getresuid() in the big-endian sparc64 guest, the uid_t values are written with their 16-bit halves reversed.
+
+For example, the UID 0x000003e8 (1000) becomes 0x03e80000.
+Steps to reproduce:
+A minimal test case looks like this:
+```c
+#define _GNU_SOURCE
+#include <stdio.h>
+#include <sys/types.h>
+#include <pwd.h>
+#include <unistd.h>
+
+int main(int argc, char **argv) {
+	struct passwd *pw = getpwuid(geteuid());
+	if (pw == NULL) {
+		perror("getpwuid failure");
+		return 1;
+	}
+	printf("getpwuid()->pw_uid=0x%08x\n", pw->pw_uid);
+
+	uid_t ruid = 0, euid = 0, suid = 0;
+	if (getresuid(&ruid, &euid, &suid) != 0) {
+		perror("getresuid failure");
+		return 1;
+	}
+	printf("getresuid()->suid=0x%08x\n", suid);
+
+	return 0;
+}
+```
+
+Compile and run with:
+```
+$ sparc64-linux-gnu-gcc -Wall -O0 -g -o sid-sparc64/test test.c
+$ sudo chroot sid-sparc64
+[chroot] $ qemu-sparc64-static ./test
+```
+
+Alternatively, static compilation without a chroot is also possible (despite a warning about `getpwuid()`):
+```
+$ sparc64-linux-gnu-gcc -static -Wall -O0 -g -o test test.c
+$ qemu-sparc64-static ./test
+```
+
+Expected output:
+```
+$ ./test 
+getpwuid()->pw_uid=0x000003e8
+getresuid()->suid=0x000003e8
+```
+
+Actual output:
+```
+$ ./test 
+getpwuid()->pw_uid=0x000003e8
+getresuid()->suid=0x03e80000
+```
+Additional information:
+I'm not sure if this is a glibc, qemu or kernel issue, but it doesn't occur outside qemu.
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1564 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1564
new file mode 100644
index 00000000..b25f81c3
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1564
@@ -0,0 +1,70 @@
+stat64 on sparc64 failed to get correct major/minor dev
+Description of problem:
+The reported device major/minor is not correct, e.g: stat /dev/zero:
+Reported: Device type: 0,10500000
+Correct : Device type: 1,5
+Steps to reproduce:
+1. "stat /dev/zero" or "ls -l /dev/zero"
+Additional information:
+The problem is a missing padding into target_stat64 struct related to sparc64. Here patch to solve the issue (it also fixes some incorrect variables size):
+
+```
+--- qemu-20230327/linux-user/syscall_defs.h	2023-03-27 15:41:42.000000000 +0200
++++ qemu-20230327/linux-user/syscall_defs.h.new	2023-03-27 21:43:25.615115126 +0200
+@@ -1450,7 +1450,7 @@ struct target_stat {
+ 	unsigned int	st_dev;
+ 	abi_ulong	st_ino;
+ 	unsigned int	st_mode;
+-	unsigned int	st_nlink;
++	short int	st_nlink;
+ 	unsigned int	st_uid;
+ 	unsigned int	st_gid;
+ 	unsigned int	st_rdev;
+@@ -1465,8 +1465,7 @@ struct target_stat {
+ 
+ #define TARGET_HAS_STRUCT_STAT64
+ struct target_stat64 {
+-	unsigned char	__pad0[6];
+-	unsigned short	st_dev;
++	uint64_t	st_dev;
+ 
+ 	uint64_t	st_ino;
+ 	uint64_t	st_nlink;
+@@ -1476,14 +1475,13 @@ struct target_stat64 {
+ 	unsigned int	st_uid;
+ 	unsigned int	st_gid;
+ 
+-	unsigned char	__pad2[6];
+-	unsigned short	st_rdev;
++	unsigned int	__pad0;
++	uint64_t	st_rdev;
+ 
+         int64_t		st_size;
+ 	int64_t		st_blksize;
+ 
+-	unsigned char	__pad4[4];
+-	unsigned int	st_blocks;
++	int64_t		st_blocks;
+ 
+ 	abi_ulong	target_st_atime;
+ 	abi_ulong	target_st_atime_nsec;
+@@ -1522,8 +1520,7 @@ struct target_stat {
+ 
+ #define TARGET_HAS_STRUCT_STAT64
+ struct target_stat64 {
+-	unsigned char	__pad0[6];
+-	unsigned short	st_dev;
++	uint64_t st_dev;
+ 
+ 	uint64_t st_ino;
+ 
+@@ -1533,8 +1530,7 @@ struct target_stat64 {
+ 	unsigned int	st_uid;
+ 	unsigned int	st_gid;
+ 
+-	unsigned char	__pad2[6];
+-	unsigned short	st_rdev;
++	uint64_t        st_rdev;
+ 
+ 	unsigned char	__pad3[8];
+```
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1609 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1609
new file mode 100644
index 00000000..612f56dc
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1609
@@ -0,0 +1,19 @@
+SPARC emulation: userspace program run from gdb crashes OS running in emulator
+Description of problem:
+SPARC emulation: userspace program run from gdb crashes OS running in emulator
+Steps to reproduce:
+As a user (not root!):
+1. as -Q n -K PIC -b -L mandelbrot.s
+2. ld -m a.out -o test
+3. gdb ./test
+4. run
+
+`as' is from gnu binutils (binutils-2.20.1-sol26-sparc-local.gz).
+Additional information:
+[mandelbrot.s](/uploads/edfe6f1fd01fa39ecce9ba4201454ae3/mandelbrot.s)
+
+screenshot: https://imgur.com/a/JD51DJA
+
+It could very well be a bug in my assembly code, but it is still strange that it crashes the whole system.
+
+~"kind::Bug"[in_asm.dat.xz](/uploads/6bb43ce2b7d6973da4751d236fb44e12/in_asm.dat.xz)
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1745 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1745
new file mode 100644
index 00000000..cdf76938
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1745
@@ -0,0 +1,67 @@
+qemu-system-sparc64 v8.0.2 failed to read the file system.
+Steps to reproduce:
+1. Run qemu-system-sparc64 with the following command line.
+  `qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2`
+2. The system will report a issue "Could not open option rom 'pflash0': No such file or directory"
+3. Then, enter the boot command on the boot loader.
+4. The command failed with following message.
+```
+Boot device: vdisk  File and args:
+Bad magic number in disk label
+Can't open disk label package
+
+Can't open boot device
+```
+Additional information:
+```
+$ qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2
+Could not open option rom 'pflash0': No such file or directory
+cpu Probing I/O buses
+
+
+Sun Fire T2000, No Keyboard
+Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
+OpenBoot 4.20.0, 256 MB memory available, Serial #1122867.
+[mo23723 obp4.20.0 #0]
+Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.
+
+
+
+ok boot
+Boot device: vdisk  File and args:
+Bad magic number in disk label
+Can't open disk label package
+
+Can't open boot device
+
+ok
+```
+
+It works fine with the previous qemu-system-sparc64 version.
+
+```
+$ qemu-7.2.3/build/qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2
+cpu Probing I/O buses
+
+
+Sun Fire T2000, No Keyboard
+Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
+OpenBoot 4.20.0, 256 MB memory available, Serial #1122867.
+[mo23723 obp4.20.0 #0]
+Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.
+
+
+
+ok boot
+Boot device: vdisk  File and args:
+Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54.
+FCode UFS Reader 1.12 00/07/17 15:48:16.
+Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot
+Loading: /platform/sun4v/ufsboot
+SunOS Release 5.10 Version Generic_118822-23 64-bit
+Copyright 1983-2005 Sun Microsystems, Inc.  All rights reserved.
+Use is subject to license terms.
+Hostname: unknown
+
+unknown console login:
+```
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1807 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1807
new file mode 100644
index 00000000..566a9a0b
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1807
@@ -0,0 +1,24 @@
+sparc64 always segfaults doesn't work on Ubuntu 23.04
+Description of problem:
+It segfaults when it tries to use 'printf' or 'puts' to print to the screen.
+Steps to reproduce:
+Do the following at the command line
+
+```
+$ sparc64-linux-gnu-g++ --version
+sparc64-linux-gnu-g++ (Ubuntu 12.2.0-14ubuntu2) 12.2.0
+Copyright (C) 2022 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+$ echo -e "#include <stdio.h> \n int main(void) { puts(\"Hello World\"); }" > test.cpp
+$ sparc64-linux-gnu-g++ -o test test.cpp -static
+$ qemu-sparc64-static --version
+qemu-sparc64 version 7.2.0 (Debian 1:7.2+dfsg-5ubuntu2)
+Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
+$ qemu-sparc64-static ./test
+Segmentation fault (core dumped)
+$ qemu-sparc-static ./test
+qemu-sparc-static: ./test: Invalid ELF image for this architecture
+$ qemu-sparc32plus-static ./test
+qemu-sparc32plus-static: ./test: Invalid ELF image for this architecture
+```
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1901 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1901
new file mode 100644
index 00000000..5fa434b5
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1901
@@ -0,0 +1,19 @@
+qemu-sparc64 / sparc32plus apparent wrong results from VIS fmul8x16 instruction
+Description of problem:
+Experimenting with SPARC emulation, I noticed that the results of the UltraSparc fmul8x16 instruction don't appear to match the behaviour of real silicon (aka it doesn't appear to work at all -- in the test program, the result seems to be always 0).  Other VIS instructions I tried seem to be OK (I have not tried all of them).
+
+The same problem is observed both in 64-bit (qemu-sparc64) and 32-bit (qemu-sparc32plus) applications.
+Steps to reproduce:
+1. Compile the attached test program (which exhaustively tests all possible combinations of 16-bit and 8-bit inputs) with gcc:
+   ```
+   sparc64-unknown-linux-gnu-gcc -static -Os -mcpu=ultrasparc -mvis -o test_fmul8x16 test_fmul8x16.c
+   ```
+2. Run it in qemu-sparc64:
+   ```
+   qemu-sparc64 -cpu 'TI UltraSparc II' ./test_fmul8x16
+   ```
+3. Observe almost all tests fail.
+
+   Running the exact same compiled binary on a real UltraSparc II CPU gives all pass results.
+Additional information:
+[test_fmul8x16.c](/uploads/2bf68e53652fba2ed69ac3ebb3f4b5e9/test_fmul8x16.c)
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2015 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2015
new file mode 100644
index 00000000..e1e85e0b
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2015
@@ -0,0 +1,27 @@
+qemu-system-sparc fails to boot Solaris 8 in an emulated SS-5
+Description of problem:
+Sun PROM fails to boot Solaris 8 in an emulated Sparcstation 5, with qemu exiting with a `trap 0x29` error.
+Steps to reproduce:
+1. Launch qemu with command line above
+2. Sun PROM tries to boot from the network and shows `Tiemout waiting for ARP/RARP packet` messages
+3. Interrupt network boot entering `sendkey stop-a` in qemu monitor (`compat_monitor0`)
+4. Back in Sun PROM, boot from cdrom: `boot cdrom:d`
+5. Solaris 8 starts booting
+6. qemu exits with fatal error
+
+```plaintext
+qemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled, Error state
+pc: f0041298  npc: f004129c
+%g0-7: 00000000 f02441a8 04400fc2 000001e2 00000027 f0243b88 00000000 f0244020
+%o0-7: ffff8000 00008000 00000f00 044000c1 f0258518 ffeec000 fbe3a4b8 f0041be4
+%l0-7: 04400fc1 f0041c78 f0041c7c 00000002 0000010f 00000002 0000002a fbe39f78
+%i0-7: ffff8000 00008000 00000f00 044000c2 00000000 ffeec000 fbe3a020 f0041be4
+%f00:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+%f08:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+%f16:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+%f24:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+psr: 04000fc1 (icc: ---- SPE: SP-) wim: 00000002
+fsr: 00000000 y: 00000000
+```
+Additional information:
+![Boot.png](/uploads/b83fe980b5baa1f0103fccc0abb6ec6c/Boot.png)
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2017 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2017
new file mode 100644
index 00000000..fe30b1ed
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2017
@@ -0,0 +1,17 @@
+Qemu 8.1-8.2 Sparc Now Timeout Boot Failing with Sun Bios
+Description of problem:
+Boot with original Sun bios never reaches the ok prompt.  You get a series of ongoing network boot attempts with the message "Timeout waiting for ARP/RARP package."
+
+On earlier versions of Qemu up to and including 8.0, you could use the original firmware in the combinations below on Sparc model SS-5 and SS-20 machines. 
+
+Note: Model SS-5 needs the cpu set to "TI MicroSparc II" or "TI MicroSparc IIep."  Model SS-20 needs the cpu set to "TI SuperSparc 50" or "TI SuperSparc 60."
+Steps to reproduce:
+1. Use Qemu 8.1, 8.2, or current
+2. Run above command line using original sun bios
+3. See result below
+
+![sun-obp-boot-error-timeout](/uploads/0b795b515108813528f6293b65f85c7a/sun-obp-boot-error-timeout.png)
+Additional information:
+Glad to test further and give checksums in bios files if needed.  Have real hardware for the Sparcstation 5.  Default lance card on qemu is active with usermode networking.
+
+Sun bios helps for booting some older versions of Solaris and is generally nice to have for testing.
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2059 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2059
new file mode 100644
index 00000000..76a6bf55
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2059
@@ -0,0 +1,23 @@
+Solaris 2.6.5 panic when trying to debug a binary with Sun Workshop V5n1, or V6n1 debugger
+Description of problem:
+Following [this guide](https://www.gekk.info/articles/solaris26.htm), and similarly to issue #1166, the guest panics when one tries to debug a binary with the debugger provided in [Sun Workshop V5n1](https://archive.org/details/sunworkshopforsolaris2vol5num1_704546810revb), and in [Sun Workshop v6n1](https://archive.org/details/devpro_v6n1) as well.
+The Sun Workshop is EOL, available at the archive, with free non-expiring demo licenses [made available](https://archive.org/details/suncomp-lic) by Sun before the Oracle acquisition.
+The guest was patched with the latest available patches included [in this cluster](https://archive.org/details/sun26gnu).
+The following information was collected when debugging bunzip2, but any binary panics the guest.
+```
+panic: Non-parity synchronous error: ctx=54 va=ef7cbc44 pa=e0a8c44
+syncing filesystems... 15 done
+NOTICE: zs3:ring buffer overflow
+```
+Steps to reproduce:
+1. Start the Sun Workshop (SUNWspro/bin/workshop), go to the Debugger in the menu
+2. Debug/New Program, load any binary, place a breakpoint in main or wherever
+3. Execute, guest kernel panic
+Additional information:
+This happens with the Fujitsu MB86904 specified as CPU, and without specifying a cpu, using the default for the SS-5.
+
+![sol26](/uploads/375b25f8614a49bfe634c71520890b5c/sol26.png)
+
+Explicitly setting the TI MicroSparc I and setting memory to 32M seems to start the debugger, the guest still panics, but a bit further down the line
+
+![sol262](/uploads/7a9c834f66fea1706ef92eb65ce8fe39/sol262.png)
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2141 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2141
new file mode 100644
index 00000000..b01a6796
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2141
@@ -0,0 +1,24 @@
+Output of "-cpu help" for sparc does not clearly indicate the valid input for "-cpu" option.
+Description of problem:
+The output of the "-cpu help" does not indicate clearly what the input to a "-cpu" command can be.
+Steps to reproduce:
+1. ./qemu-system-sparc -cpu help
+Additional information:
+```
+% ./qemu-system-sparc -cpu help
+Sparc  Fujitsu MB86904 IU 04000000 FPU 00080000 MMU 04000000 NWINS 8 
+Sparc  Fujitsu MB86907 IU 05000000 FPU 00080000 MMU 05000000 NWINS 8 
+Sparc  TI MicroSparc I IU 41000000 FPU 00080000 MMU 41000000 NWINS 7 -fsmuld 
+Sparc TI MicroSparc II IU 42000000 FPU 00080000 MMU 02000000 NWINS 8 
+Sparc TI MicroSparc IIep IU 42000000 FPU 00080000 MMU 04000000 NWINS 8 
+Sparc TI SuperSparc 40 IU 41000000 FPU 00000000 MMU 00000800 NWINS 8 
+Sparc TI SuperSparc 50 IU 40000000 FPU 00000000 MMU 01000800 NWINS 8 
+Sparc TI SuperSparc 51 IU 40000000 FPU 00000000 MMU 01000000 NWINS 8 
+Sparc TI SuperSparc 60 IU 40000000 FPU 00000000 MMU 01000800 NWINS 8 
+Sparc TI SuperSparc 61 IU 44000000 FPU 00000000 MMU 01000000 NWINS 8 
+Sparc TI SuperSparc II IU 40000000 FPU 00000000 MMU 08000000 NWINS 8 
+Sparc            LEON2 IU f2000000 FPU 00080000 MMU f2000000 NWINS 8 
+Sparc            LEON3 IU f3000000 FPU 00080000 MMU f3000000 NWINS 8 
+```
+It's unclear from this output whether an appropriate choice for a -cpu option is
+"Sparc  Fujitsu MB86904", "Sparc Fujitsu MB86904", "Fujitsu MB86904", "MB86904", or even something else like "FJI, MB86904"
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2143 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2143
new file mode 100644
index 00000000..7ea2ab9b
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2143
@@ -0,0 +1,38 @@
+ladr_match can cause bus error due to unaligned fetch
+Description of problem:
+On a SPARC host system, which does not support unaligned fetches, QEMU sometimes takes a bus error in ladr_match.
+Steps to reproduce:
+1. (see QEMU command line above)
+2. let the system boot
+3.
+Additional information:
+Problem is a hack in ladr_match - hw/net/pcnet.c:635 (present since 2006!):
+
+```
+Core was generated by `./qemu-system-sparc -rtc base=utc,clock=host -vga cg3 -g 1024x768x8 -machine SS'.
+Program terminated with signal SIGKILL, Killed.
+#0  0xffffffff7ec3b178 in ladr_match (size=110, buf=0xffffffff7ffee972 "33", s=0x808f2a20) at ../hw/net/pcnet.c:634
+634         if ((*(hdr->ether_dhost)&0x01) &&
+[Current thread is 632 (LWP    1        )]
+(gdb) list
+629     }
+630     
+631     static inline int ladr_match(PCNetState *s, const uint8_t *buf, int size)
+632     {
+633         struct qemu_ether_header *hdr = (void *)buf;
+634         if ((*(hdr->ether_dhost)&0x01) &&
+635             ((uint64_t *)&s->csr[8])[0] != 0LL) {
+636             uint8_t ladr[8] = {
+637                 s->csr[8] & 0xff, s->csr[8] >> 8,
+638                 s->csr[9] & 0xff, s->csr[9] >> 8,
+(gdb) print &s->csr[8]
+$1 = (uint16_t *) 0x808f4a7c
+```
+The address of s->csr[8], in this case, is on a 4-byte boundary not an 8-byte boundary, so the hack to test for 8 bytes (4 x 16-bit words) being 0 by casting the address up to a pointer to uint64_t and dereferencing it fails.
+
+The data does not seem to be allocated with a deterministic alignment, this failure does not always occur.
+
+A solution to avoid alignment errors could be to test
+```
+  (s->csr[8] | s->csr[9] | s->csr[10] | s->csr[11]) != 0
+```
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/216 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/216
new file mode 100644
index 00000000..b9c64929
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/216
@@ -0,0 +1 @@
+qemu-system-sparc64 with tribblix-sparc-0m16.iso ends with "panic - kernel: no nucleus hblk8 to allocate"
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2163 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2163
new file mode 100644
index 00000000..18c48d14
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2163
@@ -0,0 +1 @@
+Move architecture specific interruption code around SPARC CPUs from hw/sparc/ to target/sparc/
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2281 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2281
new file mode 100644
index 00000000..14006e85
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2281
@@ -0,0 +1,7 @@
+[bugfix incl.] Solaris Debuggers Panic OS with "Nonparity Synchronous Error"
+Description of problem:
+General use of a debugger (mdb, adb, gdb), such as single-stepping, causing a breakpoint to trigger, and/or simply running a program will cause a kernel panic of "Nonparity Synchronous Error" on many versions of Solaris / SunOS.
+
+This a well reported issue.
+
+#
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2319 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2319
new file mode 100644
index 00000000..0ed68638
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2319
@@ -0,0 +1,17 @@
+SPARC32-bit SDIV of negative divisor gives wrong result
+Description of problem:
+SDIV of negative divisor gives wrong result because of typo in helper_sdiv(). This is true for QEMU 9.0.0 and earlier.
+
+Place -1 in the Y register and -128 in another reg, then -120 in another register and do SDIV into a result register, instead of the proper value of 1 for the result, the incorrect value of 0 is produced.
+
+There is a typo in target/sparc/helper.c that causes the divisor to be consider unsigned, this patch fixes it:
+
+\*\*\* helper.c.ori Tue Apr 23 16:23:45 2024 --- helper.c Mon Apr 29 20:14:07 2024
+
+---
+
+\*\*\* 121,127 \*\*\*\* return (uint32_t)(b32 \< 0 ? INT32_MAX : INT32_MIN) | (-1ull \<\< 32); }
+
+! a64 /= b; r = a64; if (unlikely(r != a64)) { return (uint32_t)(a64 \< 0 ? INT32_MIN : INT32_MAX) | (-1ull \<\< 32); --- 121,127 ---- return (uint32_t)(b32 \< 0 ? INT32_MAX : INT32_MIN) | (-1ull \<\< 32); }
+
+! a64 /= b32; r = a64; if (unlikely(r != a64)) { return (uint32_t)(a64 \< 0 ? INT32_MIN : INT32_MAX) | (-1ull \<\< 32);
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2340 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2340
new file mode 100644
index 00000000..f668e661
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2340
@@ -0,0 +1,33 @@
+SPARC fp operation INVALID  trap hangs on offending instruction.
+Description of problem:
+An IEEE Invalid Operation exception is typically not enabled in programs - but if it is and an Invalid Operation occurs, a hardware TRAP should be generated which eventually becomes a SIGFPE.   However, instead, the program seems to hang on the offending instruction, never moving forward.
+
+This small C example (you'll need a C compiler) demonstrates the problem, by enabling the INValid floating-pt exception, then executing the FDTOI instruction which causes an INValid trap because the floating-pt source operand is too large for the 32-bit integer result .  The SPARC V9 manual specifies that exception should happen, so it's correct to generate the trap.   However, the program simply hangs on the FDTOI instruction instead of receiving the signal.
+
+It could be something in trap emulation that is the underlying culprit here - other possible IEEE traps (such as division-by-zero) might similarly fail?
+
+`#include <ieeefp.h>`
+
+`main()`
+
+`{` 
+
+  `double val;`
+
+  `int i;`
+
+  `fpsetmask(FP_X_INV);`
+
+  `val = 1000000000000003.0; /* Number that is too large for int */`
+
+  `printf("val is %f\n", val);`
+
+  `i = val;`
+
+  `printf("i is %d\n", i);`
+
+`}`
+Steps to reproduce:
+1. Enable IEEE iNValid operation traps in the TEM in the FSR.
+2. Generate an instruction that causes an iNValid trap
+3. Instruction hangs, no SIGFPE is generated
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2518 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2518
new file mode 100644
index 00000000..ace94a5d
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2518
@@ -0,0 +1,14 @@
+Incorrect vertical mouse leaps on qemu-system-sparc
+Description of problem:
+In openwin (i.e. X) if you turn the scrollwheel on the mouse 1 click the cursor jumps almost all of the way down the screen. Similarly, just pressing the scroll wheel (middle click) multiple times will sometimes produce similar behavior but the cursor doesn't jump as far.
+Steps to reproduce:
+- Boot Solaris and log in
+- capture the mouse by clicking on the screen
+- position the mouse cursor near the top of the screen (just so you can see how far it jumps)
+- click the scroll wheel up or down one click and observe the cursor jump downward
+Additional information:
+The issue is independent of which graphic display is used -- sdl, gtk and vnc all do the same thing. Debugging so far suggests that the problem is related to the fact that `sunmouse_event` in `escc.c` is sending a flood of duplicate events in response to the mouse scroll action. My surmise is that this is causing one byte to be dropped from the 5 byte mouse protocol expected by the Solaris kernel and that it is interpreting a sync byte as a vertical motion byte.
+
+`sunmouse_event` should not send events with only `dz` non-zero and no button changes. The Mouse Systems Corp spec for the the Sun mouse says that it never sends duplicate events (i.e. an event is produced only if there is non-zero `dx` or `dy` or there has been a button state change), and the mouse protocol has no support for `dz` events.
+
+I will propose a patch shortly to enforce this (and which has seemingly fixed the problem).
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2534 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2534
new file mode 100644
index 00000000..34b6c9b2
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2534
@@ -0,0 +1,10 @@
+Solaris cannot be power offed with system_powerdown on qemu-system-sparc
+Description of problem:
+When a `system_powerdown` is done in the QEMU Monitor, nothing happens. Also happens with `qemu-system-sparc.exe` version 9.1.0-rc3, that is, it's not fixed in newer versions. Looking at [sun4m.c](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/sparc/sun4m.c#L451) code, it registers a system_powerdown handler, but it's not working.
+Steps to reproduce:
+1. Start the machine with the command line above and wait for the complete OS initialization
+2. Open the machine monitor
+3. Do a `system_powerdown` command
+4. Nothing will happen
+Additional information:
+
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/255 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/255
new file mode 100644
index 00000000..ba1d551e
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/255
@@ -0,0 +1 @@
+Build on sparc64 fails with "undefined reference to `fdt_check_full'"
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/260 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/260
new file mode 100644
index 00000000..76d3a20c
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/260
@@ -0,0 +1 @@
+qemu-system-sparc64 -M sun4v aborts on tribblix-sparc-0m16.iso
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2618 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2618
new file mode 100644
index 00000000..ed596fe7
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2618
@@ -0,0 +1 @@
+INTEGER_OVERFLOW in sparc.c
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2620 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2620
new file mode 100644
index 00000000..e0abc4f2
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2620
@@ -0,0 +1,9 @@
+Freezes when installing NeXTSTEP 3.3 or OPENSTEP 4.2 RISC version in qemu-system-sparc
+Description of problem:
+
+Steps to reproduce:
+1.Boot from NeXTstep 3.3 or OPENSTEP 4.2 RISC ISO.  Works on real Sparcstation 5, 10, or 20
+2.Start OS install
+3.
+Additional information:
+
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2674 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2674
new file mode 100644
index 00000000..c120e8e1
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2674
@@ -0,0 +1,24 @@
+NextSTEP 3.3 for Sparc graphical glitches
+Description of problem:
+It installs/boot by using complex boot syntax and taskset -c 0 under Linux
+
+see end of https://gitlab.com/qemu-project/qemu/-/issues/2620#note_2207999780
+
+But after it installs I see  some gfx corruption
+Steps to reproduce:
+1. install NEXTSTEP 3.3 for RISC computers
+2. Boot to desktop (may need ctrl-c  to skip some services at startup)
+3. Select Info and watch for Workspace Manager info window to appear.
+4. Move this window to the right - it corrupts!
+Additional information:
+Bug also exist if I boot qemu with  -g 1024x768x24
+
+Moving window vertically (up/down) does not corrupt it
+Moving any window around corrupt it.
+
+Resizing and scrolling inside say Terminal emulators work.
+
+There was 86Box issue around one FPU instruction that looked a bit like this, 
+is there way to check fpu emulation?
+
+![ns33-qemu-903-corruption](/uploads/5230c7263bbc44acc37c4736f1d306ff/ns33-qemu-903-corruption.png)
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2723 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2723
new file mode 100644
index 00000000..cef92a2c
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2723
@@ -0,0 +1,23 @@
+qemu-system-sparc: nesqemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled
+Description of problem:
+It boots into the BIOS. I connect to the monitor on port 4444, and send "sendkey stop-a", and then in the main window (VNC session) I enter "boot disk1:d". It starts to load vmunix, and then crashes with:-
+   ```
+nesqemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled, Error state
+pc: f00053dc  npc: f00053e0
+%g0-7: 00000000 f00ee048 00000000 ffef0000 ffef9b6c f00e1000 00000000 ffefebc4
+%o0-7: 00008000 00008000 000000e0 feff8008 00001ff0 00000068 f00d7490 f0005c98 
+%l0-7: 04800fc1 f0005d14 f0005d18 00000002 0000010f 00000002 00000007 f00d6f50 
+%i0-7: 00008000 00008000 00000005 feff8008 00000000 00000000 f00d6ff8 f0005c98 
+%f00:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+%f08:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+%f16:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+%f24:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+psr: 04000fc1 (icc: ---- SPE: SP-) wim: 00000002
+fsr: 00080000 y: 00000000
+
+Aborted (core dumped)
+   ```
+Additional information:
+md5sums (both files can be found online)
+ede0690b3cb3d2abb6bddd8136912106  Solaris1_1_2.iso
+6364e9a6f5368e2ecc4e9c1d915a93ae  ss5.bin
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2736 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2736
new file mode 100644
index 00000000..4aaf2a2a
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2736
@@ -0,0 +1,10 @@
+assert_fail in vmstate_load_state (icount related)
+Description of problem:
+qemu crashes with an assert failure.
+Steps to reproduce:
+- Run qemu-system-sparc with "-i count auto -rtc clock=vm"
+ - Create a snapshot. Exit qemu.
+ - Run qemu-system-sparc without "-i count auto -rtc clock-vm"
+ - Try to load the snapshot via the monitor
+Additional information:
+[gdb.out](/uploads/d08539ce9eb6b599918513e279f13453/gdb.out)
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/293 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/293
new file mode 100644
index 00000000..d938058e
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/293
@@ -0,0 +1 @@
+Qemu SPARC64 Panics on Sun Solaris 5.8 -  BOP_ALLOC failed
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/421 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/421
new file mode 100644
index 00000000..fb961ae8
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/421
@@ -0,0 +1 @@
+Please clarify what network card is available with qemu-system-sparc64
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/499 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/499
new file mode 100644
index 00000000..a7454919
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/499
@@ -0,0 +1 @@
+booting a linux guest with qemu-system-sparc with icount enabled hangs
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/597 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/597
new file mode 100644
index 00000000..78f396b5
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/597
@@ -0,0 +1,19 @@
+sunhme sometimes causes the VM to hang forever
+Description of problem:
+When using sunhme, sometimes on receiving traffic (and doing disk IO?) it will get slower and slower until it becomes entirely unresponsive, which does not happen on the real hardware I have sitting next to me (Sun Netra T1, running the same OS+kernel, though not the same image)
+
+virtio-net-pci does not, so far, demonstrate the problem, and neither does just sending a lot of traffic out over the sunhme interface, so it appears to require receiving or some more complex interaction.
+
+It doesn't always happen immediately, it sometimes takes a couple of tries with the command, but when it does, it's gone.
+
+Output logged to console below.
+Steps to reproduce:
+1. Log into VM (rich/omgqemu)
+2. sudo apt clean;sudo apt update;
+3. If it doesn't lock up the VM, repeat step 2 a few times.
+Additional information:
+Disk image can be found [here](https://www.dropbox.com/s/0oosyf7xej44v9n/sunhme_repro_disk.tgz?dl=0) (tarred in the hope that it does something reasonable with sparseness)
+ 
+Console output can be found [here](https://www.dropbox.com/s/t1wxx41vzv8p3l6/sunhme%20sadness.txt?dl=0)
+
+Ah yes, [the initrd and vmlinux](https://www.dropbox.com/s/t7i4gs7poqaeanz/oops_boot.tgz?dl=0) would help, wouldn't they, though I imagine the ones in the VM itself would boot...
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/958 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/958
new file mode 100644
index 00000000..309b9d7c
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/958
@@ -0,0 +1,13 @@
+qemu-system-sparc crashes on floppy access
+Description of problem:
+qemu-system-sparc crashes when accessing the emulated floppy drive of the guest system.
+Steps to reproduce:
+1. wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.2/sparc/installation/bootfs/boot.fs.gz
+2. gunzip boot.fs.gz
+3. qemu-system-sparc -nographic boot.fs
+4. Select option "3) floppy"
+5. qemu-systems-sparc crashes with the messages:
+```
+    Ejecting floppy disk
+    Segmentation fault (core dumped)
+```
diff --git a/gitlab/issues_text/target_sparc/host_x86/accel_TCG/1927 b/gitlab/issues_text/target_sparc/host_x86/accel_TCG/1927
new file mode 100644
index 00000000..35bae568
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_x86/accel_TCG/1927
@@ -0,0 +1,524 @@
+SPARC64 pci-bridge kernel panic
+Description of problem:
+Kernel panics when a PCI bridge is added.
+I wanted to install a number of PCI devices, but never got enough slots from the default PCI bus (pciB, pciA is not open at all).
+So, I added a PCI bridge, but the kernel panics during boot:
+```
+OpenBIOS for Sparc64
+Cannot manage 'PCI-to-PCI bridge' PCI device type 'pci':
+ 1b36 1 (6 4 0)
+Cannot manage 'misc communication device' PCI device type '<NULL>':
+ 1af4 1003 (7 80 0)
+Cannot manage 'undefined' PCI device type '<NULL>':
+ 1af4 1005 (0 ff 0)
+Cannot manage 'undefined' PCI device type '<NULL>':
+ 1af4 1009 (0 2 0)
+Cannot manage 'SCSI bus controller' PCI device type 'scsi':
+ 1af4 1004 (1 0 0)
+Configuration device id QEMU version 1 machine id 0
+kernel phys 404000 virt 40004000 size 0x11f9290
+kernel cmdline root=/dev/sda rw log_buf_len=8M mitigations=off ktest.dir=/repos/janpieter/ktest ktest.env=/tmp/build-test-kernel-YOUlNpfwIz/env crashkernel=128M console=earlyprom0 loglevel=15 irqpoll kasan.fault=panic
+CPUs: 1 x SUNW,UltraSPARC-IIi
+UUID: 00000000-0000-0000-0000-000000000000
+Welcome to OpenBIOS v1.1 built on Mar 7 2023 22:22
+  Type 'help' for detailed information
+[sparc64] Kernel already loaded
+
+PROMLIB: Sun IEEE Boot Prom 'OBP 3.10.24 1999/01/01 01:01'
+PROMLIB: Root node compatible: sun4u
+Linux version 6.5.0-ktest-02812-g4d2faeb4fb58 (janpieter@linuxserver) (sparc64-linux-gnu-gcc (Gentoo 11.3.0 p4) 11.3.0, GNU ld (Gentoo 2.41 p2) 2.41.0) #10 SMP Mon Oct  9 15:55:57 CEST 2023
+printk: bootconsole [earlyprom0] enabled
+ARCH: SUN4U
+Ethernet address: 52:54:00:12:34:57
+MM: PAGE_OFFSET is 0xfffff80000000000 (max_phys_bits == 40)
+MM: VMALLOC [0x0000000100000000 --> 0x0000060000000000]
+MM: VMEMMAP [0x0000060000000000 --> 0x00000c0000000000]
+Kernel: Using 5 locked TLB entries for main kernel image.
+Remapping the kernel... 
+done.
+OF stdout device is: /pci@1fe,0/pci@1,1/ebus@1/su
+PROM: Built device tree with 66340 bytes of memory.
+Top of RAM: 0x7fe80000, Total RAM: 0x7fe80000
+Memory hole size: 0MB
+Allocated 16384 bytes for kernel page tables.
+Zone ranges:
+  Normal   [mem 0x0000000000000000-0x000000007fe7ffff]
+Movable zone start for each node
+Early memory node ranges
+  node   0: [mem 0x0000000000000000-0x000000007fe7ffff]
+Initmem setup node 0 [mem 0x0000000000000000-0x000000007fe7ffff]
+On node 0, zone Normal: 192 pages in unavailable ranges
+Booting Linux...
+CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus]
+CPU CAPS: [vis]
+percpu: Embedded 16 pages/cpu s93992 r8192 d28888 u4194304
+pcpu-alloc: s93992 r8192 d28888 u4194304 alloc=1*4194304
+pcpu-alloc: [0] 0 
+Kernel command line: root=/dev/sda rw log_buf_len=8M mitigations=off ktest.dir=/repos/janpieter/ktest ktest.env=/tmp/build-test-kernel-YOUlNpfwIz/env crashkernel=128M console=earlyprom0 loglevel=15 irqpoll kasan.fault=panic
+Misrouted IRQ fixup and polling support enabled
+This may significantly impact system performance
+Unknown kernel command line parameters "crashkernel=128M", will be passed to user space.
+printk: log_buf_len: 8388608 bytes
+printk: early log buf free: 128952(98%)
+Dentry cache hash table entries: 262144 (order: 8, 2097152 bytes, linear)
+Inode-cache hash table entries: 131072 (order: 7, 1048576 bytes, linear)
+Sorting __ex_table...
+Built 1 zonelists, mobility grouping on.  Total pages: 259905
+mem auto-init: stack:off, heap alloc:off, heap free:off
+Memory: 2020416K/2095616K available (6609K kernel code, 7566K rwdata, 1640K rodata, 560K init, 1980K bss, 75200K reserved, 0K cma-reserved)
+SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
+ftrace: allocating 21433 entries in 42 pages
+ftrace: allocated 42 pages with 3 groups
+trace event string verifier disabled
+rcu: Hierarchical RCU implementation.
+rcu:    RCU event tracing is enabled.
+rcu:    RCU restricting CPUs from NR_CPUS=4096 to nr_cpu_ids=1.
+        Rude variant of Tasks RCU enabled.
+rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
+rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
+NR_IRQS: 2048, nr_irqs: 2048, preallocated irqs: 1
+rcu: srcu_init: Setting srcu_struct sizes based on contention.
+clocksource: tick: mask: 0xffffffffffffffff max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns
+clocksource: mult[a000000] shift[24]
+clockevent: mult[1999999a] shift[32]
+Console: colour dummy device 80x25
+Calibrating delay using timer specific routine.. 201.35 BogoMIPS (lpj=402700)
+pid_max: default: 32768 minimum: 301
+Mount-cache hash table entries: 4096 (order: 2, 32768 bytes, linear)
+Mountpoint-cache hash table entries: 4096 (order: 2, 32768 bytes, linear)
+RCU Tasks Rude: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1.
+rcu: Hierarchical SRCU implementation.
+rcu:    Max phase no-delay instances is 1000.
+smp: Bringing up secondary CPUs ...
+smp: Brought up 1 node, 1 CPU
+devtmpfs: initialized
+device: 'platform': device_add
+bus: 'platform': registered
+bus: 'cpu': registered
+device: 'cpu': device_add
+bus: 'container': registered
+device: 'container': device_add
+Performance events: No support for PMU type 'ultra12'
+bus: 'workqueue': registered
+device: 'workqueue': device_add
+clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
+futex hash table entries: 256 (order: 1, 16384 bytes, linear)
+bus: 'virtio': registered
+NET: Registered PF_NETLINK/PF_ROUTE protocol family
+device: 'root': device_add
+bus: 'platform': add device root
+device: 'ffe1c220': device_add
+bus: 'platform': add device ffe1c220
+device: 'ffe1c348': device_add
+bus: 'platform': add device ffe1c348
+device: 'ffe26eb0': device_add
+bus: 'platform': add device ffe26eb0
+device: 'ffe1c600': device_add
+bus: 'platform': add device ffe1c600
+device: 'ffe1c6e0': device_add
+bus: 'platform': add device ffe1c6e0
+device: 'ffe1c820': device_add
+bus: 'platform': add device ffe1c820
+device: 'ffe1c948': device_add
+bus: 'platform': add device ffe1c948
+device: 'ffe26978': device_add
+bus: 'platform': add device ffe26978
+device: 'ffe289d0': device_add
+bus: 'platform': add device ffe289d0
+device: 'ffe28c20': device_add
+bus: 'platform': add device ffe28c20
+device: 'ffe2d168': device_add
+bus: 'platform': add device ffe2d168
+device: 'ffe2d780': device_add
+bus: 'platform': add device ffe2d780
+device: 'ffe2dd10': device_add
+bus: 'platform': add device ffe2dd10
+device: 'ffe2e2a8': device_add
+bus: 'platform': add device ffe2e2a8
+device: 'ffe2ba78': device_add
+bus: 'platform': add device ffe2ba78
+device: 'ffe2bbd8': device_add
+bus: 'platform': add device ffe2bbd8
+device: 'ffe2e478': device_add
+bus: 'platform': add device ffe2e478
+device: 'ffe2ef68': device_add
+bus: 'platform': add device ffe2ef68
+device: 'ffe2f8d0': device_add
+bus: 'platform': add device ffe2f8d0
+device: 'ffe302d0': device_add
+bus: 'platform': add device ffe302d0
+device: 'ffe30448': device_add
+bus: 'platform': add device ffe30448
+device: 'ffe305f0': device_add
+bus: 'platform': add device ffe305f0
+device: 'ffe30b40': device_add
+bus: 'platform': add device ffe30b40
+device: 'ffe30ea8': device_add
+bus: 'platform': add device ffe30ea8
+device: 'ffe310e8': device_add
+bus: 'platform': add device ffe310e8
+device: 'ffe31470': device_add
+bus: 'platform': add device ffe31470
+device: 'ffe31990': device_add
+bus: 'platform': add device ffe31990
+device: 'ffe31e50': device_add
+bus: 'platform': add device ffe31e50
+device: 'ffe323e8': device_add
+bus: 'platform': add device ffe323e8
+device: 'ffe32c80': device_add
+bus: 'platform': add device ffe32c80
+device: 'ffe332b8': device_add
+bus: 'platform': add device ffe332b8
+device: 'ffe33a68': device_add
+bus: 'platform': add device ffe33a68
+device: 'ffe33f58': device_add
+bus: 'platform': add device ffe33f58
+device: 'ffe34448': device_add
+bus: 'platform': add device ffe34448
+device: 'ffe34940': device_add
+bus: 'platform': add device ffe34940
+device: 'ffe34f58': device_add
+bus: 'platform': add device ffe34f58
+device class 'bdi': registering
+device class 'pci_bus': registering
+bus: 'pci': registered
+bus: 'pci_express': registered
+device class 'tty': registering
+device class 'vtconsole': registering
+device: 'vtcon0': device_add
+bus: 'serial': registered
+device class 'iommu': registering
+device class 'devlink': registering
+device class 'dma': registering
+bus: 'serial-base': registered
+bus: 'serial-base': add driver ctrl
+bus: 'serial-base': add driver port
+device: 'cpu0': device_add
+bus: 'cpu': add device cpu0
+bus: 'platform': add driver psycho
+bus: 'platform': add driver sabre
+bus: 'platform': __driver_probe_device: matched device ffe2e478 with driver sabre
+bus: 'platform': really_probe: probing driver sabre with device ffe2e478
+pci@1f,0: PCI IO [io  0x1fe02000000-0x1fe02ffffff] offset 1fe02000000
+pci@1f,0: PCI MEM [mem 0x1ff00000000-0x1ffefffffff] offset 1ff00000000
+pci@1f,0: SABRE PCI Bus Module ver[0:0]
+PCI: Scanning PBM /pci@1f,0
+device: 'pci0000:00': device_add
+device: '0000:00': device_add
+sabre ffe2e478: PCI host bridge to bus 0000:00
+pci_bus 0000:00: root bus resource [io  0x1fe02000000-0x1fe02ffffff] (bus address [0x0000-0xffffff])
+pci_bus 0000:00: root bus resource [mem 0x1ff00000000-0x1ffefffffff] (bus address [0x00000000-0xefffffff])
+pci_bus 0000:00: root bus resource [bus 00-03]
+pci 0000:00:01.1: [108e:5000] type 01 class 0x060400
+device: '0000:00:01.1': device_add
+bus: 'pci': add device 0000:00:01.1
+pci_bus 0000:01: extended config space not accessible
+device: '0000:01': device_add
+pci 0000:01:01.0: [108e:1000] type 00 class 0x068000
+pci 0000:01:01.0: reg 0x10: [mem 0x1ff20000000-0x1ff20ffffff]
+pci 0000:01:01.0: reg 0x14: [io  0x1fe02000000-0x1fe02007fff]
+device: '0000:01:01.0': device_add
+bus: 'pci': add device 0000:01:01.0
+pci 0000:01:03.0: enabling bus mastering
+pci 0000:01:03.0: [1095:0646] type 00 class 0x01018f
+pci 0000:01:03.0: reg 0x10: [io  0x1fe02008000-0x1fe02008007]
+pci 0000:01:03.0: reg 0x14: [io  0x1fe02008080-0x1fe02008083]
+pci 0000:01:03.0: reg 0x18: [io  0x1fe02008100-0x1fe02008107]
+pci 0000:01:03.0: reg 0x1c: [io  0x1fe02008180-0x1fe02008183]
+pci 0000:01:03.0: reg 0x20: [io  0x1fe02008200-0x1fe0200820f]
+device: '0000:01:03.0': device_add
+bus: 'pci': add device 0000:01:03.0
+pci 0000:00:01.0: [108e:5000] type 01 class 0x060400
+device: '0000:00:01.0': device_add
+bus: 'pci': add device 0000:00:01.0
+pci_bus 0000:02: extended config space not accessible
+device: '0000:02': device_add
+pci 0000:02:00.0: [1af4:1000] type 00 class 0x020000
+pci 0000:02:00.0: reg 0x10: [io  0x1fe02800000-0x1fe0280001f]
+pci 0000:02:00.0: reg 0x20: [mem 0x1ff60000000-0x1ff60003fff 64bit pref]
+device: '0000:02:00.0': device_add
+bus: 'pci': add device 0000:02:00.0
+pci 0000:02:01.0: [1b36:0001] type 00 class 0x060400
+pci 0000:02:01.0: reg 0x10: [mem 0x1ff60080000-0x1ff600800ff 64bit]
+device: '0000:02:01.0': device_add
+bus: 'pci': add device 0000:02:01.0
+pci 0000:02:02.0: [1af4:1004] type 00 class 0x010000
+pci 0000:02:02.0: reg 0x10: [io  0x1fe02802000-0x1fe0280203f]
+pci 0000:02:02.0: reg 0x20: [mem 0x1ff60200000-0x1ff60203fff 64bit pref]
+device: '0000:02:02.0': device_add
+bus: 'pci': add device 0000:02:02.0
+driver: 'sabre': driver_bound: bound to device 'ffe2e478'
+bus: 'platform': really_probe: bound device ffe2e478 to driver sabre
+bus: 'platform': add driver schizo
+bus: 'platform': add driver pci_sun4v
+bus: 'platform': add driver fire
+device: 'writeback': device_add
+bus: 'workqueue': add device writeback
+device class 'block': registering
+device class 'misc': registering
+iommu: Default domain type: Passthrough
+device class 'scsi_host': registering
+bus: 'scsi': registered
+device class 'scsi_device': registering
+SCSI subsystem initialized
+device class 'input': registering
+device class 'rtc': registering
+device class 'pps': registering
+pps_core: LinuxPPS API ver. 1 registered
+pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
+device class 'ptp': registering
+PTP clock support registered
+device class 'net': registering
+device: 'lo': device_add
+bus: 'platform': add driver rtc
+bus: 'platform': add driver mostek
+bus: 'platform': __driver_probe_device: matched device ffe302d0 with driver mostek
+bus: 'platform': really_probe: probing driver mostek with device ffe302d0
+/pci@1f,0/pci@1,1/ebus@1/eeprom@14,2000: Mostek regs at 0x1fe02002000
+Registering platform device 'rtc-m48t59.0'. Parent at platform
+device: 'rtc-m48t59.0': device_add
+bus: 'platform': add device rtc-m48t59.0
+driver: 'mostek': driver_bound: bound to device 'ffe302d0'
+bus: 'platform': really_probe: bound device ffe302d0 to driver mostek
+bus: 'platform': add driver bq4802
+bus: 'platform': add driver fhc
+bus: 'platform': add driver clock_board
+bus: 'platform': add driver auxio
+clocksource: Switched to clocksource tick
+device class 'mem': registering
+device: 'null': device_add
+device: 'zero': device_add
+device: 'full': device_add
+device: 'random': device_add
+device: 'urandom': device_add
+device: 'kmsg': device_add
+device: 'tty': device_add
+device: 'console': device_add
+device: 'tty0': device_add
+device class 'vc': registering
+device: 'vcs': device_add
+device: 'vcsu': device_add
+device: 'vcsa': device_add
+device: 'vcs1': device_add
+device: 'vcsu1': device_add
+device: 'vcsa1': device_add
+device: 'tty1': device_add
+device: 'tty2': device_add
+device: 'tty3': device_add
+device: 'tty4': device_add
+device: 'tty5': device_add
+device: 'tty6': device_add
+device: 'tty7': device_add
+device: 'tty8': device_add
+device: 'tty9': device_add
+device: 'tty10': device_add
+device: 'tty11': device_add
+device: 'tty12': device_add
+device: 'tty13': device_add
+device: 'tty14': device_add
+device: 'tty15': device_add
+device: 'tty16': device_add
+device: 'tty17': device_add
+device: 'tty18': device_add
+device: 'tty19': device_add
+device: 'tty20': device_add
+device: 'tty21': device_add
+device: 'tty22': device_add
+device: 'tty23': device_add
+device: 'tty24': device_add
+device: 'tty25': device_add
+device: 'tty26': device_add
+device: 'tty27': device_add
+device: 'tty28': device_add
+device: 'tty29': device_add
+device: 'tty30': device_add
+device: 'tty31': device_add
+device: 'tty32': device_add
+device: 'tty33': device_add
+device: 'tty34': device_add
+device: 'tty35': device_add
+device: 'tty36': device_add
+device: 'tty37': device_add
+device: 'tty38': device_add
+device: 'tty39': device_add
+device: 'tty40': device_add
+device: 'tty41': device_add
+device: 'tty42': device_add
+device: 'tty43': device_add
+device: 'tty44': device_add
+device: 'tty45': device_add
+device: 'tty46': device_add
+device: 'tty47': device_add
+device: 'tty48': device_add
+device: 'tty49': device_add
+device: 'tty50': device_add
+device: 'tty51': device_add
+device: 'tty52': device_add
+device: 'tty53': device_add
+device: 'tty54': device_add
+device: 'tty55': device_add
+device: 'tty56': device_add
+device: 'tty57': device_add
+device: 'tty58': device_add
+device: 'tty59': device_add
+device: 'tty60': device_add
+device: 'tty61': device_add
+device: 'tty62': device_add
+device: 'tty63': device_add
+device: 'hw_random': device_add
+NET: Registered PF_INET protocol family
+IP idents hash table entries: 32768 (order: 5, 262144 bytes, linear)
+tcp_listen_portaddr_hash hash table entries: 1024 (order: 1, 16384 bytes, linear)
+Table-perturb hash table entries: 65536 (order: 5, 262144 bytes, linear)
+TCP established hash table entries: 16384 (order: 4, 131072 bytes, linear)
+TCP bind hash table entries: 16384 (order: 6, 524288 bytes, linear)
+TCP: Hash tables configured (established 16384 bind 16384)
+UDP hash table entries: 1024 (order: 2, 32768 bytes, linear)
+UDP-Lite hash table entries: 1024 (order: 2, 32768 bytes, linear)
+NET: Registered PF_UNIX/PF_LOCAL protocol family
+PCI: CLS 0 bytes, default 64
+bus: 'platform': add driver power
+bus: 'platform': __driver_probe_device: matched device ffe30448 with driver power
+bus: 'platform': really_probe: probing driver power with device ffe30448
+power: Control reg at 1fe02007240
+driver: 'power': driver_bound: bound to device 'ffe30448'
+bus: 'platform': really_probe: bound device ffe30448 to driver power
+device: 'mdesc': device_add
+bus: 'clocksource': registered
+device: 'clocksource': device_add
+device: 'clocksource0': device_add
+bus: 'clocksource': add device clocksource0
+bus: 'platform': add driver alarmtimer
+bus: 'clockevents': registered
+device: 'clockevents': device_add
+device: 'clockevent0': device_add
+bus: 'clockevents': add device clockevent0
+bus: 'event_source': registered
+device: 'uprobe': device_add
+bus: 'event_source': add device uprobe
+device: 'kprobe': device_add
+bus: 'event_source': add device kprobe
+device: 'tracepoint': device_add
+bus: 'event_source': add device tracepoint
+device: 'software': device_add
+bus: 'event_source': add device software
+workingset: timestamp_bits=62 max_order=18 bucket_order=0
+9p: Installing v9fs 9p2000 file system support
+device class 'bsg': registering
+Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
+bus: 'platform': add driver simple-pm-bus
+bus: 'pci_express': add driver pciehp
+pciehp: pcie_port_service_register = 0
+bus: 'pci': add driver pcieport
+bus: 'pci': __driver_probe_device: matched device 0000:00:01.1 with driver pcieport
+bus: 'pci': really_probe: probing driver pcieport with device 0000:00:01.1
+pcieport 0000:00:01.1: runtime IRQ mapping not provided by arch
+pcieport: probe of 0000:00:01.1 rejects match -19
+bus: 'pci': __driver_probe_device: matched device 0000:00:01.0 with driver pcieport
+bus: 'pci': really_probe: probing driver pcieport with device 0000:00:01.0
+pcieport 0000:00:01.0: runtime IRQ mapping not provided by arch
+pcieport: probe of 0000:00:01.0 rejects match -19
+bus: 'pci': __driver_probe_device: matched device 0000:02:01.0 with driver pcieport
+bus: 'pci': really_probe: probing driver pcieport with device 0000:02:01.0
+pcieport 0000:02:01.0: runtime IRQ mapping not provided by arch
+pcieport: probe of 0000:02:01.0 rejects match -19
+bus: 'pci': add driver shpchp
+bus: 'pci': __driver_probe_device: matched device 0000:00:01.1 with driver shpchp
+bus: 'pci': really_probe: probing driver shpchp with device 0000:00:01.1
+shpchp 0000:00:01.1: runtime IRQ mapping not provided by arch
+shpchp: probe of 0000:00:01.1 rejects match -19
+bus: 'pci': __driver_probe_device: matched device 0000:00:01.0 with driver shpchp
+bus: 'pci': really_probe: probing driver shpchp with device 0000:00:01.0
+shpchp 0000:00:01.0: runtime IRQ mapping not provided by arch
+shpchp: probe of 0000:00:01.0 rejects match -19
+bus: 'pci': __driver_probe_device: matched device 0000:02:01.0 with driver shpchp
+bus: 'pci': really_probe: probing driver shpchp with device 0000:02:01.0
+shpchp 0000:02:01.0: runtime IRQ mapping not provided by arch
+shpchp 0000:02:01.0: HPC vendor_id 1b36 device_id 1 ss_vid 0 ss_did 0
+shpchp 0000:02:01.0: Can't get msi for the hotplug controller
+shpchp 0000:02:01.0: Use INTx for the hotplug controller
+Unable to handle kernel NULL pointer dereference
+tsk->{mm,active_mm}->context = 0000000000000000
+tsk->{mm,active_mm}->pgd = fffff80000402000
+              \|/ ____ \|/
+              "@'/ .. \`@"
+              /_| \__/ |_\
+                 \__U_/
+swapper/0(1): Oops [#1]
+CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-ktest-02812-g4d2faeb4fb58 #10
+TSTATE: 0000004411001601 TPC: 00000000007e5f98 TNPC: 00000000007e5fbc Y: 00000000    Not tainted
+TPC: <shpc_init+0x638/0x900>
+g0: fffff8000228ca18 g1: 0000000000000000 g2: 0000000000001f00 g3: 0000000000000000
+g4: fffff80002148000 g5: fffff8007e410000 g6: fffff800021a4000 g7: 0000000000000001
+o0: 0000000000000000 o1: 00000000007e4da0 o2: 0000000000000000 o3: 0000000000000000
+o4: 0000000000b9b950 o5: 0000000000000000 sp: fffff800021a6b01 ret_pc: 00000000007e607c
+RPC: <shpc_init+0x71c/0x900>
+l0: 00000000015ef800 l1: 00000000ff1f7fff l2: 0000000000b78440 l3: 0000000000b9c6b0
+l4: 000000000000001f l5: 000000007f000000 l6: fffff80002553280 l7: fffff800022f7680
+i0: fffff8000254ea00 i1: fffff800021f6000 i2: 00000000015ef800 i3: 0000000000000000
+i4: 0000000000b9b800 i5: 0000000000000000 i6: fffff800021a6bc1 i7: 00000000007e29f0
+I7: <shpc_probe+0x70/0x3a0>
+Call Trace:
+[<00000000007e29f0>] shpc_probe+0x70/0x3a0
+[<00000000007c5bf8>] pci_device_probe+0x78/0x100
+[<0000000000a6b70c>] really_probe+0x16c/0x41c
+[<0000000000a6ba68>] __driver_probe_device.part.0+0xac/0xc0
+[<0000000000846b28>] driver_probe_device+0x88/0x120
+[<0000000000846d64>] __driver_attach+0x84/0x1c0
+[<0000000000844bb4>] bus_for_each_dev+0x54/0xc0
+[<000000000084659c>] driver_attach+0x1c/0x40
+[<0000000000845e24>] bus_add_driver+0xe4/0x1e0
+[<0000000000847cfc>] driver_register+0x7c/0x140
+[<00000000007c5028>] __pci_register_driver+0x48/0x60
+[<0000000001398e64>] shpcd_init+0x18/0x68
+[<0000000000427c90>] do_one_initcall+0x30/0x240
+[<000000000137eea4>] kernel_init_freeable+0x1d4/0x22c
+[<0000000000a6d824>] kernel_init+0x1c/0x138
+[<00000000004060c8>] ret_from_fork+0x1c/0x2c
+Disabling lock debugging due to kernel taint
+Caller[00000000007e29f0]: shpc_probe+0x70/0x3a0
+Caller[00000000007c5bf8]: pci_device_probe+0x78/0x100
+Caller[0000000000a6b70c]: really_probe+0x16c/0x41c
+Caller[0000000000a6ba68]: __driver_probe_device.part.0+0xac/0xc0
+Caller[0000000000846b28]: driver_probe_device+0x88/0x120
+Caller[0000000000846d64]: __driver_attach+0x84/0x1c0
+Caller[0000000000844bb4]: bus_for_each_dev+0x54/0xc0
+Caller[000000000084659c]: driver_attach+0x1c/0x40
+Caller[0000000000845e24]: bus_add_driver+0xe4/0x1e0
+Caller[0000000000847cfc]: driver_register+0x7c/0x140
+Caller[00000000007c5028]: __pci_register_driver+0x48/0x60
+Caller[0000000001398e64]: shpcd_init+0x18/0x68
+Caller[0000000000427c90]: do_one_initcall+0x30/0x240
+Caller[000000000137eea4]: kernel_init_freeable+0x1d4/0x22c
+Caller[0000000000a6d824]: kernel_init+0x1c/0x138
+Caller[00000000004060c8]: ret_from_fork+0x1c/0x2c
+Caller[0000000000000000]: 0x0
+Instruction DUMP:
+ c20c2219 
+ 80a06000 
+ 0240000a 
+<d628e0da>
+ d25e2048 
+ 15002e71 
+ 11002de1 
+ 960ae0ff 
+ 9412a3a0 
+
+Kernel panic - not syncing: Fatal exception
+Press Stop-A (L1-A) from sun keyboard or send break
+twice on console to return to the boot prom
+---[ end Kernel panic - not syncing: Fatal exception ]---
+qemu-system-sparc64: terminating on signal 2
+
+```
+Steps to reproduce:
+1. compile a sparc64 kernel (config file included)
+2. add a config where a pci-bridge is installed in slot 1,2 or 3 (virtio-slot-pci takes the first slot)
+3. create a empty file using fallocate
+Additional information:
+attached: tar.xz file:
+- linux arch/sparc64/boot/image (uncompressed) as vmlinuz
+- linux .config file as config
+- linux modules in the lib directory
+
+[sparckernelinfo.tar.xz](/uploads/55f1475c5c811cd56d1374386e8f9e6e/sparckernelinfo.tar.xz)
diff --git a/gitlab/issues_text/target_sparc/host_x86/accel_TCG/2133 b/gitlab/issues_text/target_sparc/host_x86/accel_TCG/2133
new file mode 100644
index 00000000..f0733823
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_x86/accel_TCG/2133
@@ -0,0 +1,55 @@
+Debian sparc64 works on hardware, segfaults in qemu
+Description of problem:
+
+Steps to reproduce:
+1. Start the installer normally (boot cdrom), use guided all disk partition, change ext4 to btrfs for /
+2. Installer always segfaults at the same place while installing base system step:
+
+```
+Jan 28 09:17:48 debootstrap: Setting up mawk (1.3.4.20200120-3.1) ...
+Jan 28 09:17:49 debootstrap: update-alternatives:
+Jan 28 09:17:49 debootstrap: using /usr/bin/mawk to provide /usr/bin/awk (awk) i
+n auto mode
+Jan 28 09:17:49 debootstrap:
+Jan 28 09:17:54 debootstrap: Selecting previously unselected package debconf.
+Jan 28 09:17:54 debootstrap: (Reading database ... 1459 files and directories cu
+rrently installed.)
+Jan 28 09:17:54 debootstrap: Preparing to unpack .../debconf_1.5.82_all.deb ...
+Jan 28 09:17:54 debootstrap: Unpacking debconf (1.5.82) ...
+Jan 28 09:17:55 kernel: [ 2994.426867] dpkg-deb[12709]: segfault at ffffffffffff
+ffff ip fffff80100a1c3ec (rpc 0000000000000030) sp fffff80102402041 error 1 in l
+iblzma.so.5.4.1[fffff80100a00000+2a000]
+Jan 28 09:17:55 debootstrap: dpkg-deb: error: <decompress> subprocess was killed
+ by signal (Segmentation fault)
+Jan 28 09:17:56 debootstrap: dpkg: error processing archive /var/cache/apt/archi
+ves/debconf_1.5.82_all.deb (--install):
+Jan 28 09:17:56 debootstrap:  dpkg-deb --fsys-tarfile subprocess returned error
+exit status 2
+Jan 28 09:17:57 debootstrap: Errors were encountered while processing:
+Jan 28 09:17:57 debootstrap:  /var/cache/apt/archives/debconf_1.5.82_all.deb
+Jan 28 09:18:10 base-installer: error: exiting on error base-installer/debootstr
+
+
+cd /target/var/cache/apt/archives
+# ar x debconf_1.5.82_all.deb
+/target/var/cache/apt/archives # unxz data.tar.xz
+/target/var/cache/apt/archives # unxz control.tar.xz
+```
+another try, to ext2 fs:
+```
+Jan 28 10:31:16 debootstrap: Preparing to unpack .../dpkg_1.21.21_sparc64.deb ..
+.
+Jan 28 10:31:16 debootstrap: Unpacking dpkg (1.21.21) over (1.21.21) ...
+Jan 28 10:31:23 kernel: [ 7402.528016] dpkg-deb[20720]: segfault at 7240015 ip f
+ffff8010091def4 (rpc 000000006e17c498) sp fffff80103124041 error 1 in liblzma.so
+.5.4.1[fffff80100900000+2a000]
+Jan 28 10:31:23 debootstrap: dpkg-deb: error: <decompress> subprocess was killed
+ by signal (Segmentation fault)
+Jan 28 10:31:24 debootstrap: dpkg: error processing archive /var/cache/apt/archi
+ves/dpkg_1.21.21_sparc64.deb (--install):
+Jan 28 10:31:24 debootstrap:  cannot copy extracted data for './usr/share/doc/dp
+kg/changelog.gz' to '/usr/share/doc/dpkg/changelog.gz.dpkg-new': unexpected end
+of file or stream
+```
+Additional information:
+All times i've tried under Ubuntu qemu or latest build for Windows it segfaults unpacking package, and i believe it's a misleading error message, since very same ISO installs normally on Sun Fire T1000 machine (sun4v). I've tried also booting FreeBSD-12.4-RELEASE-sparc64-disc1.iso which dies shortly after booting the kernel, but i am more interested in Debian, since it was verified to work on a real hardware. BTW i was able to unpack specified file with "ar x" within installer.
diff --git a/gitlab/issues_text/target_sparc/host_x86/accel_missing/1942 b/gitlab/issues_text/target_sparc/host_x86/accel_missing/1942
new file mode 100644
index 00000000..d6979724
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_x86/accel_missing/1942
@@ -0,0 +1,9 @@
+GCC segfault (ICE) while building in qemu-user sparc64
+Steps to reproduce:
+1. Follow Qemu-user [documentation](https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Compiling_with_qemu_user_chroot) for Sparc64
+2. Attempt to build libpaper: `emerge -v app-text/libpaper-2.1.0:0/2`
+
+Resulting compilation will fail with an internal compilation error.
+Additional information:
+This can be tested by trying to [compile](/uploads/ba4585ea75fa157a34bf8f3ffb64bded/H1NM.i) with `gcc -mcpu=ultrasparc -O2 -c` instead of building the entire libpaper package.
+Here is the [output.](/uploads/30a154eb602caa5a8b1bd82a6271d6d8/output.txt)
diff --git a/gitlab/issues_text/target_tricore/host_missing/accel_TCG/1363 b/gitlab/issues_text/target_tricore/host_missing/accel_TCG/1363
new file mode 100644
index 00000000..30de1177
--- /dev/null
+++ b/gitlab/issues_text/target_tricore/host_missing/accel_TCG/1363
@@ -0,0 +1,3 @@
+TriCore: writing to registers is not working (as it's supposed to)
+Description of problem:
+Reading the tricore register list from QEMU works just fine. However, writing this registers is not working as expected. It looks like the bug is on QEMU's side, since third party gdb client faces the same issues.
diff --git a/gitlab/issues_text/target_tricore/host_missing/accel_missing/1452 b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1452
new file mode 100644
index 00000000..61dad225
--- /dev/null
+++ b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1452
@@ -0,0 +1 @@
+Tricore: support for shuffle and syscall instruction
diff --git a/gitlab/issues_text/target_tricore/host_missing/accel_missing/1453 b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1453
new file mode 100644
index 00000000..fad6becb
--- /dev/null
+++ b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1453
@@ -0,0 +1 @@
+Tricore: different definitions of pcxi register field
diff --git a/gitlab/issues_text/target_tricore/host_missing/accel_missing/1523 b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1523
new file mode 100644
index 00000000..844dc24c
--- /dev/null
+++ b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1523
@@ -0,0 +1 @@
+Tricore: no interrupts emulation
diff --git a/gitlab/issues_text/target_tricore/host_missing/accel_missing/1667 b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1667
new file mode 100644
index 00000000..2bc8ba5e
--- /dev/null
+++ b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1667
@@ -0,0 +1 @@
+Tricore: missing a few TC1.6.2 instruction set
diff --git a/gitlab/issues_text/target_tricore/host_missing/accel_missing/1698 b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1698
new file mode 100644
index 00000000..52d0fb1b
--- /dev/null
+++ b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1698
@@ -0,0 +1 @@
+Global-buffer-overflow in QEMU TirCore TCG
diff --git a/gitlab/issues_text/target_tricore/host_missing/accel_missing/1699 b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1699
new file mode 100644
index 00000000..e9d3ce63
--- /dev/null
+++ b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1699
@@ -0,0 +1 @@
+Tricore: Call instruction wrong
diff --git a/gitlab/issues_text/target_tricore/host_missing/accel_missing/1700 b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1700
new file mode 100644
index 00000000..c151dd65
--- /dev/null
+++ b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1700
@@ -0,0 +1 @@
+TriCore:  helper_ret() is not correctly restoring PSW
diff --git a/gitlab/issues_text/target_tricore/host_missing/accel_missing/1774 b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1774
new file mode 100644
index 00000000..aeda4b96
--- /dev/null
+++ b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1774
@@ -0,0 +1,23 @@
+8.1-rc0 failure to build with capstone 5.0
+Description of problem:
+Use >=capstone-5.0 dependency, try to build qemu, get this error:
+```
+/opt/homebrew/Cellar/capstone/5.0/include/capstone/tricore.h:561:3: error:
+redefinition of 'tricore_feature' as different kind of symbol
+} tricore_feature;
+  ^
+../target/tricore/cpu.h:261:19: note: previous definition is here
+static inline int tricore_feature(CPUTriCoreState *env, int feature)
+                  ^
+1 error generated.
+```
+
+The fix is trivial and it was already mentioned in the mailing list but wasn't fixed for rc0, so I figured it might have been forgotten about.
+
+https://lore.kernel.org/qemu-devel/CA+PgxXVxVKpT0SZ3N+Fc1YvXCiwkkbqm0FmLKqLTbgcDpYCNgg@mail.gmail.com/
+
+If you meet any other problem with capstone (e.g. some regression), please don't hesitate to report it mainstream.
+
+There are plans to make a new patch release soon with fixes for some most annoying bugs since the 5.0 release: https://github.com/capstone-engine/capstone/issues/2081
+
+https://github.com/capstone-engine/capstone/releases
diff --git a/gitlab/issues_text/target_tricore/host_missing/accel_missing/1847 b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1847
new file mode 100644
index 00000000..5b90c532
--- /dev/null
+++ b/gitlab/issues_text/target_tricore/host_missing/accel_missing/1847
@@ -0,0 +1 @@
+TriCore missing ftoq31, ftoq31z, and q31tof instructions
diff --git a/gitlab/issues_text/target_tricore/host_missing/accel_missing/596 b/gitlab/issues_text/target_tricore/host_missing/accel_missing/596
new file mode 100644
index 00000000..c9338e13
--- /dev/null
+++ b/gitlab/issues_text/target_tricore/host_missing/accel_missing/596
@@ -0,0 +1 @@
+"./ylwrap: -d: not found" error in tricore-debian-cross-container job
diff --git a/gitlab/issues_text/target_tricore/host_missing/accel_missing/652 b/gitlab/issues_text/target_tricore/host_missing/accel_missing/652
new file mode 100644
index 00000000..1e319e98
--- /dev/null
+++ b/gitlab/issues_text/target_tricore/host_missing/accel_missing/652
@@ -0,0 +1,28 @@
+Tricore: wrong implementation of OPC1_16_SRO_LD_H in target/tricore/translate.c
+Description of problem:
+The translation of the 16bit opcode LD.HD[15], A[b], off4 (SRO) is not done properly.
+Page 210 of
+https://www.infineon.com/dgdl/Infineon-TC2xx_Architecture_vol2-UM-v01_00-EN.pdf?fileId=5546d46269bda8df0169ca1bf33124a8
+as 
+D[15] = sign_ext(M(A[b] + zero_ext(2 * off4), half-word));
+1) Implemented in target/tricore/translate.c as
+    case OPC1_16_SRO_LD_H:
+        gen_offset_ld(ctx, cpu_gpr_d[15], cpu_gpr_a[r2], address, MO_LESW);
+        break;
+
+2) Should be 
+    case OPC1_16_SRO_LD_H:
+        gen_offset_ld(ctx, cpu_gpr_d[15], cpu_gpr_a[r2], address * 2, MO_LESW);
+        break;
+
+Detected: 
+testsuite gcc9.1.0 delta analysis of Infineon Instruction Set Simulator vs. qemu-system-tricore
+fix from 2) is successfull
+
+Confidence Level for bugfix high.
+Is according to spec. and in line with reference Instruction Set Simulator from Infineon.
+
+Motivation
+Reexecution of gcc/g++/libstdc++ testsuites with qemu
+
+I honor the implementation work which was done by bkoppelmann, vo_lumit@gmx.de
diff --git a/gitlab/issues_text/target_tricore/host_missing/accel_missing/653 b/gitlab/issues_text/target_tricore/host_missing/accel_missing/653
new file mode 100644
index 00000000..41b4a798
--- /dev/null
+++ b/gitlab/issues_text/target_tricore/host_missing/accel_missing/653
@@ -0,0 +1,59 @@
+Tricore: wrong implementation of OPC2_32_RCRW_IMASK and OPC2_32_RCRW_INSERT in target/tricore/translate.c
+Description of problem:
+The translation of the instructions is not done properly.
+please check
+https://www.infineon.com/dgdl/Infineon-TC2xx_Architecture_vol2-UM-v01_00-EN.pdf?fileId=5546d46269bda8df0169ca1bf33124a8
+
+1) Implemented in target/tricore/translate.c as
+    switch (op2) {
+    case OPC2_32_RCRW_IMASK:
+        tcg_gen_andi_tl(temp, cpu_gpr_d[r4], 0x1f);
+        tcg_gen_movi_tl(temp2, (1 << width) - 1);
+        tcg_gen_shl_tl(cpu_gpr_d[r3 + 1], temp2, temp);
+        tcg_gen_movi_tl(temp2, const4);
+        tcg_gen_shl_tl(cpu_gpr_d[r3], temp2, temp);
+        break;
+    case OPC2_32_RCRW_INSERT:
+        temp3 = tcg_temp_new();
+
+        tcg_gen_movi_tl(temp, width);
+        tcg_gen_movi_tl(temp2, const4);
+        tcg_gen_andi_tl(temp3, cpu_gpr_d[r4], 0x1f);
+        gen_insert(cpu_gpr_d[r3], cpu_gpr_d[r1], temp2, temp, temp3);
+
+        tcg_temp_free(temp3);
+        break;
+
+2) Should be 
+    case OPC2_32_RCRW_IMASK:
+        tcg_gen_andi_tl(temp, cpu_gpr_d[r3], 0x1f);
+        tcg_gen_movi_tl(temp2, (1 << width) - 1);
+        tcg_gen_shl_tl(cpu_gpr_d[r4 + 1], temp2, temp);
+        tcg_gen_movi_tl(temp2, const4);
+        tcg_gen_shl_tl(cpu_gpr_d[r4], temp2, temp);
+        break;
+    case OPC2_32_RCRW_INSERT:
+        temp3 = tcg_temp_new();
+
+        tcg_gen_movi_tl(temp, width);
+        tcg_gen_movi_tl(temp2, const4);
+        tcg_gen_andi_tl(temp3, cpu_gpr_d[r3], 0x1f);
+        gen_insert(cpu_gpr_d[r4], cpu_gpr_d[r1], temp2, temp, temp3);
+
+        tcg_temp_free(temp3);
+        break;
+From encoding point of view d4 is target and not source.
+Assumption is here misleading swap of d3 and d4.
+
+
+Detected: 
+testsuite libstdc++ 9.1.0 delta analysis of Infineon Instruction Set Simulator vs. qemu-system-tricore
+fix from 2) is successfull
+
+Confidence Level for bugfix high.
+Is according to spec. and in line with reference Instruction Set Simulator from Infineon.
+
+Motivation
+Reexecution of gcc/g++/libstdc++ testsuites with qemu
+
+I honor the implementation work which was done by bkoppelmann, vo_lumit@gmx.de
diff --git a/gitlab/issues_text/target_xtensa/host_missing/accel_missing/565 b/gitlab/issues_text/target_xtensa/host_missing/accel_missing/565
new file mode 100644
index 00000000..60198d24
--- /dev/null
+++ b/gitlab/issues_text/target_xtensa/host_missing/accel_missing/565
@@ -0,0 +1 @@
+maybe-uninitialized warning in Xtensa flush_window_regs()